2018年8月11日 (土)

PixInsightで画像処理を始めよう ~ 第10回 嗚呼、星はいい(5) ストレッチ

【目次】

10-1. ストレッチの注意点
10-2. ArcsinhStretch
 (1) ArcsinhStretch の使い方
 (2) さらに明るく
10-3. PixelMath で合成
10-4. ここまでのまとめと動画の紹介


10-1. ストレッチの注意点

前回で色合わせまで終わりました。その画像を改めて見てみましょう。

10_01_beforestretch
図10-1. 前回までの画像(ストレッチ無し)

忘れている人もいるかもしれませんが、前回、前々回の解説で見てきた画像は、STF で見かけ上明るくしたものであって、実はこんなに暗い画像だったのです。右側にこの画像のヒストグラムを HT で示していますが、ほぼ左端にべたっと寄っていて、10倍に引き延ばさないと山の形がよくわからないくらいです。今回は、これをストレッチして明るくします。

ちなみに、この段階では画像はまだリニアですので、リニア画像に対してやるべき処理は今のうちにやっておいてください。例えば、第4回で紹介した Deconvolution も本来はリニア画像に対してやるべき処理の一つです。焦点距離の長い光学系で撮影した画像は Deconvolution をしておいた方が良いことが多いと思いますが、その場合にはここでやっておきましょう。ただ、今回の画像は 40mmのレンズで撮ったものなので、Deconvolution はせず、このままストレッチをすることとします。

さて、ストレッチする(明るくする)と言っても、その方法は様々です。皆さんは暗い画像をどのようにして明るくしていますか?一般的な画像処理方法としてよく解説されるのが、ヒストグラムの下に表示されているハイライトマークを左側に寄せる方法(ハイライトクリッピング)です。

10_02_ht_hlc
図10-2. ハイライトクリッピング

しかし、これには大きな問題があります。この HistogramTransformation (HT) で変換した次の画像を見てください。

10_03_hlc
図10-3. ハイライトクリッピングで明るくした画像

ご覧の通り、ギラギラになります。中央下端の領域はほぼ真っ白になってしまっていますね。中でも一番深刻なのは星です。次の画像を見てください。

10_04_hlc_readout_2x
図10-4. 星は完全に飽和している(2:1拡大)

ある程度以上明るい星は、R も G も B もすべて 1 に飽和してしまっています。図10-2 の設定からわかる通り、元画像で 0.043 より明るかったピクセルは 1 になって飽和してしまっているのです。天体写真で一番明るく写るのは星ですから、ハイライトクリッピングをすると、それが真っ先に飽和します。そして星が大きく写ってしまうようになります。

さらに、明るい領域が飽和してしまうほどに強くストレッチしているというのに、暗い領域は大して明るくなっておらず、依然として暗いままです。逆に言うと、コントラストは高いということになりますが、やはり飽和しているピクセルがある上に、暗い領域があまり明るくならないというマイナス面が大きいですね。

飽和するということは、色の情報がなくなるということです。星にもひとつひとつ色があります。せっかくあった色の情報が失われるような操作は避けなければなりません。また、もともと暗いピクセルをシャドウクリッピングしてもほとんど目立ちませんが、もともと明るいピクセルをハイライトクリッピングすると、非常に目立ちます。したがって、第3.5回でも述べた通り、天体写真の画像処理においては原則的にハイライトクリッピングはしません。

一方、ハイライトではなく、ミッドトーンのマークを左側に寄せて明るくする方法もあります。

10_05_ht_midtone
図10-5. ミッドトーンを左に

これで変換すると次のようになります。

10_06_mts
図10-6. ミッドトーンの位置を変えて変換

ハイライトクリッピングで明るくした画像と比較すると、平均的な明るさは実はどちらも大して変わらないのですが、随分と印象が違いますね。図10-5 の変換曲線を見るとわかる通り、この変換では、元々明るさが 1 だったピクセル以外は、変換後も明るさが 1 になることはありません。実際、図10-6 には飽和していそうなところは見当たりませんね。星はどうでしょうか。

10_07_mts_readout_2x
図10-7. 星にも情報が残されている(2:1拡大)

図10-4 と同じ星ですが、今度は飽和していません。さらに、暗い領域はやや明るくなって淡い星雲が若干浮かび上がっていることがわかります。つまり、飽和しているピクセルが無い上に、暗い領域が比較的明るくなるわけです。こうしたことから、ストレッチと言えばミッドトーンを動かして明るさを変えるストレッチが普通です。

しかし、図10-5 の変換は非線形変換です。これまで何度も言っている通り、非線形なストレッチをすると、色が薄くなります。暗い領域をそれなりに明るくする上に、色を薄くしない。そうしたストレッチの方法はないものでしょうか。

目次へ戻る この節のトップへ戻る

10-2. ArcsinhStretch

PixInsight にはストレッチ用のプロセスが多数用意されていますが、ここでは ArcsinhStretch を紹介しましょう。

10_08_arcsinhstretch
図10-8. ArcsinhStretch

ArcsinhStretch に関しては、以前紹介した Image Processing Tips でも取り上げています。

10_09_ipts_pi_021_title
図10-9. PixInsightでの画像処理(その21)- ArcsinhStretch

(上図をクリックするとページを開きます。)

詳細は Tips の方をご覧いただくとして、ArcsinhStretch も基本的には非線形変換なのですが、R と G と B の比率を変えないようにストレッチします。ということは、色相と彩度が変わらないということです。つまり、色を変えずに明るくすることができる わけです。せっかく PCC で測光的な色合わせをしたのに、ストレッチで色が変わってしまったら台無しですから、その色を変えないように ArcsinhStretch でストレッチしましょう。

(1) ArcsinhStretch の使い方

ArcsinhStretch はパラメータの数が少ないことからもわかる通り、使い方は簡単です。別に決まった手順はないのですが、2つのパラメータのうち、まず Black point から入力しましょう。Black point とは、シャドウクリッピングをするポイントのことです。つまり、それ以下の明るさのピクセルは変換後に 0 になる、という値です。この大まかな値は、HT でヒストグラムを見て決めることができます。

10_10_arcsinhs_ht
図10-10. HT で Black point の大まかな値を決める

HT のシャドウマークを右に動かすと、 Shadows の値が変わりますが、これがそのときのクリッピングポイントです。そして、さらにその右側に、そのクリッピングポイントでクリップされる(変換後に 0 になる)ピクセルの数とパーセンテージが表示されます。これを見ながら、クリップされるピクセル数があまり多くなり過ぎない範囲でクリッピングポイントを決め、その値を ArcsinhStretch の Black point に入力します。次に、ArcsinhStretch のリアルタイム・プレビューを開いて、それを見ながら Stretch factor のスライダーを右に動かします。

10_11_arcsinhs_exp01
図10-11. Black point を入力し、Stretch factor を変更する

すると、画像が次のように明るくなります。

10_12_ahsedimage
図10-12. ArcsinhStretch で少し明るくする

なお、このとき Black point も横のスライダーを動かすことで調整することができます。しかし、これを大きくするとシャドウクリップされるピクセル数が増えます。ハイライトクリッピングと同様、シャドウクリッピングもピクセルの情報を捨てることを意味するので、あまり良いことではありません。

そこで、リアルタイム・プレビューを開く際、"Highlight values clipped to zero" を有効にしておくと、クリップされるピクセルがプレビュー内で強調表示されるので、どの程度のピクセルがクリップされるのか視覚的に分かるようになります。

10_13_clippedpixels
図10-13. クリップされるピクセルの強調表示(Black point を大きくし過ぎた場合)

このようにリアルタイム・プレビューを見ながら明るくしていきます。もちろん、一度でもっと明るくしても良いのですが、コントラストを上げるために、その都度 Black point の値を変えながら複数回にわたって少しずつ明るくするのがコツです。

今回は2回実行し、最終的に次のような画像が得られました。

10_14_afterahs
図10-14. 通常の明るさにストレッチ

図10-6 と比較すると、随分と鮮やかですよね。従来のストレッチに慣れていると、「ArcsinhStretch でストレッチすると色が鮮やかになる」と誤解しがちですが、そうではありません。上で述べた通り、ArcsinhStretch は色を変えずに明るくしているのです。つまり、ストレッチ前の 図10-1 自体がこういう色だったということなのです。従来のストレッチが色を薄くしていただけのことなのです。

目次へ戻る この節のトップへ戻る

(2) さらに明るく

通常は 図10-14 くらいの明るさでストレッチ完了として良いのですが、右上の淡い星雲 Sh2-27 が淡すぎて少しはっきりしません。そこで、今回はもうひと工夫しましょう。

その前に 図10-14 の clone(クローン)画像を作ります。画像左側の画像名のタグを PI の背景部分にドラッグ・アンド・ドロップすると、クローン画像が作られます。

10_15_clone
図10-15. clone(クローン)

これをもっと明るくするとどうなるでしょうか。

10_16_ahs_bright2
図10-16. さらに明るく

右上の Sh2-27 も少し浮き出てきました。しかし、これでは明るい領域がちょっと明るくなり過ぎていますよね。そこで、図10-14 と 図10-16 の「いいとこ取り」をして合成しましょう。

目次へ戻る この節のトップへ戻る

10-3. PixelMath で合成

まず、通常の明るさの 図10-14 をアクティブにして、メニューバーから IMAGE > Extract > Green Channel を選択します。

10_17_extractg
図10-17. G画像を抽出

すると、図10-14 の G 画像が出力されます。

10_18_ahs_normal_g
図10-18. G画像

STF と HT を使って、明るい領域をさらに明るくし、暗い領域はほとんど見えないくらいに調整します。そして、メニューバーの PROCESS の中から invert を選択して明暗を逆にします。

10_19_ahs_normal_g_mask
図10-19. マスク画像

これをマスクとして 図10-14(通常の明るさの画像)に適用します。マスクの適用は、下図のように、マスク画像名のタグを適用先の画像の左側の枠(タグ以外の場所)にドラッグ・アンド・ドロップして行います。

10_20_apply_mask
図10-20. マスクを適用

ところで、画像にマスクを適用して処理を行うと、「マスクの白いところだけ処理が行われる」と説明されることが多いですね。もちろんそれで間違ってはいないのですが、より正確に表現すると、マスクは「元画像と処理後の画像のブレンド比の分布」です。マスクを適用した画像に処理を行うと、元画像と処理後の画像をマスクの明るさに応じてブレンドすることになります。白い部分ほど処理後の画像の割合を多くしてブレンドします。したがって、マスクに明るさ 1 の真っ白な領域と明るさ 0 の真っ黒な領域しかなければ、「マスクの白いところだけ処理が行われる」のと同じことになるわけですね。このように、マスクとは「元画像と処理後の画像のブレンド比の分布」と理解した方が、画像処理におけるマスクの意味を理解しやすくなります。

さて、マスクを適用したら、次に PixelMath (PM) を起動します。

10_21_pixelmath
図10-21. PixelMath (PM)

PM は、自由度の高さが「売り」の PI の中でも最も自由度の高いプロセスで、自由に数式や論理式を書いてその通りに実行させることができます。ただ、何の補助機能もなく式を書けと言っても大変なので、Expression Editor という補助ツールが付いていて、PI が今読み込んでいる画像名や、PMで使用できる論理記号等をリストから選択して入力することができるようになっています。

その Expression Editor を使って、"RGB/K" と "Symbols" に次のように書きます。

 RGB/K: k*$T + ~k* [明るい画像名]
 Symbols: k=0.2

10_22_pm_expeditor
図10-22. Expression Editor

"OK" ボタンを押せば、PM に反映できます。

10_23_pixelmath_fin
図10-23. PixelMath に式と定数値を入力

"$T" は、処理対象の画像(元画像)を意味する変数で、PM ではこう書くことになっています。これからこれを通常の明るさの画像(図10-14)に対して実行するので、$T は 図10-14 を意味することになります。

"k" は単なる定数で、"~k" は k の invert つまり、"1-k" を意味します。したがって、RGB/K の欄に書いた式は、通常の明るさの画像と過度に明るくした画像とをブレンドするという意味で、k を小さくするほど明るい画像に近づくことになります。

先ほど、マスクもブレンドを意味すると言いました。そして、ここでもブレンドします。言ってみれば二重にブレンドするわけですが、マスクだけでブレンドすると、その比率を変えるのにマスクごと変えなければならなくなって面倒です。ですから、処理自体を「ブレンド」にして、そのブレンド比は自由に変えられるようにしたのです。こうすれば、k の値を変えて再実行するだけで、得られる画像を調整することができます。

図10-23 の PM を 図10-14 の画像に対して実行(いつものように左下の三角マークをドラッグ・アンド・ドロップ)すると、次のようになります。

10_24_combined
図10-24. 合成完了

明るい領域も、暗く淡い星雲も、ともに適度な明るさで表示されるようになりました。

ちなみに、今節の最初で G画像をマスクの元としました。通常、マスクを作るときには、L画像を元とすることが多いのですが、今回 G画像を元としたのには少々わけがあります。図10-14 や 図10-16 には、右上に赤い星雲(Sh2-27)が淡く写っていましたね。この星雲は、L画像や R画像、さらには B画像にも写っていました。ところが、G画像にはほとんど写っていないのです。赤い星雲がほとんど写っていないということは、invert すればそこはほぼ真っ白になります。それをマスクにすれば、赤い星雲を効率的に浮かび上がらせるような合成ができます。このように、マスクの元とする画像を目的に応じて変えるというのも、細かいですがコツの一つではないでしょうか。

目次へ戻る この節のトップへ戻る

10-4. ここまでのまとめと動画の紹介

今回の内容でストレッチまで終わりました。ストレッチではハイライトクリッピングは原則としてすべきではないということ、そして、PI には、色を変えずに明るさを増幅させる ArcsinhStretch というプロセスがあるということを紹介しました。ArcsinhStretch は色を変えないので、普通のストレッチより色を鮮やかに保ったまま明るくすることができます。ここでもう一度その効果を見てみましょう。

10_26_comp
図10-25. ArcsinhStretch の効果

一つは ArcsinhStretch でストレッチしたもの、もう一つは STF のオートストレッチ(とHT)を使ってストレッチしたものです。オートストレッチはいわば「普通の」ストレッチです。両者の全体的な明るさはほとんど変わりませんが、色合いの違いは一目瞭然ですね。逆に言うと、普通のストレッチはこれだけ色を落としてしまっていたというわけです。皆さんも、ストレッチで色を薄くしてしまっていませんか?

デジタル画像において、おそらく「現像」の明確な定義は存在せず、どんな形であれ、画像化すればそれを現像と言うのでしょうが、第6回で述べたように、とくに、debayer(カラー画像化)、色合わせ(色調補正)、明るさ調整の3つは大抵含まれますよね。いわゆる「RAW現像」ができるプログラムでRAW現像した場合も、プログラム内部でこの3つの処理は必ず行われます。この3つをやらないと、人間が普通に写真だと思える画像にはならないからです。その意味で言うと、debayer は前処理(第7回)の段階でやり、色合わせは第9回でやりました。そして今回ストレッチをしたということで、ここまでがとりあえず「現像」に相当すると言ってもそれほど間違ってはいないと思います。天体写真の出来は、前処理を含めてこの「現像」までの比較的早い段階の処理でその9割以上は決まってしまいます。

第7回の DBE、第8回の PCC 、そして今回の ArcsinhStretch は、いずれもなかなか他のプログラムにはできない処理でしょう。中でもとくに、PCC や ArcsinhStretch なんかは属人的なテクニックや「慣れ」を必要とする要素がありません。他のプログラムだと、ここまでの段階でトーンカーブをよく使うと思いますが、あれこそ天体写真の画像処理を難しくしている元凶だと思います。トーンカーブを使った処理は属人的なテクニックや慣れが多分に必要ですし、もう一回やってくれと言われても「もう二度とできませんっ!」てなことがありますよね。画像処理で非常に重要な早い段階での処理に、誰がいつ何度やってもほぼ同じ結果が得られるようなユニークで強力なツールが使える、というところが PI の大きな魅力となっています。

なお、この入門とは素材の画像が違いますが、第7回から今回までの「DBE での光害除去」、「PCC での色合わせ」、「ArcsinhStretch でのストレッチ」の操作を簡単に紹介した動画があります。文字を読むより動画を視聴する方が理解しやすいかと思いますので、こちらも是非ご覧ください。

● 『天体写真を PixInsight で画像処理 Post processing 前編』

  • 「PixInsight ではこんなことができる」 といったような紹介を目的とした動画です。今回の入門よりもざっくりとした内容ですが、だいたい同じようなことを言っています。20分弱ですので、気楽にご覧ください。

目次へ戻る この節のトップへ戻る

<つづく>

2018年7月25日 (水)

PixInsightで画像処理を始めよう ~ 第9.5回 【補足】 天体写真の色

【目次】

9.5-1. 星の色に着目
9.5-2. 色指数
9.5-3. 銀河の色は星の色


9.5-1. 星の色に着目

観賞用の天体写真は芸術写真とも言えますから、どんな色に仕上げても表現の自由として許されるべきだと思うのですが、本来の色の再現を目指すのであれば、留意すべきことがあります。

まず、天体写真の色調補正の際に基準となるのは星です。星雲ではありません。もちろん、原理的には星雲も基準になりうるのですが、今のところ基準となるのは星だけです。まず最初に星を見ましょう。星はほぼ完全な黒体放射(黒体輻射)で輝いていると考えられるため、その色は表面温度によって決まります。温度が高いと青白く、低いと赤っぽく輝きます。緑色やピンク色の星は存在しません。

一方、真っ赤な星はどうでしょう。赤いということは、星としては表面温度が非常に低いということです。表面温度が低い星と言えば、そのほとんどが質量の小さい赤色矮星です。赤色矮星は、数の上では宇宙で最も多く存在するタイプの星と考えられていますから、一番沢山写ってもよさそうに思えますが、実はそうではありません。

質量が小さくなると明るさは急激に暗くなります。太陽系から最も近くにある恒星として知られるプロキシマ・ケンタウリは、4.25光年という至近距離にあるにもかかわらず、見かけの明るさは11等星で、とても肉眼では見えません。これより小さくなれば、色はさらに赤くなりますが、明るさはどんどん暗くなります。遠くにあれば一層暗くなります。ということで、真っ赤な星はたくさん存在するものの、天体写真にはところどころに暗く小さくポチっと写る程度に過ぎなくなります。

ある種の色収差や最微光星を除いて、多くの星の色がそのような存在しないはずの色やほとんど写らないはずの色になっていた場合には、色調補正に失敗しているということを意味します。

目次へ戻る この節のトップへ戻る

9.5-2. 色指数

第9回でも述べた色指数は、個々の星の色を推定するのに重要な情報です。星の色指数は、例えば stellarium といったプラネタリウムソフトでも調べることができます。

色指数の元となる B とか V とかいう値は、その色のフィルターを通して測った星の等級(明るさ)ですから、暗いほど大きな値となります。V(緑)より B(青)が暗ければ、B の方が大きな値ですから、色指数 B-V は正の値となります。青が暗いということは、その星は赤っぽい星だろうと推察できますよね。したがって、色指数 B-V が大きな値であるほど、その星は赤っぽい星ということになります。

この色指数の説明でよく例として挙げられるのが、はくちょう座のサドル(Sadr)という星です。サドルは、はくちょう座の十字の交点の星で、はくちょうのお腹にあたる星ですが、この星の色指数 B-V は、0.67 もしくは 0.68(カタログによって多少の違いはあります)です。

09_05_01_stellarium
図9.5-1. stellarium で見たサドル

対して、私たちの太陽の色指数 B-V は 0.65。つまり、サドルは太陽とほぼ同じ色であり、白もしくは薄っすら黄色だろうと推測することができます。実際、PCC で色調補正を行ったサドル周辺の写真を見てみるとこんな感じです。

09_05_02_sadr
図9.5-2. サドル周辺 (クリックすると高解像度版に飛びます)

この写真は薄曇りの条件下で撮影したので、出来はあまり良くありませんが、中央付近に見える輝星がサドルです。ほぼ白ですよね。高解像度版で見るとよくわかると思います。他にも、オレンジ色と思われる星はしっかりオレンジ色に写っています。もちろん、これが正しい色だなどと言うつもりは毛頭なく、ツッコミどころもあって全体的な出来は良くないので、この写真を全面的に信じてはいけませんが、一つの参考にはしていただけると思います。

ところで、皆さんの中に、青が嫌いという人はほとんどいないでしょう。天体写真も青っぽく仕上げたくなる人は多いと思います。とくにこの領域は、この写真を見てお分かりの通り赤が非常に目立つので、色のバランス的にもついつい青を入れたくなりますよね。しかし、そうして青が目立つように処理し過ぎると、サドルが青くなる、オレンジ色のはずの星が黄緑色になる、といったことが往々にして起こります。

また、地球の大気を通して天体を見ると、大気によって青い光が散乱されて少なくなるはずなので、宇宙から見たらもっと青いはずだ、と考える人もいるでしょう。もちろん、その考察自体は正しいと思いますが、これにも注意が必要です。大気によって減衰するのは青い光だけではありません。水蒸気や二酸化炭素による吸収等もあって、他の色の光もまんべんなく減衰しています。果たして大気中で R/G/B がそれぞれどの程度減衰しているのか、定量的な考察が無いと問題です。定量的な考察のないまま、たった一つの定性的な考察を根拠に青だけを強くしていると、結局は自分の感性の赴くままに、自分の好みの色になるまで青くしてしまいがちで、何の根拠もないまま色合わせをするのと同じことになってしまいます。

目次へ戻る この節のトップへ戻る

9.5-3. 銀河の色は星の色

天体写真の主要なターゲットの一つに系外銀河(私達の銀河系ではない別の銀河)もありますね。とくに長焦点の大砲をお持ちの方には最大の獲物かもしれません。ご存知の方も多いと思いますが、銀河は星の集まりです。ということは、その色はそこに含まれる星によって決まります。

一口に銀河と言っても、渦巻き銀河や楕円銀河など幾つかの種類があるのですが、実は銀河の色も、その種類に応じた傾向があります。楕円銀河やレンズ状銀河(S0銀河)には、共通的に星形成領域がほとんどないことが知られています。つまり、ほとんど星が新しく生まれていないということです。

青い星は質量が大きいのですが、質量が大きいと寿命が短くなります。反対に、赤っぽい星は質量が小さく、寿命が長い星です。青い星はすぐに寿命を終えて消えてしまうので、それがたくさん存在するには、常に新しく生み出され続けなければいけません。

したがって、楕円銀河やレンズ状銀河に星形成領域がほとんどないということは、これらの銀河には寿命の短い青い星はほとんどなく、長寿命の赤っぽい星が多いということが推察できます。ほとんど赤っぽい星だけが含まれるのなら、その銀河は赤っぽくなりますよね。そうなんです。楕円銀河やレンズ状銀河は、黄色からオレンジ色をしているのです。春の銀河祭りの主役「おとめ座銀河団」を写すと、そうした銀河が沢山写ります。

09_05_03_virgocluster
図9.5-3. おとめ座銀河団 (クリックすると高解像度版に飛びます)

これはかなり彩度を上げた画像ではあるのですが、楕円銀河やレンズ状銀河は、黄色あるいはオレンジ色っぽく写っています。PCC を使うと、こうした色合いも如実に再現されて驚きます。

もちろん、最初に言った通り、芸術作品ですから星やその他の天体をどんな色に仕上げても自由ですし、それは別に構いません。そもそも、天体改造カメラで写せば、とくに赤い星雲なんかはもはや人間が目で見た通りには土台写りません。(Hα線は、人間の目には感度がそれほど良くないので、どす黒い赤に見えるはずです。)

フォトコンの厳しい審査員等から星や銀河の色についての指摘を受けたとしても、「偉い人にはこの美しさがわからんのですよ!」と言って意に介さないくらいの気骨の持ち主には、ある種の好感を持ちます。あまり厳しいことばかり言っていると、新海誠監督の作品は見られません(笑)。

しかし、「写真である以上、人間が目で見た通りの色の再現に努めるべき」というのも一理ある主張であって、天体写真にとって本来の色の再現が大きなテーマの一つであることは間違いありません。星の色を正しく調整出来れば、それに伴ってその他の天体の色も本来の色に近くなりますから、まずは星の色に気を付けてみてください。

また、天体写真を上手に仕上げるには、物理学や天文学の知識が多少必要となることがあります。そうした知識も敬遠せずにどんどん吸収するように心がけましょう。

目次へ戻る この節のトップへ戻る

<つづく>

PixInsightで画像処理を始めよう ~ 第9回 嗚呼、星はいい(4) 色調整、倍率色収差補正

【目次】

9-1. 測光的手法による色調整
9-2. 倍率色収差の補正


9-1. 測光的手法による色調整

前回 DBE で光害を除去して、やっと天体本来の姿が露出するようになりました。

09_01_afterdbe_las
図9-1. 光害除去後の画像

次にやるべき処理は、色合わせです。前処理の段階で色合わせをしていなかったのは、まだ光害を除去していなかったからでもありますが、いずれにしても 8-2節で説明した通り、色合わせは画像がリニアな段階でやっておかないといけません。

ちなみに、この 図9-1 は STF で linked auto stretch したものです。R/G/B でストレッチの強さを変えると色が変わってしまうので、色合わせ以降のオートストレッチは R/G/B をリンクして行うことになります。したがって、これから行う色合わせの効果を前後比較したければ、この段階から linked auto stretch しておきましょう。この段階では、全体的にやや紫色っぽく見えますね。

ところで、カメラやレタッチソフトで現像するときには、予め決められた割合で R/G/B を配合するわけですが、果たしてそれは本当の色なのかというと、そんな保証はありません。それに、例えば「太陽光(昼光)」というホワイトバランスは、太陽の光を受けた状態で白が白に見えるということですよね。でも、天体(月や惑星を除く)は別に太陽の光を受けて見えているわけではありません。ですから、カメラのホワイトバランスなんか、厳密には当てにならないわけです。

もっと厳密で直接的な色合わせの方法はないものでしょうか。それが天体写真の場合にはあるんです。天体写真には、色の基準となるものが写っているからです。それは「星」です。

天文学の世界では、2つの異なる色フィルターを通して星の明るさ(等級)を測り、その差を color index(色指数)と呼んで星の色を表す物差しとして使っています。例えば、青系の光だけを通すフィルターで星を見た等級が B で、緑系の光だけを通すフィルターで測った等級が V だったとします。このとき、"B-V" をこの星の色指数とするわけです。

ちなみに、緑を V と表すのは、人間の目にとって最も感度の高い波長の光が緑であるためで、"Visual" からとった V を用います。B や V だけじゃなく、赤の R や、青より短い波長(紫外域)の U を測って、R-V とか、U-B なんかも色指数になります。これらの値は、カタログ(星表)にまとめられていて、インターネット等で広く公開されています。

その中で、とくに APASS という全天光度測量カタログに記載されている r'(Sloan r')、V(Johnson V)、B(Johnson B) の値に着目し、B-V と r'-V の2つの色指数を調べます。ここで、この r'、V、B をそれぞれ R、G、B に対応するものと見立てれば、B-V と r'-V はそれぞれ、デジカメで撮影した星の B:G ならびに R:G の比率に対応することになりますから、両者を合わせることによって、正確な色合わせができるはずですよね。こうした考え方で色調整をしてくれるプロセスが、PhotometricColorCalibration (PCC) です。

09_02_pcc
図9-2. PhotometricColorCalibration (PCC)

PCC は R/G/B の比率をカタログと比較して合わせようというプロセスですから、画像がリニアでないと正しくできません。PCC での色合わせを画像がリニアな段階でやる理由はここにもあります。

では、使い方を見ていきましょう。あ、そうそう。PCC はインターネットでカタログを検索するので、当然ネット環境が必要です。注意してください。

(1) パラメータ設定(位置同定)

星の色指数を利用するからには、まず、写真に写っているのがどの星なのか(どこを撮った写真なのか)を特定する必要があります。これを plate solving と言ったりするのですが、そのために以下の情報を入力します。

09_03_pcc_imageparams
図9-3. Image Parameters

(a) 写真に写っている任意の点の赤経・赤緯
いきなり値を入力するのは難しいので、写真に写っている天体名からその位置を検索することで入力することが可能です。"Search Coordinates" ボタンを押すと 図9-4 のような検索画面がポップアップされます。Object 欄に天体名を入力して Search ボタンを押すと、検索が行われて天体の位置座標等が表示されます。今回の画像の場合、M23 が中央付近に写っていたので、その座標を検索しました。位置座標が表示されたら、Get ボタンを押すと PCC の方に反映されます。

09_04_searchcoor
図9-4. 座標検索

(b) 撮影日
歳差運動が影響を及ぼさない範囲で、だいたいの日付を入力すれば大丈夫です。
(c) 望遠鏡やレンズの焦点距離 (mm)
(d) カメラ(センサ)の画素サイズ (μm)
(c) と (d) は、写真の画角を求めるのに必要な情報です。画素サイズは、センサの大きさと画素数がわかれば求められますね。

入力が必須なのはこれだけです。

(2) パラメータ設定(Background Neutralization)

今回はこれに加えて Background Neutralization も入力することにします。DBE実行後であれば、してもしなくてもそれほど大きく変わらないとは思いますが、一応解説ですから念のため。Background Neutralization (BN) というプロセスは月の画像処理(第5回)でも使いましたが、指定したバックグラウンド領域の色をニュートラルにしてくれます。

09_05_pcc_bn
図9-5. Background Neutralization

「ここはバックグラウンドだろう」と思われる領域を preview 領域で囲んで、"Region of Interest" の "From Preview" ボタンからその領域の範囲を入力します。ただし、今回の画像の場合、明確にバックグラウンドだと言える領域はないと言っても過言ではありません。そんなときには、とくに暗そうな領域を慎重に選んでそこをバックグラウンドとみなしても大丈夫でしょう。

09_06_bn_area
図9-6. ここをバックグラウンドとする

そして、その領域の中でとくに「この値以下のピクセルをバックグラウンドとみなしなさい」という値を "Upper limit" に設定します。例えば、バックグラウンド領域として囲んだ領域の中にも微光星が写っているかもしれません。微光星はもちろんバックグラウンドではありませんから、それを除くわけです。任意のピクセル値を確認するには、ツールバーの "Readout Mode" をオンにして画像上をマウスでクリックすると、Readout Preview 画面が表示されるので、それで確認することができます。

09_07_bnupperlimit
図9-7. Readoutモードでバックグラウンドの値を確認

今回の場合、"0.006" 以下のピクセルをバックグラウンドとみなせば良さそうだったので、図9-5 の "Upper limit" にはそのように設定してあります。

(3) 実行、および "Limit magnitude" の調整

ここまで設定すれば、あとは実行するだけです。実行すると、前述の通り、その写真がどこを撮った写真なのか(写っているのはどの星か)を特定する処理(plate solving)から始まります。その plate solving が正常に終わると、以下のような解析結果が console に出力されるので、それが目安になりますね。

09_08_pcc_solve_console
図9-8. plate solving 成功

Plate solving が終われば個々の星が特定できるので、続けて色指数の比較が始まります。

が、ここで一つ注意が必要です。写真に写っている星ひとつひとつの R/G/B の比率は決して正確なものではなく、カタログの値と比較するとどうしてもある程度のバラつきが出てしまいます。したがって、なるべく沢山の星の色指数を比較して、それらの統計をとらないと正しい色合わせができません。

沢山の星を比較対象とするには、"Photometry Parameters" の "Automatic limit magnitude" を無効にして、"Limit magnitude" の値を大きくしてください。すると、その等級の星まで調べてくれることになっています。

09_09_pcc_photometryparams
図9-9. Limit magnitude を変更

ただし、2018年6月末現在のバージョンだと、Limit magnitude をあまり大きくしすぎると PCC はエラーで終了してしまいます。それでエラー終了してしまうのは、プログラムとして如何なものかと思いますが、PCC は開発されて日が浅いプロセスですから、今後改善されていくのではないかと期待しています。とにかく、Limit magnitude は、エラー終了しない範囲で、なるべく大きな値を指定すると良いでしょう。

ちなみに、Automatic limit magnitude を有効にしたままで実行すると、検索する星の数が少なすぎるケースが多いと思います。なので、最初から Limit magnitude を 12 ~ 15 くらいにして実行すると良いかもしれません。この辺は画像によって違うので一概には言えませんが、それで一度実行してみて、plate solving はできているのに、その後、エラー終了してしまうようなら、Limit magnitude を少し小さくして再実行してみてください。

PCC で処理した結果、図9-1 は以下のようになりました。

09_10_pcc_comparison
図9-10. PCC で色合わせ完了

色合いが変わっているのがわかりますね。なお、これは STF でオートストレッチしたものです。オートストレッチのような非線形ストレッチをすると、8-2節で見た通り、色が薄くなります。色が薄くなってこのくらいに変わるということは、実際の色は、もっとはっきり変わっているということを理解しましょう。

なお、処理をやり直す場合には、ツールバーの Undo ボタンを押すことで一つ前の状態に戻すことができます。また、Undo/Redo を繰り返し押すことで処理前後の画像を連続表示して比較することもできます。

10_25_undoredo
図9-11. Undo/Redo

さて、ここまでご覧になってお分かりの通り、PCC での色合わせには、人それぞれの好みや思い込みといった主観が入り込む余地はほとんどありません。自分の好みを反映できないというところに、不満を感じる人も中にはおられるかもしれませんが、天体写真において、正確な色の再現が一つのテーマであることは間違いありません。もちろん、PCC で完全に正確な色を再現できるわけではありませんが、非常に科学的で優れたアプローチと言えます。

また、第6回で述べた通り、カメラで現像したり、あるいは RAWデータを直接現像できるプログラムで現像する場合、R/G/B を既定の比率で配合することで色合わせを行います。それに対して PCC は、言わば「現物を見て」、カタログという基準と照らし合わせたうえで R/G/B の配合を調整します。ここでは、どちらがより正しいのかという議論はしませんが、少なくとも PCC によるアプローチは、大きな「可能性」を感じさせてくれますね。

これまでレタッチソフト等を使った色合わせに苦労していた人は多いでしょう。あれこれ弄っているうちに何が何だか分からなくなった、という経験も数多くされていることでしょう。PCC は、そんな苦労からあなたを解放してくれる強い味方です。PCC で色調整して「これはこんな色をしていたのか」と驚くことも多いかと思います。ぜひ一度、試してみてください。

目次へ戻る この節のトップへ戻る

9-2. 倍率色収差の補正

PCC を使って色合わせは終わりましたが、周辺部に写っている星をよく見ると、放射方向に赤い光と青い光が少し分離して写っています。こういうのを倍率色収差と言い、屈折レンズを使った光学系の場合には、ある程度避けられない収差です。

09_11_magnification
図9-12. 左下周辺部の倍率色収差(2:1拡大)

もちろん、倍率色収差は、光学性能の高い高級な光学系を使えばほとんど目立たずに済むことが多いです。この画像でも、2:1に拡大してこの程度なので、そんなに酷く目立つというほどではないのですが、補正できるものなら補正したいですよね。

倍率色収差を補正する方法は幾つかありますが、まずは画像を R/G/B それぞれのチャンネルに分けて見てみましょう。メニューバーから IMAGE > Extract > Split RGB Channels を選択して3つのチャンネルに分割してください。

09_12_splitrgb
図9-13. R/G/Bに分割

分割すると、名前が "XXXX_R"(R画像)、"XXXX_G"(G画像)、"XXXX_B"(B画像)という画像が3つ出力されます。これら3つの画像を比較すると、星が写っている位置が僅かにズレていることがわかります。

09_13_magnificationrgb
図9-14. R/G/B画像を比較(2:1拡大)

このように3色で星の位置がズレているから色が分離したように見ていたわけです。なら、この位置のズレを補正することができれば、倍率色収差を無くすことができるはずですね。そこで、StarAlignment (SA) プロセスを使います。

09_14_staralignment
図9-15. StarAlignment

SA はその名の通り、自動的に星の位置を揃える、すなわち位置合わせ(registration)をするためのプロセスで、主に前処理(pre processing)で使われます。第7回で紹介した BPP も、内部で SA が動いています。この SA もまた PI を代表する優れものプロセスの一つです。今回はこれを使って倍率色収差を補正しましょう。

やり方は簡単です。今回は、G画像を基準(reference)として、R画像と B画像の星の位置を補正することとします。まず、"Reference image" に先ほど分割した G画像を入力します。右側の三角マークから選択することができます。設定は基本的にはこれだけです。これで、一番下の三角マークを R画像と B画像にドラッグ・アンド・ドロップしてください。

09_15_apply_sa
図9-16. SAを実行

すると、"XXXX_registered" という名前の画像が新たに出力されます。これが、補正後の画像です。R画像と B画像を補正できたら、ChannelCombination プロセスでそれらを再合成します。

09_16_channelcombination
図9-17. ChannelCombination で再合成

R および B には、先ほど補正された画像を入力します。入力する画像は、右端の四角いボタンから選択することができます。R/G/B それぞれの画像を指定したら、左下の丸ボタン(Apply Global)を押せば合成できます。合成後の画像を元の画像と比べてみましょう。

09_17_correctmag
図9-18. 補正前後の画像比較(2:1拡大)

もちろん完璧ではありませんが、かなり奇麗に補正されているのがわかると思います。

なお、パラメータの中にはさらに精度を上げられるパラメータがありますが、今回の画像の場合、パラメータをすべてデフォルトのまま実行したケースと比較してほとんど結果が変わりませんでした。パラメータがデフォルトのままでも大抵良い結果が得られるというところが、SA の優れた点の一つだと思います。

【補足】天体写真の色についてはこちら

目次へ戻る この節のトップへ戻る

つづく

2018年7月13日 (金)

PixInsightで画像処理を始めよう ~ 第8回 嗚呼、星はいい(3) 光害除去

【目次】

8-1. Post processing(後処理)
8-2. リニア画像
8-3. 光害除去
8-4. DBEや光害除去に関するその他の注意点


8-1. Post processing(後処理)

前回は pre processing(前処理)と呼ばれる一連の処理を行いました。あの前処理は、これから先に行う処理のための準備の処理です。だから「前」処理なんですね。

それに対して、ここから先の処理は post processing(後処理:あとしょり) と呼ばれます。処理する人の技量が問われる腕の見せ所が沢山あって、慣れると大変楽しいのですが、この後処理には実に多くの種類の処理があって、一体何からやれば良いのかわからないという声をよく聞きます。しかし、後処理にもある程度の順序というものがあるので、この入門ではその順番通りに解説していこうと思います。ただ、その前に1つ説明しておかなければならないことがあります。

目次へ戻る この節のトップへ戻る

8-2. リニア画像

天体写真の画像処理において、よく耳にする言葉として「リニア(linear)」という言葉があります。「リニア」とは「線形(線型)」のことですが、別の言葉で言い換えれば「比例」という意味になります。比例をグラフで表現すれば直線を引くことになるので、「線形」とも言うわけですね。つまり、リニア画像とは、簡単に言えば、被写体の明るさが2倍(3倍)なら画像上でも明るさが2倍(3倍)であるような画像のことを言います。例えば、RAWデータはリニアです。厳密には違うみたいですが、ほぼリニアだと言われています。そして、そうだとすればそれを使って前処理した直後の画像もまたリニアです。

対して、撮って出し画像のような画像は、通常、リニアではありません。なぜでしょうか。第6回の話を思い出してください。撮って出し画像は、RAWデータをカメラ内で現像したものですが、その現像には明るさ調整(ストレッチ)が含まれていましたね。あのストレッチは、通常、非線形なストレッチだからです。例えば 図8-1 のようなトーンカーブを見てください。

08_01_ct
図8-1 非線形なトーンカーブの例

変換曲線がその名の通り曲線である場合、それで変換された画像はすべて非線形画像になります。非線形なストレッチを行うとどんな問題が起こるのでしょうか。一例として、図8-2 を見てください。

08_02_non_linear_s
図8-2. A と B は同じ色なのに・・・

A は R と G と B の明るさがそれぞれ 0.1、0.2、0.3 です。これを A(R, G, B) = (0.1, 0.2, 0.3) と表しましょう。一方 B はと言うと、B(R, G, B) = (0.2, 0.4, 0.6) です。どちらも R:G:B の比率が 1:2:3 なので、A と B は明るさが違うだけで色相も彩度も同じです。つまり、A と B は同じ色 なのです。このような色と明るさの星があったと仮定します。

これに対して 図8-1 のような非線形な変換をかけてストレッチします。変換後の画像をそれぞれ A'、B' とすると、A'(R, G, B) = (0.289, 0.524, 0.675)、B'(R, G, B) = (0.524, 0.771, 0.896) となります。R を 1 としたときの R:G:B の比率を計算すると、A' は 1 : 1.81 : 2.33、B' は 1 : 1.47 : 1.71。つまり、比率が違うわけですから、A' と B' は 同じ色ではない ということになります。もちろん、A と A'、B と B' も違う色ですし、明るいほど色が薄くなります。

元々は同じ色だったのに、非線形ストレッチをすると違う色になってしまう。だから、天体写真の画像処理でも、非線形ストレッチをしてから星の色合わせをしようとすると、

 A'の星で色合わせを行うと B'の星の色がおかしくなる
 B'の星で色合わせを行うと A'の星の色がおかしくなる

ということが起きてしまうのです。非線形ストレッチを伴う現像をしてしまうと、厳密にはもはや色合わせはできなくなります。したがって、色合わせをするなら画像がリニアな状態のうちにやらなければなりません。

この他、画像がリニアだからこそできる(しやすい)処理が色々あります。まずはそういった処理から行っていく必要があります。しかし、前処理直後の画像は非常に暗く、そのままでは処理がしづらいです。したがって、処理をするにもある程度明るくする必要があります。でも、それだとリニアではなくなる・・・。

こうしたジレンマを解消してくれるのが、この入門で既に何度も登場している STF です。STF でのストレッチはすべて非線形ストレッチなのですが、見かけ上明るくしているだけで本当にストレッチしているわけではありません。だから、STF で明るくしてからリニア画像でなければできない処理を行っても問題ないのです。STF はこのためにあるのです。

以降、特に断りが無ければ、STF でオートストレッチしていると思ってください。

目次へ戻る この節のトップへ戻る

8-3. 光害除去

さて、前処理直後の画像をもう一度見てみましょう。

08_03_afterbpp_ulas
図8-3. 前処理直後の画像

前処理によって、ノイズが激減し、周辺減光も修正されました。しかし、これで天体本来のあるべき姿が露わになったかというと、そうでもありません。まだ取り除いておくべき「余分なもの」があります。それが、光害です。

図8-3 を見ると、画像の下の方が僅かにぼんやり明るくなっていますね。この画像は伊豆の天城高原で撮影したものです。天城高原から南側には街はほとんどなく、南天は非常に暗いのですが、それでも光害が完全に0というわけではありません。その僅かな光害が含まれてしまっています。もっとも、これだけ低空になると必ずしも光害のせいだけではないかもしれませんが、いずれにしても、余分なものが含まれていると以降の処理が正しくできなくなるので、まず最初にこれを取り除きましょう。

ちなみに、光害というのは、天体の光に足し算で加えられた光です。ですから、光害を除去するには、元の画像から光害分の光を引き算するわけですが、厳密なことを言うと、引き算で光害の光を除去することができるのはリニア画像だけです。一旦非線形なストレッチをして非線形画像にしてしまうと、そこから光害分の光だけを引き算して除去することができなくなります。したがって、光害除去も画像がリニアな段階でやるべき処理です。

さて、この光害の除去に苦労している方は非常に多いと思いますが、光害等に起因するバックグラウンド(背景)の明るさの勾配を補正する強力なツールが PI にはあります。その1つが DynamicBackgroundExtraction (DBE) です。

08_04_dbe
図8-4. DynamicBackgroundExtraction (DBE)

この DBE もまた PI を代表する「優れものプロセス」の一つで、これを使いたいがために PI を買うという人もいるくらいです。もちろん、PI 以外にもこれと同じような機能を持つプログラムはあります。例えば AstroPixelProcessor (APP) にも同じような機能があります。しかし、両者を比べると(私がまだ APP を使いこなしていないだけかもしれませんが)、やはり DBE に一日の長があるように思います。それほどに強力で優秀なツールです。初めて見る方は、その効果にきっと驚かれることでしょう。

では、DBE の使い方から説明します。と言っても、これと決まった手順があるわけではないので、あくまで一つの方法くらいに考えてください。

(1) バックグラウンドサンプルを打点する

DBE で光害を除去するには、まず、どこがバックグラウンドであるかを DBE に教える必要があります。バックグラウンドとは、星も星雲も何も無い領域です。それを小さな background sample(バックグラウンドサンプル) としてポイントしていきます。対象画像をクリックすればポイントできます。

08_05_bgsample
図8-5. バックグラウンドサンプル

このバックグラウンドサンプルを画像上に何点か打つことによって、バックグラウンドの色や明るさの分布を推定できるようになります。そうして推定された分布を background model(バックグラウンドモデル) と言い、そのバックグラウンドモデルを使って、光害等に起因するバックグラウンドの勾配を補正・除去するというわけです。
ただ、困ったことに、図8-3 の画像の場合、厳密にバックグラウンドと言える領域はほぼありません。なぜこんな画像を素材として選んでしまったのか、ここで早速後悔するわけですが、もう遅いですよね(苦笑)。

図8-3 を見ると、ほぼ全面に天の川が写っていて、そこからなるべく離れた右上あたりをバックグラウンドと思いたいところですが、そこには大きな赤い輝線星雲 Sh2-27 が微かに写っていますからダメです。また、天の川に広範囲に存在する暗黒帯も、厳密にはニュートラルなバックグラウンドではありません。銀河中心部には星間物質が多く存在しています。星間物質の多くは、水素原子や水素分子などの非常に小さな粒子です。その中を光が通過すると、レイリー散乱によって青い光ほど強く散乱されてしまい、通過してくるのは赤っぽい光が多くなります。星間物質の密度が高くなればなるほど、また、厚さが厚くなればなるほどその傾向は強くなります。天の川中心部が赤っぽく見えるのはそのためですね。暗黒帯はその星間物質がとくに濃い部分ですから、これも完全な黒ではなく、厳密には「赤に偏った黒」と考えるのが妥当でしょう。

しかし、そうは言っても、他に無いのなら仕方がありません。暗黒帯の中でも、とくに暗いところなら、事実上バックグラウンドとして扱っても大きな問題は無いでしょう。そういったところを注意深く狙って打点していきます。

なお、サンプルの大きさはデフォルトでは半径5に設定されていますが、"Default sample radius" の値を変えると、それ以降に打点するサンプルの大きさが変更されます。既に打ってあるすべてのサンプルの大きさを一律に変更したければ、"Resize All" ボタンを押してください。

08_06_changebgr
図8-6. サンプル半径を変更

この内側に入るピクセルがバックグラウンドのサンプルとなりますので、小さすぎると十分なサンプル数が確保できずに正確な計算ができなくなる可能性がありますし、大きすぎると逆にバックグラウンドではない星雲等が入り込んでしまうことが多くなります。多くの場合、10 から 15 くらいで良いと思いますが、すべてのサンプルが同じ大きさである必要はありませんし、その画像や打点位置に応じて適宜調整してください。

今回の例の場合、以下のようにサンプルを打点しました。

08_07_bgsample_all
図8-7. バックグラウンドサンプル打点完了

(2) パラメータを調整する

バックグラウンドサンプルを打つと、サンプルが赤く表示されることがあります。これは、有効なピクセルが少なすぎる bad sample であることを意味していて、そのままではバックグラウンドサンプルとしては使えません。

08_08_bad_sample
図8-8. Bad sample

その場合には、"Tolerance" の値を大きくしてください。光害が酷くなるほど Tolerance を大きくしないといけなくなります。ただし、あまり大きくしすぎると、バックグラウンド以外のピクセルもバックグラウンドとして扱われてしまうので、要注意です。

08_09_tolerance
図8-9. Tolerance

今回の場合は、Tolerance 値はデフォルトの 0.500 がちょうど良さそうでした。

(3) 補正方法を選択する

打点したすべてのバックグラウンドサンプルが有効になるようにパラメータを調整出来たら、"Correction" で "Subtraction"(引き算)を選択し、"Discard background model" が無効になっていることを確認して実行します。先ほども述べた通り、光害は天体の光に足し算で加えられた光ですから、それを "Subtraction"(引き算)で補正するわけです。また、バックグラウンドモデルはこのあと検証のために使いますので、discard(捨てる)しないようにしてください。

08_10_targetimagecorr
図8-10. Target Image Correction

実行は、左下の三角マークをドラッグ&ドロップするか、緑のチェックマークを押すか、どちらでも可能です。

(4) バックグラウンドモデルを検証する

実行すると、補正された画像とバックグラウンドモデルの2つの画像がポップアップされると思います。このうち、window名に "xxx_background" と書かれたバックグラウンドモデルを STF で unlinked auto stretch してください。

08_11_bgmodel
図8-11. バックグラウンドモデル

これが、推定されたバックグラウンドの色や明るさの分布です。これが光害の光の分布として妥当かどうかを検証します。ポイントは2つあります。

明るさの勾配は、なだらかで、どちらかに向かって単調であること
光害は地表に近いところほど強くなりますから、上下左右どこかの端が最も明るくなるはずです。端以外の部分(例えば中央付近)が周囲より明るくなっていたとしたら、光害の光源が空中にあることになってしまいますから、明らかにおかしいですよね。また、条件にもよりますが、勾配が急激に変化するというのも、光害としては不自然です。
全面にわたってほぼ同じ色合いであること
光害の色が局所的に変わるということはまずありえませんよね。大きなスケールで見れば多少変わることはあり得るとしても、一部分だけが赤っぽくなったり青っぽくなったりするなどということはないはずです。

このような観点で 図8-11 を見ると、上から下に向かって単調に明るくなっていて、部分的に不自然に明るくなっているようなところは見当たりません。色合いについては、よぉ~く見ると、中央付近がなんとなぁ~くぼんやり赤っぽく見えなくもないですが、この程度であれば問題ないと言って差支えないでしょう。

図8-11 のバックグラウンドモデルでバックグラウンドの勾配が補正されたものが次の画像です。

08_12_afterdbe_ulas
図8-12. 光害除去された画像例

もちろん完璧ではありませんが、厄介と思われた光害が非常にきれいに除去されたと思います。前処理直後の 図8-3 と比較するとこんな感じです。

08_13_dbe_comp
図8-13. DBE前後の比較

かなり印象が変わることに驚くと思います。光害を除去すると薄い光の幕が取り除かれることになるので、コントラストが一気に向上します。また、光害には光害特有の色があるので、それを取り除くことによって初めて天体本来の色を再現できるようになります。

(5) DBE の失敗例

(4) で見たように、DBE による光害除去の効果は絶大です。しかし、バックグラウンドサンプルの打ち場所が非常に重要で、これを上手く設定しないとバックグラウンドモデルがおかしくなってしまい、結果、正しく補正できなくなります。バックグラウンドサンプルをどこに打つべきか。慣れると短時間で設定できるようになりますが、慣れるまでは多少苦労するかもしれません。

では、ここで失敗例を見てみましょう。先ほどの 図8-7 に加えて、1点だけ余分に M16(わし星雲)の上にバックグラウンドサンプルを打点しました。

08_14_fail_bgsample
図8-14. 失敗例(バックグラウンドサンプル)

これで実行したところ、バックグラウンドモデルは次のようになりました。

08_15_fail_ex_bgmodel
図8-15. 失敗例(バックグラウンドモデル)

ひと目でわかる通り、左上が部分的に赤く明るくなっています。(4) の検証ポイント ① ② のいずれにも反していますね。この失敗例では、バックグラウンドサンプルを赤い星雲上に打ちました。バックグラウンドサンプルで与えられた領域は、バックグラウンドですから本来ニュートラルで暗いはずです。にもかかわらず、何かしらの色が特徴的についていたり、明るくなっていたりすると、DBE はその色や明るさを余分なものとしてバックグラウンドモデルにまとめ、それを "Subtraction"(引き算)しようとするわけです。そのため、補正後の画像は次のようになってしまいました。

08_16_fail_ex_afterdbe_ulas
図8-16. 失敗例(補正後の画像)

M16付近の赤い色が不足し、やや暗くなっています。バックグラウンドモデルが赤く明るくなっていた部分ですね。あの分の赤さと明るさが引かれてしまったのです。たった1点誤ったサンプルをとってしまったためにこれだけ見事に失敗します。

DBE を実行したら、バックグラウンドモデルが光害の光の分布として妥当かどうかを検証し、不適当と判断したら、バックグラウンドサンプルの位置を見直して実行しなおしてください。

目次へ戻る この節のトップへ戻る

8-4. DBEや光害除去に関するその他の注意点

DBE はバックグラウンドにある明るさの勾配を補正するツールですので、光害除去だけでなく、周辺減光補正すなわちフラット補正もある程度できます。前処理でフラット補正をしていない場合、"Correction" で "Division"(割り算)を選択してください。そこそこきれいにフラット補正してくれます。

08_17_dbe_division
図8-17. フラット補正する場合には "Division" を選択

ただ、DBE でフラット補正するより、やはりフラットフレームを使って補正する方が正確な補正ができます。とくに、センサ前に付いたゴミの影による減光は、DBE では補正困難です。ゴミの影による減光のような、局所的な勾配の変化をモデル化することは不得手なのです。フラット補正をするのなら、面倒でもやはりフラットフレームを使った方が良いですね。

また、フラットフレームとして実際の夜空を対象としたスカイフラットを撮影する人もいますよね。もちろんそれ自体は別に悪いことではありませんが、注意してほしいことがあります。

実際の夜空を対象にフラットフレームを撮れば、それには光害の明るさも含まれるので、前処理時のフラット補正で光害除去も同時にできると思われるかもしれません。しかし、結論から言うと、それは誤りです。理由は簡単。上に述べた通り、光害の光は天体の光に足し算で加えられます。一方、7-2節で説明した通り、フラット補正は割り算で行われます。足し算で加えられたものを割り算で除去することはできません。それが理由です。

確かに全体としてフラットにはなるでしょう。しかし、補正後の画像には光害の光が含まれたままになります。写っている光の何割かは光害の光で、その分、天体の光が弱められることになります。光害の光を含んだフラットフレームを使ってフラット補正するのは、厳密には(あくまで「厳密には」です)望ましくありません。

目次へ戻る この節のトップへ戻る

つづく

2018年7月 4日 (水)

PixInsightで画像処理を始めよう ~ 第7回 嗚呼、星はいい(2) 前処理

【目次】

7-1. 千億の星の在り処
7-2. Pre processing の準備
7-3. Pre processing の手順概要
7-4. Pre processing 実行
7-5. できた画像を見てみよう


7-1. 千億の星の在り処

今回からいよいよ星野写真の画像処理を始めますが、その素材はこの画像にします。

07_00_lightjpeg
図7-1. 素材画像(JPEG撮って出し)

[撮影データ]
 カメラ:CANON EOS kiss X5(改造)
 レンズ:CANON EF40mm F2.8 STM
 絞り:F3.5
 ISO感度:1600
 露出時間:240秒
 赤道儀:SWAT-200(ノータッチガイド)

撮影カメラは、かつてAPS-Cサイズのエントリーモデルとしてロングセラーを誇った機種なので、お持ちの方も多いのではないでしょうか。レンズは、小さい・軽い・安いと三拍子揃った「パンケーキレンズ」です。軽いので、散歩のお供に持ち歩くのにも最適ですね。この組み合わせを、自由雲台を介して SWAT-200 に載せ、ノータッチで追尾させただけという、大変お気軽な方法で撮影したものです。しかも、三脚まで含めて総重量はわずか 5kg 。別段、特別な機材もソフトも必要ありません。一千億の星があると言われる天の川銀河の中心部は夜空の中で一番明るい対象なので構図も確認しやすく、ピントや露出時間等の設定を間違えなければ(まあ、それが難しいんですけど)、初心者がいきなり撮れてもおかしくないかもしれませんね。しかし、それでもJPEG撮って出しだと、このように色も薄く低コントラストにしか写りません。これを、見違えるような画像に仕上げていきましょう。

目次へ戻る この節のトップへ戻る

7-2. Pre processing の準備

前回、天体写真を明るく高コントラストな画像に仕上げる前に、pre processing(前処理)として主に以下のことを目的とした処理をしましょう、というお話をしました。

 ① ランダムノイズの低減
 ② 固定パターンノイズの除去
 ③ 周辺減光の補正
 ④ バイアスの除去
 ⑤ debayer

このうち、①~④の処理を行うには、必要な写真が幾つかあります。まずは、その説明をしておきましょう。念のため言っておきますが、以下の写真はすべて RAWデータとして撮影してください。

(1) Light Frame(ライトフレーム)

天体を撮影した写真のことです。さすがにこれを撮り忘れることは無いでしょう(笑)。

07_02_lightframe
図7-2. ライトフレーム(ストレッチ有)

このライトフレームに対して①~⑤を目的とした処理を施すことを前処理と呼びます。このうち、ランダムノイズを減らすため(目的①のため)には、ライトフレームをたくさん重ね合わせる必要がありますので、なるべく沢山撮影しておきましょう。今回は、27枚のライトフレームを使用します。
なお、図7-2 はストレッチして適度に明るくしてあります。以下、とくに断りがない限り、適度にストレッチした画像を掲載します。

(2) Calibration Frame(キャリブレーションフレーム)

ライトフレームに対して、とくに②~④の処理を施すために必要な写真がライトフレームとは別に3種類あります。これらをまとめてキャリブレーションフレームと呼びます。面倒ではありますが、これらも撮影しておいてください。

  • Bias Frame(バイアスフレーム)
    • 第6回でも触れましたが、カメラのセンサーに光を当てずに、理想的には露出0秒で撮影した写真です。現実的には露出0秒で撮影することはできないので、そのカメラの最短露出時間で撮影します。光を当てず、最短露出時間で撮影しても、完全に真っ黒な画像にはなりません。これは余分な情報なので、ライトフレームからこれを差し引くわけですね。これが、目的④です。

      ただし、バイアスフレームにもランダムノイズが含まれるので、まずは沢山のバイアスフレームを重ね合わせて平均化することでランダムノイズを減らさないといけません。最短露出時間で撮れば良いので、短時間で沢山のバイアスフレームを撮影することができますね。ちなみに、私は100枚程度のバイアスフレームを使うことが多いです。沢山のバイアスフレームを平均化したフレームを master bias(マスターバイアス) と呼びます。

      07_02_masterbias
      図7-3. マスターバイアス(EOS kiss X5)

  • Dark Frame(ダークフレーム)
    • カメラのセンサーに光を当てずに、ライトフレームと同じ露出時間をかけて撮影した写真です。
      光を当ててはいませんが、これにはライトフレームと同じ固定パターンノイズが「写って」いるはずですので、これを使ってライトフレームに含まれる固定パターンノイズを除去(目的②)します。ただし、ダークフレームにもランダムノイズは含まれるので、ダークフレームも沢山撮って重ね合わせなければなりません。沢山のダークフレームを平均化したフレームを master dark(マスターダーク) と呼びます。

      07_03_masterdark
      図7-4. マスターダーク

      上の画像はマスターバイアスと同じ強さのストレッチをすることでノイズを強調した画像ですが、マスターバイアスに比べてかなりザラザラしていますね。このマスターダークからマスターバイアスを取り除けば、原理的には固定パターンノイズだけを取り出すことができます。その固定パターンノイズをライトフレームから引き算すれば、目的②が果たせます。これを「ダーク減算」と呼びます。(単純にダークフレームを引くことをダーク減算と呼ぶこともあります。)

      しかし、図7-4 のザラザラのほとんどは、実はランダムノイズの残りであることが多いです。ランダムノイズは、引き算すると逆に増えてしまうので、沢山のダークフレームを撮ってランダムノイズを可能な限り減らさないといけないのですが、ダークフレームはライトフレームと同じ露出時間をかけなければならないので、それを沢山撮るとなると大変な時間と労力が必要となります。しかも、最近のデジタルカメラでは固定パターンノイズはあまり目立たなくなってきており、とくに目立つものは他の方法で除去することもできるので、ダークフレームを使っても使わなくても最終画像における効果が変わらないことが多いです。したがって、撮るのに時間がかかるばかりか、苦労して撮ってもそれに見合う効果がないのなら最初から撮影しない(使用しない)、という選択をする人も増えてきています。

  • Flat Frame(フラットフレーム)
    • 光学系(望遠鏡やレンズ)による周辺減光や、センサ前に付いたごみの影による減光の様子だけを捉えた写真です。
      光学系に入ってくる光がムラのない一様な光となるように、通常、白色半透明なアクリル板やトレーシングペーパー、半透明なビニール袋等で対物レンズを覆い、ピント位置や絞り等の光学系に関する条件はすべてライトフレーム撮影時と同じ条件にして撮影します。

      そして、これにもランダムノイズが含まれていますので、沢山撮影して重ね合わせる必要があります。私はこれもまた100枚程度撮影することが多いです。

      さらに、バイアスと固定パターンノイズも含まれていますので、マスターバイアスとマスターダークを使ってこれを取り除きます。ただし、ダークフレームとフラットフレームとでは露出時間が異なることが多いので、フラットフレームに含まれる固定パターンノイズを取り除くには、露出時間分の補正をしてから取り除きます。

      このようにして、バイアスと固定パターンノイズを除去したフラットフレームを沢山重ね合わせて平均化したフレームを master flat(マスターフラット) と呼びます。

      07_04_masterflat
      図7-5. マスターフラット

      これを使ってどうやって光学系の周辺減光を補正するのでしょうか。それは簡単です。

      07_05_flatcorr
      図7-6. 周辺減光の補正

      例えば、図7-5 で中心付近の点 A と周辺部の点 B を考えましょう。点 A の明るさを1としたとき、点 B の明るさが 0.8 だったとしたら、点 B の明るさを 0.8 で割れば点 A と同じ明るさになりますよね。つまり、ライトフレームの各ピクセルの明るさを、マスターフラットの同じ位置のピクセルの明るさで割れば良いのです。PIの場合、正確には、[マスターフラットの同じ位置のピクセルの明るさ]/[マスターフラットの中央値] で割ります。

      こうして、目的③の周辺減光の補正を行うことができます。ちなみに、マスターフラットによって、周辺減光だけでなくセンサ前に付いたゴミの影による減光も補正して、写野全面にわたって同じ明るさの画像にすることができます。マスターフラットは、これが無いと綺麗な写真に仕上げることができないと言い切っても良いほど、非常に重要なフレームです。

      ただし、物理的に光量が足りないところを無理やり増幅させているだけなので、周辺部は中心部に比べてノイズが多くなる等、画質が下がることは間違いありません。あまり周辺減光が大きい光学系の場合には、フラット補正しても周辺部はクロップ(トリミング)する思い切りが必要かもしれません。

以上、3種類のキャリブレーションフレームを用意したら、いよいよ前処理開始です。なお、何度も言っていることではありますが、これらのフレームには、すべてランダムノイズが含まれています。キャリブレーションフレームの枚数が少なくてそのランダムノイズが大きいままだと、せっかくライトフレームを沢山撮っても意味がなくなってしまいますので、ご注意ください。

目次へ戻る この節のトップへ戻る

7-3. Pre processing の手順概要

前処理は以下の手順で行われます。

(1) Calibration(キャリブレーション)

前処理の5つの目的のうち、ライトフレームに対して上記の ②~④ を目的とした処理を施すことを calibration(キャリブレーション) と言い、細かく以下の処理に分けることができます。

  1. マスターバイアスの生成
  2. マスターダークの生成
  3. マスターフラットの生成
  4. 各ライトフレームのキャリブレーション

1~3 でそれぞれのマスターファイルを作り、それらを使って 4 で ②~④ の処理を行います。

(2) debayer

次は前処理の目的 ⑤ の処理です。
キャリブレーションが終わったライトフレームをカラー画像化します。第6回でも説明した通り、debayer しただけでは色調は滅茶苦茶なのですが、前処理では色合わせ(色調補正)は行いません。

(3) Registration(位置合わせ)

第3回の月の写真を重ね合わせるときにも説明しましたが、各ライトフレームに写っている星の位置は微妙にずれることが多いです。どうしてもずれてしまうケースもあれば、わざとずらして写すケースもあるのですが、いずれにしても星の位置がずれて写っています。

07_07_starshift
図7-7. 星の位置がずれている(6:1拡大)

最終的にはこれらを重ね合わせるわけですが、星の位置がずれたまま重ね合わせてしまうと、星が線状に連なって写ってしまったり、重ね合わせ方によっては星が消えてしまったりします。それではせっかく写した天体写真が台無しですので、重ね合わせの前に星の位置をきっちり合わせておく必要があります。

(4) Integration(重ね合わせ)

位置合わせが終わったライトフレームを連続して表示すると次にようになります。

07_08_after_reg
図7-8. 位置合わせ後のライトフレーム(3:1拡大)

こうして見ると、不規則なランダムノイズの様子がよくわかりますね。最後にこれらのランダムノイズを減らすために(目的 ① のために)重ね合わせを行います。これで、最初に述べた前処理の5つの目的の処理はすべて行ったことになります。

目次へ戻る この節のトップへ戻る

7-4. Pre processing 実行

本来、前処理は前節のように幾つもの手順を踏んで行われる処理なのですが、どんな天体を写した写真であっても、やり方は全く同じなので、これらの処理を全部まとめてクリック1発で行えるように、PI には BatchPreprocessing(BPP) というスクリプトが用意されています。
メニューバーから、SCRIPT > Batch Processing > BatchPreprocessing と辿って起動してください。

07_07_startbpp
図7-9. BatchPreprocessingを起動

07_08_bpp
図7-10. BatchPreprocessing

大抵の場合はこの BPP がきれいに処理してくれるので、基本的な使い方だけ知っていれば大丈夫でしょう。

07_09_how2usebpp
図7-11. BPPの基本的な使い方

最低限の設定手順は以下の通りです。以下の (a)~(f) は、図中の (a)~(f) に対応します。

(a) "Add xxxx" ボタンからライトフレームとその他のキャリブレーションフレームを入力
(b) カラー画像なら "Global options" の "CFA images" をチェック
(c) 入力したキャリブレーションフレームがマスターフレームなら、該当するものにチェック
(d) 位置合わせの基準とする画像を選択
左側のファイルリストの中にある場合は該当ファイルをダブルクリックすれば OK
(e) 処理されたファイルを出力するディレクトリを指定
(f) 実行!

たったこれだけです。 難しいことは何一つありません。

なお、前処理の手順や内容等について、以下の動画でもう少し詳細に解説しています。文字情報を読むより、動画を見た方が理解しやすいと思いますので、こちらもご覧いただけると幸いです。どちらの動画も各40分と長いので、お時間のある時にご覧ください。

● Pre processing 前編

  • BPPの使い方を中心に説明しています。PI 初心者でもわかるように丁寧に解説したつもりです。まずはこちらからご覧ください。

● Pre processing 後編

  • BPP を使わずに pre processing を行う方法を解説しています。一つ一つの処理についてかなり詳細に解説していますので、中級~上級者向けですね。PI での Pre processing の詳細な内容も知りたいという方は、こちらをご覧ください。

それから、処理速度も気になるところですよね。天体写真の前処理には非常に沢山の写真を使うので、処理に長い時間がかかるのが普通です。私もキャリブレーションフレームを含めるとかなりの枚数を使って前処理することが多いので、いつも相当な時間がかかります。しかし、何時間もかかってしまうと流石にうんざりしますよね。そこで、参考のために、前処理専用のフリーソフトとして有名でユーザも多い DeepSkyStacker (DSS) と処理時間を比較しました。PC は以下のようなスペックです。

 OS: Windows 10
 CPU: AMD Ryzen 7 2700X (8コア16スレッド)
 メモリ: 32GB
 ストレージ: SSD

計測に使った画像は EOS 6D で撮影したもので、今回素材として使っている画像(図7-2等)ではありません(紛らわしくて済みません)が、以下の枚数を前処理するのにかかった時間を計測しました。

 ライトフレーム: 10枚
 キャリブレーションフレーム: 各10枚

結果は次の通りです。

BPP v1.46  3 分 48 秒
DSS 4.1.1(64bit)  8 分 57 秒(*)

(*) 最後に画像を表示する時間は含みません。

PixInsight はマルチスレッド効率が高いので、マルチスレッドな CPU で処理するとかなり速いです。キャリブレーションフレームにマスターフレームを使えば、さらに時間は短縮できます。ただし、キャリブレーションの処理はシングルスレッドで動く時間が長く、ライトフレームだけでなく、フラットフレームの枚数が多いと時間がかかる傾向が顕著です。

目次へ戻る この節のトップへ戻る

7-5. できた画像を見てみよう

BPP で前処理が終わったら、BPP の output directory に指定したディレクトリ(フォルダ)の下を見てください。master というディレクトリができていて、その下に以下のファイルがあるはずです。

 ・ bias-BINNING_1.xisf
 ・ dark-BINNING_1-EXPTIME_xxx.xisf ("xxx"は露出秒数)
 ・ flat-BINNING_1.xisf
 ・ light-BINNING_1.xisf

上から3つが、順にマスターバイアス、マスターダーク、マスターフラットです。そして、最後のファイルが前処理された目的の画像です。これを開いてみましょう。

メニューバーの FILE > Open... から開いてもいいですし、ファイルを PI に直接ドラッグ&ドロップしても開けます。

07_10_fileopen
図7-12. ファイルの開き方

開くと、次のように非常に暗いことにまず驚くと思います。

07_12_light_binning_1
図7-13. pre processing直後の画像

この画像がこんなに暗い理由は2つあります。一つは、第6回でも説明した通り、もともと RAWデータが暗いということ。そして、もう一つは、PI の画像表示方法にあります。PI が画像を表示するときには、その画像を 16bit化して表示するのですが、デジタルカメラの RAWデータはほとんどが 14bitですよね。ここに4倍の情報量の差があります。

大抵のレタッチソフトや画像表示ソフトで 14bit画像を 16bit化して開くときには、14bit画像を4倍にストレッチして 16bit画像にすると思います。一方、PI は、14bit画像の情報はそのままにして、後ろに空の 14bitを3個くっつけて 16bitにします。したがって、見かけ上、明るさが 1/4 になるわけです。暗くはなりますが、14bit画像の情報はそのままにしているので、別に圧縮しているわけではありませんよ。この辺りのことは、上で紹介した動画(前編)でも最初に説明しています。

いずれにしても非常に暗いので、このままでは何が何だかわかりません。そこで、ScreenTransferFunction(STF)で明るくしましょう。

STF は第3回でも登場しましたが、画像を見かけ上明るくするツールです。この左側にあるマークのうち、鎖マークをオフにしたうえで、原子力マークに似たマークを押すと、自動的にある程度の色調整をしながら適度に明るくしてくれます。これを auto stretch(オートストレッチ)と言います。

07_12_stf
図7-14. STF でオートストレッチ

鎖マークのオンとオフは、R/G/B を合わせて(リンクして)ストレッチするか、それともバラバラに(リンクしないで)ストレッチするか、ということを意味します。鎖マークをオンにしてオートストレッチすることを linked auto stretch(リンクト・オートストレッチ)、オフにしてオートストレッチすることを unlinked auto stretch(アンリンクト・オートストレッチ)と言います。前処理直後の画像は色合わせが未調整なので、リンクせずにオートストレッチしないとおかしな色に表示されてしまいます。

このオートストレッチを使って、BPP で前処理した画像と、ライトフレーム1枚を debayer しただけの画像とを比べてみましょう。

07_15_comparison
図7-15. pre processing の効果

いちいち解説するまでもなく、ひと目で違いがわかりますね。前処理によってノイズが劇的に減り、周辺減光も修正されて綺麗な画像に生まれ変わりました。前処理が如何に重要か、お解りいただけたかと思います。

なお、前回(第6回)もお話した通り、pre processing(前処理)という用語は、天体写真の世界、あるいは PI の中だけで使われる特別な用語というわけではありません。何らかの処理を行う前にノイズを取り除くこと、および次の工程の処理の準備をすることを目的として行われる処理のことを、広く一般的に pre processing(前処理)と呼びます。今回説明した処理は、まさにその前処理と呼ぶに相応しい処理なので、そう呼ばれているわけです。覚えておきましょう。

次回(第8回)からは、この前処理後の画像の処理について解説していきます。

目次へ戻る この節のトップへ戻る

つづく

2018年6月20日 (水)

PixInsightで画像処理を始めよう ~ 第6回 嗚呼、星はいい(1) RAWデータ

【目次】

6-1. RAWデータと撮って出し画像
6-2. 最初にすべき補正処理
6-3. Pre processing (前処理)とは


「星を見ておいでですか、閣下」
「ああ、星はいい」

とは、どこぞの銀河帝国で常勝と称された天才の美青年と、その赤髪の腹心との会話だったかと記憶していますが、やはり星は見ているだけでもいいものです。それを美しい写真に残せたらもっと素敵ですよね。

ということで、第3回から第5回まで計3回にわたって月の写真の画像処理について解説してきましたので、次は星野写真の画像処理について解説しましょう。

月面写真編ではカメラ撮って出しのJPEG画像を使って説明しましたが、今度はRAWデータを使います。いきなり処理を始めても良いのですが、その前に、RAWデータを扱うのであれば知っておいていただきたい予備知識が幾つかありますので、今回はその予備知識について解説します。具体的な処理テクニックの話じゃないのでつまらないかもしれませんが、少しの間辛抱してください。

6-1. RAWデータと撮って出し画像

RAWデータと撮って出し画像に関して、画像処理初心者は(一部経験者でも)様々な誤解を抱いているケースが多いのではないかと思います。そこで、まずはその誤解を解くために、撮って出し画像とは何か、RAWデータは撮って出し画像と何が違うのか、について簡単に解説することとしましょう。

まず、RAWデータは、カメラのイメージセンサの各画素が受けた光の量、言い換えれば輝度の情報しか持っていません。したがって、これを単純に画像化すると、図6-1 のようなモノクロ画像になります。

06_01_rawimage
図6-1. RAW画像例

モノクロ画像であるとともに、非常に暗いことに気づきますね。そうなんです。RAWデータって、実は凄く暗いんです。右下にヒストグラムを表示していますが、山が左の方に寄っていますね。

(注) PixInsight で RAWデータを "Pure Raw" 表示すると、実際にはもっと暗く表示されます。 これは、PI の画像表示が 16bit表示なのに対し、RAWデータが 14bitであることに起因します。 つまり、1/4倍に逆ストレッチされているような形になっているのです。 したがって、RAWデータそのものの明るさを再現するには、PI で開いた直後の RAWデータを4倍に線型ストレッチしないといけません。 図6-1は、4倍に線型ストレッチした後の画像です。これが RAWデータの明るさです。

この画像の一部を拡大すると次のようになっていまして、とりあえず何かが写っていることくらいは分かると思います。

06_02_raw_l
図6-2. RAW画像の拡大図(12倍)

何やら格子状に見えていると思いますが、これは12倍に拡大したものでして、この格子1つ1つが1つのピクセルに相当します。これらの画像を見て何が写っているのかピンと来た人は、たぶん横浜の方でしょう(笑)。

さて、撮って出し画像とは、こうした RAWデータに対して主に以下の処理を施した画像のことです。(本当はノイズ処理等も行われますが、ここでは省きます。)

  1. Debayer(De-mosaic)
  2. 色調整(色調補正)
  3. 明るさ調整

順に見ていきましょう。

(1)  Debayer (De-mosaic)

一般的なデジタルカメラはイメージセンサの前面に 図6-3 のような特殊なカラーフィルターを置き、各画素が R/G/B のいずれかの色のフィルターを通った光だけを受けるようにしてあります。

06_03_bayer_layout
図6-3. カラーフィルターのイメージ図
(あまりじっと見ていると目がチカチカしてきますよ。)

つまり、図6-2 で格子状に見えていた各ピクセルは、それぞれ R/G/B いずれかの色に対応していて、そのフィルターを通った光の輝度情報のみを持っているわけです。こうして撮影されたRAWデータから R/G/B それぞれの画像を生成し、カラー画像化する処理のことを debayer もしくは de-mosaic と言います。詳細はここでは割愛しますが、この辺りのことはインターネット上の様々なサイトで解説されていますので、興味のある方はそちらをご参照ください。図6-1 の RAWデータを debayer した画像が次の 図6-4 です。

06_04_raw_debayer
図6-4. RAWデータ+debayer

(2)  色調整(色調補正)

相変わらず暗いままですが、debayer することでカラー画像にはなりました。しかし、これを見ると、暗いだけではなく、色調(色合い)がおかしいことに気が付きますね。人間が目で見た通りの色合いにはなっていません。そこで次に、debayer で生成された R画像と G画像と B画像の「配合」を調整することによって色合いを調整します。このときに参照されるのが、カメラで撮影するときに設定されていたホワイトバランスです。

ホワイトバランスは、「太陽光」とか「日陰」とか「電球(白熱球)」とかいろいろな値に設定できると思いますが、これらの設定それぞれで3色の画像の配合の仕方が違っています。「太陽光」ならこの配合、「電球」なら別の配合、という具合に。だからホワイトバランスを変えると違う色合いになるわけですね。この配合の仕方はカメラメーカによって予め決められています。図6-4 を「太陽光」のホワイトバランスで色調整するように模擬したものが、次の 図6-5 です。

06_05_raw_debayer_cc
図6-5. RAWデータ+debayer+色調整

(3)  明るさ調整

色合いを調整して、なんとなく自然な色合いになってきました。しかし、これだと依然として暗いままです。そこで、この画像を次のように明るくします。

06_06_raw_debayer_cc_s
図6-6. RAWデータ+debayer+色調整+明るさ調整

これでやっと普通の写真らしくなりましたね。このように、画像を明るくすることを stretch(ストレッチ)と呼ぶことがあります。ヒストグラムを引き延ばすような処理だからそう呼ばれるのでしょう。また、ここまでやってきたような処理をまとめて「現像」と呼びます。フィルム写真の「現像」に倣った呼び方ですね。そして、カメラの画像エンジンでこのように現像された画像が、撮って出し画像というわけです。通常、JPEG形式で保存されることが多いので、「JPEG撮って出し」と言われたりもしますね。

ここで、図6-5 と図6-6 を比較すると、随分と強くストレッチしていることがわかりますね。「わざわざこんなに強くストレッチしなければならないほどに元の画像が暗いのなら、もうちょっと露出時間を長くすれば良いんじゃないの?」と思う人もいるかもしれません。しかし、デジタルカメラが登場するまでは、カメラと言えばフィルムカメラでした。そのフィルムカメラでは、「この明るさの被写体ならこの絞りとこの露出時間でちょうど良いくらいに写った」という経験があったわけで、デジタルカメラでもそれを継承しなければなりません。ところが実際にデジタルカメラでその設定で撮ってみると暗くて仕方がない。だから強くストレッチしている。そういうことなんだと思います。

デジタルカメラで撮影すると、すぐに背面モニタにこの画像が表示されるので、RAWデータもこの撮って出し画像のような色合いと明るさに最初から記録されているのだ、と誤解している人が多いのではないかと思いますが、ここまで見てきたように、実はそうではありません。RAWデータを単純にカラー画像化しただけでは、色調は滅茶苦茶ですし、しかも非常に暗いのです。それをカメラの画像エンジンが瞬時に現像処理して背面モニタに表示しているのです。その撮って出し画像を見て「あ、飽和しちゃった」と思っても、RAWデータそのものは実はまだまだ露出アンダーな状態にあることがほとんどなのです。

レタッチソフトで RAWデータを開いても、これとほぼ同じ画像がポンと表示されますよね。レタッチソフトも、最初に RAWデータを開くときに現像処理をして、現像後の画像をユーザに表示するわけです。でも、レタッチソフトはそんな処理をしているなんて逐一言ったりしない(というより「言う必要が無い」)ので、ユーザはそれに気づかないだけなのです。レタッチソフトでのレタッチ(加工)とは、こうした現像処理が行われた画像を基準として、それに対して追加で行う処理のことです。風景写真や人物写真といった一般的な写真を加工する場合にはそれで十分なのですが、天体写真の場合にはもっと深いレベルから加工する必要があります。そして、そのためにはやはり RAWデータが必要なのです。ちなみに、レタッチソフトで開いた直後の画像は、カメラの撮って出し画像とは色合いも明るさもほんの僅かに違っていると思います。それは、上記の処理(例えば色調整での3色の配合の仕方)がカメラの画像エンジンとレタッチソフトとで僅かに異なるからです。

それともう一つ。ホワイトバランスは撮影時に設定するものではありますが、実は現像時に使われる情報なので、撮影時にどんなホワイトバランスに設定していても、RAWデータそのものは変わりません。したがって、RAWデータを使って画像処理し、色調整を自分でするのなら、撮影時のホワイトバランスの設定に意味はありません。

目次へ戻る この節のトップへ戻る

6-2. 最初にすべき補正処理

天体写真が、一般的な風景写真や人物写真と異なる点(特徴)は何でしょうか。風景写真や人物写真では、カメラから被写体までの距離が様々で、ピントはそれに合わせて変えなければいけないのに対し、天体写真の被写体は常に無限遠にある、ということも特徴の一つですね。それに加えて、最も大きな特徴といえば、何といっても「被写体が暗い」ということでしょう。月や惑星くらいならまだ明るいのですが、星雲や星団といった所謂「星野写真」となると、被写体が非常に暗いので露光に長い時間をかけないと写りません。しかも、写ったところでコントラストが非常に低く、明るさのメリハリがあまりありません。天体写真はこのように暗く低コントラストな写真なので、画像処理して最終的には明るく高コントラストな写真に仕上げなければなりません。しかし、暗く低コントラストな写真を明るく高コントラストにするためには、幾つかの困難を解決する必要があります。

(1)  ノイズ

露光時間が長くなると、困った問題が発生します。それは、ノイズです。ノイズのある写真を明るく高コントラストな写真に処理しようとすると、ノイズまで強調されてしまいます。もちろん、ノイズが目立ったって天体写真には違いないのですが、ノイズが目立つと汚らしく見えてしまいますので、やはりノイズは除去するか、あるいは可能な限り減らした方が良いでしょう。

ノイズにもいろいろな種類があって、これらを分類するには、発生原因で分類する方法とノイズの出現形態で分類する方法があるかと思います。後者で分類するのであれば、主要なノイズとして以下の2つが挙げられます。

  • ランダムノイズ(Random Noise)
    • ランダムノイズという言葉は、月面写真編(第3回)でも出てきましたね。
      ランダムノイズは、全く同じ場所で、カメラの諸設定を全く同じにして撮影しても、毎回異なる位置の画素に不規則に発生するのでランダムノイズと呼ばれます。 センサに光が当たっていなくても素子自体の熱等によって勝手に電流(暗電流)が流れることに起因して現れたり、光が微弱なために計測に揺らぎが発生すること(ショットノイズ/フォトンノイズ)等に起因して現れたりします。 他にも、信号読み出し回路から混入されるランダムノイズもあります。

      発生原因にもよりますが、露光時間が長くなるほど振幅が大きくなるランダムノイズがあるので厄介です。このランダムノイズを画像処理によって減らすには、第3回でも述べたように、沢山の写真を重ね合わせる必要があります。何枚重ね合わせてもランダムノイズを完全に0にすることはできませんが、重ね合わせる枚数が多いほどノイズの振幅を小さくすることができます。

      ただし、複数の画像を重ね合わせる際には、一つ注意が必要です。
      月面写真編でも、月の位置を合わせてから重ね合わせましたよね。あれと同じように、星野写真でも各画像に写っている星の位置を合わせてから重ね合わせる必要があることを覚えておいてください。

  • 固定パターンノイズ(Fixed Pattern Noise)
    • 特定の画素が不自然に明るかったり暗かったりすることで現れるノイズです。例えば下図のようなものです。

      06_07_hotpixel
      図6-7. ホットピクセル

      中央やや右下に1ピクセルだけ非常に明るいピクセルがありますね。周囲に写っている星像と比べると明らかに不自然です。これはどの写真にも常に同じ位置に現れます。こうした固定パターンノイズを特にホットピクセルと呼びます。固定パターンノイズにも発生原因は複数あり、振幅が露光時間に比例する固定パターンノイズもあれば、振幅が露光時間には比例しない固定パターンノイズもあります。しかし、いずれにしても、このノイズは発生する画素の位置が特定できるので、パターンがわかってしまえば画像処理で比較的容易に修正できるノイズと言えます。

      ただ、例えばホットピクセルを含む RAWデータをそのまま現像すると、図6-8 のように、ホットピクセルだけでなくその周囲のピクセルまで滲んだように影響が及んでしまいます。

      06_08_hotpixel
      図6-8. ホットピクセルを現像すると・・・

      これは、debayer時に周辺ピクセルから足りない色情報を集めることでそのピクセルの色情報を補完しているからです。したがって、固定パターンノイズの修正処理は、現像後の画像にではなく、現像前の RAWデータに対して行う必要があります。

(2)  周辺減光

こうしたノイズの他にも困った問題(できれば補正したいもの)があります。光学系(レンズや望遠鏡)の特性に起因する周辺減光がそれです。

06_09_vignetting
図6-9. 周辺減光(少し強調してあります)

写真の中央付近に比べて周辺部は光量が少なくなるため、どうしても暗く写ってしまいます。風景写真や人物写真等では、中央付近のメインの被写体以外はピントが合わずにボケて写っていることが多く、こうした周辺減光は一つの味わいとされることがありますが、天体写真では写野内に写っている天体はすべて被写体であり、ピントは写野全面で同じように合っているはずなので、周辺部でも中央付近と同じ明るさで写っていないと見苦しく感じられてしまうことが多いです。この周辺減光も補正したいものの一つです。

(3)  バイアス

ノイズと周辺減光の他にもう一つ、これは困難というほどのものではないのですが、取り除いておきたいものがあります。

カメラのセンサーに光を当てずに、露出 0 秒で撮影することができたとしたら、それには何が写るでしょうか。現実的には露出 0 秒で撮影することはできないので、そのカメラの最短露出時間で撮影したものが、次の図6-10 です。

06_10_bias
図6-10. バイアス(EOS 6D)

光を当てず、最短露出時間で撮影しても、実は完全に真っ黒な画像にはなりません。これを bias(バイアス) と言います。バイアスは「読み出しノイズ(readout noise)」と言われることもあり、その名の通り、実はこれもノイズの一種なのですが、後の説明のためにここではあえて別出しにします。

デジタルカメラでは、たとえ露出0秒でも常にこのバイアスが「写り」ます。すべての写真は、このバイアスの上に光の情報が記録されたものです。つまり、デジタルカメラで写した写真はすべて、常に下駄を履いた状態になっているのです。本当の伸長を測るには、その下駄を脱いでもらわないといけません。この余分な下駄も除去しましょう。

目次へ戻る この節のトップへ戻る

6-3. Pre processing (前処理)とは

ということで、星野写真を画像処理するのであれば、まず最初に主に以下の補正を目的とした処理を行います。

 ・ ランダムノイズの低減
 ・ 固定パターンノイズの除去
 ・ 周辺減光の補正
 ・ バイアスの除去

これらの補正を施す処理のことを、まとめて pre processing あるいは「前処理(まえしょり)」と呼びます。一般的な画像処理の世界でも、何らかの目的で画像処理を行う前に、ノイズを取り除くこと、および次の工程の処理の準備をすることを目的として行われる処理のことを前処理と言うことがありますから、それと同じです。

これらの補正処理は、どんな天体を写した写真であっても共通の方法と手順で処理することができます。つまり、人間がやる必要はなく、クリック一発でパソコンに処理させることができるということです。パソコンは元々そういうこと(決められたことを決められた手順でやること)が得意ですから、人間様がやるよりよっぽど手早くきれいに処理してくれます。

さらに、これらの補正処理と同様、debayer も決まり切った処理なので、debayer も加えて前処理と言います。PixInsight には、この前処理を自動的に実行してくれるプログラムが備わっていますので、次回は PI での前処理のやり方を説明しましょう。

目次へ戻る この節のトップへ戻る

つづく

2018年6月 6日 (水)

PixInsightで画像処理を始めよう ~ 第5.5回 【補足】 Image Processing Tips

【目次】

5.5-1. Image Processing Tips のご紹介
5.5-2. BackgroundNeutralization(BN)
5.5-3. LocalHistogramEqualization(LHE)


5.5-1. Image Processing Tips のご紹介

この連載をご覧の方の中には既にご存知の方もいらっしゃるかも知れませんが、私は Google+ に Image Processing Tips というコレクションを作っています。

Ipts_title

図5.5-1. Image Processing Tips

(上図をクリックするとページを開きます。)

これは、天体写真の画像処理方法の例を Tips 形式でまとめたコレクションでして、その中に 「PixInsightでの画像処理」 と銘打ったシリーズ記事を書いています。初期のころは大した内容は書いていませんでしたが、だんだんとプロセスのアルゴリズムを絡めた詳細な解説を載せるようになってきました。今ではもう、すっかり天体写真の画像処理経験者向けの内容になっています。

この「画像処理入門」で紹介するプロセスの幾つかは、その中でやや詳細に解説しています。より詳しい解説に興味をお持ちの方は、こちらをご覧ください。

この入門の第5回に出てきたプロセスのうち、次の2つのプロセスについては Image Processing Tips でも紹介しています。

目次へ戻る この節のトップへ戻る

5.5-2. BackgroundNeutralization(BN)

Ipts_bn_title
図5.5-2. PixInsightでの画像処理(その14) - BackgroundNeutralization
 
(上図をクリックするとページを開きます。)

BNは、任意の指定領域のピクセルの中央値が R/G/B で同じになる、つまりニュートラルになるように画像全体の色を調整するプロセスです。指定領域の中に星や星雲が含まれてしまっている場合には、「この値以上明るいピクセルはバックグラウンドではないから除外しなさい」という閾値を設定することもできます。

通常、RAWデータを debayer(カラー画像化)しただけの画像は、色合わせが全くできていません。したがって、何らかの基準に基づいて色合わせをしないといけないのですが、その基準の一つが「バックグラウンドはニュートラルなはず」というものです。

このプロセスによってバックグラウンドをニュートラルにするだけで、画像が見違えるほど自然な色合いになることがあります。天体写真の画像処理においては、一度はこのプロセスを使うことになるはずですので、皆さんもお手持ちの色んな画像で試してみてください。

なお、このプロセスは、画像がリニアな状態のうちにやっておくべきプロセスです。つまり、かなり早いうちにやっておく処理です。また、一度バックグラウンドをニュートラルにしたら、以降の処理でこれを崩すような処理をするべきではありません。

目次へ戻る この節のトップへ戻る

5.5-3. LocalHistogramEqualization(LHE)

Ipts_lhe_title
図5.5-3. PixInsightでの画像処理(その16) - How to enhance constrast

(上図をクリックするとページを開きます。)

LHEは、いわゆる「ローカルコントラスト」を上げるためのプロセスです。「ローカルコントラスト」という言葉は、天体写真の画像処理で時々耳にする言葉ではありますが、その意味をきちんと理解して話をしている人は果たしてどれほどいるでしょうか。「ローカル」も「コントラスト」もそれなりに意味が解るのに、その2つが合わさると意味がよく解らなくなる。そんな言葉の好例かもしれませんね。

一般的に、同じ画像であれば、ヒストグラムの山がなだらかであるほど(山の幅が広いほど)コントラストが高い画像になります。であれば、いっその事ヒストグラムを真っ平にしてしまおう、というのが Histogram Equalization(HE)という処理で、それを発展させた Contrast Limited Adaptive Histogram Equalization(CLAHE)という処理が LHE のベースとなっています。任意のピクセルを中心とした局所的な領域でヒストグラムをとって、その領域で HE を行おう、というのが CLAHE の根本的な発想です。世の中にある、ローカルコントラストを操作するツールは、大抵この CLAHE の派生形でしょう。

それはともかく、LHE は BN と同様にパラメータの種類が比較的少ないので、いろいろと試して自分なりの使い方を模索してみてください。ただし、2点ほど注意点があります。まず、Kernel Radius を大きくすればするほど処理に時間がかかるようになります。もっとも、大抵は Real-Time Preview を見ながらやりますし、最近はハイスペックなパソコンも多くなってきましたから、あまり問題にはならないかもしれません。

2つ目は、この処理を施すとノイズが一気に目立つようになるということです。あまりノイズが目立つようなら、後でノイズリダクションも実行すると良いでしょう。

目次へ戻る この節のトップへ戻る

<つづく>

PixInsightで画像処理を始めよう ~ 第5回 花有清香月有陰(3)

【目次】

5-1. 色合いを変えてみよう
5-2. コントラストを強調しよう
5-3. 彩度を調整しよう
5-4. RAWデータから処理すると・・・


前回の第4回までで最低限の処理は終わりました。 ここから先は、お好みで、あるいは必要に応じてやる、ということで良いと思います。

5-1. 色合いを変えてみよう

第3回から始めた月の画像処理は、カメラ撮って出しのJPEG画像を元画像としてやってきました。カメラ撮って出しのJPEG画像というのは、概ね人間が目で見た通りの色合いになるように、ある程度カメラの画像エンジンで処理が施されたものです。前回までの写真を見てお解りの通り、月は全体的に黄色っぽく写っていますが、実際に望遠鏡で月を覗くと、やっぱり全体的に黄色っぽく見えるはずです。なので、あえてその色を変える必要もないのですが、黄色一辺倒というのもあまり面白みがありません。そこで、少し色合いを変えてみることにしましょう。

色合いを変えるにも様々な方法がありますが、今回は、人の目に頼らず、機械的に色調整をしてみます。

(1)  バックグラウンドをニュートラルに

色調整をするうえで、まず最初にやらなければいけないのは、背景(バックグラウンド)の色調整です。背景の宇宙はどの色にも偏っていない(ニュートラルである)はずですよね。逆に言うと、背景宇宙の色が、写真全体の色を決めるうえで一つの基準になるというわけです。なので、まずは背景宇宙の色の偏りをなくしましょう。

その準備として、図4-3 と同様の手順で、背景の一部を preview 領域で囲んでください。要は、その領域の色をニュートラルにしようというわけです。

囲む領域は背景であればどこでも構いませんが、月の光は強烈なため、地球の大気によって強く散乱されて、月のすぐ近くはニュートラルな色ではなくなっています。そこで、なるべく月から離れた領域を囲むと良いでしょう。(あまり気にする必要もありませんけどね。)

05_01_bnpreview
図5-1. ここをキャンプ地バックグラウンドとする

バックグラウンドとする領域を preview 領域で囲んだら、メニューバーから PROCESS > ALL Processes > BackgroundNeutralization と辿って BackgroundNeutralization(BN) を起動します。

05_02_bn
図5-2. BackgroundNeutralization

Reference image に先ほど囲んだバックグラウンドの preview 領域を指定して、図4-5 と同じ要領で、左下の三角マークをドラッグ&ドロップして実行します。

05_03_applybn
図5-3. BN実行

このプロセスは、Reference image の範囲のピクセルの平均(正確には中央値)がニュートラルになるように色調整します。大事なのは、バックグラウンドだけをニュートラルに色調整するわけではなく、あくまで画像全体を色調整しているという点です。バックグラウンドがニュートラルになるように、画像全体の色を等しく調整しているということです。

この画像の場合には、元々バックグラウンドがニュートラルに近いので大して変化がありませんが、元々のバックグラウンドの色が大きく偏っている画像の場合には、ここで色合いが大きく変化します。

なお、レタッチソフトを使ってこの操作をやる場合には、R/G/B のヒストグラムを見ながら手動で調整することになると思いますが、手動でやると、正確にニュートラルにすることはまず不可能です。こういった作業はコンピュータにやらせた方が速いし、なにより正確です。

(2)  明るいところを白く

背景の色をニュートラルにしたら、今度は「白」の基準を決めます。

まず、月の表面の中で、特に明るい部分を preview 領域で囲みます。囲む範囲は小さくて構いません。その領域の色を、今度は白だと仮定しようというわけです。

05_04_ccpreview
図5-4. 「ここは白い」と仮定する

もちろん、この領域が厳密に白であるはずなんかないのですが、ここは「色合いを変えてみよう」という話なので、とりあえずこの領域が白であるとした色調整をしてみます。

白の基準(white reference)とする領域を preview 領域で囲んだら、メニューバーからPROCESS > ALL Processes > ColorCalibration と辿って ColorCalibration(CC) を起動します。

05_05_cc
図5-5. ColorCalibration

CCを起動したら、一番上の White Reference の Reference image に 図5-4 で新たに囲んだ preview 領域を指定します。

次に、Structure Detection のチェックを外します。(外さなきゃいけないというわけではないんですけどね。)

そして、下の方にある Background Reference の Reference image に (1) で選んだバックグラウンド領域を再度指定します。

これでとりあえず準備はOKなので、また左下の三角マークをドラッグ&ドロップして実行します。

05_06_applycc
図5-6. CC実行

色が全体的に白っぽくなりましたね。実際に月を目で見た色合いとは少し異なると思いますが、月の表面の微妙な色の違いを表現するには、こちらの方が好都合だったりします。

ちなみに、ここでやった色調整は、レタッチソフトのレベル調整でも似たようなことができると思います。でも、レタッチソフトのレベル調整では、白や背景の基準とする領域は点でしか指定できないのがほとんどでしょう。それに対して、PixInsightは任意の領域の平均を基準とすることができます。

目次へ戻る この節のトップへ戻る

5-2. コントラストを強調しよう

ここまで、画像をシャープにしたり色合いを変えたりしてきましたが、ここで月全体をもう一度よく見ると、月の明るい部分(太陽の光が当たっている方)は、どこも一様に明るく、コントラストが低いと感じます。例えば、危難の海周辺は全体的に明るくなっていて、海がはっきりしません。

そこで、月全体のスケールでコントラストを高くしましょう。コントラストを上げる方法も幾つかありますが、今回は2つのプロセスを紹介します。

(1)  HDRMultiscaleTransform

ツールバーの PROCESS から HDRMultiscaleTransform(HDRMT)を起動します。

05_07_hdrmt
図5-7. HDRMultiscaleTransform

HDRMTは、ベタっと一様に明るくなってしまっている領域のコントラストを、各ウェーブレットレイヤーのスケールで回復させる効果があります。一番上の Number of layers はデフォルトでは "6" になっていますが、これを変えて数パターン実行してみましょう。

05_08_hdrmt
図5-8. HDRMT実行結果

人それぞれ好みもあるかと思いますが、この場合は 7 辺りが良いのではないかと思います。ベタっと明るかった危難の海周辺のコントラストが高くなり、海とそうでない部分がはっきりと区別できるようになりました。

(2)  LocalHistogramEqualization

2つ目に紹介するプロセスは、LocalHistogramEqualization(LHE)です。

05_09_lhe
図5-9. LocalHistogramEqualization

LHEは、contrast limited adaptive histogram equalization というアルゴリズムによって、所謂ローカルコントラストを上げるプロセスです。

第4回で登場した MultiscaleLinearTransform と同様、LHEにも Real-Time Preview 機能があるので、左下の白丸ボタンを押して Real-Time Preview 画面を見ながらパラメータを調整していきます。パラメータの数は少ないですし、決まった手順等はないのですが、以下のような手順で操作するのがやり易いかと思います。

  1. Contrast Limit を少し上げる (2. の効果が見やすくなる)
  2. Kernel Radius を調整する
  3. Amount (1. 2. で調整した画像と元の画像とのブレンド比) を調整する

05_10_rtp_lhe
図5-10. Real-Time Preview で見た LHE の効果

調整が終わったら、Real-Time Preview を閉じ、左下の三角マークをドラッグ&ドロップして適用します。

目次へ戻る この節のトップへ戻る

5-3. 彩度を調整しよう

画像の色が全体的に薄い場合には、CurvesTransformation(CT)を使って彩度を上げることができます。

05_11_ct
図5-11. CurvesTransformation

これは、レタッチソフト等での「トーンカーブ」に相当する変換ツールです。

3.5-2章で HistogramTransformation(HT)の説明をしましたが、あれと似ています。ただ、HTは Shadow/Midtone/Highlight を変えることで変換曲線を調整したのに対し、CT は変換曲線の形を直接変えることができます。

05_12_ct_ex
図5-12. CTでの変換曲線の例

さらに、このCTは、画像の明るさを変換するだけでなく、色の色相や彩度等も変換することができます。

CTの画面の一番右の下から4つ目の "S"(Saturation の S) をオンにすると、彩度を調整するモードになります。その状態で曲線を左上の方に反らせて実行すると、図5-13 のようになります。

05_13_applyct
図5-13. CT実行例

図5-13 のサイズだとややわかりづらいかもしれませんが、月表面の地質による色の違いがはっきりとわかるようになります。

ちなみに、図5-13で突然月の向きが変わっていますが、メニューバーの IMAGE > Geometry から画像の向きを変えることができます。

05_14_geometry
図5-14. 画像の向きを変える

目次へ戻る この節のトップへ戻る

5-4. RAWデータから処理すると・・・

ここまでは、カメラ撮って出しのJPEG画像を使って処理をしてきましたが、JPEG画像は RAWデータをカラー画像化(debayer)して、色合わせをして、さらに適度に明るくしたものです。したがって、RAWデータから処理する場合には、これらの処理を加える必要があります。具体的には、だいたい以下の通りの手順となります。 

  1. カラー画像化(debayer)
  2. 位置合わせ&重ね合わせ(FFTRegistration)
  3. 色合わせ(BackgroundNeutralization, ColorCalibration)
  4. 画像復元(Deconvolution)
  5. 明るくする(HistogramTransformation等)

色合わせは、重ね合わせ直後にやるのが望ましいです。しかし、そのままだと非常に暗いはずですので、STFで見かけ上の明るさを明るくしてから処理をしてください。実際に明るくするのは最後で結構です。

RAWデータから処理した例がこちらです。

05_15_raw
図5-15. RAWデータからの処理例 (クリックすると高解像度版が見られます)

同じように処理したはずなんですが、JPEG画像から処理したものとはまた違った色合いになっています。月表面の地質による色の違いは、こちらの方がわかりやすいかもしれませんね。

さて、第3回から計3回にわたって、月の写真を使った画像処理方法をご紹介してきました。 もちろん、他にも色々な処理方法がありますので、研究してみて下さい。

次回(第6回)からは、星野写真の画像処理方法を解説したいと思います。

目次へ戻る この節のトップへ戻る

つづく

2018年5月21日 (月)

PixInsightで画像処理を始めよう ~ 第4.5回 【補足】 Layerとは? Deconvolutionとは?

【目次】

4.5-1. レイヤー
4.5-2. Deconvolution


4.5-1. レイヤー

第4回の Deconvolution や MultiscaleLinearTransform の処理の説明で Layer(レイヤー)という言葉が出てきました。この Layer とは、正確に言えば Wavelet Layer(ウェーブレット・レイヤー)なんですが、そんなこと言っても余計にわかりませんよね。
ちゃんと理解するには、Wavelet解析を知らないといけないのですが、とりあえずそんなもの知らなくても、簡易的に画像を各レイヤーに分解することはできます。

メニューバーから SCRIPT > Image Analysis > ExtractWaveletLayers と辿って ExtractWaveletLayers スクリプトを起動します。

45_1_ewlscript
図4.5-1. ExtractWaveletLayers

Target image に 図4-4 の Preview01 を選んでこのまま OK ボタンを押すと、次のように計6枚の画像が出力されます。

452_layers_all_l
図4.5-2. 分解されたレイヤー画像

ここで、Layer00 という画像がウェーブレット・レイヤーの Layer1 に相当します。以下、Layer01 が Layer2 に、Layer02 が Layer3 に・・・と、それぞれ相当します。
これらのうち、小さなレイヤーの画像を見ると、微細な構造は見えていますが、大きなスケールの構造は消えているのがわかると思います。逆に大きなレイヤーの画像を見ると、微細な構造は見えなくなって、大きなスケールの構造が写るようになっています。一言で言うと、各レイヤーには、月の表面の構造の輪郭が色んなスケールで写っていると言い換えても良いでしょう。

前回の 4-1.(2) MultiscaleLinearTransform の処理では、 MLT の Bias の値をプラス方向に少し動かしましたが、これは、そのレイヤーの比重を大きくして、そのレイヤーを強調するという処理です。図4-10 の例の場合、Layer2 と Layer3 の Bias を大きくしました。このレイヤーには、クレーター等の輪郭がとくにはっきりと写っていますので、それが強調されたというわけです。ちなみに、Layer1 にはより微細な構造が写っているので、これも強調した方が良いんじゃないかと思うかもしれませんが、一般的には、このレイヤーにはピクセル単位のノイズも写っていますので、Layer1 の Biasを大きくすると、そうしたノイズも強調されてしまうということに注意が必要です。
図4-10 の月の画像の場合には、実はそんなにノイズは含まれていなかったので Layer1 を強調しても良かったのですが、通常は、小さなレイヤーを扱う時には常にノイズを意識しなければならないということを覚えておきましょう。

目次へ戻る この節のトップへ戻る

4.5-2. Deconvolution

第4回でも紹介した通り、Deconvolution は、PI を代表する優れものプロセスの1つです。このプロセスの原理と言いますか、基本的な考え方について、ここで極簡単に解説しましょう。1つだけ数式が出てきますので、数式を見ると隣の人の首を絞めたくなるという人は読み飛ばしてください。(笑)

さて、これまで何回か言っている通り、地球上で分厚い大気や何らかの光学系を通して見る像はぼやけています。しかし、本来はシャープな像だったはずです。

図4.5-3 を見てください。

45_3_deco
図4.5-3. Deconvolution の考え方

理想的な点光源像が大気や光学系を通した結果、h(x) で表されるような広がりを持つぼやけた像になるとします。すると、本来 f(x) で表されるはずだった天体の像は、式(1) のような g(x') として観測されることとなります。

この式(1) が convolution で、日本語では畳み込み積分とか重畳積分とか言われるものです。そして、h(x) のことを point spread function(PSF)、日本語では点像分布関数等と言います。
ここで、知りたいのは天体の本来の像である f(x) で、これがよくわからないわけです。しかし一方、g(x') は観測された像なのでよくわかっています。なら、あとは h(x) がわかれば、あるいはこれを何らかの形に仮定すれば、f(x) もわかるでしょう、というのが Deconvolution の発想です。発想自体はそんなに難しくはありませんね。

第4回で調整した Deconvolution のパラメータ StdDev は、この PSF の標準偏差です。例えばこれが 0 だとすると、PSF はδ関数ということになり、本来の理想的な点光源像のままで全くぼやけていないという意味になりますから、Deconvolution をしても変わらないということになります。PI の Deconvolution では、StdDev に 0 は指定できませんが、これを小さくすると、Deconvolution を実行しても元の画像のままに近くなる(ほとんど変わらなくなる)、というのはすぐに理解できると思います。
もう1つのパラメータ Shape は PSF の尖度のことで、デフォルトの 2 が正規分布であることを意味しているようです。尖度というと、0 を正規分布とするのが普通だと思いますが、ここは注意が必要です。

ともかく、パラメータを調整するときには、まず StdDev から調整し、次に Shape のスライダーを動かすという手順で、両パラメータのスイートスポットを追い込むと良いでしょう。なお、画像に星が写っている場合には、その星像を元に PSF を推定する DynamicPSF というプロセスもありますが、ここでは紹介だけに止めておきます。

目次へ戻る この節のトップへ戻る

<つづく>

PixInsightで画像処理を始めよう ~ 第4回 花有清香月有陰(2)

【目次】

4-1. 画像復元
 (1) Deconvolution
 (2) MultiscaleLinearTransform


4-1. 画像復元

第3回では、FFTRegistration によって沢山の画像を重ね合わせることでノイズを減らし、滑らかな画像を得ることができました。
しかし、図3-7 や図3-8 をよく見ると、確かに滑らかにはなったものの、なんだか少しぼやけていますよね。これは、第1回でも触れたように、主に地球の大気の影響です。地上から分厚い大気の層を通して撮影する以上、どんなにピントを合わせても多少ぼやけて写ってしまうものなのです。でも、元々ははっきりくっきりした像だったはずです。それが、地球の大気によってぼけた像になってしまったのです。地球の大気だけでなく、レンズ等の光学系の収差によっても、ぼやけたり歪んだりすることがあります。
そのように光学系や大気等、様々な影響によって劣化した画像を修正し、元のはっきりくっきりした画像を再現することを「画像復元」と総称したりします。今度は、この少しぼやけた月の写真を画像復元して、はっきりくっきりした画像にしましょう。

(1) Deconvolution

画像復元にはいろいろな方法がありますが、今回ご紹介するのは、Deconvolution というプロセスです。この Deconvolution は、PI を代表する「優れものプロセス」の一つでして、一言でいえば Convolution の逆です。「じゃあ、Convolutionって何だ?」ということになりますが、これを単純に翻訳すると「畳み込み積分」とか「重畳積分」という日本語訳が出てくると思います。どっちにしても頭の上に「?」マークが2万個くらい出てきそうですね。(笑)
Deconvolution の考え方については、第4.5回の補足で少しだけ詳しく解説していますので、興味のある方はそちらを見ていただくとして、ここではそんな数学的な難しいことは置いといて、とりあえず使ってみることにしましょう。

メニューバーから、PROCESS > Deconvolution > Deconvolution と辿って起動してください。

04_01_select_deconvolution
図4-1. Deconvolutionを起動

もちろん、PROCESS > All Processes > Deconvolution でも構いません。
すると、下図のような画面が立ち上がります。

04_02_deconvolution
図4-2. Deconvolution

さっそく Deconvolution を実行してみたいところですが、Deconvolution をいきなり画像全体に適用すると処理に少々時間がかかるので、その前に一部分だけを切り取って、その中だけで、いわば「試し処理」をしてみることにします。

ツールバーの "New Preview Mode" をオンにして、どこでも良いのであまり大きくならない範囲を選択してください。

04_03_select_preview
図4-3. Preview領域を選択

すると、画像のウィンドウの左側の枠に "Preview01" というタブが現れます。そして、それをクリックすると、先ほど選択した preview 領域だけが表示されるようになります。

04_04_preview01
図4-4. Preview領域だけを表示

この領域に対して、Deconvolution の試し処理を施してみます。
Algorithmオプションは、まあどれでも良いんですが、デフォルト通り "Regularized Richardson-Lucy" を選択してみましょう。Richardson-Lucy法というのは、光学設計に詳しい方なら馴染み深いのではないでしょうか。他のオプションも、まずはデフォルトのままで実行してみます。
プロセスの実行は簡単で、プロセス画面の左下にある四角マークを押すか、もしくは下図のように三角マークを処理対象の画像にドラッグ&ドロップするだけです。

04_05_deco_dd
図4-5. Deconvolution実行

これだけでも画像が少しくっきりとしてくると思います。

ここで、Preview画面に対しては、ツールバーの下図の矢印マークを押すことでプロセス実行の Undo/Redo を繰り返し表示することができます。これで、プロセス実行前後の画像の変化を見て、その効果を確認することができるわけです。

04_06_undoredo
図4-6. Undo/Redo Preview

デフォルトパラメータでどの程度の効果があるかがわかったら、次に、StdDevShape の値を少し変更して再度実行してみてください。この2つのパラメータを変えて何度か実行して Undo/Redo を繰り返していると、そのうち2つのパラメータのスイートスポットがわかってくると思います。どこがスイートスポットなのかは、画像によっても違いますし、人それぞれの好みもあるかと思いますが、私は下の画像くらいが良いのではないかなと思います。

04_07_deco_sweetspot
図4-7. Deconvolution実行例

ぼやけていた画像がだいぶくっきりしてきましたね。2つのパラメータのスイートスポットがわかったら、Iteration を 30~50くらいに上げて再度確認し、それで良ければ今度は画像全体のタブに切り替えて、画像全体に対して実行してください。画像の画素数が大きくなればなるほど、また Iterationの回数が多くなればなるほど、処理には時間がかかるようになるので、そのおつもりで。

04_08_deco_doall
図4-8. パラメータが決まったら画像全体に実行

これで、Deconvolution 完了です。

目次へ戻る

(2) MultiscaleLinearTransform
 
Deconvolutionで画像復元したら、今度は画像の輪郭を強調しましょう。輪郭を強調すると、画像がシャープに見えるようになります。

使うプロセスは、MultiscaleLinearTransform(MLT) です。UnsharpMask というプロセスでも似たような効果が得られるのですが、今回は MLT を使ってみます。

04_09_mlt
図4-9. MultiscaleLinearTransform

これも Deconvolution 同様、なんだかパラメータやオプションがいっぱいあって、見ただけで「もうわけわからん!」と言いたくなりますが、この MLT は、画像をシャープにしたりぼかしたり、あるいはノイズを減らしたりと、色々な用途で万能的に使えるプロセスです。おまけに MLT には Real-Time Preview 機能がついていて、いちいち実行しなくてもリアルタイムで効果を確認することができます。
まず、図4-4と同様に月のPreview領域だけを表示するようにし、MLTの左下の丸印のボタンを押して、Real-Time Preview 画面を表示します。
そして、2もしくは3くらいの比較的小さな Layer(レイヤー)で Bias のスライダーを右に動かします。

04_10_mlt_beforeafter
図4-10. Real-Time Preview上での MultiscaleLinearTransform実行例

Bias をプラス方向に動かせば、そのレイヤーが強調されます。
このレイヤーについても補足でもう少し詳しく解説しますが、この処理で月のクレーター等の輪郭が強調されます。人間の目は、物の輪郭が強調されるとシャープになったように見えるから不思議ですね。それはともかく、Real-Time Preview を使えば、パラメータ値を変えるとその都度すぐに効果が確認できるので便利です。Real-Time Preview で Bias値のスイートスポットがわかったら、Deconvolutionのときと同様、月の画像全体に MLT を実行します。なお、さきほども言った通り UnsharpMask でも似たような効果が得られるので、気になる方は UnsharpMask も試してみて、気に入った方のプロセスを選択してください。

では、ここまでの画像処理によって、撮って出し画像がどのように変わってきたのか、繋げて見てみることにしましょう。

04_11_sofar
図4-11. MLTまでの処理結果

どうですか?だいぶ印象が変わって見えるようになったと思います。

今回は、Deconvolution にしろ MLT にしろ、必要最小限のパラメータしか変更していませんが、それでもかなりの効果が見られます。どちらのプロセスもパラメータが沢山ありますので、色々とパラメータを変えて試してみて、自分の好みに合ったパラメータセットを見つけてみて下さい。

目次へ戻る

つづく

«PixInsightで画像処理を始めよう ~ 第3.5回 【補足】 Histogram と HistogramTransformation