teacup. [ 掲示板 ] [ 掲示板作成 ] [ 有料掲示板 ] [ ブログ ]

 投稿者
  題名
  内容 入力補助画像・ファイル<IMG>タグが利用可能です。(詳細)
    
 URL
[ ケータイで使う ] [ BBSティッカー ] [ 書込み通知 ] [ 検索 ]

スレッド一覧

  1. 足あと帳(0)
スレッド一覧(全1)  他のスレッドを探す 

*掲示板をお持ちでない方へ、まずは掲示板を作成しましょう。無料掲示板作成


MaskにHDR

 投稿者:  投稿日:2014年10月 2日(木)00時21分38秒
返信・引用
  M74の再処理中です。
渦状腕の間には強調したい構造が無いのに輝度は高いので、Deconvolutionやマルチバンドシャープ、ノイズリダクション(反転で使う)の際の輝度マスクが上手く作れなくて困っていましたが、マスクにHDRを施すことを思いついて試してみようと思います。
ただ、HDRのScaling Functionの意味が解らないんですよね。試行錯誤しかないでしょうか。

http://homepage3.nifty.com/galaxies/index.htm

 
 

PIのドリズル

 投稿者:  投稿日:2014年 6月 4日(水)23時28分45秒
返信・引用
  しばらく投稿が無いと掲示板が無くなってしまうかと心配になったので、様子見に投稿しておきます。
tantanさんから教えて頂いた新装備のドリズル、ぜひ試してみたいと思っております。(秋まで撮像できそうに無いですが・・・)

http://homepage3.nifty.com/galaxies/index.htm

 

PixInsightk小ネタ

 投稿者:星羊翁  投稿日:2014年 2月11日(火)11時14分4秒
返信・引用
  Process Explorerの<Favorites>、どうすれば内容を編集できるの?といつも疑問に思っていたのですが、偶然にもやっと発見しました。
Processにマウスを合わせ右クリックするとメニューが表示され、そこにAdd to Favorites、Remove from Favoritesがありました。
何をいまさらという声も聞こえてきそうですが、見つけた喜びを含めてアップします。
ただ、並びはアルファベット順ですね。並び順を変える方法あるんでしょうかね。
 

Re: バッチ処理

 投稿者:  投稿日:2013年10月31日(木)11時39分4秒
返信・引用
  > No.72[元記事へ]

> 自分ではやったことがないのですが、ブルーミングの処理は基本的にはCCDを回転して撮影した画像を使って消すのですよね?CCDメーカーの中にはブルーミングを消去するソフトを付属している所もあるようですが可能なんですか?ブルーミングって飽和した部分のように見えますが、星のデータは残っているのですか?

私は単純にCCDOPSのツールを使っていますが、ブルーミング痕の下の星のデータは残っていないと思います。
ブルーミングや白線除去は垂直方向の線だけなので、もしかしたら解る方には簡単に解決できるかもしれませんね。
 

バッチ処理

 投稿者:tantan  投稿日:2013年10月31日(木)07時24分56秒
返信・引用
  scriptをいじってみてBatchPreProcessingが動く仕組みが分かりました。私はこのscriptを非常に重宝していますが、HDDの領域を使いすぎますね。
自分ではやったことがないのですが、ブルーミングの処理は基本的にはCCDを回転して撮影した画像を使って消すのですよね?CCDメーカーの中にはブルーミングを消去するソフトを付属している所もあるようですが可能なんですか?ブルーミングって飽和した部分のように見えますが、星のデータは残っているのですか?
 

Re: PI Script

 投稿者:  投稿日:2013年10月31日(木)01時41分47秒
返信・引用
  > No.70[元記事へ]

tantanさん、お久しぶりです!
元データを全部放り込めばコンポジット画像が吐き出されてくるようなScript、凄~く欲しいのですが、目下の撮像データはブルーミング除去やカラム欠損(?)の黒筋除去やら煩雑な初期処理があって、けっきょく試行錯誤の手作業をしております。

ところで皆さん、このBBSを時々は覗かれているのでしょうかね、、、私の所には投稿されれば通知が来ますが。
 

PI Script

 投稿者:tantan  投稿日:2013年10月30日(水)13時11分28秒
返信・引用
  久しぶりにコメントします。この所PixInsightのScriptを組み立てていました。
試行錯誤なので、正しいのかどうかは分かりませんが、多分重要なポイントを2つ程上げておきます。

まず、画面上のアクティブ画像から、新しいコピー画像を定義して、それを回転するという部分です。
画像に手を加えるときには、beginProcess, endProcessで括る必要があります。

var SourceView = ImageWindow.activeWindow.mainView;

var Rotate= new ImageWindow( SourceView.image.width,
                             SourceView.image.height,
                             SourceView.image.numberOfChannels,
                             SourceView.window.bitsPerSample,
                             SourceView.window.isFloatSample,
                             SourceView.image.colorSpace != ColorSpace_Gray,
                             "Rotate" );

            Rotate.mainView.beginProcess(UndoFlag_NoSwapFile);
            Rotate.mainView.image.assign( SourceView.image );
            Rotate.mainView.image.rotate90cw();
            Rotate.show();
            Rotate.mainView.endProcess();

もう1つはPIに組み込まれたProcessを呼び出す方法です。
プロパティはデフォールトなら定義する必要は無いので、変更したい部分のみに値を入れます。

var pm = new PixelMath;
with ( pm )
{
   expression = "max("+ "imgFinal" + "," + "Rotate" + ")";
   expression1 = "";



   newImageAlpha = false;
   newImageColorSpace = SameAsTarget;
   newImageSampleFormat = SameAsTarget;
}

    imgFinal.mainView.beginProcess(UndoFlag_NoSwapFile);
    pm.executeOn(imgFinal.mainView);
    imgFinal.show();
    imgFinal.mainView.endProcess();

とりあえず、この2つを発見した事が第1歩でした。

http://yoshi8472.my.coocan.jp/index.html

 

NGC2976

 投稿者:  投稿日:2013年 8月17日(土)00時18分20秒
返信・引用
  掲示板の賑わせに投稿しますね。

空の奥行き感、銀河の解像感、星の色等もう少し何とかならないかと幾度も処理し直しておりましたが、レンジを狭めると空が薄っぺらくなってしまったり、いつの間にか星の輝度が落ちてしまっていたり、色浮きが生じてしまったり、ホントに上手く行きません。目下の所これが精一杯でした。ノイズリダクションは弱めです。
 

STFの罠

 投稿者:  投稿日:2013年 8月 1日(木)06時36分47秒
返信・引用 編集済
  落ちるのは私だけかもしれませんが、念のため御報告を上げておきますね。

STFの自動調整は、画像の潜在能力と言いますか、写っているもの全てを顕在させてくれるので信頼しています。ここに顕れたものを出来るだけ失わないような処理を心がけています。
ただ、Integrationで重ならなかった周辺部分を残したまま使うと当然ながら結果が変わってしまい、それで大失敗を致しました。添付のNGC2976画像、左はCropしなかったもの、右はCropしたものです。
ステライメージのDDPも同様ですが、このままHTに持ち込んでしまうと、後の処理では一度失われた輝きを取り戻すことが難しくなります。
 

Re: 白い星

 投稿者:  投稿日:2013年 7月21日(日)17時59分40秒
返信・引用
  > No.63[元記事へ]

はい、私も開発の方のこの回答を読んで「小気味の良い考え方だな」とファンになった一人です。

「白い星」と書きましたのは、例えばG2型星を基準とするというような科学的な意図では無くて、ただ絵的にサッと決まるとラクと思っただけなんです。
 

白い星

 投稿者:tantan  投稿日:2013年 7月21日(日)13時40分48秒
返信・引用
  訳すの面倒なので、そのままですみません。
白い星を使わない理由はここに書いてあります。アマチュア天体写真家は別に学術的な写真ではないので、こういう解説にグッときてPIファンになるのではないでしょうか?私もその1人です。

Why not rely on any particular spectral type for color calibration? Because we can't find any particularly good reason to use the apparent color of a star as a white reference for deep sky images. A G2V star is an ideal white reference for a daylight scene, in case we want to take the human vision system as the underlying definition of "true color". For example, a G2V star is a plausible white reference for a planetary image. The reason is that all objects in the solar system are either reflecting or radiating the sun's light. So if your image sensor has linear response to incident light and you apply a linear transformation to the image such that a G2V star is rendered as pure white, then the planetary scene will be rendered in true daylight color, or just as it would be seen directly by a human.

In a deep sky image however, no object, in general, is reflecting light from a G2V star. Deep sky images are definitely not daylight scenes, and most of the light that we capture and represent in them is far beyond the capabilities of the human vision system. We think that using a G2V star as a white reference for a deep sky image is a too anthropocentric view. We prefer to follow a completely different path, starting from the idea that no color can be taken as "real" in the deep sky, on a documentary basis. Instead of pursuing the illusion of real color, we try to apply a neutral criterion that pursues a very different goal: to represent a deep sky scene in an unbiased way regarding color, where no particular spectral type or color is being favored over others. In our opinion, this is the best way to provide a plausible color calibration criterion for deep sky astrophotography, both conceptually and physically.

http://yoshi8472.my.coocan.jp/PixInsight/canp13/LRGB.htm

 

Re: あ、

 投稿者:  投稿日:2013年 7月21日(日)11時58分30秒
返信・引用
  > No.61[元記事へ]

tantanさん、ありがとうございます。

> それで、SI7で処理してみた画像を私のHPに載せてあります。

拝見しました。http://yoshi8472.my.coocan.jp/digital.htm ですね。十分自然な色彩に上がっているように見えます。
SI7のオートストレッチのバックグラウンド指定は「できるだけ星や星雲の無い領域」それが難しい場合は「星雲や天の川が写っていない領域」または「画像全体を選択してもほぼ問題ありません」との事ですね。便宜的にヒストグラムの中央を採用する(だったでしょうか)という方法は、柔軟で好ましい対応と思いますが、この方法で赤だけの散光星雲も上手く行くのか?自分で撮った経験が無いので伺いたく思った次第です。

(個人的には、画面中の白い星を自動的に星図から検出して、それに合わせてカラーバランスを取ってくれるようなScriptがあったらいいなぁと思います)
 

あ、

 投稿者:tantan  投稿日:2013年 7月21日(日)08時46分33秒
返信・引用
  忘れてました・・・
それで、SI7で処理してみた画像を私のHPに載せてあります。バックグラウンドはPIの設定と同じ暗黒帯にしてみました。PIではバックグラウンドについては明確に出来るだけ綺麗なダークグレー記載されていますが、SI7では画面全体でも良いのですか?

http://yoshi8472.my.coocan.jp/PixInsight/canp13/LRGB.htm

 

Re: カラーキャリブレーション

 投稿者:  投稿日:2013年 7月21日(日)06時38分0秒
返信・引用
  > PIで全画面をReferenceにする場合かなりSI7と似ていますし

再度申し訳ありません。この場合のSI7のバックウラウンド指定は全画面でしょうか?(確かにマニュアルには「画像全体を指定してもほぼ問題ありません」の記述がありましたが)画面全体が赤い星雲の場合のWBの考え方が未だ全然理解出来ておりません。
 

カラーキャリブレーション

 投稿者:tantan  投稿日:2013年 7月20日(土)08時45分48秒
返信・引用
  Kさんが紹介してくれたフォーラムに書いてあったPIのカラーキャリブレーションの考え方です。
撮影時のR',G', B'からR,G,Bを求める作業がカラーキャリブレーションと解説されています。bがRGB各チャンネルのバイアスでヒストグラムのピークのズレとして現れる部分で、BNではこれをそろえるそうです。その後各チャンネルのkを見つける作業がCCだそうです。
SI7のオートストレッチは上坂さんの解説によると、正にこのkをRGB各ヒストグラムの標準偏差から算出しているようですね。一番大きい広がりのヒストグラムに合わせるオートストレッチはどんな対象でも破綻する事は無い賢い方法だと思います。
PIで全画面をReferenceにする場合かなりSI7と似ていますし、PIではWhiteReferenceを使う場合フィルター係数は無いのである意味1:1:1と同じ事だと思います。肝心のkの決め方はPIではブラックボックスですが、こんな解説があります。
http://pixinsight.com/forum/index.php?PHPSESSID=c45ffef17d4a59f70a95450352931f19&topic=2542.0

これを読むと、CCでは凄い事をやってる雰囲気もしますが、実は散光星雲はうやむやにされています。

http://yoshi8472.my.coocan.jp/index.html

 

Re: そう言われれば、確かに

 投稿者:k  投稿日:2013年 7月20日(土)02時54分44秒
返信・引用
  > No.57[元記事へ]

星羊翁さん、

> 最近、SI7のオートストレッチを使っています。フィルター係数を1:1:1にすれば以外と自然な発色になります。これって、PIで画面全体をリファレンスすることと基本的には同じことですね。

この場合、バックグラウンド指定は画面全体を囲まれるのですか?
 

Re: そう言われれば、確かに

 投稿者:星羊翁  投稿日:2013年 7月19日(金)17時53分47秒
返信・引用
  > >白いところがないです。
>
> にウケたのですが、PI以外をお使いの方はどうなさっているのでしょう?

最近、SI7のオートストレッチを使っています。フィルター係数を1:1:1にすれば以外と自然な発色になります。これって、PIで画面全体をリファレンスすることと基本的には同じことですね。ただ、白の定義は各ソフトで違っているようですが。
なお、オートストレッチした結果はPIに読み込んでもカラーバランスは崩れません。
 

Re: そう言われれば、確かに

 投稿者:k  投稿日:2013年 7月18日(木)10時16分9秒
返信・引用
  > No.54[元記事へ]

人工の星にも凹凸ムラが出来てしまうのでしたら、元画像のせいでは無さそうですね。少し気にしていたので安堵しました。

Forumの回答、暗黒星雲や「カラフルな散光星雲領域では画像全体を」referenceとして使うとは相変わらず大胆ですよね。

えっちゃんさんの、

>白いところがないです。

にウケたのですが、PI以外をお使いの方はどうなさっているのでしょう?
 

それから

 投稿者:tantan  投稿日:2013年 7月18日(木)05時45分11秒
返信・引用
  Re: れ:NGC3953で紹介されていたフォーラムは役に立ちました。
最近のものですね。CANP前は結構読んだのですが、これは見つけなかった。

内容はBNとCCの話で、ざっくりしたエッセンスはこんなことでしょうか。

・Structure Detectionをするときは星に偽色や色の偏りが無いか精査する
・Structure Detectionはどっちかと言うと最後の手段で沢山星がある場合に使う(この時バラエティーに富んだ色の星が沢山ある領域を指定する。白い星を選ぶわけではない)
・BNで適当なダークグレースカイが無ければ暗黒星雲をRegion of Interestで使う
極めつけは
・アンタレス付近のようなカラフルな散光星雲領域では画像全体をWhight Referenceとして使うことで良い結果になる事がある。

製作者サイドのCCに関する考え方ですね。昔と大きく変わっていないようで安心しましたが、それにしてもCCは奥が深い。

で、赤い散光星雲だけのような画像では全体を使っても良い結果は出ない(経験上)ので、やっぱりRegion of InterestかStructure Detectionになりますかね。

http://yoshi8472.my.coocan.jp/PixInsight/canp13/LRGB.htm

 

そう言われれば、確かに

 投稿者:tantan  投稿日:2013年 7月18日(木)05時14分15秒
返信・引用
  最初の例でアップされた1つの星はど真ん中ですが、元の銀河の画像で星を調べると確かに典型的なJpeg圧縮の副作用ですね。左は星を模して作った円をJpeg圧縮したもの。右が銀河の画像内左側の1つの星。
HDRはど真ん中に穴が開きますが、このようなむらは生じませんよね。

http://yoshi8472.my.coocan.jp/PixInsight/canp13/LRGB.htm

 

レンタル掲示板
/4