2018年9月14日 (金)

PixInsightで画像処理を始めよう ~ 最終回 嗚呼、星はいい(8) 主なレタッチ処理2

【目次】

13-1. 赤と青を強調する
 (1) Lab色空間を利用して赤っぽい領域を強調
 (2) マスクをもう少し工夫しよう
 (3) 青を強調
13-2. 最後のまとめ
 (1) PixInsight こそ初心者向け
 (2) 初心者でも気軽に天体写真を


前回まで12回に亘って続けてきた本連載も今回でいよいよ最終回です。今回も、まずは前回に引き続いて、主なレタッチ処理についてご紹介していきたいと思います。

13-1. 赤と青を強調する

13_01_org
図13-1. 元画像

ここまで、PCC で測光的な手法で色合わせをし、ArcsinhStretch でその色を保存したまま明るくしたのですから、色合いに関してはもうこれ以上何もする必要はないはずです。でも、ときには赤い星雲や青い星雲をもう少し鮮やかに目立たせて美しく仕上げたくなる、というのは人情というものでしょう。

しかし、トーンカーブ等で単純に R(あるいは B )を増やすと、赤(青)くない領域までもが赤(青)くなって、全体の色合いが変わってしまいます。なので、赤っぽいところだけをより赤く、青っぽいところだけをより青く強調する必要があります。そのためには、赤っぽいところだけ、あるいは青っぽいところだけを抽出したマスクを作れば良いのです。

そのマスクを作る方法には複数あって、最も代表的なものは、G 画像を基準に R(B)画像の方が明るいピクセルだけを抜き出す、つまり "R - G" や "B - G" といった引き算した画像をマスクにするという方法があります。しかし、ここでは別の方法を紹介しましょう。

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

(1) Lab色空間を利用して赤っぽい領域を強調

それは、Lab色空間を利用するという方法です。Lab色空間と言っても厳密には何種類かあるのですが、ここでは CIE L*a*b*(CIELAB)色空間 のことを指すものとします。この Lab色空間にはその名の通り L、a、b、の3つの座標軸があります。まず、L は明度を表します。そして a は、赤(マゼンタ)か緑かを表す座標に対応していて、a が大きな値であるほどマゼンタっぽい色、小さな値であるほど緑っぽい色になります。一方 b は、黄色か青かを表す座標に対応していて、b が大きな値であるほど黄色っぽい色、小さな値であるほど青っぽい色になります。この Lab色空間で見て、赤(マゼンタ)っぽい、あるいは青っぽいピクセルを抜き出してみましょう。PixelMath(PM)に以下のように記述してみてください。

RGB/K:CIEa($T)-m
Symbols:m=0.5

13_02_pm_r_a
図13-2. PixelMath

CIEa($T) は、各ピクセルの Lab色空間での a成分の値を返してきます。したがって、m=0.5 であれば、a の座標値が 0.5 よりも大きなピクセルだけを抜き出すことになります。この PM を 図13-1 に対して実行すると次のような画像が出力されます。

13_03_output_pma
図13-3. 出力画像(STFでオートストレッチ)

これがマスクの元になります。どの辺の色を強調させたいかによって m の値を適宜変えてください。これをさらに STF や HT で調整して以下のようなマスク画像を作ります。

13_04_a_mask1
図13-4. aマスク1

元画像でとくに赤を目立たせたい領域だけが残るようにするわけですね。便宜上、これを aマスク と呼ぶことにしましょう。これを元画像にかけて、aマスクが白っぽくなっている部分の色を強調します。

色を強調するには、通常、CurvesTransformation(CT)が使われることが多いと思います。CT はこの連載でも既に何度か紹介していますが、これは所謂トーンカーブのツールです。マスクで選択された領域の赤い色を強調したければ、CT を使って以下に示すように、component selection から Red channelCIE a* component、もしくは Saturation を選択してカーブを左上に反らせます。

13_05_amask1_r
図13-5. Red channel を増幅

13_06_amask1_a
図13-6. CIE a* component(a成分)を増幅

13_07_amask1_s
図13-7. Saturation(彩度)を上げる

Lab色空間は人間の視覚に近い色空間であるためか、少し値を変えただけで色合いが大きく変わったように見えます。個人的には彩度を上げるのが良いかと思いますが、これは好みの問題ですので、一度試したうえで自分なりに選択してください。

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

(2) マスクをもう少し工夫しよう

図13-4 のような aマスクでももちろん構いませんが、このマスクは明るい領域ほどより白っぽくなっていますね。これだと、元々明るかった領域の色がより強調されることになります。

明るい領域だけではなく、むしろ「暗いけど赤い領域」を目立たせるようなマスクを作ってみましょう。今度は PixelMath に次のように書いてみてください。

RGB/K:(CIEa($T)-m) / CIEL($T)
Symbols:m=0.5

CIEL($T) は、各ピクセルの Lab色空間での L成分の値、すなわち明るさです。それで割るということは、同じ程度の赤さであっても、より暗いピクセルの方が大きな値になるということです。これで作った aマスクが次の画像です。

13_08_a_mask2
図13-8. aマスク2

先ほどの 図13-4 の aマスクとはちょっと趣が異なりますね。「より赤い」だけでなく「より暗い」ピクセルがより白くなっています。このマスクを元画像にかけて CT で彩度等を強調すると、次のようになります。

13_09_amask2_s
図13-9. aマスク2で赤を強調

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

(3) 青を強調

Lab色空間を利用して青っぽい領域を強調するようなマスクを作る場合には、今度は PM に以下のように書いてください。

RGB/K:m-CIEb($T)
Symbols:m=0.5

CIEb($T) は、各ピクセルの b成分です。これで、青っぽいピクセルだけを抜き出すことができます。(1)の時と同様、m の値は適宜調整してください。これを基画像に対して実行すると、次のようなマスクができます。

13_10_b_mask
図13-10. bマスク

これを bマスクと呼ぶことにしましょう。後は(1)や(2)と同様の方法で、青っぽい領域を強調することができます。

13_11_bmask_s
図13-11. 青を強調

もともと青が少ない領域なのでほとんど変わっていないように見えますが、よく見ると青い星がより鮮やかになっていることがわかります。

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

13-2. 最後のまとめ

第7回の前処理から始まった星野写真の画像処理も、これにてひとまず終わりとしましょう。それでは、これまで紹介してきた処理によって仕上がった完成画像をご覧ください。

13_12_final
図13-12. 完成画像例 (クリックすると高解像度版に飛びます)

カメラが現像したJPEG撮って出しと比べると、もはや別物と言った方が良いくらいですね。あのカメラとあのレンズでこれだけの表現ができれば十分でしょう。

(1) PixInsight こそ初心者向け

PixInsight での星野写真の処理の流れを振り返ると、まず前処理は全自動です。色合わせ(PCC)とストレッチ(ArcsinhStretch)も属人的なテクニックを必要としないので苦労しません。DBE を使った光害除去に多少の慣れが必要かと思いますが、苦労するとしたらそこくらいで、現像までの処理であれば、あまり苦労しないで非常に綺麗な画像を得ることができます。

複数のプログラムを使う不便もなければ、属人的なテクニックを必要とするトーンカーブなんかほとんど使う必要がありません。「元データが同じであれば、誰がいつ何度やっても同じ結果が得られるような処理が多い」、つまり「人を選ばない」という意味で、むしろ PI こそ天体画像処理の初心者向けプログラムであると言える面もあります。

天体写真の画像処理プログラムは、究極的には、ユーザが何も考えなくても、あるいは何ら苦労しなくても、「プログラムに元データを放り込めば後は全部プログラムが適宜処理して綺麗な画像が出来上がる」、というのが理想だと思うのですが、今のところそこまでのプログラムは存在しません。いずれはそのような AI(人工知能)が開発されると思いますが、それまでは多少の手間や苦労を甘受しなければなりません。そんな現在の状況にあって、PixInsight はその理想に最も近づいているプログラムだと思います。

「PixInsight はとっつきにくい」とよく言われることがありますが、どんなプログラムでも慣れるまでは使いにくいものです。逆に慣れ始めれば、それほど使いにくいとは思わなくなります。本連載では使い方も丁寧に説明したつもりですので、これを参考にして、まずは試しに使ってみてください。ただし、PI といえど完璧で万能なわけではありません。世の中に数多(あまた)ある画像処理プログラムの一つに過ぎないことだけは忘れないようにしましょう。

それから、天体写真の画像処理をしている方は、とかく現像後のレタッチテクニックにばかり関心を向けがちかと思います。しかし、大事なのはむしろ現像まで(すなわちストレッチまで)の工程です。第10回でも述べましたが、元データが同じであれば、天体写真の出来は、現像までの処理工程でその9割以上は決まってしまいます。同じ元データを使っても完成画像の出来栄えに差が出た場合、その差は現像までの段階で既についていたはずです。現像までの基礎的な処理こそ重要なのだと認識して、その処理の内容をよく勉強して理解していただきたいと思います。

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

(2) 初心者でも気軽に天体写真を

さて、この画像を撮影した機材はこんな機材です。

13_13_equipments
図13-13. 撮影機材(雲台のみ異なる)

星野写真の機材としては、なんとも簡素な機材です。さらに、この写真ではカメラを 3WAY雲台の上に載せていますが、実際にはこれがボールタイプの自由雲台でしたのでもっと簡素な構成でした。赤道儀の SWAT-200(生産終了)は重量が僅かに 1.4kg という軽さで、そのおかげもあってカメラから三脚まで全部ひっくるめた総重量もたったの 5kg しかありません。これなら女性の細腕でも楽々持ち運べますよね。オートガイダー等の余計な機材やソフトも一切必要ありませんし、まさに「お手軽撮影」です。

天体写真ファンが集まると、ともすると自分がどれだけ特殊で凄い機材を持っているかという機材自慢の場になりがちで、そこに居合わせた幼気な初心者がドン引く姿を何度か見たことがあります(笑)。もちろん、ファンが機材や設備といった「道具」にこだわるのは何も天体写真の世界に限った話ではありません。どんな分野であっても突き詰めれば道具にこだわるようになるのは自然なことであり、大切なことです。

しかし、そもそも趣味というのは自己満足のためにやるものですから、どんな方法であれ、自分が満足しさえすればそれで良いのです。道具に満足感を求める方向性があるのなら、もっと気軽に星空を楽しむという趣味の方向性があっても良いはずです。

高価で大きな機材は持っていないけど、満天の星空には憧れる。できればそれを写真に撮ってみたい。そう考えている人は世の中に大勢いることでしょう。そんな初心者の皆さんも、ぜひお手持ちのカメラと、できれば SWAT赤道儀を持って空の暗い場所に行き、一晩中満天の星空に抱かれながらお気に入りの星空を写真に収めてみてはいかがでしょうか。そのとき、画像処理はきっとあなたの強い味方になってくれますよ。

最後になりましたが、本連載の執筆をご提案くださったユニテックの加曽利様をはじめ、このような拙文を最後までお読みいただいた寛容で根気強い読者の皆様に厚く御礼申し上げるとともに、本連載の内容が一人でも多くの皆様にとって有益となることを祈りつつ、13回(補足回を含めれば計17回)に亘る連載を締めくくりたいと思います。また、いつか撮影地で皆様にお会いできることを楽しみにしております。その際には気軽にお声がけください。どうもありがとうございました。

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

<おわり>

2018年9月 2日 (日)

PixInsightで画像処理を始めよう ~ 第12回 嗚呼、星はいい(7) 主なレタッチ処理1

【目次】

12-1. 星像を小さくする(スターリダクション)
 (1) MorphologicalTransformation (MT) 再び
 (2) 周辺部の星だけを小さくする
 (3) UnsharpMask でシャープに
12-2. コントラスト強調
12-3. 暗黒帯を強調する


通常、天体写真の画像処理は、第10回のストレッチまででほぼ出来上がりです。今回の素材画像の場合は星ハロが目立ったので、前回(第11回)それを除去しましたが、星ハロが気にならない画像であれば不要な処理です。そして今回は、天体写真の画像処理でよく使われる仕上げの加工処理について、代表的なものを幾つか紹介していこうと思います。

以前も述べましたが、これから紹介する処理はすべての天体写真に必須の処理ではありませんし、決まった順番があるわけでもありません。画像に応じて、必要な処理だけを選んでやってください。また、やり方や考え方がわかれば、所謂レタッチソフトでも実現することはある程度可能だろうと思います。レタッチソフトでの処理に慣れている方は、この連載で考え方だけを吸収し、使い慣れたソフトで同じことをやってみる、というスタンスでも良いと思います。

12-1. 星像を小さくする(スターリダクション)

前回は盛大に出ていた星ハロを除去しました。その画像をもう一度見てみましょう。

12_01_afterrmhalo
図12-1. 星ハロ除去後の画像

これはこれで十分な気もしますが、これでもやや星が目立ちすぎてやかましいと感じる人もいるかもしれませんね。そういう場合には、星像を少し小さくしましょう。星像を小さくすると小さな星は消えて星の数が減るので、スターリダクションとも呼ばれます。

(1) MorphologicalTransformation (MT) 再び

星像を小さくすると言えば、星ハロ除去でも使った MT ですね。多くのレタッチソフトで「明るさの最小値」「明るさの最大値」として知られているフィルターに相当する処理を行うことができます。

ですが、処理の前に、まずはこの時点でのスターマスクを作りましょう。基本的な作り方は 11-3節(1) の通りです。大きく写った輝星がある場合には、MLT の Layers の値を変えることで微光星と輝星に分けてスターマスクを作り、それらを PixelMath で合成した方が良いケースが多いと思います。合成には max() 関数を次のように使って、いわゆる「比較明合成」をすると良いでしょう。

 max([微光星のスターマスク], [輝星のスターマスク])

今回は 図12-1 の画像のスターマスクとして以下のマスク画像を作りました。

12_02_starmask1
図12-2. スターマスク

これを 図12-1 にかけて、MT を Erosion で実行します。

12_03_mt
図12-3. MT

このとき、MT の Size というパラメータを大きくすると、一気に星を小さくしたり、微光星を消したりすることができるようになります。星が小さくなると、あるいは星の数が少なくなると、相対的に星雲が目立つようになるので、星の数をドカンと減らしてほとんど星が目立たないくらいにし、星雲を思いっきり目立たせるように仕上げる、というのも表現方法の一つだと思います。

しかし、「せっかく写っているものをあまり消したくはない」とか、「星が写ってこそ天体写真だ」といった考え方もあるかと思います。私もどちらかというとそう考えるタイプでして、せっかく写っているものを消すのはもったいないということで、Size を最小の 3 にし、Amount も 0.5~0.6 くらいに小さくすることが多いです。Amount をさらに小さくしてもう一度実行することもあります。どの程度が正解ということはないので、お好みで調整してください。今回は、中央やや左に写っている散開星団(M23)が分離した状態を保持している段階で止めることとしました。

12_04_sr
図12-4. MTでスターリダクション(全体)

12_05_srx2
図12-5. MTでスターリダクション(中央を2:1拡大)

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

(2) 周辺部の星だけを小さくする

光学系の中には、中央部はシャープでも周辺部は星が少しぼやけて写ってしまうものも多いでしょう。周辺部まで全面シャープな光学系はなかなか無いものです。今回の画像も、中央部に比べて周辺部の星は若干ぼやけて大きく写ってしまっていますので、周辺部の星だけを小さくするという処理も加えたいと思います。

ここでもやはりマスクを使うのですが、要するに、図12-2 のスターマスクのうち周辺部だけを抽出したものを作れば良いわけです。そこで、PixelMath に以下のような式を書いてみましょう。

RGB/K: r=rdist(cen_x, cen_y);
iif(r<R, (r/R)^3, 1)
Symbols: r, cen_x=2700, cen_y=1550, R=2700

12_06_pixelmath
図12-6. PixelMath(円形グラデーション)

要するに、点(cen_x, cen_y) を中心とした半径 R の円形グラデーションを描こうというわけです。円の外側の明るさは 1 です。画像を見て、この辺が光軸中心だろうと思われるだいたいの点の座標を (cen_x, cen_y) に入力し、半径 R も画像に応じて適宜変えてください。これを対象画像に対して実行すると、次のような画像ができます。

12_07_circle_grad
図12-7. 円形グラデーション

指定した中心点が真っ暗で、そこから離れるにつれて徐々に明るくなるグラデーションができました。ちなみに、このグラデーションは、中心からある程度のところまではほとんど明るくならず、ある程度離れるとそこから急激に明るくなる、という工夫をしています。レンズや望遠鏡も、光軸の中心からある程度の距離までは収差が少なくて、ある程度の距離が離れるとそこから急激に収差が大きくなるのが一般的でしょう。グラデーションもなるべくそれに合わせるのが理想的です。あとは、このマスクとスターマスクとを掛け合わせれば、周辺部だけのスターマスクができます。

12_08_starmask_corner
図12-8. 周辺部のみのスターマスク

これを 図12-4 に適用して、再度 MT を実行します。

12_09_sr_corner
図12-9. 周辺部のみスターリダクション(前後比較)

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

(3) UnsharpMask でシャープに

MT でスターリダクションを行うと、星像のシャープさが失われることが多くあります。このまま星を消すのならそれでも構いませんが、星を残すのであれば、星像にはある程度のシャープさが欲しいところです。そこで、もう一度 図12-2 のスターマスクを適用して UnsharpMask を実行することにします。

12_10_unsharpmask
図12-10. UnsharpMask

UnsharpMask も大抵のレタッチソフトで使えると思いますが、これを実行すると、画像に写っている被写体のエッジ(輪郭)が鋭くなります。エッジが鋭くなると、画像がシャープになったように見える効果があるので、天体写真に限らず色んな画像処理でよく使われると思います。

星像をシャープにするために UnsharpMask を使うときのコツとして、「あまりシャープにしすぎない」ということが挙げられると思います。あまりシャープにしすぎると、星像としては逆に不自然に見えてしまうからです。なので、MT で星像を小さくした後、UnsharpMask を適用しない人も多いと思います。この辺は人それぞれの好みの問題でしょう。

PI の UnsharpMask の場合、StdDev を大きくすると、被写体のエッジをよりなだらかにシャープにする(表現として矛盾していますけど(笑))ことができるようになります。また、私は Amount もデフォルトの 0.8 より小さくして、あまりシャープになりすぎないように調整することが多いです。

MT と UnsharpMask を上手に使ってスターリダクションを行うと、自然なシャープさを保ったまま星像を小さくすることができます。

12_11_apply_mtusm
図12-11. MT と UnsharpMask でスターリダクション(中央を2:1拡大)

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

12-2. コントラスト強調

天体写真は、明るい部分がベタっと明るくなってしまったり、逆に暗い部分もあまり明暗の差がなかったりして、部分的にコントラストが悪い場合が多いと思います。

12_12_after_sr
図12-12. 部分的にやや低コントラスト

ここまで様々な処理を施してきたこの画像も、とくに天の川がベタっと明るくなってしまって、ややコントラストが悪い印象があります。(そんなことないと言えばそんなことないのですが、これも人それぞれの好みの問題かもしれません。)

そんなときにはコントラスト強調を行います。よく使われるのは、月面写真編の第5回でも登場した LocalHistogramEqualization (LHE) でしょう。

12_13_lhe
図12-13. LocalHistogramEqualization (LHE)

LHE は所謂「ローカルコントラスト」を向上させるための処理で、これを適用すると、淡い星雲のエッジや明るい領域内の細かい模様が強調される効果があります。第5.5回でも紹介した通り Image Processing Tips でも取り上げていますので、詳しく知りたい方はそちらをご覧ください。

星野写真の場合には、LHEを使うときにもマスクを作った方が良いでしょう。今回は RangeSelection でマスクを作ることにします。

12_14_rangeselection
図12-14. RangeSelection

Lower limit は、簡単に言うと、それより暗いピクセルを 0(真っ黒)にするという意味で、Upper limit は、その明るさのピクセルを 1(真っ白)にし、それより明るいピクセルを真っ黒にするという意味のパラメータです。つまり、Lower limit から Upper limit までの範囲(Range)の明るさのピクセルだけを抽出し、グラデーションを付けてマスクを作るということになります。左下の白丸ボタンを押してリアルタイムプレビューを表示させ、それを見ながらパラメータを調整すると良いでしょう。

今回は、比較的明るい部分だけのマスクを作ります。図12-14 の RangeSelection を対象画像(図12-12)に対して実行すると、図12-15 のようなマスクができます。

12_15_lhe_mask
図12-15. LHE用のマスク

これを 図12-12 に適用して、LHE を実行します。LHE の使い方は、第5回の 5-2節(2) に書いてありますので、そちらを参照してください。リアルタイムプレビューを見ながらパラメータを調整します。

12_16_apply_lhe
図12-16. LHE実行

比較的明るい領域の陰影が強調されましたね。LHE では、Kernel Radius のパラメータが非常に重要で、これを変えると印象が全く違った画像になります。

12_17_lhe_kr
図12-17. Kernel Radius を変えると・・・

これは LHE の効果がわかりやすいように Amount をやや大きくしたものですが、Kernel Radius を小さくすると小さなスケールの構造(模様)が強調され、大きくすると大きなスケールの構造が強調されます。とくに目立たせたい模様が最もはっきりと強調されるような値をリアルタイムプレビューで探してください。

また、暗い部分のコントラストを上げたければ、暗い部分だけのマスクを作り、それを適用して LHE を実行してください。このとき、暗い領域にはそれほど細かな模様はないことが多いので、Kernel Radius は明るい領域よりも大きくすることが多いと思います。

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

12-3. 暗黒帯を強調する

コントラストを上げる代表的なツールとして LHE を紹介しましたが、ここでもう一つ、別のアプローチによって全体的なコントラストを上げるツールを紹介しましょう。そのアプローチを端的に言うと「暗いところをより暗くする」というアプローチです。

12_18_after_lhe
図12-18. 元画像

この画像を見ると、天の川の真ん中を走る暗黒帯周辺がぼやっと明るい印象を受けますね。そこで、この暗黒帯の明るさを落として、その周辺領域の明るさにメリハリをつけたいところです。ところが、左上から対角線上に走る暗黒帯よりも、実は右上の赤い輝線星雲 Sh2-27 の方がむしろ暗いのです。したがって、単純に輝度情報だけを基に RangeSelection によって「明るいところ」と「暗いところ」を区別しようとすると、図12-19 のように暗黒帯とともに Sh2-27 周辺も黒くなります。

12_19_range_mask
図12-19. 輝度だけを基に作ったマスク

これをマスクにして暗黒帯をより暗くしようとすると、次の図12-20 のように Sh2-27 周辺まで漏れなく暗くなってしまいます。

12_20_darkreduc
図12-20. 図12-19をマスクにして輝度を落とすと・・・

せっかく浮かび上がっていた淡い星雲が暗くなってしまっては、ちょっと残念ですよね。もちろん、レタッチソフトなら、塗り絵用のツールを使って、狙ったところだけを処理するようなマスクを意図的に作ることもできるでしょうが、写真はあくまで写真であって塗り絵ではないので、なるべくそういったことはやらない方向で何か良い手だてはないものでしょうか。

そんなときに使えるのが、DarkStructureEnhance (DSE) というスクリプトです。メニューバーから "SCRIPT" > "Utility" > "DarkStructureEnhance" と辿って起動してください。

12_21_dse
図12-21. DarkStructureEnhance (DSE)

これは、ある大きさのスケールで見たときに顕著に現れる明暗の差を捉えて、それを基に暗い領域をより暗くするツールです。ただ、そう言われてもすぐにはピンとこないでしょうから、まずは第4.5回でも説明した ExtractWaveletLayers (EWL) スクリプトを用いて図12-18 をレイヤー分解してみましょう。

12_22_ewl
図12-22. ExtractWaveletLayers (EWL)

すると、次のような構造が見えてきます。

12_23_layers
図12-23. レイヤー分解した画像

これらを見ると、Layer07 あたりで、天の川の中心を流れる暗黒帯が比較的明確に見えていますよね。一方、右上に写っているはずの輝線星雲 Sh2-27 は、これにはあまりはっきりとは見えていません。DSE はこれを利用して、特定の大きさのレイヤーではっきり見える暗黒帯を暗くしてくれます。

ExtractWaveletLayers での Layer07 は、その他のツールでは Layer 8 に相当するので、DSE の "Layers to remove" を 8 にし、Amount を適宜変えて "OK" ボタンを押すと、以下のようになります。

12_24_after_dse
図12-24. DSEで暗黒帯を暗く強調

暗黒帯だけが暗くなって、メリハリの利いた画像になりましたね。一方、Sh2-27 周辺の明るさはとくに変わっていません。このように、DSE を使うと、単に暗い領域というわけではなく、明るい領域の中にある暗い領域を効率的に暗くすることができます。

なお、DSE で Iteration の回数を増やすと、暗黒帯がどんどん暗くなっていきます。必要に応じて Layers to remove を変えて複数回実行すると良いかもしれません。

こういうツールはレタッチソフトにはなかなか無いかもしれませんね。このように、SCRIPT の中には意外と便利で「使える」ツールが沢山隠れていますので、PROCESS だけでなく、SCRIPT の方もいろいろと試して遊んでみると面白いでしょう。

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

つづく

2018年8月21日 (火)

PixInsightで画像処理を始めよう ~ 第11回 嗚呼、星はいい(6) 星ハロ除去

【目次】

11-1. ここから先はレタッチ
11-2. 盛大な星ハロ
11-3. 星ハロのマスクを作ろう
 (1) Starmask(スターマスク)を作ろう
 (2) ハロのHue(色相)値を確認しよう
 (3) カラーマスクを作ろう
 (4) ハロマスクを作ろう
11-4. Morphology(モルフォロジー)
11-5. 星ハロ除去
11-6. もうひと声
 (1) 青い星
 (2) 緑色の星?


11-1. ここから先はレタッチ

前回でストレッチまで終わり、これで現像がひとまず終わったことに相当すると言いました。この段階でも、撮って出し画像と比べればとても同じ写真とは思えないほどに綺麗になっているはずなので、初心者のレベルなら、ここまででも十分ではないかと思います。

11_01_afters_comp
図11-1. 撮って出し画像との比較

ここから先の処理は、すべての天体写真に絶対に必要な処理というわけではありません。できた画像を見て、必要に応じてやれば良いものと思ってください。

また、ここから先はレタッチ(加工)であり、レタッチソフトでもだいたい同じことはできると思います。いや、むしろレタッチソフトの方が本職なので、何も無理して PI を使わなくても良いと思いますが、ここから先も強力なツールは用意されているので、このまま PI で処理を続けましょう。

ただ、はじめにお断りしておきますが、今回は「入門」からは完全に逸脱します。あまり馴染みのないプロセスを見たこともないような手法で使うという怒涛の連続スマッシュが飛んでくるので、初心者にはちょっとキツイかもしれませんが、ご容赦ください。

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

11-2. 盛大な星ハロ

それでは、ストレッチが終わった画像を改めて見てみましょう。

11_02_afterstretch
図11-2. 星ハロ(全体と2:1拡大)

前回、前々回の段階で既に気付いていた人もいると思いますが、拡大すると、比較的明るい(かと言って輝星ほど明るくはない)星の周りがマゼンタになっていたり、赤くなっていたりするのがわかります。これはいわゆる「星ハロ」ですね。写野全体に等しく出ているわけではなく、中央部分に集中しているように思えますが、かなり盛大に出ています。これは、R(赤)のピントが合っていなくて、R の星像が肥大化していることが直接の原因です。

11_03_bloatedr
図11-3. Rの星像が肥大化している(RとGとの比較)(中央部を2:1拡大)

そのため、元々青かった星の周りがマゼンタになり、元々黄色やオレンジ色だった星の周りが赤くなっているのです。このように、R/G/B でピントの位置が僅かに違うというのはよくある話です。高級な光学系ならここまで酷くなることはないでしょうから、必要のない方は今回はまるっと読み飛ばしてください。ただし、そんな高級な光学系ばかりを使って楽をしていると、いざという時の処理テクニックが身に付きません。一度はこういう苦労をしておいた方が良いと思いますよ(笑)。とにかく、写ってしまっている以上は仕方がないので、この星ハロを何とかして除去しましょう。

星ハロの除去方法にも幾つかあります。例えば、レタッチソフトの中には「フリンジ除去」と呼ばれる機能があるものもあります。それを使うのが一番手っ取り早いのですが、それだと星の元の色の復元は難しいですよね。また、星ハロ以外の部分、例えば星雲の色にも影響を及ぼさないか、ちょっと不安です。

では、どうやるのか。しかも、ただ除去するだけではなく、星の元の色もなるべく復元するにはどうすれば良いのか。今回は最もオーソドックスかつ直接的な方法でやります。

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

11-3. 星ハロのマスクを作ろう

先ほど、R の星像が肥大化しているのだと言いました。だったら R の星像を小さくすれば良い のです。これから、そのための準備をしましょう。

(1) Starmask(スターマスク)を作ろう

まず第一段階は、スターマスクを作ることから始めます。要するに、星だけを抜き出してマスク化するのです。スターマスクを作る方法にも幾つかあり、PI にはその名もずばり StarMask というプロセスもあるのですが、今回はこれは使いません。いきなり入門レベルを逸脱します(笑)。

代わりに、第4回でも登場した MultiscaleLinearTranstorm (MLT) を使います。MLT は色んな用途で使える便利なツールでして、おそらく開発者は意図してはいなかったと思いますが、スターマスクを作るのにも使えます。

まず、メニューバーから IMAGE > Extract > Lightness と辿って、対象画像の L画像を抽出します。ツールバーにも "Extract CIE L* component" というアイコンがあるので、それを押しても抽出できます。

11_04_extractl
図11-4. L画像を抽出

11_05_l_image
図11-5. 抽出されたL画像(中央部を2:1拡大)

これがスターマスクの土台となります。左枠の画像名のタグをダブルクリックすれば、画像名を変えることができますので、スターマスクだとわかる名前に適宜変更しておくと良いでしょう。

続いて、MLT を次のように設定します。

11_06_mlt_for_starmask
図11-6. スターマスク作成用に MLT を設定(例)

MLT のリスト部分に表示されるレイヤーの数は、右上の Layers から選択することができます。ハロが発生している星の大きさに応じて Layers の値を適宜変えてください。一番下の R のチェックを外すのがミソです。Layer 1 のチェックを外しているのは、第4.5回でも述べたように、どうせこれはノイズ主体のレイヤーだからです。これを先ほどの L画像に対して実行して STF でオートストレッチすると、次のようになります。

11_07_aftermlt
図11-7. MLT実行後(中央部を2:1拡大)

ほぼ星だけが残ります。しかし、星以外のものも残っていると思いますので、STF のシャドウ及びミッドトーンを動かすことによってこれを消し、星だけが残るようにします。これを HT を介して反映すれば、スターマスクの完成です。(STF は見かけ上の明るさを変えるだけなので、HT を通して反映させる必要があることを思い出してください。)

11_08_starmask
図11-8. starmask(中央部を2:1拡大)

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

(2) ハロのHue(色相)値を確認しよう

準備の第二段階は、星ハロの色の範囲を数値的に確認することです。PI のウインドウの下枠に三角マークがありますよね。ここから Readout のオプションが選択できます。この三角マークを押して、Readout Data > CIE L*c*h* を選択してください。

11_09_readoutoptions
図11-9. Readout Options

CIE L*c*h* とは、色空間の一種で、L は明るさ、c は彩度、h は色相をそれぞれ意味します。この状態で画像の任意の点をマウスで長押しすると、そのピクセルの L/c/h の値をそれぞれ確認することができます。L と c は 0~1 の値ですが、h は 0~360 の値で表現されます。これで星ハロの色相を確認します。

11_10_hue
図11-10. Readout で星ハロの色相を確認

今回の画像の場合、マジェンタのハロの色相値は 320 以上、赤のハロは 40 以下であるようでした。ハロ部分の色相値がわかったら、その色相値のピクセルだけを抜き出したマスクを作りましょう。

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

(3) カラーマスクを作ろう

準備の第三段階です。第10回にも登場した PixelMath (PM) にここでも再登場してもらいます。この PM に次のように書いてください。

RBG/K: k * iif((CIEhd($T)>mag)||(CIEhd($T)<red), CIEc($T), 0)
Symbol: k=2, mag=320, red=40

11_11_pm_for_halomask
図11-11. PixelMath

iif(x, a, b) というのは、x が正しければ a の値を、正しくなければ b の値を返しなさい、という意味の論理式です。Excelの関数なんかでもよく見ますよね。で、その中に書かれている CIEhdr() というのは、そのピクセルの色相値を返す関数で、CIEc() は彩度の値を返す関数です。したがって、この式は、この画像の中で色相値が mag より大きいかまたは red 未満のピクセルを抜き出し、その彩度の値を輝度に置き換えて画像を作りなさい、という意味です。ここではこれをカラーマスクと呼ぶことにしましょう。なお、iif(x, a, b) や CIEhdr()、CIEc() は Expression Editor から選択・入力することができます。

図11-11 の PM を 図11-2 に対して実行すると、次のようなカラーマスクが得られます。

11_12_colormask
図11-12. カラーマスク

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

(4) ハロマスクを作ろう

さあ、準備の最終段階に入ります。このカラーマスクには星ハロが含まれています。しかし、色相値の条件だけで抽出すると、星ハロ以外のピクセル(例えば星雲)も同時に含まれてしまいます。このカラーマスクから、星ハロだけを抜き出すにはどうすれば良いでしょうか。ピンときた人もおられるでしょう。そうです。(1)で作ったスターマスク(図11-8)にはハロを含めた星だけが抜き出されていますから、スターマスクとカラーマスクをかければ(掛け算すれば)良いのです。

「2つのマスクを AND 条件で合成したければ単純に掛け算すれば良い」という発想は、ピクセルの明るさを 0~255 の範囲で考えるレタッチソフトに慣れてしまっていると、すぐには浮かびにくいかもしれませんね。その点、PI のようにピクセルの明るさを 0~1 の範囲で考えているとすんなり発想できます。

(1)で作ったスターマスクと(3)で作ったカラーマスクを PM を使って掛け合わせると、次のような画像ができます。

11_13_halomask
図11-13. ハロマスク

これが、星の中でハロとして異常な色となっていた部分だけを抜き出したマスク画像です。これをここではハロマスクと呼ぶことにしましょう。明るさは適宜調整してください。

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

11-4. Morphology(モルフォロジー)

図11-13 のハロマスクを見ると、星のハロの部分だけがドーナツ状に抽出されていることがわかりますね。このように星ハロだけを抜き出したマスクができたら、これを R画像に適用し、肥大化して星ハロとなってしまった部分だけを消すわけです。

それには MorphologicalTransformation (MT) を使います。

11_14_mt
図11-14. MorphologicalTransformation (MT)

MT は、その名の通り Morphology(モルフォロジー)という操作によって処理を行います。モルフォロジーには、主に Dilation(膨張)Erosion(収縮) という2つの操作があります。膨張(収縮)は、「対象ピクセルの周辺のピクセルの中で最大値(最小値)をとるピクセルの値を対象ピクセルの値として置き換える」という操作です。

11_15_morphology1
図11-15. モルフォロジーの原理

例えば 図11-15 を見てください。9個のピクセルの真ん中のピクセルの値をモルフォロジーによって変換するとします。この周囲(この場合は3×3)のピクセルの最大値は "0.5" ですので、Dilation では "0.5" に置き換えます。一方、最小値は "0.1" ですので、Erosion では "0.1" に置き換えます。これがモルフォロジーです。

普段、レタッチソフトの使用に慣れている人なら、聞いたことがある処理だと思います。そうです。多くのレタッチソフトに「明るさの最大値」「明るさの最小値」といった処理があると思いますが、あれです。

なぜこれが膨張や収縮と言われるのかというと、図11-16 を見てください。周辺ピクセルの最大値で置き換えていけば、点は大きくなり、線は太くなります。逆に、周辺ピクセルの最小値で置き換えていけば、点はより小さくなり(あるいは消滅し)、線は細くなります。この原理を利用して、星を大きくしたり小さくしたりすることができるわけです。

11_16_morphology2
図11-16. モルフォロジーの効果

ちなみに、MT では、その「周辺ピクセル」の範囲を明に指定することもでき、それによって、星の大きさを変えるだけでなく、形を変えることもできます。この辺りのテクニックは Image Processing Tips にも書いてありますので、興味のある方はご覧ください。

10_09_ipts_pi_021_title
図11-17. PixInsightでの画像処理(その6)- MorphologicalTranstormation (MT)

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

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

11-5. 星ハロ除去

いよいよハロを除去します。R画像にハロマスク(図11-13)をかけて MT で Elosion(収縮)を実行します。

11_18_rmhalo_r
図11-18. R画像にハロマスクをかけて Erosion(中央2:1拡大)

随分と星が小さくなりましたね。どれだけ収縮させれば良いかは画像によっても違いますので、適宜 Amount で調節してください。こうして星像が小さくなった R画像を、G画像および B画像と合成します。(3色の合成には、9-2節でも登場した ChannelCombination プロセスを使います。)

11_19_rmhalo_rgb
図11-19. RGB合成(中央2:1拡大)

あれだけ盛大に出ていた星ハロが一気に目立たなくなりましたね。目立たなくなったばかりか、星像が小さくなり、しかもマゼンタだった星が青っぽくなりました。前にも説明した通り、マゼンタだった星は本来は青っぽい星だろうと考えられるので、本来の色に近づいたとも言えます。

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

11-6. もうひと声

うるさく目立っていた星ハロが除去できて、これでも別に悪くないと思うのですが、この画像の場合にはちょっと気になる点が2点ほどありますので、ついでにそれらも修正しておきたいと思います。

(1) 青い星

マゼンタだった星が本来の青い色に近づいたとは言っても、正直なところ青というより紫ですよね。こんな色の星も存在しないだろうと考えられるので、これに手を入れます。

紫もマゼンタも主に R と B を混ぜることでできますから、言ってみれば同族の色です。こうしたマゼンタ系の色を簡単に除去する方法があります。そのためにちょっとだけ発想を転換しましょう。

先ほども言いましたが、マゼンタは R + B です。ということは、RGB色空間においてその反対の色は G ということになりますね。このような反対の色のことを「補色」と言うこともあります。この補色の関係を利用しましょう。

まず、図11-19 の星ハロ除去後の画像を invert します。

11_20_rmhalo_invert
図11-20. invertした画像

この画像で緑色っぽく見える部分が、元の画像ではマゼンタぽかったところです。この中で星にだけ処理を行いたいので、これに再びスターマスクをかけます。ただ、ここで使うスターマスクは、星ハロ除去後の画像を元に作り直した方が良いでしょう。(ハロを除去した分、最初の画像より星像が小さくなっているため。)

そして、SCNR プロセスを起動します。

11_21_scnr
図11-21. SCNR

元々これは緑のノイズを減らすために開発されたツールなのですが、ここでこれを利用します。 "Color to remove" で Green を選択し、先ほどスターマスクをかけた invert画像(図11-20)に実行します。このとき、Amount を適宜調整してください。少し小さめに設定した方が良いことが多いと思います。ちょっと分かりにくいかもしれませんが、実行すると、緑色だった星が赤茶色っぽく変わるはずです。

11_22_invert_scnr
図11-22. SCNR実行(中央2:1拡大)

そうしたら、スターマスクを外して再び invert します。すると、紫だった星の色が青っぽく変わります。

11_23_purple2blue
図11-23. 紫だった星の色が青に(中央2:1拡大)

HαやO-III等、特定の波長域だけを狙ったナローバンド撮影をし、それらを R/G/B に割り当てて疑似色合成する所謂「ハッブルパレット」で画像処理すると、星の色がマゼンタになることがあるようで、それを除去するためにこうした技法を使う人がいるようです。

ちょっとした春風亭コワザですね。(はい?)

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

(2) 緑色の星?

ハロを除去した画像をよ~く見ると、ところどころに緑色の星が小さく写っています。第9.5回で説明した通り、本来、緑色の星は存在しないはずです。これは何でしょうか。

実はこれらの星は、元々は黄色かオレンジ色の星だったと考えられます。星ハロ除去前の R 画像に写っていた星をもう一度良く見てください。リング状に写っている星が沢山見受けられますよね。

11_24_r_image
図11-24. R画像には星がリング状に写っていた(中央2:1拡大)

これは所謂「リングボケ」ですね。こういうボケ方をする光学系にはときどきお目にかかりますが、R だけこれほどピントを外しているということは、やはりもう少し R 側にピントをずらした方が良かったかもしれません。

いずれにしても、点状の光がリング状にボケると、その穴の部分は光が弱くなります。つまり、この部分は R が薄くなっているわけです。黄色やオレンジ色の星の場合、B(青)の光はほとんど含まれておらず、R(赤)と G(緑)の光が多く含まれます。このうち R がリングボケによって薄まった結果、G だけが目立つようになったというわけです。ということは、この緑色の星の部分に R を足してやれば、元の色に近づくはずですよね。

ただ、こんな症状に悩まされている人はあまり多くないと思われるので、ここでは手順をざっくり説明するだけにしたいと思います。

リングボケの穴を埋める
モルフォロジーを知っている人ならピンとくるでしょうが、モルフォロジーの closing を使うとリングボケの穴を埋めることができます。ただし、MT ではなんと closing と opening の表記が逆になっているので注意が必要です。「誰かつっこまないのかよ」といつも思うのですが、PI ユーザはスルースキルが高いようです(笑)。
リングボケの穴だけを抽出したマスクを作る
穴が埋まった画像から元のリングボケの画像を引けば、穴だけを抽出したマスクを作ることができます。
緑色になってしまった星だけのマスクを作る
②のマスクと 11-3節の技法を使って、リングボケの穴であり且つ緑色になっている部分だけを抜き出したマスクを作ります。
R を足す
③のマスクを 図11-23 の画像にかけて、CurvesTransformation (CT) で R だけを増幅します。

この手順の処理で緑色の微光星を黄色やオレンジ色に戻すことができます。

11_25_rest_gstar
図11-25. 緑の微光星を元の色に復元(中央2:1拡大)

これで、ひとまず星ハロを除去することができました。今回の一連の星ハロ除去処理について、除去前と除去後の画像を比較することでその効果を見てみましょう。

11_26_rmhalo_all
図11-26. 星ハロ除去の効果(全体を1:4縮小)

11_27_rmhalo_x1
図11-27. 星ハロ除去の効果(中央等倍)

まあ、こんなところでしょうか。除去前の星ハロが盛大だった分、効果が分かりやすいですね。

今回の内容は少々ハードだったかもしれませんが、いかがでしたでしょうか。この画像の場合はあまりに酷くて無視するわけにはいかなかったので説明することにしましたが、優秀な光学系を使っていれば大抵不要な処理だと思います。日頃こうした症状に苦しんでいる方に何かしらの参考にしていただければ幸いです。

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

つづく

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)