WinJUPOS の 'Save image sequence' 機能は 'De-rotation of images' 機能のサブ機能で、昨年末にリリースされたバージョン 12.3.12 で追加された機能です。簡単に言うと、'De-rotation of images' の設定の 'Reference time' を 'Image measurement' の最初の観測日時から最後の観測日時までの間で連続でずらしていきながら 'Compile image' するものです。
実は昨年作者の Grischa Hahn 氏に要望を送ったのがきっかけで実装されました。と、思っていたのですが、Cloudy Night の Hubble さんの投稿を見ると、この人も要望を送っていたそうです。以前から複数の要望があったのかもしれません。
今回は最新版のバージョン 12.4.0 でこの機能を利用して気付いたことを以下にまとめます。一言で言うと、何時間もかけて撮影したデータを処理するには不十分ですが、数十分以内のデータなら使い方を気をつければ手軽に処理できると思います。
作例
高橋 ミューロン180C (D180mm f2160mm F12 反射), AstroStreet GSO 2インチ2X EDレンズマルチバロー (合成F41.4), ZWO IR/UVカットフィルター 1.25", ZWO ADC 1.25" / Vixen SX2 / ZWO ASI290MC (Gain 430), SharpCap 4.1.11817.0 / 露出 8ms x 1500/3000 コマをスタック処理 x 5 を WinJUPOS で save image sequence / AutoStakkert!4 4.0.11, WinJUPOS 12.4.0, RegiStax 6.1.0.8, ffmpeg 4.4.2
2024年10月13日未明に撮影した木星のタイムラプス動画です。今回はカラーカメラで撮影したデータを使いました。モノクロカメラのデータも使ってLRGB合成で仕上げた静止画は1月にアップしています。
撮影当日は約36秒の動画をモノクロ・カラー合わせて150本撮影しています。このうちカラーカメラで撮影した分の連続した5本を今回のタイムラプス動画にしました。1本の撮影時間は約36秒(3000フレーム)、モノクロとカラーを交互に撮影しており、カラーカメラの撮影間隔は約3分半、1本目から5本目まで約13分(762秒)です。
各動画は AsutoStakkert! でスタックして RegiStax で軽く wavelet をかけてから WinJUPOS で image measurement して .ims ファイルを作成し、そうしてできた5つの .ims ファイルを de-rotation of images に add して save image sequence で de-rotation 済みの128コマのフレームを生成しました。
生成した各フレームは RegiStax で wavelet 処理して、それらを ffmpeg で20fps/6.4秒(約120倍速)の動画にまとめました。
'Save image sequence' 機能の使い方
'Save image sequence' 機能は de-rotation of images のおまけ機能のようなものです。まずはいつも通り De-rotation of images ダイアログを開いて .ims ファイルを追加して、de-rotation のための各種設定を行います。
Reference time は設定しなくてよいです。それ以外の設定が完了したら [Save image sequence] ボタンを押すと Save image ダイアログが開きます。
ここで 'Number of images between first and last Image measurement' の入力欄に生成するフレームの数を入力します。
ここに具体的にどんな値を入力すべきかは、その下の 'Time span in seconds' (Image measurement の最初から最後まで何秒間か)を参考にします。後述しますが、入力する値はほぼ {Time span in seconds} / 6 + 1 の一択です。今回は 'Time span in seconds' が762なので、762 / 6 + 1 = 128 を入力しました。
入力したら [OK] を押すとダイアログが閉じて de-rotatin 画像の連続出力が始まります。
出力中は De-rotation of images ダイアログの左下に現在出力中のフレームのカウントと reference time が表示されます。出力画像は Destin. directory に設定したフォルダに保存されます。Ryzen 5 8600G (6C12T/4.3GHz)のPCで128コマの出力に約12分かかりました。
各出力画像のファイル名の書式は通常の de-rotation と同じで {Reference time(UT)}-{Observer}-{Image info}.{Image type} です。ファイル名を昇順に並べると reference time 順になります。
この後は RegiStax の Macro/Batch 機能でまとめて wavelet 処理をかけます。出力ファイル名には一律のプレフィックスが付くのでファイル名昇順ソートで reference time 順になるのは変わりません。
RegiStax で出力先フォルダを wavelet-sequence、出力ファイル名のプレフィクスを wavelet-、出力画像形式を PNG とすると、ffmpeg に以下のようなオプションを付ければOKです(-vf オプションはクロッピングの指定です)。
ffmpeg -framerate 20 -pattern_type glob -i 'wavelet-sequence/wavelet-*.png' -vf 'crop=w=800:h=800:x=560:y=560' -an -c:v libx264 -crf 15 -pix_fmt yuv420p Jupiter-2024-10-12-1904_0-1916_7.mp4
問題点
'Save image sequence' 機能を使ってみて気付いた問題点を以下に挙げていきます。
出力コマ数の指定方法の問題
タイムラプス動画を作る場合、再生速度を何倍速にするか、fps をいくつにするかを意識すると思いますが、'Save image sequence' 機能では、フレーム間の時間間隔は [Save image sequence] ボタンを押すと開く 'Same image' ダイアログの 'Number of images between first and last Image measurement' に指定した出力画像のコマ数で決まります。
ダイアログには 'Time span in seconds' (最初の Image measurment の観測時刻から最後の Image measurment の観測時刻までの秒数)が表示されていますが、これを参照してコマ数に {Time span in seconds} / 6 + 1 を指定するとフレーム間の時間間隔が6秒(0.1分)になります。
ここで、この値を超える値を指定しても意味がありません。ファイル名が 0.1 分単位で決まるので、ファイル名が重複して上書きされて結局 {Time span in seconds} / 6 + 1 コマしか出力されません。これに気付かずに指定枚数を元に fps を設定すると想定した速度にならないため注意が必要です。
また、コマ数に {Time span in seconds} / 6 + 1 より小さい値を指定した場合、コマ間の経過時間が等間隔にならないことがあります。
例えば 1658.5 〜 1707.9 の Time span in seconds が 564 の de-rotation で90枚を指定たところ、1659_2, 1659_3, 1659_5, 1659_6, ... のように不連続なファイル名が生成される箇所が出てきました。
実際の de-rotation の reference time が 0.1 分より高い精度で計算されていてファイル名のタイムスタンプだけ丸められているのなら問題ないのですが、出力画像を見た感じでは reference time の段階で時刻を丸めているようで、1659_2, 1659_3, 1659_5, 1659_6 のコマ間の経過時間は 0.1分、0.2分、0.1分というふうになり、2コマ目と3コマ目はジャンプしたように見えました。実際のところ20cm級の鏡筒での撮影倍率だとほとんど気付かないと思いますが…
以上のようにややこしいので、コマ数指定は {Time span in seconds} / 6 + 1 の一択、すなわちコマ間の経過時間を0.1分に揃えるのが正解だと思います。
長時間の撮影データを扱う場合はコマ数が増えすぎるとデータ量が大変なのでコマを間引きして出力したくなるかもしれませんが、後述するように実際には本機能で長時間の撮影データを扱うのはほぼ不可能なので気にしなくて良いです。
長時間の撮影データを扱う際の問題
長時間撮影、すなわち多数の動画を連続して撮影した場合、通常は動画の数だけ Image measurement を行い .ims ファイルを作成して、そこから連続した数本の .ims ファイルを使って1コマの de-rotation 画像を生成すると思います。
多数の .ims ファイルを使って de-rotation すればノイズの点で有利にはなりますが、最初の .ims の時刻と最後の .ims の時刻まで時間が開くと、その間の模様の変化などがスタック処理で平均されてしまうので時間解像度が落ちてしまいます。
また、多数の .ims ファイルを使った de-rotation では、出力画像にアーティファクトが出やすくなります。アーティファクトというのは惑星の縁に不自然なノイズが出る現象のことを言っています。以下は今回本機能で出力した de-rotation 画像のうち最後(reference time が最大)のコマを拡大したものです(見やすいように明度を挙げてあります)。
この画像では惑星の縁に黒いノイズが乗っていますが、惑星の縁の外側に白いノイズが乗るパターンもあります。これらのアーティファクトはLDを下げる、de-rotation 前に適度に wavelet をかける、Weighting を工夫する等の対策で軽減できますが、経験的には de-rotation のタイムスパンが長くなると対処が困難になります。
おそらく image measurement の精度が足りないのだと思いますが、少なくとも自分の腕前では reference time はタイムスパンの中央付近に設定して .ims ファイルは5本まで、というのが限界です。
しかし 'Save image sequence' 機能で長時間のタイムラプス動画用のフレームを生成しようとすると、全ての .ims ファイルを De-rotation of images ダイアログに追加して、全てのスタック画像を使った de-rotation を行うしかありません。Weighting も全フレームに一律に適用されるので工夫の余地がありません。
これだと、出力の時間解像度は落ちてしまいますし、アーティファクトも出やすくなってしまいます。時間解像度はゼロというか、全フレームが全スタック画像の惑星面の平均になってしまうので、惑星面は事実上同じ画像をシミュレーションで回転させているだけの動画になってしまいます。
ということで、長時間のタイムラプス動画のフレームを 'Save image sequence' 機能で一度に生成するのは現実的ではありません。やるとしたら .ims ファイル5本ずつぐらいに分割して save image sequence を繰り返すことになるでしょう。
もっとも作例でも最終フレームにアーティファクトが出ていたり、途中でも最初と最後で惑星の縁の明るさが変化したり(左の縁は暗く、右の縁が明るくなっていく)、5本でも多い気がします。
.ims ファイル3本ならこのあたりの問題は軽減できそうですが、de-rotation のスタックによるノイズ軽減効果はかなり減ってしまい、de-rotation 後の wavelet 処理もあまり強くはかけられなくなりそうです。
ならば .ims ファイル5本にして、save image sequence の出力フレームの最初の方と最後の方は捨てる、次の回の save image sequence では前回使った .ims ファイルの最初の2本を抜いて、続きの2本を追加して処理する… といったことを繰り返すのがベストになりそうです。
これだと手順的には手作業で reference time をずらしながらフレームを生成しているのとあまり変わらず、reference time を0.1分ずつずらして compile image する手間は省けますが、.ims ファイルの入れ替え作業等は同じだけ手間がかかり、出力フレームの一部を捨てる作業が追加されることになります。それでもトータルではだいぶ省力化にはなるのでしょうが、イマイチ釈然としないものがあります…
それではどうする？
昨年10月12日深夜から13日未明にかけての木星の撮影データの処理はあまりにデータが大量で、手作業でのタイムラプス動画用フレームの生成は行き詰まっていました。12月の記事でそのあたりの話を書いています。
ここで、.icm ファイルを自動生成して WinJUPOS のマクロ機能で一括処理することを考えていたのですが、.icm ファイルのファイルフォーマットが公開されていないので困ってしまいました。実はこの後 WinJUPOS の作者の Hahn さんに教えてもらおうとしたのですが、結局教えてもらえませんでした。
で、自力で .icm ファイルを解析したりもしていたのですが…
WinJUPOSの.icmファイルの解析、ここまでできた。 pic.twitter.com/WJd5nWUWgo
— 🌻ﾅょωﾚよ″丶)ょぅすﾚﾅ🌻 (@rna) December 29, 2024
ここまでやった後、アトラス彗星(C/2024 G3)がやってきたりでバタバタして燃え尽き気味になってしまい、そこから進んでいません。また解析作業を再開しますかねぇ。.icm ファイルを JSON なり XML なりの扱いやすい形式相互変換する公式ツールがあればこんなことしなくて済むのですけど。
あるいは WinJUPOS がオープンソースになれば自分で(あるいはみんなで)なんとかできるかもしれないのですが。お金出してソースコードの権利売ってもらえたりできないですかね。100万円くらいなら出していい気がしてます…
