11月1日に撮った木星のデータをまだいじってます。前回の記事でイオの模様が写っているという話をしましたが、なんとかイオと木星の両方をいい感じに仕上げようと頑張りました。
問題は wavelet で木星の模様を復元する強調処理をするとイオのディテールが飛んでしまうこと。撮影時のプレビューやスタック後の強調前の画像を見てもわかる通り、本来イオは木星よりかなり暗いのですが、wavelet をかけると木星よりも明るくなってしまいます。
例えば22:35前後に撮影した7500フレームをスタックして de-rotation したL画像で、平均輝度を調べると、イオの明るい部分で17.3%、木星の明るい部分(赤道帯の中央部)で52.1%で、木星の方が3倍くらい明るいのですが、これを木星の模様が映えるパラメータで wavelet 処理すると、イオが84.3%、木星が68.9%になり、明るさが逆転してしまいます。
これはイオの直径が小さいため、イオの縁で発生するリンギングの効果がイオ全体に及んでしまっているのだと思います。リンギング、あるいはリムの二重化現象は、天体の縁が明るくなりその内側に暗い線が出るもので、光学系の回折像に由来するものですが、明るい天体の縁というコントラストの高い部分で発生するため wavelet 処理で大きく強調されてしまいます。
前回の記事で紹介した『月刊 天文ガイド』2020年11月号の山崎明宏さんの記事「火星画像処理のポイント」にもありますが、リンギングを妥当に処理するシステマティックな画像処理手法は今のところありません。RegiStax の de-ringing は多くの場合は効果的ですが、妥当なパラメータを推定する方法がなく、天体の縁以外でも輝度差の大きい模様(火星の極冠等)に作用してしまうという問題があります。
そんなわけでとりあえずイオと木星で wavelet のパラメータを変えて合成することにしました。とはいえ元の輝度差をそのまま再現すると木星が白飛びするかイオが暗すぎてよく見えないかということになってしまうので、木星を適正な明るさにしつつ、明るさが逆転しない範囲でイオを明るく仕上げるようにしました。なんちゃってHDR処理みたいな感じです。
また、スタックは 1.5x Drizzle にして wavelet 処理したものを2/3縮小して最終的な仕上げをしています。元々 Drizzle しなくてもオーバーサンプリングのデータなのであまり意味はないかもしれませんが、前回の処理の時に Drizzle したものの方が wavelet の微調整がやりやすいように感じたので。単に老眼のせいかもしれませんが…
結果はこちら。
高橋 ミューロン180C (D180mm f2160mm F12 反射), AstroStreet GSO 2インチ2X EDレンズマルチバロー (合成F41.4), ZWO IR/UVカットフィルター 1.25", ZWO ADC 1.25" / Vixen SX2 / L: ZWO ASI290MM (Gain 265), RGB: ZWO ASI290MC (Gain 325), SharpCap 4.0.9268.0 / 露出 1/60s x 500/1000 コマをスタック処理 x 27 (L:15, RGB:12) をLRGB合成 / AutoStakkert!3 3.1.4, WinJUPOS 12.2.7, RegiStax 6.1.0.8, Photoshop 2024, Lightroom Classic で画像処理 で画像処理
なかなかよく仕上がったな、と思う一方、18cmではここらが限界なのかな… という思いも…
さて、先日からやっている画像処理では作業効率化のためにこんなツール(SCAS2WinJUPOS)を作って使いました。
どういうツールかというと、一言ではイマイチ説明しづらいのでとりあえず README の説明を引用。
SharpCap 4 で撮影した動画を AutoStakkert! 3 でスタックした画像ファイルに対して WinJUPOS での処理に適したファイル名のコピーもしくはハードリンクを生成します。
生成された画像ファイル名のタイムスタンプ部分にはキャプチャー時間の中央時刻が入り、WinJUPOS の Image Measurement で画像ファイル読み込むと撮影時刻が自動入力されます。AutoStakkert! 3 で Limit Frames を設定した場合も対象フレームのキャプチャ時間の中央時刻の推定値を計算してファイル名に設定します。
これは天リフさんが紹介していた Lambda さんの記事に触発されて作ったものです。
「WinJUPOSの時刻入力を楽にする方法」が追記。惑星画像処理の上級テクニック「デロテーション」。過去記事ですが木星は今が見ごろ、ご参考に！
— 天リフ編集部 (@tenmonReflexion) August 22, 2023
「エコノミー天文機材で行く、ゆるーい天文趣味」よりピックアップ。
https://t.co/rf89HcE9ST
要は適切な書式のファイル名を画像ファイルに付けておいたら Image Measurement (画像測定)で画像を開くと自動的に撮影時刻を入力してくれる、という話。よく見たらヘルプにも書いてあったんですが、これを見るまで知りませんでした…
WinJUPOS には時刻をUTCで0.1分単位で入力しなくてはならず、また通常キャプチャ時間の中央時刻を指定しなくてはならないので*1 なかなか面倒でした。実は SharpCap の .CameraSettings.txt ファイルから中央時刻を抜き出して WinJUPOS に入力する値に変換するスクリプトは以前作っていたのですが、そこからさらに自動入力できれば完璧じゃん？と思って作ったわけですが…
Lamba さんの記事では PIPP なら WinJUPOS 用のファイル名を自動生成できるとありましたが、実は SharpCap 4 でも設定で同様のことができました。メニューから [ファイル - SharpCapの設定] で開いたダイアログで [ファイル名] タブを開いて「WinJUPOS互換のファイル名を作成する」をチェックすればOKです。しかもこの設定だと通常撮影開始時刻になるファイル名のタイムスタンプが中央時刻になります！
もうこのツールいらないじゃん、って思いかけましたが、SCAS2WinJUPOS には以下のメリットがあります。
- 撮影カメラ名や AS!3 の Free Fieald に設定した値を自動でファイル名に付与でき、WinJUPOS ではそれが Image info (画像情報)欄に自動入力される
- 観測者名を OS のユーザー名から自動でファイル名に付与でき、WinJUPOS ではそれが Observer (観測者)欄に自動入力される
- AS!3 で Limit Frames を使った場合でも自動でフレームの範囲の中央時刻を計算(fpsから概算)してファイル名に付与する
ということで「痒いところに手が届く」ツールになっています。まあ、そこが痒くなるような使い方してないよ？という人も多いとは思いますが、ピンと来た方は試してみてください。Python 3.8 以上が動いてる環境ならどこでも動くと思います。
*1:キャプチャ時間が短めで de-rotation の精度もそこまでいらない条件なら撮影開始時刻でも構わないと思いますが、ALPO-Japan に報告する場合は中央時刻を10秒以内の精度で報告することを求められています。
