ほしぞloveログ

天体観測始めました。

カテゴリ: 画像処理


縞ノイズを時間的に見てみる

もしかしたら興味がある人もいるかと思い、縞ノイズを時間的に可視化してみました。先のバラ星雲の1日目のディザーなしで撮影した失敗画像約2時間ぶんの24枚を使っています。中心あたりの一部を拡大して見ています。といってもやったことは簡単で、ディザーなしで撮影した画像を、PixInsightで動画にしただけです。

Blink

これはガイドをしていても、たわみなどでガイド鏡と撮影鏡筒の相対的な視野が一方向にずれてしまうために起きます。それでももしノイズが完全にランダムなら、このように流れるようには見えないはずです。ノイズが流れて見えるということは、ノイズに時間的なコヒーレンスがあるということです。うーん、結構ありますね。あれだけの縞ノイズになるのもわかる気がします。

integration_DBE_PCC_AS_cut



縞ノイズ動画の作り方

さて、この動画の作り方です。今回縞ノイズを時間的にみる目的でしたが、このやり方覚えておくと色々応用が効きそうです。基本的に、PixInsightを使います。
  1. 普通にBatchPreprocessing 処理などで進めます。
  2. master以下のregsteredフォルダに入っている、位置合わせまで終わって、Integrationする寸前のファイルを使います。ここまでは普通にDebayerしてStarAlignmentでも構いません。
  3. Blinkでそれらのファイルを開きます。
  4. とりあえずは、デフォルト機能の再生ボタン(右三角)を押すと確認できますが、順に動画のようになるように見せるだけです。オートストレッチもできるのでみやすくなります。カラーバランスが悪い場合は、RGBのリンクをオン/オフする「鎖マーク」のアイコンを押してください。
  5. Previewで一部を切り取るとその部分だけ拡大して見えます。
  6. それをBlink画面の右下の一番右端の撮影開始マークアイコンで動画にします。
  7. ffmpegがない場合は別途インストールしてください。
  8. ffmpegがインストールされていても、実行ファイルをフルパスで入れないとダメでした。/usr/local/bin/ffmpegとかいうことです。
  9. オプションは秒20コマのgifファイルにしたかったので、 -y -r 20 -i Blink%05d.png Blink.gifとしました。
このように結構簡単に動画を作ることができます。


M42の場合

もう一つ例です。TSA-120でM42を撮影した時のものです。約30分くらいの撮影時間で、枚数は14枚です。これはディザーもそうですが、ガイドさえもしてないので赤道儀の極軸の精度が悪くてずれていってしまっているものです。上のバラ星雲のように画像の一部ではなくて、ほぼ全体像を示しています。解像度はこのブログにアップできるように(一画像当たり5MBが制限)落としてあります。

Blink

縞ノイズの原因となるクールノイズなどに混ざって、おそらくバイアスノイズに相当する縦線のように見えるノイズも流れていることがわかります。基本的にランダムでないノイズは、全て縞ノイズになり得るだろうことがわかります。

これを普通にスタックすると下のように縞ノイズが盛大に出てくるわけです。

integration



バラ星雲のもそうですが、時間的にこれだけ明らかに変化しているのがわかるのなら、なんとか分離してペラっと一枚皮を剥ぐようにこのノイズだけ取れないですかね?

以前、星像切り出し用のコードをPythonで書いたのですが、




Matlab用に少し書き直したので公開します。結果はすでにここ最近の記事で使っているので、これまでに見ている方も多いかと思います。デザインはピンとくる方もいるかと思いますが、スターベース東京のブログの作例の切り出し画像のフォーマットに合わせてあります。

ファイル選択ですが、以前選んだフォルダを覚えるようにしました。以下のページを参考にしました。ありがとうございました。
前回の対応フォーマットはJPEGだけでしたが、今回はMatlabのimreadコマンドでサポートする画像ファイルに対応しています。なので、かなりのフォーマットに対応するはずです。実際に全部試したわけではないので分かりませんが、
  • BMP、JPEG、PNG、CUR、JPEG 2000、PPM、GIF、PBM、RAS、HDF4、PCX、TIFF、ICO、PGM、XWD

に対応するらしいです。天文で関連するのは主にJPG, PNG, TIFFくらいでしょうか。RAWファイルはあまり対応できないのですが、個別にFITS形式だけ対応させておきました。

カラーの8bit、16bitに対応しています。32bitには対応していません。あと、グレー画像は多分ダメです。結果はファイル名に”_cut25”というのが足されて、元のファイル形式と同じ形式(例えばjpgならjpg、tifならtif)に書き出されます。


7bc22bb9_cut


あまり綺麗でないですが、ソースコードです。 コピペして、Matlab上で走らせてみてください。上のような画像が出てくるはずです。簡単なコードなので、各自で希望に応じて適当に書き換えてみてください。3x3マスとかも簡単にできるはずです。

clear; %%% Paramters CS = 300; BW = 5; % File select if ispref('MyPreferences','LastUigetfileFolder') folder = getpref('MyPreferences','LastUigetfileFolder'); if ~ischar(folder) folder = '/Users/'; % for mac. if windows use 'C:\'. end else folder = '/Users/'; % for mac. if windows use 'C:\'. end [file,path] = uigetfile({ '*.*', 'All files(*.*)'}, 'Pick a file','MultiSelect', 'on',folder); if ~isnumeric(path) setpref('MyPreferences','LastUigetfileFolder',path) end % Reading image with size and class (full size) [filepath,name,ext] = fileparts(file); if extractBefore(ext,5) == '.fit' Img = fitsread(fullfile(path, file)); else Img(:,:,:) = imread(fullfile(path, file)); end [y, x, l] = size(Img); if isa(Img,'uint16') cv = 256; else cv = 1; end % Size of ASP-C ay = round(size(Img,1)/1.6); ax = round(size(Img,2)/1.6); % empty cut image CutImg = zeros(5*CS+6*BW, 5*CS+6*BW, 3, class(Img)); % Orange area CutImg(:,:,1) = 235 *cv; CutImg(:,:,2) = 170 *cv; CutImg(:,:,3) = 80 *cv; % Blue Area BA = CS+BW+1:4*CS+5*BW; CutImg(BA,BA,1) = 50 *cv; CutImg(BA,BA,2) = 50 *cv; CutImg(BA,BA,3) = 80 *cv; % Define areas in cut image C = zeros(CS,5); for i = 1:5 C(:,i) = (i-1)*CS+i*BW+1:i*(CS+BW); end % Area in original image IX(:,1) = 1:CS; IX(:,2) = round((x-ax)/2)+1:round((x-ax)/2)+CS; IX(:,3) = round((x-CS)/2)+1:round((x+CS)/2); IX(:,4) = round((x+ax)/2)+1:round((x+ax)/2)+CS; IX(:,5) = x-CS+1:x; IY(:,1) = 1:CS; IY(:,2) = round((y-ay)/2)+1:round((y-ay)/2)+CS; IY(:,3) = round((y-CS)/2)+1:round((y+CS)/2); IY(:,4) = round((y+ay)/2)+1:round((y+ay)/2)+CS; IY(:,5) = y-CS+1:y; % Filling cut image by original cut for i = 1:5 for j = 1:5 if ( ((j==1)||(j==5)) && ((i==2)||(i==4)) ) || ( ((j==2)||(j==4)) && ((i==1)||(i==5)) ) CutImg(C(:,i),C(:,j),:) = 256 *cv; % fill with white else CutImg(C(:,i),C(:,j),:) = Img(IY(:,j),IX(:,i),:); end end end %image(CutImg); if extractBefore(ext,5) == '.fit' fitswrite (CutImg, fullfile(path, [name,'_cut25',ext])); else imwrite (CutImg, fullfile(path, [name,'_cut25',ext])); end




途中からいろいろ簡略化しているのでわかりにくいと思います。% Define areas in cut image以降を、以下のコードに置き換えるとまだわかりやすいかと思います。

% Define areas in cut image C1 = 0*CS+1*BW+1:1*CS+1*BW; C2 = 1*CS+2*BW+1:2*CS+2*BW; C3 = 2*CS+3*BW+1:3*CS+3*BW; C4 = 3*CS+4*BW+1:4*CS+4*BW; C5 = 4*CS+5*BW+1:5*CS+5*BW; % Area in original image IX1 = 1:CS; IX2 = round((x-ax)/2)+1:round((x-ax)/2)+CS; IX3 = round((x-CS)/2)+1:round((x+CS)/2); IX4 = round((x+ax)/2)+1:round((x+ax)/2)+CS; IX5 = x-CS+1:x; IY1 = 1:CS; IY2 = round((y-ay)/2)+1:round((y-ay)/2)+CS; IY3 = round((y-CS)/2)+1:round((y+CS)/2); IY4 = round((y+ay)/2)+1:round((y+ay)/2)+CS; IY5 = y-CS+1:y; % Filling cut image by original cut CutImg(C1,C1,:) = Img(IY1,IX1,:); CutImg(C2,C1,:) = 256 *cv; CutImg(C3,C1,:) = Img(IY3,IX1,:); CutImg(C4,C1,:) = 256 *cv; CutImg(C5,C1,:) = Img(IY5,IX1,:); CutImg(C1,C2,:) = 256 *cv; CutImg(C2,C2,:) = Img(IY2,IX2,:); CutImg(C3,C2,:) = Img(IY3,IX2,:); CutImg(C4,C2,:) = Img(IY4,IX2,:); CutImg(C5,C2,:) = 256 *cv; CutImg(C1,C3,:) = Img(IY1,IX3,:); CutImg(C2,C3,:) = Img(IY2,IX3,:); CutImg(C3,C3,:) = Img(IY3,IX3,:); CutImg(C4,C3,:) = Img(IY4,IX3,:); CutImg(C5,C3,:) = Img(IY5,IX3,:); CutImg(C1,C4,:) = 256 *cv; CutImg(C2,C4,:) = Img(IY2,IX4,:); CutImg(C3,C4,:) = Img(IY3,IX4,:); CutImg(C4,C4,:) = Img(IY4,IX4,:); CutImg(C5,C4,:) = 256 *cv; CutImg(C1,C5,:) = Img(IY1,IX5,:); CutImg(C2,C5,:) = 256 *cv; CutImg(C3,C5,:) = Img(IY3,IX5,:); CutImg(C4,C5,:) = 256 *cv; CutImg(C5,C5,:) = Img(IY5,IX5,:);







今話題のTopaz DeNoise AIをいくつか試してみました。少しクセのあるソフトで、相性の良い画像はものすごいノイズの改善が見られますが、合わないものは逆にノイズを増やしたりするようです。大雑把に言うと、ノイズだらけのものはキャパシティーを超えるようでノイズが残りますが、そこそこ気合を入れて処理をして、最後に残ったノイズを取るといったケースが得意なようです。

今回挙げるのはその中でも比較的成功した方のものです。この中には最初失敗して、その後うまくいったのも含まれてます。


オリオン大星雲

先日のAZ-GTiの経緯台モードで撮影した、初心者の撮影レベルを考えたくらいの画像に適用してみました。

まずは先の記事で出した、PixInsightとPhotoshop CCの通常の画像処理。

integration2_cut

次にTopaz DeNoise AIを適用したもの。

integration2_cut-denoise_DN

ザラザラ感はなくなるのに、ディテールがほとんど失われていません。むしろシャープさが増しているような感じです。DeNoiseすごいです。引き出せていない引き出しを開け切るような感覚です。

もう一つ、同じ元画像からの再処理です。ちょっと飛んでしまっているところもありますが、後でノイズが消せることを前提に、無理して最初から炙り出して、後からノイズを消した例です。

integration_cut2

結構見えにくいレベルの分子雲も出てしまっています。DeNoiseがあることを考慮した画像処理で進めると、まだまだ引き出す余地はあった言うことですかね。


6Dで初めて撮った星雲: 馬頭星雲と燃える木

調子に乗って、過去画像にも適用してみました。昔星マスクのテストで処理したEOS 6Dでほぼ初めて撮影した馬頭星雲です。まず下のが、当時処理した画像です。今見るとたくさんアラがありますが、その時は十分満足していました。

HORSE_7c_20171128-00h09m_x34_kb_masked_PS_photo_ps

スタートは、上の絵になる前の加工途中の元ファイルで、ステライメージでスタックして、デジタル現像でストレッチくらいまで処理し終えたところの画像です。以前はここからPhotoshopで星マスクを作りそのままPhotoshopで画像処理しました。

今回は強力な星マスクとしてStarNet++、ノイズ軽減にTopaz DeNoiseと、ツールが進化しています。あと、まあ、画像処理の腕もそれなりに進展はしているでしょう。と信じて、どんどん進めます。

そもそも、DeNoiseで後からある程度ノイズが軽減できるからと思い、処理途中に多少ノイジーになったとしてもあまり気にせず、むしろ分子雲とかを出す方向で進めます。今思うとカブリが残っている画像(かなりあぶり出せたのでやっと気づくことができた、当時は多分気づきもしなかったと思われます)なので、PixInsightのDBEを掛ければさらに良くなる気もしますが、とりあえず気にせずにそのままで進めます。

途中一旦処理を停止しました。ノイズが大きいためにDeNoiseでも処理しきれなかったのです。ポツポツになってしまいます。そこで、PhotoshopのDfineで一旦ノイズを軽減してみました。するとDeNoiseでもうまく処理できるようになりました。シャープさも十分に復元して、特に燃える木のところなんかは以前処理したものより解像度ははるかに増しています。既存のノイズ除去ツールとの併用もうまく使えばより効果的に処理することができそうです。

と、できた画像がこちら。

HORSE_LIGHT_6D_180s_3200_+7cc_20171128-00h09m41s_x34_SNP_star_ok

うーん、2年くらいたって多少はいろんな技術が上がっているとはいえ、あまりに違いすぎます。本当に同じ素材かと思いたくなるくらいです。ちょっとやりすぎの感もありますが、テストなのでまあよしとします。

これでも2年前はマスク処理が初めてうまくいったと、そこそこ満足していたんですよ。特にStarNet++との組み合わせは相当いいです。恒星をなくした画像を見ると、恒星を抜いたところの跡がいつも結構汚いのですが、それもある程度緩和してくれます。まだまだ元の画像には処理し損ねている余地が残っていたんだということを思い知らされました。


昨年末撮った魔女の横顔

馬頭星雲は2年前のものだったので、流石に技術に差がありすぎました。では、つい最近、年末に撮影し画像処理した魔女の横顔はどうでしょうか?まずは当時の元画像です。

integration_DBE_DBE1_PCC_AS_SNP_mask_all2a_cut

自宅からノーフィルターで撮影したもので、思ったより出るものだと自分なり満足していました。でもスターリンクでしょうか、たくさんの衛星痕と、バンディングノイズに悩まされて背景を少し暗く抑えています。これをDeNoiseで処理することを前提に前に戻って画像処理します。

スタートはPixInsightで処理しStarNet++で星雲部分と恒星部分に分けたところから始めます。DeNoiseはバンディングノイズもかなり軽減してくれます。それでもこの時のノイズは、特に衛星痕が酷かったらしく、完全に除去することはできませんでした。結果はというと、バンディングノイズが軽減できた分だけ背景もよりあぶり出せた感じです。

integration_DBE_DBE1_PCC_AS_SNP_DN-denoise_cut

でもよく見ると、魔女の部分のディテールは失われてしまっています。これはDeNoiseのせいというよりも、かけている時間が10分の1くらいで、ディテールを出す手間を惜しんでしまったからだと思います(というか、どうやって出したかすっかり忘れてしまった...。よく出してたなと思います。)。

それでも背景の分子雲に関しては、十分な成果は出るようです。ノイズが目立ってあえて押さえていたところを、やっと解放できるような感覚がいいです。当然ですが、一つ上の馬頭の改善と比べると2年間分の技術が上がっている分、絞り出せる余地もある程度少なくなっています。馬頭のときほどは差が出ません。

これらのことから、DeNoiseをうまく使ってノイズ除去された仕上がり画像だけ見ると、画像処理の上手い人と下手な人の差が分かりにくくなるということを示唆しています。うまい人は油断できなくなり、初心者は逆にチャンスとなりますね。


先日の太陽のプロミネンスにSharpn AIを適用

さらに、先日3nmのHαフィルターでコントラストが上がった画像

15_45_23_lapl4_ap1555_IP2_color_cut

を、DeNoise AIではなく、今度はTopaz製の別のソフト「Sharpen AI」で再処理してみました。注目したのはプロミネンスとスピキュールのみで、光彩面は無視します。さらに差がわかりやすいようにモノクロにしています。上のカラー画像でも十分に出ていると思っていましたが、処理すると遥かに鮮明になります。

15_45_23_lapl4_ap1555_IP2_SAI_cut

もうスピキュールがトキトキ(すみません、名古屋弁です)ですね。Sharpenも十分なパフォーマンスを示してくれます。ここまで情報が入っていたのかと思えるくらいです。ただしここまで出てくると、擬線もいくつか出ているのではと思います。今回はテストなので見栄えだけ気にしていますので、ご了承ください。

Sharpen AIの方は「Sharpen」「Stabilize」「Focus」の3つのモードがあって、だんだん強くなるようですが、カラー画像で試すと偽色が出ることがあって、取り合えず「Sharpen」のみが使えています。ノイズキャンセルもDeNoiseの方が強力なようです。どうもお互いに、名前を冠していない機能は制限されたようなものを搭載しているような感触です。処理過程でいうと、DeNoiseの方にもシャープ機能はついているし、Sharpenにもノイズキャンセル機能はついています。確かに少しだけ違うかもしれませんが、根本的にはあまり大きな差はないように思えます。


まとめ

一言で言うと、やはりDeNoise AIもSharpen AIもすごい。最後に処理するだけでもいいのですが、あらかじめ後でノイズが消せること前提で画像処理を進めると、途中でかなり思い切った炙り出しができます。StarNet++やDfineなどと組み合わせて使うのも、さらに効果的になるのかと思います。

その一方やりすぎると、ここは違うだろうと言う模様が出てくることもあります。例えばHIROPONさんが以前指摘していたように、縞状のノイズはさらに縞を拡大する場合があります。今回の画像にもそういったものが少し残って(例としてあえて残して)います。例えば馬頭星雲の馬の右側の縞とかです。

こう言った簡易なツールが出てくるのは個人的には歓迎です。特に初心者にとってはノイズの処理は相当敷居が高いはずです。このツールは有料になりますが、かなり初心者の画像処理の負担を軽減してくれると思います。

また、天文マニアにとっても、やはりノイズには常に悩まされるので、このようにディテールを壊さずにノイズを軽減してくれるツールはとても助けになります。これまでもいろいろノイズ除去に関するツールは使ってきましたが、いまのところこのTopazのDenoiseは最強に近いと思います。

ただ、月や、惑星など、正確さを求めて丁寧にやっている方たちには、こう言った処理ツールは心配のタネというのも理解ができます。偽の情報が出てくる可能性は否めません。

私のようなとりあえず綺麗に見えればいいというレベルでは、腕の無さを補完してくれるありがたいツールです。使うべきところと使わない方がいいところを、うまく分けていけばいいのではないかと思います。

これまでの天体画像も様々な画像処理テクニックの恩恵を受けています。これからもっとすごい技術が出てくるかもしれません。新しい技術だからと頑なにならずに、柔軟に受け入れていけばいいのかと思います。


白濁したレンズを納得済みで購入したFC-76を使って、干潟、三裂、猫の手星雲撮影した画像の仕上げです。いろいろ紆余曲折して時間がかかってしまいました。


3枚の画像を合わせて処理

まずは前回の記事で使った、3枚の画像をまとめて仕上げてみました。FC-76とFSQ-60の2機種で、FC-76は180秒と300秒露光の2枚、FS-60Qは300秒露光が1枚です。総露光時間はそれぞれ30分なので、計1時間半分の画像があるわけです。

まずPixInsightのStarAlignment機能を使って3枚をあわせてスタックするのですが、鏡筒が違うので星像には微妙なズレが出てしまいました。

IMG_7557
例として右上隅の様子。星像の下半分が二重になっています。
上半分がずれていないように見えるのは
画角のずれで重なり合っていない部分だからです。

このずれはデフォルトの位置と回転のみでは補正しきれないので、StarAlignmentのいくつかのパラメータを調整します。

IMG_7554

触ったところは「Registration modl」を「2-D Surface Splines」にしたこと。これは2次元スプライン補間で画面全体を歪ませるモードです。でもこれだけだと不十分で、さらに「Distortion correction」をチェックしたこと。これは非線形な歪みを修正するとのことです。これで周辺部までずれずに綺麗に星像を合わせることができました。


結局2枚だけ使うことに

ここで問題に気づきます。

まず、FC-76が1.04倍のフラットナーを使っているので焦点距離は624mm、FS-60Qは600mmとFS-60Qの方が少し広いエリアを写しています。FS-60Qで写したの画角の中に、FC-76で写したエリアが全て入ってれば何の問題もなかったのですが、FS-60Qへの切り替え時に時間がなくて焦っていていくつかの確認工程を省いてしまい、狭いFC-76の方にしか写っていない部分があることに気づきました。しかもカメラの回転角のチェックも甘かったので、回転でも15度位ずれていたようです。

共通する部分だけを取り出そうとすると、かなりトリミングしなくてはいけません。それに加えて、FS-60Qの星像がピンボケで肥大していること、おそらく口径が小さいことによりノイジーに見えることなどを鑑み、FC-76で撮影した2枚のみを使うことに決めました。


2枚だとダメ!?

しかしここでもまた問題が発生。PixInsightのImageIntegration機能(スタックのことです)は何と最低3枚からしか動かないようです。他のソフトに行くか迷って、それでもいろいろ調べていると、PixInsightの英語のフォーラムの中に同じ画像を登録してしまえばいいと言う記述を見つけました。このページを見つけるためにgoogleで検索したワードは「pixinsight integration two image sources」です。では、なぜこのワードが出てきたかというと、PixInsightで2枚のみでIntegrationしようとしたら

"This instance of ImageIntegration defines less than three source images."

と出てきたからです。普通 "source images" という単語はパッとはなかなか出てきません。このようにエラーメッセージからヒントを得て、PixInsightとつけて検索してやるとすぐに

"ImageIntegration can't integrate 2 images? - PixInsight"

というページが2番目に出てきたと言うわけです。ちなみに日本語のページではこのような情報を見つけることはできませんでした。

さて、2枚の画像を2回登録して4枚にしてスタックしてやると無事に完了。ただし、少しカブリが残っているようなので、DynamicBackgroudExtractionで暗黒帯もなさそうな暗い部分を6-7点ほどのみ選んでカブリを除去しました。少し色がずれているようなので念の為PhotometricColorCalibrationをして、その後ScreenTransferFunctionでAutoStretchをして、HistgramTransformationで適用します。あとはPhotoshop CCに引き渡し、画像処理です。


最終画像

Photoshopで色々いじって、最終的にできたのが以下の画像です。

integration_DBE_PCC_stretched3
富山県富山市下大久保 2019/6/25 22:02-23:21
FC-76 + QBP + 新フラットナー+ CGEM II + EOS 6D(HKIR改造)
f=624mm, F8.2, ISO3200, 露出180秒x10枚 + 露出300秒x6枚, 総露出60分
PixInsightでダーク、フラット補正、スタック, Photoshop CCで画像処理


普段あまりしていないのですが、今回は少し茶色いモジャモジャも出してみました。でも高々トータルで1時間分の画像なので、まだまだノイジーです。ところでこのモジャモジャ部分って名前あるのでしょうか?モジャモジャの間の黒い部分は暗黒帯でいいんですよね。

あと、参考に四隅の切り出し画像を示しておきます。FC-76に新フラットナーをつけたもので、300秒露光したJPG撮って出し画像をオートストレッチしたものです。6Dなのでフルサイズです。これを見る限り、ほぼ点像ですね。新フラットナーいい仕事しています。

M8_LIGHT_6D_300s_3200_+24cc_20190625-22h51m58s692ms_8cut



まとめ

今回白濁したレンズが付いているFC-76で撮影して、上で示したくらいまで写すことができました。これがオリジナルのFC-76に比べてどれくらい劣っているのかはまだわかりませんが、少なくともまともなFS-60Qに比べて、遜色ない程度に撮影することはできるのは示すことができたのではないかと思います。

IMG_7576
改めて白濁が見えやすいように撮ってみました。
一様でもなく、濃いところ薄いところもあります。
結構ひどいことがわかるかと思います。

ではこの白濁の度合いはどうなのでしょうか?これだけ写るのならそもそも大した白濁でないのじゃないか?という疑問も出てきます。単に大げさに騒いでいるだけではないかということです。なので今一度自分自身でも確認の意味を込めて、まとめておきます。
  1. 対物レンズが白濁したFC-76をスターベース名古屋店で閉店直前に格安で購入しました。白濁があるため、タカハシ直営店ではジャンクとみなしてそれだけの値段しかつけることができなかったということです。
  2. 昼間明るいうちに見てみると、接眼側からアイピースを外してのぞいてみると対物レンズは真っ白近く。これはダメだろうと半分諦めながら実際にアイピースで覗いてみたのですが、解像度にため息が出て、少し眠い気もするが、白濁なんか全く気にならないレベルの鏡筒であることがわかりました。
  3. 眼視で月を見ると、FS-60Q年隠して多少コントラストが低下するところがわかりましたが、単体で見たら(少なくとも私レベルでは)絶対気づかないくらいの影響しかなかったこと。
  4. 撮影でも、と言うよりは眼視よりもさらに白濁の影響は少ないのでは、という今回の撮影結果を得たこと。
要するに、メーカーの直営ショップが白濁部分をジャンクレベルと評価し(おそらく世間一般でも同様の評価かと思いますが)安い値段をつけたものであるが、撮影まですると実は性能はその値段ほど落ちているとは思えないというのが今回の結論かと思います。もちろん、白濁していること自体が嫌な方がいるのは十分理解できますので、売値としては正しいものなのかもしれません。でも私は、白濁にさえ目をつぶれば性能的にはいまのところ不満はないので、十分満足です。むしろこの値段でこれだけ面白い経験をさせてもらったので、それだけでお得感満載です。

最後の疑問、これからもこの白濁レンズFC-76を撮影に使うかと言うと
.
.
.
.
今回は間違いなくこれからも使います。だってホント、全然問題に思えないんですもの。


今回の太陽GIFアニメ制作の過程で太陽画像を大量に処理したので、処理方法がだいぶん確立しました。

昨年まだ太陽を始めた頃に、一度画像処理方法をまとめましたが、あれから随分経ち手法もかなり変わってきたので、ここらで一度メモがわりにまとめておきます。

ネット上で得られた情報を元に、自分で実際に試してみて有効だと思った方法です。自分自身でもいくつか発見した方法も織り交ぜています。有益なソフトを開発してくれた作者様、ネットで各種手法を公開していただいている方々に感謝いたします。


画像スタックと細部出し

AutoStakkert3

太陽を撮影した動画(RAWフォーマットのser形式推奨)ファイルをAutoStakkert3でスタックします。

1.  「1)Opne」を押してファイルをオープン後、「Image Stabilization」で「Surface」を選択。
2. 画像が見える画面で、緑の枠をコントロールキーを押しながら移動。光球面のきわと背景の境目とか、プロミネンスがはっきり見えているところとか、黒点やプラージュの周りとかの構造がはっきりわかる部分を選択。
3. 後のパラーメータはあまり影響はないので適当に、私は下の写真の通り。「2)Analysis」を押す。
IMG_6870

4. 解析終了後、画像の方に移り「Min Bright」を調整して、光球面のみAPでおおわれるように。APの大きさは小さいほうが精度が出るが、小さすぎると出来上がった画像が破綻する。破綻がない程度に小さく。
IMG_6872


5. 「Stak Options」では「TIF」を選択して保存。「Sharpend」はオフに。
6. 「3) Stack」を押してスタック開始。


ImPPG

ImPPGで細部を抽出。パラメータの一例を下に示しておく。
IMG_6873

1. スタックしたtifファイルを開く
2. 上の方のアイコンの、左から4つ目の曲線グラフアイコンをオンにしてトーンカーブ調整エディタを表示。
3. 背景の一部と光球面の一部が四角い枠で選択された状態で、トーンカーブ調整エディタの「stretch」を押す。
4. 「gamma」は出来上がり画像の傾向を見るために使う。まずチェックボックをオンにして、ガンマを調整。光球面を出したいときはガンマの値を0.6くらいまで落とし、プロミネンスを出したいときは1.5-2.0程度までガンマを挙げる。
5. ここから模様出し。「Prevent ringing」はオンに。
6. 「Iterations」は大きい方がいいが、大きすぎると逆にリンギングが目立つ時がある。
7. 「Adaptive」はほとんど使っていない。
8.  画像保存時にはガンマのチェックボックスをオフにする。->後でPhotoshopで同様の処理をするため。画像を16bit tiffで保存。


Photoshopにてフラット補正と疑似カラー化

光球面の切り出し

光球面とプロミネンスをどの様に合成させるかが難しいです。以下に示した方法はあくまで一例です。

1. Photoshop CCにおいて、上で作成した画像を開く。
2. 「イメージ」->「モード」->「RGBカラー」でカラーモードに変換。
3. 背景を全選択して、コピー、ペーストする。光球面処理用レイヤーとする。
4. ペーストで作られた光球面レイヤーを選択してから、画面で「マグネット選択ツール」で光球面とプロミネンスの境、光球面が枠の縁に接しているところをなぞり、光球面のみ選択。
5. 「選択範囲」->「選択範囲を変更」->「境界をぼかす」で4ピクセルほどぼかす。
6. 「選択範囲」->「選択範囲を反転」で光球面以外を選択された状態にし、DELキーなどで削除。光球面のみが残る。これが光球面レイヤーとなる。


フラット補正

次に、光球面のフラット補正。光球面はエタロンの影響で減光が大きいので、フラット補正をした方がいいです。以下に示したフラットフレームの作り方は、境界がボケるのでもっといい方法があるかもしれません。

1. 背景を全選択して、コピーする。ペーストを2回する。一枚はプロミネンス処理用レイヤー、もう一枚はフラット補正レイヤーとする。
2. フラット補正レイヤーを選択し、「フィルター」「ぼかし」「ぼかし(ガウス)」で半径を20ピクセルほどにして適用。フラット画面を作る。念の為もう一度同じガウスぼかしを適用してさらにフラットに。
3. このレイヤーのかぶせ方を「通常」から「除算」に変更。この時点でかなり明るく飛ぶ。
4. 「レイヤー」->「 新規調整レイヤー」->「レベル補正」でできたレイヤーを右クリックして「クリッピングマスクを作成」をクリック。
5. 調整レイヤーのレベル補正のハイライト側をヒストグラムが盛り上がっているところまで下げる。

IMG_6867

(2019/4/13 追記: 上記4、5の方法だと、プラージュなど白い領域が飛んでしまうことがわかりましたので訂正しておきます。明るい領域の諧調を保つためにも、やり方も簡単になることも含め、下に書いた方法のほうがよさそうです。)

4. フラット補正レイヤーを「イメージ」「色調補正」「トーンカーブ」で調整します。トーンカーブで真ん中らへんを一点選んで上下し、明るさが適当になるように調整。
5. 光球面のみのレイヤー、フラット補正レイヤーの2つを選んで、右クリックで「レイヤーを結合」してフラット補正が完了。
6. フラット補正された光球面レイヤーを一番上に持っていく。境が自然になっていることを確認。


プロミネンスレイヤーを疑似カラー化

1. 一番上の光球面レイヤーの目のマークをクリックして非表示に、プロミネンスレイヤーを選択。
2. 「イメージ」->「色調補正」->「レベル補正」を選んでダーク側の三角をヒストグラムが下側の山(背景の暗い部分に相当)になっているところのピーク付近まで持ち上げ、真ん中の三角を下のほうまでもっていき、できるだけプロミネンスを出す。ここでいったん「OK」。
3. 再度「イメージ」->「色調補正」->「レベル補正」を選んで、「チャンネル」の「レッド」を選択。真ん中の三角を左端の山の際くらいまでもっていく。
4. 「チャンネル」の「ブルー」を選択。真ん中の三角を右端くらいまでもっていく。
5. 「チャンネル」の「グリーン」を選択。真ん中の三角を少しだけ右にもっていって赤っぽくなるように調整。
6. もし背景に赤いノイズが残っていたら、Nik collectionのDfine 2が有効。さらに背景を少し暗くするため、「イメージ」->「色調補正」->「トーンカーブ」を選んで補正。


光球面レイヤーを疑似カラー化

1. 一番上の光球面レイヤーの目のマークをクリックして表示させ、選択。
2. 「イメージ」->「色調補正」->「レベル補正」を選んで、「チャンネル」の「レッド」を選択。真ん中の三角を左端の山の際くらいまでもっていく。
3. 「チャンネル」の「ブルー」を選択。真ん中の三角を右端くらいまでもっていく。
4. 「イメージ」->「色調補正」->「トーンカーブ」を選んで、50%のところを選んで少しだけ下げ、模様を強調。これはImPPGのガンマ補正で数値を上げたことに相当する。

IMG_6869


これで完成です。あとは適当に荒れた縁の方をトリミングして、画像を保存するなどしてください。


太陽観測のススメ

他のソフトや、細かい工夫などの方法はまだまだあるかと思いますが、画像処理の基本はこんなところかと思います。太陽の隠れた面が見えてくるのはとても楽しです。あなたも太陽観測試してみませんか?

と気楽に呼びかけているのですが、太陽の一番のハードルはやはり観測機器の値段でしょうか。太陽観測に必須のエタロンは精度が必要な光学部品なので、どうしても価格が上がってしまいます。入門用のCORONADOのP.S.T.でも簡単に10万円越え。これでも口径40mmなので解像度に不満が出るかもしれません。P.S.T.より上級機ではCORONADOのSolar MaxやLUNTなど、口径60mmクラスでBFの径にもよりますが数10万円から50万円コース、口径80mm越えだと50万円からなんと100万円以上のものもあります。

この値段がネックなのか、海外などでは比較的安価に手に入るP.S.T.の改良記事もたくさん見受けられます。このブログでも改造記事を紹介していますが、くれぐれも太陽観測は安全に気をつけて、改造するにしても自己責任で、繰り返しになりますが本当に安全に気をつけながら楽しんでください。


しつこいようですが、いまだにコンバージョンファクターの測定です。だんだん何が目的かわからなくなってくる完全に自己満足の世界です。カラーでどうしても疑問が解決しないので、モノクロCMOSカメラのASI290MMを使って、基本に立ち返って検証してみました。


疑問点


疑問は2つ。
  1. ノイズの評価に標準偏差を使うとSharpCapに比べて大きく出すぎる。平均偏差だと同じくらいのノイズになるが、正しい方向なのか?
  2. debayerをするとノイズが平均化され小さく出るが、果たして公平な解析と言えるのか?
です。カラーカメラは余分な処理も多いので、もっとシンプルなモノクロCMOSカメラを使えば何か知見が得られるかもしれません。


モノクロカメラのSharpCapでの自動測定の結果


まずはSharpCapのセンサー測定機能で測定してみます。光源はこれまで通りiPadのColor Screenです。測定結果だけ示しますが、ほぼメーカー値と同じ値が出ます。ゲイン0でのコンバージョンファクター(Gain, e/ADU)は3.6程度です。

IMG_6411


モノクロカメラのマニュアル測定と自作コードでの解析の結果

次は自分で撮影して、その画像を解析します。画像の撮影自身にはSharpCapを使いました。今回はより厳密に、SharpCapで自動測定している様子をビデオに撮って、その時に使われたパラメータ、特に露光時間を全く同じにして測定しました。解析はpythonでの自作コードです。結果を示しますが、ここでは2つの結果を比較したいと思います。まず一つは、ノイズの評価に標準偏差を使ったもの。これはカラーCMOSカメラの場合は、ノイズが大きすぎると結論を出したものです。結果です。

Conversion_Factor_ASI290MM_std
モノクロの場合は標準偏差を使うことで、少しだけずれますがほぼメーカー値およびSharpCapの自動測定と同じ結果を出すことができるようです。Unity gainのズレとして15程度、1.5dBなので、1.18倍くらいの違いなので、まあ許容範囲でしょう。

一方、カラーで正しそうな値を出した平均偏差を使った場合の結果はというと

Conversion_Factor_ASI290MM_madmean
というように、ノイズが小さく評価されすぎていてメーカー値より大きなコンバージョンファクターとなってしまっています。

カラーカメラを再びマニュアルで解析

前回の測定は何かまだ問題があったかもしれません。再確認のために、モノクロカメラで測定した時と限りなく同様に、自動測定の時の様子をビデオに撮影し、その時のパラメーターを再現することで、より厳密にマニュアルで撮影、解析してみました。

まずは一番素直でモノクロの結果に一番近いはずの、標準偏差でのノイズ評価と、CFA分離です。結果はやはりノイズが大きく出すぎていて、コンバージョンファクターはメーカー値4程度に対して、わずか半分程度と出てしまいます。

Conversion_ASI294MC_Pro_Factor_CFA_std1
次に、CFA分離ですが平均偏差での評価です。3.3程度とだいぶんましになりますが、やはりまだ4とは優位にズレがあります。

Conversion_ASI294MC_Pro_Factor_CFA_madmean


次に、あぷらなーとさんが解析してくれたようにdebayerした場合です。ノイズが平均化されてばらつきが少なく出ます。まずは標準偏差を使ってノイズ評価した場合。それでも結果は2.5程度と、まだノイズが大きく出すぎています。

Conversion_ASI294MC_Pro_Factor_RGB_std

最後に、前回正しいと判断したdebayerして平均偏差をノイズ評価に使った場合です。結果は4.06と、メーカー値の4程度にかなり近い値が「たまたま」出ています。

Conversion_ASI294MC_Pro_Factor_RGB_madmean

今回はモノクロで正しい値が出たものと、相当近い方法でより厳密に測定していますが、結果は前回と変わりませんでした。前回もすでに、測り方としては特におかしい方法だったわけではない、ということがわかります。でもやはりこの平均偏差を使うことと、debayerでノイズを小さく見積もることが、恣意的な操作がなされているようで、どうしても正しいと思うことができません。


考察

モノクロの結果だけ見ると、ノイズの評価には標準偏差を使うことで、メーカー値やSharpCapと同様の結果を出すことができるので、標準偏差を使った方が正しそうということがわかり、統計の観点から言ってもその後の解析もしやすそうですし、素直な気がします。debayerで滑らかになったものを評価するような恣意的なことも入り込む余地もないので、このモノクロの結果には特に疑問となるようなことはありません。

それではなぜカラーCMOSカメラの場合は標準偏差を使うとノイズが大きく出すぎたり、debayerしたものの方よりも、RGGBのアレイごとに分割したCFA分離の方のノイズがメーカー値よりも大きな値が出たりしてしまうのでしょうか?SharpCapのSensor Analysisの説明
if you have a colour camera it must be in a RAW mode to perform sensor analysis as the debayer process used to convert RAW images into RGB or MONO images causes sensor analysis to give incorrect results.
という記述があることから、やはり解析の際にはdebayerはしていないようにしているようにとれます。


補足

ここで少し気づくことがありました。下の写真はカラーのASI294MC ProでADU値が10000程度の時を測定している様子です。

IMG_6436

SharpCapでは16bit形式で値を出しているので、実際に記録された14bitに換算する場合は4で割ってやります。横軸は10000程度になることがわかります。

ノイズは4で割って、さらにdebayerした時に15くらい下がることを考えると、RGBともに200後半台なので、結果として50程度になることが予測できます。ノイズは2条分布で評価するので、この50を2乗して2500程度。先ほどの10000をこの2500で割ってやるとコンバージョンファクターになって、10000/2500=4程度となるわけです。でもよく見るとRGBの線の他にもう一本白い線があり、こちらの方がかなり小さいノイズになっています。たぶんこれLなんですが、でもなんで?RGBよりもばらつき具合が小さくなる理由が全くわからないです。

Lの標準偏差で評価した時のノイズが、RGBでdebayerして平均偏差を使った時のノイズと、数学的に等価になるとか証明できたら安心して校舎を使うことができますが、パッと考えてもなかなかイメージできません。あと、Lのノイズが小さすぎることも気になります。

(追記: 一晩寝て考えたら多分謎が解けました。もっと単純な話で、今晩帰ったら検証してみます。)
(さらに追記: ヤッリダメでした。詳しくはコメント欄を。何か根本的におかしなところがあるのか?)

まとめ


いずれにせよ、SharpCapの自動測定は何かRGBとは違う評価方法を使っているのかと推測できます。

まだまだ先は長いですが、コンバージョンファクターもそろそろ飽きてきました。この状態だとまだASI294MCのダークノイズの評価の準備がまだ整っていない気もしますが、徐々にちらの方に移っていこうと思います。


ASI294MC Proのコンバージョンファクターを求める一環であぷらなーとさんからのコメントがあり、debayerせずにRGGBの画素ごとに分離してみたらという助言がありましたので試してみました。 

RGB分離したファイルからS-N^2分布をプロットするpythonコードを、fitsから直接CFA (Color Filter Array)のRGGBの4つ分に分離するようなものに改良して再度プロット。画像数は縦横2分の1、面積では4分の1になります。結果が以下のようになります。

20190304_02_Conversion_Factor_CFA



ところがグラフを見てもわかるように、全然メーカー値(コンバージョンファクター: 4程度、ユニティーゲイン:120程度)を再現できていません。要するに各画素の画像ファイルのノイズが大きい、すなわち輝度のばらつきが大きすぎるのです。 自分で書いたルーチンが何かおかしいのかと疑い、PixInsightを使ってマニュアルでも解析してみました。

PixInsightにはPreprocessingのところにSplitCFAというコマンドがあります。これを画像に適用してやると、画素ごとに分離された画像が自動的に出来上がります。この画像を使って、これもPixInsight上のImageInspection -> Statisticsで統計的な値をみてやりましたが、pythonで解析したのと同様の傾向でした。また、CosmeticCorrectionでのホットピクセルとクールピクセルの除去は結果にほとんど影響を与えませんでした。これは中心付近だけをみてもほとんどホットピクセルとクールピクセルが入っていないからかと思われます。

わかりやすいところで、輝度10000付近になるところを例として、結果を示しておきます。

Capture_00_16_30_00010_00_20_06_cc_CFA0->Preview01
CFA0 CFA1 CFA2 CFA3
count (px) 15544 12540 15120 14868
mean 10205.3 9805.5 9803.4 9209.9
median 10205.5 9806.6 9803.6 9209.6
stdDev 65.7 67.0 65.3 61.1
avgDev 52.6 53.2 51.9 48.9
MAD 44.0 44.0 44.0 42.0
minimum        9912.5 9528.6 9543.6 8977.6
maximum        10444.5 10049.5 10084.5 9475.6


Capture_00_16_30_00010_00_20_06_cc_RGB_VNG->Preview01
R G B
count (px) 14950 14950 14950
mean 10229.3 9798.6 9206.1
median 10229.5 9798.8 9206.9
stdDev 59.566 56.9 57.6
avgDev 47.138 44.4 45.6
MAD 39.040 36.2 38.0
minimum 10003.5 9551.6 8941.1
maximum 10484.4 10049.5 9445.2


上がCFAで分離した場合、下がdebayerした場合になります。赤いところを見比べればいいのですが、全く同じ画像から作り出したにも関わらず、明らかにCFA分離の方が平均偏差(avgDev)が大きく出てしまっています。あまり大きな差に見えないかもしれませんが、分布図を作るときにこの値を2乗してプロットするので、ざっくり(52/46)^2で1.28、約3割の増加です。1次グラフの傾きも3割くらい変わってきて、コンバージョンファクターも、ユニティーゲインも3割くらい(ZWOカメラのゲインにして40程度)変化があります。

どうもPixInsightでdebayerをするときにばらつきが減るような効果があるようなのですが、なぜそうなるのかはまだよく理解できていません。ただ、SharpCapでもただちにRGBにdebayerして測定していると思われるので、とりあえずはdebayerを正しいと思って進めることにします。

まとめですが、今回の過程でまだ2つのしっくりこない部分が残りました。
  • ばらつき具合を評価するのに標準偏差よりも平均偏差を使ったこと。
  • debayerとCFA分離でノイズに明らかに差が出る。debayerの方がノイズが少ない。
ということが判明したのですが、特に後者のわかりやすい説明があれば知りたいです。

debayerの時に周りの(同じカラーの)ピクセルの値を一部情報として輝度を決めるはずなので、確かに少しばらつきがなくなるというのも一理あるのですが、はたしてそれを性能評価として使っていいものなのか?科学的には間違っている気がしてなりません。

ではなぜメーカー値もSharpCapも同じ値を出せるのか?やはりまだ何か自分が根本的に間違っているのでしょうか?


続きの記事。

 

画像処理で出来上がったファイルの四隅の星像を比べたくなることがあると思います。これまでPhotoshopで手作業で切り取り貼り付けを駆使して作っていたのですが、何度もやるとなるとめんどくさいので、簡単にできるようにpythonとOpenCVを使って作ってみました。

超お手軽プロブラミングなので、内容はソースを見たらすぐにわかると思います。唯一工夫したところはファイル名をGUIで選択するところくらいでしょうか。Macで試しましたが、多分Windows他でも動くと思います。(すみません、チェックもしてません。)


必要な環境

環境を構築するのもいたって簡単です。今回はMacで試したので、Macでやる場合を書きます。WindowsなどでもPythonとOpenCVが動く環境なら走るはずなので、難しくもなんともないと思います。

1. Macの場合、Phython3はHomebrewからインストールするといいでしょう。Homebreはターミナルを立ち上げて、

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

でインストールできます。


2. 次にPython3です。これもコマンド一発で、

brew install python3


3. 最後はOpenCVのインストールです。

pip3 install opencv-python

でインストール完了です。xcodeをインストールしていない場合は、最初にそれも必要かも。うまくいかない場合は、私なんかの説明よりも、適当に検索すればOpenCVが使えるようになるまでの説明はすぐに出てくるので、探してみてください。


ソースコード

さて、python3とOpenCVの環境が整ったら次はプログラミングです。今回はホントにチャカチャカっと書いたコードなので、全然綺麗ではありませんのでご容赦ください。ファイル選択の際文句が出たりもしますが、とりあえず動きます。

エディタなどで以下のコードをテキストファイルにコピぺして、適当なファイル名をつけて、拡張子を.pyにすれば準備完了です。

import cv2
import numpy as np
import tkinter
from tkinter import messagebox as tkMessageBox #python3
from tkinter import filedialog as tkFileDialog #python3


def pathname(fullpath):
    n = fullpath.rfind('/') + 1
    return fullpath[:n]

def select():
    root=tkinter.Tk()
    root.withdraw()
    fTyp = [('JPEG file','*.jpg')]
    iDir = '/Users/ユーザー名/' #自分のユーザー名を入れてください
    filename = tkFileDialog.askopenfilename(filetypes=fTyp,initialdir=iDir,title = "ファイル選択")
    iDir = pathname(filename)
    return filename


filenameselect = select()
img = cv2.imread(filenameselect)


mlen = 250
size = img.shape
roi_UL = img[0:mlen, 0:mlen]
roi_UR = img[0:mlen, size[1]-mlen:size[1]]
roi_LL = img[size[0]-mlen:size[0], 0:mlen]
roi_LR = img[size[0]-mlen:size[0], size[1]-mlen:size[1]]
roi_CC = img[round((size[0]-mlen)/2):round((size[0]+mlen)/2), round((size[1]-mlen)/2):round((size[1]+mlen)/2)]

width = mlen*3
height = mlen*3
imageArray = np.zeros((height, width, 3), np.uint8)
count = np.array([[0,0],[0, mlen*3],[mlen*3, mlen*3],[mlen*3, 0]])
cv2.fillPoly(imageArray, pts=[count], color=(255,255,255))

imageArray[0:mlen, 0:mlen] = roi_UL
imageArray[0:mlen, mlen*2:mlen*3] = roi_UR
imageArray[mlen*2:mlen*3, 0:mlen] = roi_LL
imageArray[mlen*2:mlen*3, mlen*2:mlen*3] = roi_LR
imageArray[mlen:mlen*2, mlen:mlen*2] = roi_CC

savefile = filenameselect.replace('.jpg', '_4cut.jpg')
cv2.imwrite(savefile,imageArray)



実行結果

ターミナル上で上のプログラムがあるフォルダに行き、

python3.py ファイル名.py

とかで実行すると、画像ファイルを選択するダイアログが現れます。ダイアログが前面に出てこないことがあるので、下のDocからPythonというアイコンを選んでみてください。JPEGファイルしか選べませんが、プログラムの中の15行目を*.pngとかすれば多少他のファイル形式も選べます。

切り取りたいファイルを選択すると、同じフォルダの中に

オリジナルファイル名_4cut.jpg

というファイルが出来上がります。

出来上がりは下のようになります。元の画像から四隅250x250ドット分と真ん中を250x250ドット分を切り取って750x750ドットのファイルを作ってくれます。ホントにこれだけです。

test_4cut


ちなみにこれは、タカハシの新フラットナーで撮ったFS-60CBの星像です。カモメ星雲ですが現在画像処理中のものです。ほとんど流れていないことがわかると思います。元々の動機が、新旧フラットナー、レデューサー、エクステンダーでの四隅の星像を比較したくて、いちいちやるのがめんどくさいのでプログラミングに走ったというわけです。

今回のプログラムは色々制限もありますが、簡単なプログラムなので中身もすぐにわかると思います。各自で適当に改良してみてください。

例えば、26行目の250を他の値に変えると切り出してくれる画像の大きさが変わります。
ちょっと頑張れば上下左右も合わせて8方向の切り取りとかもできると思います。

画像処理プログラミングの取っ掛かりとしては、いい練習になるかと思います。

(追記: Matlabバージョンの切り出しプログラムも書いています。スターベースのブログと同じ形式で5x5マスでフルサイズとAPS-Cサイズを見るものです。よかったらこちらもどうぞ。)


参考ページ

以下のページを参考にしました。
どのページもわかりやすくて、とても役に立ちました。どうもありがとうございました。 

週末土曜日に飛騨コスモス天文台に行って、M57とM27を撮影しました。それぞれの撮影枚数は、露光時間が20秒と短いこともあり、かなりの枚数になります。具体的にはM57が282枚、M27が244枚をなり、処理の前に簡単に閲覧するだけでも大変になります。しかもSharpCapで撮影したRAWファイルなので、拡張子が.fitsファイルとなり、開けるソフトも限られています。

最初の頃はfitsファイルもステライメージで確認していたのですが、これだけ数が多いと大変になります。PixInsightでも開くことができますが、一枚一枚が結構重いので、全部を気楽に開くわけにいかなくて、選別するのが結構大変です。

そんなときはPixInsightの「ImageInspection」->「Blink」が便利です。

IMG_5690

  1. 下のフォルダマーク「Add Image Files」から複数ファイルを選択して読み込みます。
  2. 読み込みは数百枚だど数分かかるので、50枚くらいずつにしたほうがいいと思います。
  3. RAW画像でも、Debayerした画像などでも読み込むことができます。
  4. 画像が暗くて見にくい場合でもSTFがかけられた状態で表示されるので、見やすくなっているはずです。これは真ん中に3つ縦に並んでいるアイコンの、真ん中を押すと確認することができます。
  5. 読み込んだ後は、左右の矢印を押すか、画像のファイル名を一つ選択してあとはカーソルの上下で、すごい勢いで画像を連続で切り替えることができます。
  6. 左の三角ボタンを押せばアニメーション表示することもできます。
  7. ただし、ソート順はファイル名のみのようなのがちょっと残念なところです。
  8. 弾きたい画像は、マウスでファイル名を選択(複数も可能)してから、下のアイコン群の左から5つ目の小さい矢印がついているアイコンを押すと、移動したいフォルダが選択できるので、そこに移動されます。
  9. 終わった後は、下の左から3番目のアイコンを押して、すべてのファイルを閉じます。
  10. これを次の50枚とか繰り返すと、かなり効率よく見た目で明らかに悪い画像ファイルを弾くことができます。


もう一つ便利なのが、「Script」->「Batch Processing」->「SubframeSelector」になります。各画像の星像のFWHM(半値全幅)やEccentricity(偏心度)を測定してくれます。自動でだめな画像を別ディレクトリに移動することなどもできます。

詳しいことはマニュアルを読むといいのですが、英語で結構大変なので簡単な説明を書いておきます。

IMG_5688

  1. いつものようにAdd Filesで解析したいファイルを複数選択します。
  2. 最低限解析するだけなら、そのまま一番下の「Measure」を押します。
  3. CPUや解像度にも依りますが、一枚解析するのに7-8秒程度なので、数百枚でもなんとか耐えられる時間の範囲です。結構かかりますが、それでも一枚一枚やるよりははるかに楽です。最初は少数枚でテストするといいでしょう。
  4. 「Plots」を開くと結果が出ています。「FWHM」や「Eccentricity」で飛び抜けている画像を判断することができます。
  5. 飛び抜けているところをクリックするとx印がつくので、Outputで弾きたいファイルをMoveなどする設定をすると、移動してくれます。
  6. 式で評価して、自動で弾くこともできますが、そのためには下に示すようなパラメータを入れたほうがいいですし、式の入力にはいろいろやり方があるようなので、詳しくはマニュアルなどを参照してください。「星見庵日記」さんのこのページが日本語で比較的詳しく説明しています。
IMG_5689


もう少しきちんとしようとすると、最低限入力する値は、「System Parameters」の中の「Subframe scale」になります。ざっくりした見積もりの「1ピクセルあたりの画角は焦点距離600mm、ピクセルサイズ4umで約1.5秒」とかから考えてもいいですし、こんなサイトから焦点距離と自分の持っているセンサーのサイズを選択して、センサーのピクセル数で割ってやっても簡単に求めることができます。

「Camera gain」も入れるべきでしょう。でもこれは結構難しいです。メーカーのページに行ってもいいですが、例えばASI294MC場合ここの「GAIN」というグラフの横軸「Gain」の実際に撮影した時の値のところを見ればいいのですが、グラフから読み取ろうと思っても0近くになり正確な値は読み取れません。SharpCapがあれば自分で測定することもできます。結果の表からある程度の値は読み取ることができます。それでも誤差があるので、ある程度の値でかまわないでしょう。

ここまで入れると、結果もある程度(絶対値に近いという意味で)正しい値になってくるので、センサーやカメラが変わっても比較することができるようになりますし、式を使った評価でも正確性が出てきます。が、とりあえず面倒なら何も考えずに「Measure」ボタンを押してしまったほうが幸せかもしれません。


ここしばらくブログの更新が滞っていました。忙しかったのもあるのですが、一番の原因は天の川の画像処理でずっと悩んでいるからです。

8月初めに撮った木曽シュミットを背景にした天の川。ところが、気合を入れて画像処理を始めたのが、今回の迷走の始まりでした。Lightroomのレンズプロファイルでの補正と、PixInsightのDBEで周辺減光とさらカブリを除きます。星マスクを利用したり、景色部分にマスクを施したり、天の川部分のマスクも苦労して作ったりして色々試しました。多分正しい方向で進めているはずです。でもなぜでしょう、やればやるほどわざとらしくなって自然感が損なわれていく気がします。

IMG_1312_DBE1_ps

多分上の処理でも悪くないのかと思います。でも、ふと元のJPEG撮って出し画像を見直してみると、もちろんホワイトバランスも取れていないし、周辺減光はありまくりだし、天の川も強調されていないのに、なぜかわざとらしさのないこちらの方が好きな自分がいることに気づきます。ここら辺で完全に迷走状態になりました。
  • 周辺減光はきちんと補正するのが善か?天の川を中心に持ってきたらむしろ周辺減光があった方が天の川を目立たせることができるのでは?
  • 背景のホワイトバランスを撮ることは本当に正しいのか?なぜ青い夜空はダメなのか?
  • 星景写真は、科学なのか?芸術なのか?
などなど疑問が尽きません。天体写真は自分の場合あくまで趣味なので、科学写真とは違います。それでも星雲などの天体写真は宇宙の深淵を覗くという意味でまだ科学に近い気がしますが、星景写真はその名の通り景色を入れます。景色と星の組み合わせという意味ではなにか主観を入れたいという意図があることが普通なので、やはり芸術に相当近いような気がしています。こんなことを悩んでいても、正解もなければ答えが出ないこともよくわかっています。

そんな時に、ちょうどプロの星空風景写真家の方の話を聞く機会がありました。その方に上のような疑問をぶつけてみたのですが「一旦補正した周辺減光をあえて加える場合もある」「結局は自分が何を表現したいかではないか」という助言をいただきました。おそらく天体写真として撮っているアマチュアと、生計を立てているプロの写真家というのでは、全然目指している方向は違うのかもしれません。それでも人に見せるという意味では、この写真家の方の言うことは正しいのではないかと思いました。

まだ迷いはとれませが、星景で自分の見せたいものを見せてもいいという道があることがわかっただけでも大きな進歩です。でも個性を出すということは怖いですね。それを凌駕して魅力的な作品を生み続けるのがプロということなのでしょうか。色々悩んでいたことも少し吹っ切れた気がして、今回の星景写真に関しては少し自分が好きなものを目指そうと思いました。

IMG_1312_low

素材がいい場合は、画像処理も最小限で済みます。強度なあぶり出しもしていませんし、周辺減光も必要以上にとったりしていません。ホワイトバランスも多少合わせますが、好みを残しています。カブリもそのままで、この黄色から黄緑を経て青へと変わっていくような色が結構好きです。

くだらない悩みかもしれませんが、ここに至るまでに二週間くらいかかりました。まだ迷走する気はしますが、しばらくは技術にあまりこだわらずに処理をしてみようと思います。

このページのトップヘ