- このトピックには14件の返信、2人の参加者があり、最後に
により4時間、 1分前に更新されました。
-
投稿
-
初めて質問させていただきます。
Ｍ４２で多段階露光に挑戦してHDRを試してみました。
処理自体は出来たと思うのですが、書籍やAIを使いながら処理していった結果次のようなフローでした。
使ったこともなく書籍にも出てこない機能を一部使ったのでフローの妥当性がよくわかっていないです。
改善点などアドバイスいただけると幸いです。＜フロー＞
WBPP → MBE → SPCC → deepSNR → StarAlignment → LinearFit → HDRComposition
３００秒、１８０秒、６０秒のデータに対してそれぞれ「StarAlignment 」まで行って
LinearFit → HDRCompositionで実施したような感じです。
都内で撮影を始めて１年半ほど
PixInsight至ってはまだトライアル版で２週間ほどしか触っていいない中で何とか使えているのは２冊の書籍のおかげです。
この場を借りて感謝申し上げます。こてっちゃんさん、はじめまして。応用編の著者の永弘です。書籍もお読みいただいたとのこと、ありがとうございます。
処理フローを拝見しました。途中のMBEはDBEのことでしょうか？（それともMGC?）いづれにしてもフローに大きな問題はなく、これも一つの方法かなと感じました。結果も申し分なく、都会から撮ったとは思えない分子雲の写りですね！
応用編にも書いたとおり、RGBのそれぞれの飽和度の違いがあると、HDRCompositionでは処理後にカラーバランスが崩れることがあります。ですので、私の場合は
WBPP →StarAlignment → HDRComposition →DBE(MGC)→ SPCC → deepSNR
のような順番で行い、HDR合成のあとにSPCCで色合わせを行っています。
こてっちゃんさんの処理の場合、LinearFitを事前に行うことでHDR時の色のズレが抑えられているのかもしれません。もしよければLinearFitを入れた意図などお聞かせください
だいこもん様
ご返信ありがとうございます。
失礼しましたMGCの間違いです。
◆LinearFitを入れた意図
実は、意図はなくAIに状況を説明してHDRを行うにあたってアドバイスを求めると次のような回答で、試しに実施してみたいというのが正直なところです。１）露出毎にWBPP → MGC → SPCC → deepSNR の提案
都内で同日の撮影の場合、天体の位置によって背景のムラ（光害の影響）がかなり変わる点と子午線を越えた撮影データがあることを伝えると上記の提案で内容的にも違和感が無かったのでその指示に従いました。
その後に下記の説明でLinearFitをフローに盛り込む提案がありました。２）LinearFitの採用
輝度の違いが、HDRの際に色の不一致を防げる旨の説明がありました。
書籍にHDR後にカラーバランスがおかしくなる点を指摘されていたので書籍には出てこなかったがアプローチとしては必要なフローと考えて採用しました。３）HDRComposition後の色合わせ
最初は、私もこちらのフローを考えてAIに聞いてみると、光害の影響を考慮するとそれぞれを先に色合わせした方がよりうまくいくとのアドバイスでした。
この部分は、正直判断出来なかった点とLinearFitを入れる意味も初めてのHDRのため判断出来ず今回質問させて頂きました。追記
提示頂きましたフローでも処理して違いを感じてみたいと思います。
PixInsightは、自分の理解や解釈から様々なフローが出来る点がとても面白く感じています。
また、個々のような有志の方がアドバイスしてくれる雰囲気もとても気に入っています。こてっちゃんさま
説明ありがとうございます。なるほど、linearFItは光害の影響を考えてのことだったのですね。
たしかにLinearFitで各フレームの輝度を合わせることができますが、よく考えてみるとHDRCompositionまえのLinearFitの適用は以下の２点の問題（心配）があるような気がしてきました
- 例えば300秒露光の画像をreferenceにして短秒の画像をLinearFitしてしまうと、短秒露光のもともと飽和していなかったピクセルが飽和するか飽和に近い状態になってしまい、損をしないか
- カラー画像にLinearFitを行うと、RGB各フレームに対して輝度の変換が行われますが、そうするとせっかくSPCC で合わせたカラーバランスがリセットされてしまうことになりそう
です。
ちなみに、私が上にあげた処理フロー
WBPP →StarAlignment → HDRComposition →DBE(MGC)→ SPCC → deepSNR
ですが、光害が強い状況では
WBPP →StarAlignment →DBE(MGC)→HDRComposition → SPCC → deepSNR
とDBEとHDRを逆にする方が適切かもしれません。そのあたりはぜひ検証してみてください
訂正です。
WBPP→MGC→StarAlignment → LinearFit →HDR→SPCC→deepSNRで処理していました。
何度かやり直して勘違いしていました。そのため、懸念されていたSPCCの問題は起きないフローでした。
LinearFitのreferenceは、１８０秒が良いと提案がAIがしていました。
６０秒を基準としてコア（トラペジウム）を優先するか、３００秒で星雲部分を重視する
中間を狙う１８０秒かというような内容で今回は１８０秒をチョイスしました。
出来上がったM42は中心部は飽和しているので６０秒だと雰囲気が変わるかも試してみます。
LinearFitを含まない方法との比較も試してみます。
このようにフローは各機能を前後関係を考えながら理解すると面白さが増しますね。
ジャンルは全く別ですが、仕事がら業務フローやワークフローで一つ一つの処理の理解、それらの前後関係を考えて最適化するので似たような作業でとても面白いです。
こてっちゃんさん、
丹羽です。こんにちは。とても綺麗なおりオリオン大星雲ですね。
議論されているプロセスで良いと思いますが、いくつか補足します。(1) LinearFit
HDRCompositionを実行するときに、LinearFitは不要です。HDRCompositionの中にLinearFitと同じアルゴリズムが内包されているためです。実はLinearFitとHDRCompostionは2010年の10月に同時にリリースされています。
https://pixinsight.com/forum/index.php?threads/new-tool-hdrcomposition.2253/(2) WBPPとStarAlignmentについて
StarAlignmentはWBPPを別々に実行したファイルに対して、星による位置合わせをしたのかと思います。これでも問題ないのですが、WBPPのGrouping機能を使うと一回のWBPPで全ての露出が位置合わせされた画像が出力されて楽です。やり方は簡単で下記の手順です。
1. 露光ファイルを下記のルールでフォルダ分けする
ORION_1,
ORION_2,
ORION_3
ORION部分は自由につけて大丈夫です。_1, _2, _3というようにフォルダ名をつけてください。2. WBPPでDark, Flat, Lightファイルを全て読み込む。
masterDarkやmasterFlatがあればそれでも良いです。３. Grouping KeywordでORIONと入力して＋ボタンを押す。
するとCalibrationとPost-Calibrationが露光別に分かれます。4. 同じくGrouping Keywordで歯車ボタンを押して、PreとPostの両方を対象にする
これでStarAlignment済みの画像が露光別に出力されます。
今回は関係ありませんが、モザイクする時のようにStarAlignmentを別々にしたいときは、右下のRegistration Reference Imageでauto by xxに変更します。
お試しください！
なるほど、HDRCompositionではそれそれの露光時間のフレームをLinearFitで合わせてから合成しているわけですか。かんがえてみればそのはず、と言う気がします。
とすると、最も露光時間の短いフレームに残りのフレームを合わせているはずで、その過程で階調が失われないように内部で64bitの処理をおこなっているのでしょうね。
通常のLinearFitの内部処理が32bitなのか64bitなのかはわかりませんが、もし32bitだとすると露光時間の短いフレームにfitする過程で階調が失われるかも知れず、必要ないどころかやらない方が良いとまでいえそうです。
私は露光時間の長いフレームに、短い方を合わせるように思ったのですが、どうでしょうか。上に挙げられた飽和の問題は、Rejection Highを上手にコントロールしているのかな？中でやっていることなので、正体はわかんないので予想です。
ちなみに、LinearFitのリリースノートを見てみました。基本的な考えとしては露光の大きい方をリファレンスにしています（画像は残念ながらリンク切です）
https://pixinsight.com/forum/index.php?threads/new-tool-linearfit.2236/またこちらはLinearFitの説明としてよくできていますが、やっぱりノイズの少ない方をリファレンスにするよう推奨しています。
https://jonrista.com/the-astrophotographers-guide/pixinsights/linearfit/いずれにしても、だいこもんが指摘したようにHDRCompositionの前にLinear Fitはしないほうがよさそうですね。
一般的な用途でLinear Fitを使う場合は、明るい方をreferenceにするのが基本なんですね。たしかに暗い方をリファレンスにするとノイズの影響など受けてしまいそうです。
HDRComp.の場合、飽和したピクセルが含まれる長秒露光のデータに単秒露光を合わせていくと添付した図のように、1より飛び出た部分が失われてしまうのではと思いました。単秒露光の方に合わせればそのままスムースにHDR合成に移行できます。
ですがその辺は、上側に飛び出た部分を再スケールして輝度を1以内に納めるなどの方法で回避しているのかも知れませんね。
こてっちゃんさんの質問を通じて、とても勉強になりました。ここの掲示板の雰囲気を気に入ってくださっている旨書いてくれましたが、我々も皆さんの質問に答えて楽しくやっております。
確かにこのイラストを見ると、秒数が極端に違う時は問題になりそうです。
先ほどのリンクを下の方まで読んでいくと、だいこもんの言う通り64bitに変換していました。
https://pixinsight.com/forum/index.php?threads/new-tool-hdrcomposition.2253/
以前に「HDRCompositionが出力する画像は64bitなので、STFで見ると階調がジャンプして見える」という問題を質問コーナーでやりとりしたのを忘れていました。
https://masahiko.me/forums/topic/hdrcomposition/
とするとLinearFitも露光時間が短い方に合わせているのかもしれませんね。
丹羽様
コメントありがとうございます。
また、お褒めいただきありがとうございます。
快晴で深夜帯に月が出ていない時間帯であったこと、比較的高度の高いタイミングで撮影できたことが良かったようです。
フィルターもCBPを選択したこともよかったようです。●WBPPのGrouping機能
こちらの方が作業的には楽ですね。こちらも試してみます。お二人へ
内容に追いつけてないですが、同時に知識が深まりや機能の内部処理まで想像するに至ってなかなか面白い体験でした。お二人には及びませんが、「LinearFitを介さないHDR」と「LinearFitでreferenceを60秒で行ってからのHDR」と「LinearFitでreferenceを300秒で行ってからのHDR」を作って自分なりに考えてみました。
300秒は背景が明らかにほかの2パターンより明るくノイズを感じる内容でした。
「LinearFitを介さないHDR」と「LinearFitでreferenceを60秒で行ってからのHDR」はおおよそ同じですが背景の色やノイズの感じが少し違うようにも感じました。
ＨＤＲで内部的に行われているLinearFitに類する処理は露出時間の短い方に合わせる動作なのかもしれません。背景の色は「LinearFitを介さないHDR」が自然で、ノイズは「LinearFitでreferenceを60秒で行ってからのHDR」の方が個人的にはやや少ない印象です。
結果的には、LinearFitに該当する処理が1回か2回の違いでしかないのですが何らかの影響があるみたいです。追記
3パターンともSTFのリンクオフで画面で見た印象です。
