Deep Sky Memories

横浜の空で撮影した星たちの思い出

Wavelet で BlurXTerminator と勝負!(追記あり)

最近巷をざわつかせている「AIによる deconvolution ツール」BlurXTerminator (BXT) に惑星写真の画像処理の経験で培った wavelet 処理で勝負を挑んでみました。

BlurXTerminator とは

BXT とは一体何物か?これは「PixInsight 本」でお馴染みの丹羽雅彦さんの動画を見ていただくのが手っ取り早いと思います。

「BlurXTerminatorは「すごいの民主化」- PixInsight」

最初の6分半で概要の説明があり、以降は実際の画像処理のデモンストレーションやパラメータ調整のコツ、インストール方法などです。最初のところだけでも見てください。

動画の解像度だと画像処理がどこまで上手く行ったのかわかりづらいので、作例についてはだいこもん(id:snct-astro)さんのブログ記事をどうぞ。

丹羽さんもだいこもんさんも触れていますが、当初は懐疑的な声が少なからずありました。ハッブル宇宙望遠鏡(HST)の撮影画像等が学習データに使われているとされており、実質的には AI によって元画像が HST の画像に置き換えられるような処理がされてしまっているのでは、という懸念です。

しかし、BXT の作者の説明によればあくまで deconvolusion の PSF (Point Spread Function: 点光源が光学系を通って結像した時にどう広がるかを表した関数)の推定に AI を使っているのだということ、学習済モデルのファイルサイズも約108MBと、画像生成系 AI として機能するには小さ過ぎるきらいはあり(最近流行りの画像生成AI「Stable Diffusion」は数GBのモデルを使用)、かといってクラウドサービス等に処理を投げている形跡もない(ネットワークを切ったスタンドアロン環境でも正常に動作)ということで、そこまで変なことはしていないだろう、という認識に落ち着きつつあります。

とはいえ、天体写真の場合、トレーニングに使った天体と同じ天体の画像が入力された場合に、学習した画像の特徴がダイレクトに出力結果に反映されてしまうのではないか?という懸念はあります。そういうことが起きるかどうかはAIが「知識」をどこまで抽象化・一般化された形で学習しているかにかかっています。

Wavelet とどっちが強い?

だいこもんさんのブログ記事では、だいこもんさんが日頃の画像処理で使用している PixInsight (PI) の deconvolution 機能を使った作例と比較して、BXT では deconvolution 以上に解像感があり、かつ自然な仕上がりになったことを報告しています。

これを見て僕が思ったのは…

「惑星写真で鍛えたワシの wavelet 処理のウデマエをもってすれば、解像感だけならこのくらいはイケるんじゃね?」

いや、思っただけでなくコメント欄に書き込んじゃいました。傲慢!

それならば、と、だいこもんさんがブログの作例で使用した M104 の写真の元データを送ってくださいました。というわけで BXT と勝負です!

と言っても、BXT に wavelet で勝てるということは裏を返せば BXT はあり得ない結果を出力しているわけではないという話にもなり得ますので、その場合は、ある意味「BXT の勝ち」とも言えるのですが…

それはさておき、まず頂いた元データを RegiStax 6 で処理します。元データは 32bit float のグレースケール画像です。PI からは無劣化でTIFFにエクスポートできますが、残念ながら RegiStax は 32bit float のTIFFは正常に読み込めません*1ので 16bit int のグレースケールTIFFでエクスポートしたものを処理しました。

なお、頂いたデータはプライムフォーカス鏡筒の RASA11 で撮影した撮って出し画像のようで、鏡像(裏返し)のものでした。だいこもんさんのブログ上でも鏡像のまま処理していますので、こちらでも鏡像のままでアップします。

まず、リニア画像のままではコントラストが低すぎて RegiStax ではうまく処理できませんでしたので、ArcsinhStretch (stretch=115, blackPoint=0.012, protectHighlights=true)で処理したものが以下です。

ArcsinhStretch(115/0.012/Protect highlighs)
wavelet 処理前

これを頑張って wavelet 処理しました。パラメータはリンク先の flickr のページの説明欄に全て掲載しています。マスクは RegiStax で設定できる輝度レンジの制限によるもののみ使用しています。星マスクは一切使用していません。

M104-AS-crop-wavelet-4-C95-DR10_240-M92_190R8F13
RegiStax 6 による wavelet 処理後

かなり解像してはいるのですが、銀河の淡い部分に空間周波数が低めのディザパターン状のノイズが浮いてしまっています。Linked wavelets を有効にすると出やすいのですが、これはノイズ処理ではうまく消せないんですよね…

とりあえずノイズ処理でどの程度目立たなくなるか Photoshop の Camera Raw で仕上げました。ノイズ感の確認のみを目的としているので星のリンギング等のケアはしていません。

M104-AS-crop-wavelet-4-C95-DR10_240-M92_190R8F13%20-cameraraw
ノイズ処理後

暗黒帯のディテールはそこそこイケてますが、やっぱり銀河の淡い部分のノイズが目立ってますね… ちなみに解像についてだいこもんさんの評価は deconvolution と同等という評価。個人的にはちょっと上かなと思ったんですが… でも BXT の結果とはだいぶ差があるという点は一致しています。ぐぬぬ

ひょっとして 16bit TIFF に画質を落としてから処理している分 wavelet 処理が不利になっているのでは?と思い、だいこもんさんに教えていただいた PI の MultiscaleLinearTransform (MLT) で再戦を挑みました。

MLT は日本の PI ユーザー界隈ではあまり研究が進んでいないとのことですが、月面や惑星写真の処理に RegiStax と同様に使えるらしいとのこと。これは PI で処理中の 32 bit 画像にそのまま適用できます。

実際触ってみるとパラメータの体系は RegiStax とよく似ていて、deringing や denoise の機能もあります。マスク処理は PI の共通機能のマスク処理を利用します。ただし linked wavelets に相当する設定は見つけられませんでしたので、素の wavelet 処理でやってみました。

マスクなしで暗部のノイズがどう出るかも知りたかったのでクロップ範囲を広げてマスクなしで処理してみました。

やはり事前にストレッチが必要でしたので、ArcsinhStretch、MLT 後に再度 ArcsinhStretch で階調を整えています。こちらもリンク先の flickr のページの説明欄にパラメータを全て掲載しています(PI の History からのコピペです)。

M104-CROP_AS_MLT_AS
MLT による wavelet 処理後

解像は BXT に迫っている気がします!でも、やっぱりノイズが… RegiStax の結果よりは空間周波数が高めのノイズなので処理はしやすそうですが、輝度の振れ幅がデカくてザラつきを消しきれるかどうか…

ということで、Camera Raw で仕上げたのがこちらです。何故か Photoshop の編集画面と出力画像で階調が食い違ってしまって(出力の方が暗くなってしまう)かなり背景が暗くなってしまいましたがご容赦を。

M104-CROP_AS_MLT_AS-cameraraw
ノイズ処理後

縮小画像だと目立ちませんが、等倍で見るとホットピクセルやダークピクセルみたいなノイズが散らばっていて結構目障りです。これを無理やり消そうとすると解像感もかなり落ちてしまうんですよね… Photoshop のダスト&スクラッチで消せるかもしれませんがさすがにそれはやりませんでした。

ちなみに自分でも BXT のトライアルライセンスを手に入れて使ってみました。パラメータは例によって flickr のページの説明欄に記載しています。

M104-CROP-BXT2-AS
BlurXTerminator による処理結果。

お、MLT の方が解像感は上!と言いたいところですが、だいこもんさんの記事の作例に比べるとなんかぼんやりしてますね… パラメータの違いでしょうか?

ということで、MLT で wavelet を追い込めばディテールの解像に関して言えば BXT に迫れる、上手くやれば越えられるかも?という手応えはありました。逆に言えばディテールの描写に関しては BXT は特に変なことはしてないのではないか?とも言えます。鏡像の M104 に対しても普通に鏡像のディテールを出力しているので、学習した画像の特徴がそのまま出てきているというわけでもなさそうです。

が、しかし… deconvolution やってるはずなのに、なんでこんなにノイズが少ないんでしょう?ていうか出力画像のノイズレベルはほぼ元画像と同じくらいに見えます。deconvolution でそんなことできるんでしょうか?*2

考察

マニュアルの解説では 512x512 のタイルに分割してある程度適応的に PSF を推定しているとのことなのですが、ノイズの出方(というか出なさ)を見るとそんな粗い区切りでどうにかなるとは思えません。ディテールが解像している部分の周辺でも明らかにノイズが少ないのです。

そもそもノイズの発生は PSF で表現できるのでしょうか?*3 ショットノイズはまばらに到着する光子のバラつきに由来するもので、PSF は関係ないように思われます。ダークノイズに至っては光学的な要素は一切ないので PSF で表現するのはおかしいと思います。

となると、事後的にディテールのあるところにマスクをかけて denoise しているか、もしくは事前にディテールのないところにマスクをかけて deconvolution がかからないようにする、というような処理をやっているのではないかと考えられます。そのマスクもまた AI が生成しているということなのでしょうか?

もしそうなら、それらの処理を分解して各段階で生成されたパラメータを出力するようにして欲しいところです。その方が PixInsight の設計思想にもマッチするはずですし…

しかし、上で推測した処理に相当する事を全部 AI が一気通貫にやってしまっていて、そもそも処理を分解できない、という可能性もあります。だとすると、それを deconvolution と呼ぶのは無理があるのではないでしょうか? Stable Diffusion のような画像生成系の AI とは一線を画した処理になっているのだとしても、それが実際に何をしているのか、もう少し的確な説明が必要なのではないかと思います。

AI がマスクを自動生成することを「お絵描き」として禁じ手にするかどうかは微妙な問題で、(科学的な測定の対象ではない)あくまで観賞用として仕上げた写真に適用するならば容認できる、という価値観は一概に否定できるものではありません。僕も StarNet なんかは容認しています。*4

しかし「どんなマスクが生成されたのか」というところがブラックボックスのままでは、個人個人が自分の価値観に従って妥当性を検証するということができないのではないでしょうか?

熟練した天体写真家なら処理結果を見るだけでもやり過ぎか否かという判断はできるのかもしれません。しかし、処理プロセスの段階で「今自分がやっている作業はやり過ぎか否か?」ということをユーザーが自覚して自重することが可能な仕組みになっていないと、操作が簡単だからといって万人に広くお勧めできるものとは言い難いのではないかと思います。

これが一貫した理論に基いて処理されて、条件が合えば妥当なマスクが生成可能で、条件が合わなかったり調整に失敗したりした場合はあからさまに変な結果になる、ということであれば、むしろお勧めしやすいのですが…

DeepL 翻訳や ChatGPT なんかがそうですが、一部の AI は実際には失敗している結果を「それっぽく」見せてしまって、失敗していることに人間がなかなか気付けない、という怖い特性を持っています。そういった AI を自己責任で使う分にはいいのですが、結果をそのまま人に見せるのには危うさがあります。「写真」というタテマエのある画像処理においてはなおさらです。

BXT がその手の「怖い」AI なのではないか?という疑念を僕はまだ拭いきれないでいます。丹羽さんは BXT も「すごいの民主化」だと歓迎していますが、僕は第三者が検証できないブラックボックスに身を委ねる「民主化」にはどうしても抵抗があります。

では、仮に BXT が OSS 化すれば「民主化」と言えるでしょうか?それは AI がどこまでやっているかによります。masking や denoise と deconvolution が AI 処理の中で一体化していて、何をやっているか外部から検証できないようであれば、問題は残るでしょう。

もっとも、それを言ったら日ごろ使っている画像処理ツールだって素人からすれば事実上のブラックボックスではないか?という疑問はあると思います。しかし、処理のバックグラウンドにある理論に対する信頼があり、理論通りに実装されていることが何らかの形で検証可能であるならば真のブラックボックスとは言えません。

AI も学習理論自体は科学的に信頼できるものだからブラックボックスではない、と言えるでしょうか?しかし AI の学習理論はメタ理論とでも言うべきもので、理論通りにトレーニングした AI が学習した画像処理の「理論」が信頼できるかどうかは別問題です。複雑なタスクを学習させた場合、その「理論」が信頼に足るという保証は学習理論自体にはないと思います。*5

もっとも、通常の理論に対する信頼も、理論が何かを保証しているというよりは経験によるところが少なくありません。画像処理のように人間の知覚が関わる分野では特にそうです。例えば JPEG 画像も最初は医療分野で画像診断に使って良いかどうか議論があったと聞きます。それが現在では一定の圧縮率以下なら診断に使ってOKということになっています。

AI も同様にして社会的な経験の積み重ねで容認されていくということはあると思います。しかし AI には学習を続けていくことで特性が変化するという流動的な部分があります。学習が進んだ結果、今までなかった欠点が出てくる可能性も否定できず、単純な経験の蓄積では信頼が深まらない可能性があります。

これを乗り越えるには、学習アルゴリズム自体にネガティブな流動性がまず出ない、というメタレベルの経験の蓄積が必要かもしれません。あるいは長年の使用に耐える、追加学習が不要な程に十分トレーニングされたモデルが登場すれば、モデルが「枯れる」頃には信頼が蓄積されているでしょう。いずれにせよ、そうなるにはまだまだ長い時間がかかると思います。

というわけで、今のところの僕の BXT に対するスタンスは「アリ寄りのナシ」といったところでしょうか…

追記(2022/12/23 12:00): これからの AI にどうして欲しいか

昨夜書きそびれたことを。天体写真の画像処理で AI を使う場合、何をやって欲しいかというと、wavelet とか deconvolution とかの複雑なパラメータ調整の最適化です。AI が直接画像を出力するのではなく、従来からある処理のパラメータを出力して欲しいのです。

そういう形であれば検証可能性という点でも理論の信頼性という意味でもブラックボックス化を避けられますし、出てきたパラメータをさらに人間がチューニングして AI に追加学習させるといった協働作業も可能になると思います。

レーニングによって上手い人の画像処理パラメータを再現できるようだといいんですけどねぇ。wavelet なら Damian Peach 風とか熊森照明風とか。そういうモデルを作って有償配布して利益を本人に分配するとか、そういう世界になったら楽しそうです。

*1:読ませると変なカラー画像として読み込まれてしまいます。

*2:ちなみにだいこもんさんの deconvolution の作例ではマスクをかけて deconvolution がかかる範囲を制限しているとのこと。BXT の作例の方はノーマスクだそうです。

*3:ニューラルネットの研究をやっていたので convolution はわかるのですが、deconvolution のことはあまりよくわかっていません。

*4:StarNet は主題(星雲)とそれ以外(星)の境目にしか効かないから、という理由ですが。

*5:僕が大学院でニューラルネットワークをやっていたのは30年近く前の話なので、今でもそうなのかは断言できませんが…

ふたご座流星群 (2022/12/14) / SimpleMeteorDetector v0.2.0 を公開しました

先日の速報でもお伝えした通り、ふたご座流星群の極大日の12月14日の夜、ベランダから流星の撮影をしました。

昨年と同様、フォクトレンダー 17.5mm F0.95 で動画撮影して、フリーウェアを改造した手製のツール(SImpleMeteorDetector)で流星検出、ダイジェスト版動画の生成、という流れ。ただし、鳥や飛行機の誤検出と思われるものは目視で確認して取り除いてから動画にしています。

結果はこちら。10分足らずの動画です。流星、いくつみつけられるでしょうか?

2022/12/14 ふたご座流星群 ダイジェスト動画
2022/12/14 ふたご座流星群 ダイジェスト動画
Voigtlander Nokton 17.5mm F0.95 (F0.95) / Kenko-Tokina スカイメモS / OLYMPUS OM-D E-M1 Mark II (ISO6400, FHD, Super Fine, 24p), 露出: 1/24秒 / SimpleMeteorDetector 0.2.0 で検出・動画生成

検出した流星にマーカーを付けたこちらの動画で答え合わせしてください。。

2022/12/14 ふたご座流星群 ダイジェスト動画(答え合わせ編)
2022/12/14 ふたご座流星群 ダイジェスト動画(答え合わせ編)

今回はカットの冒頭でタイムスタンプに下線を表示して、そこで時間がジャンプしていることの印にしています。検出結果から生成したカット割は113カットで、最低それだけの流星が検出されたのですが、よく見ると同じカットに2つの流星が写っているものが2つありました。そのうち片方は検出漏れでマーカーが付いていませんでした。

というわけでフルサイズ換算35mmの写野の中に最低でも115個の流星が流れたことになります。元動画の撮影時間を合計すると5時間45秒ありました。平均すると2分36秒毎に1個流れたことになります。正直こんなに写るとは思っていませんでした。

ちなみに動画の撮影時間の抽出は bashワンライナーでこんな感じ。

(for f in 2022-12-1*/*.MOV ;do ffprobe $f |& grep 'Duration: '; done) | perl -e 'while(<>){ $_ =~ /Duration: ([0-9:.]+),/; print "$1\n"}'

速報でお伝えした20:30頃の流星(火球)はこの動画の7個目です。タイムスタンプを見ると 20:30:45.6 あたりから流れ初めていました。ちなみにこれが今回撮った最大の流星でした。ちなみに流星痕については、永続痕が写ったのはこれ一つですが、短痕が出ているものはいくつか写っています。

SimpleMeteorDetector v0.2.0

今回の動画作成にあたり、SimpleMeteorDetector も色々改修したので、v0.2.0 として公開しました。

変更点は以下の通り:

  • 全コマンドで -h でヘルプを表示した際にバージョンを表示するようにした。
  • detector_tuner.py に、オプション --area-threshold, --area-value-threshold, --hough-threshold, --input-config-file を追加。
    • --area-threshold は元々 detect_meteor.py にあった雲や建物を検出して塗りつぶして誤検出されないようにするオプションです。detector_tuner.py では対応していなかったのですが、今回一部のカットで写り込んだベランダの天井のエッジが誤検出されてしまったので対応しました…
    • --area-value-threshold は --area-threshold による物体塗りつぶし用のパラメータで、物体の明るさの閾値を指定するものです。今回薄暗いベランダの天井を消せるようにするため追加しました。デフォルトは127で v0.1.0 と同じ値ですが、暗い物体を消したい場合はより小さな値を指定します。
    • --hough-threshold はハフ変換の threshold パラメータです。デフォルトだと短くて暗い流星が検出しづらいので追加しました。基本小さな値ほど細く短い流星を検出しやすくなりますがなかなか予測し難い効き方をするので試行錯誤が必要です。
    • --input-config-file は一度 --output-config-file で出力した JSON ファイルを修正して効果を確かめたい場合に使います。
  • detect_meteor.py に、オプション --area-value-threshold, --hough-threshold を追加。
    • 追加オプションについては detector_tuner.py で説明したとおりです。
  • make_digest_movie.py に、オプション --gamma, --rotation, --cue を追加。
    • --gamma は入力動画のフレームにガンマ補正をかけるオプションで、ガンマ値を指定します。1.0 より大きな値にすると画像が明るくなります。
    • --rotation は入力動画のフレームを90度単位で回転するオプションで、90, 180, 270(または-90)を指定します。今回、カメラと機材の干渉を避けるためにカメラが逆さまになる形で撮影したので必要になり、実装しました。
    • --cue は、上で少し触れたように、カット割りした部分の継ぎ目がわかるようにカットの冒頭でタイムスタンプの下に下線を表示するもので、下線の表示時間を指定します。
  • color 系のオプションのヘルプの R,G,B の並び順を訂正(R,G,B → B,G,R)。
    • 実質的には不具合だが互換性のため動作は変更せず B,G,R の並びで指 定する仕様に変更する。
      • OpenCV の画像操作APIでは色が (B,G,R) の並びで指定する仕様になっているのを忘れていました…

詳細は github リポジトリの README.md を参照してください。

なお、Anaconda 付属の ffmpeg はコーデックに h264 (libx264) が指定できなくて(ビルド時に無効化してあるようです)、mp4 動画は mp4v コーデックになってしまうようです。大抵のプレーヤーでは再生できるのですが、SNSや動画サイトにアップロードすると非対応で弾かれることがあるので(Twitterでも弾かれます) h264 にしたいところ…

Ubuntu の場合、OS側の ffmpeg は h264 対応なので、make_digest_movie.py の --pipe オプションを使ってOS側の ffmpeg にフレームデータを受け渡すことで解決します。bashコマンドラインだとこんな感じです。

(conda activate; ./make_digest_movie.py --pipe --rotation 180 --cue 0.5 --gamma 1.8 --timestamp-color "(160,160,160,192)" --disable-marker `ls 20221214-PC*/*.json`) | ffmpeg -f rawvideo -pix_fmt bgr24 -s 1920x1080 -framerate 23.97 -i - -c:v libx264 -crf 17 result-20221214-h264.mp4

これを実行する shell は conda activate しない素の shell です。カッコ内で conda activate して SimpleMeteorDetector のスクリプトを実行することで、Anaconda 環境を subshell に閉じ込めて、パイプの先ではOS側の ffmpeg を起動します。

蛇足ですが、上の動画のタイトル画面も ffmpeg で追加しています。

まず GIMP なり Photoshop なりで png 画像のタイトルを作って、タイトルを3秒表示するならそれを title-01.png, title-02.png, title-03.png と3つコピーして、以下のように ffmpeg でタイトル部分だけの動画を作ります。

ffmpeg -r 1 -i "title-%02d.png" -vcodec libx264 -pix_fmt yuv420p -r 23.97 title.mp4

これを SimpleMeteorDetector で生成したダイジェスト動画(result-20221214-h264.mp4 とします)と結合します。まず、以下の内容を filelist.txt のファイル名で保存します。

file title.mp4
file result-20221214-h264.mp4

そして以下のようにして ffmpeg を実行します(出力先は out.mp4 とします)。

ffmpeg -f concat -i filelist.txt -vcodec libx264 -b:v 4000k -r 23.97 out.mp4

速報: この流星痕がすごい2022 (追記あり)

12月14日の夜、ふたご座流星群の動画撮影をしました。19:20頃から24:45頃まで5時間半くらいまで、ほぼ連続で撮影。幸い最初から最後までごく低空を除いて雲ひとつない天気が続きました。

OM-D E-M1 Mark II の Full-HD Super Fine 24fps で撮影し、動画サイズの合計は118GB。ワンカットで撮影しようとすると30分弱で停止してしまうのでおよそ15分毎に区切って撮影しました。その区切りの間にピントの再調整をしたり、一度SDカードとバッテリーを取り替えたりしているので、抜けはたぶん10分くらいはあります。

今年は結構長い間撮影中もベランダから星空を眺めていて、延べ4時間くらいは見ていたと思います。流星を見るたびにツイートしていたのですが、カメラの液晶モニター越しに4個、肉眼では21個の流星を見ました。見えたかどうかはっきりしないやつが3つ、そして流星痕だけ見たのが1つありました。

流星痕だけ、というのはこれです。20:30頃のことでした。

作業記録のため流星を見つけた時以外にも何かするたびにツイートしていたのですが、オリオン座が昇ってきたのでオリオン座が入るようにフレーミングを変更した後、そのことをツイートしようとしていてふと顔を上げるとオリオン座の胸のあたりに斜めに切り裂いたような光が… えっ?何これ?

流星の写真で見るあの形のままで明るさは少しぼんやりした感じで、一瞬、さては流星見たすぎて幻覚でも見えたか?とか思ったのですが数秒経ってもはっきり見えているので、これは流星痕なのでは?と思いとっさにツイートしたのでした。

流星自体は全く見てなかったので残像の類ではないのは確かなのですが、こんなに大きく明るく長く残る流星痕を見たことは今まで一度もなかったので信じられない思いが強く、これで動画には写ってなかったらどうしよう… などとずっと思っていました。

22:20頃に1枚目のSDカードがいっぱいになって2枚目と交換し、1枚目のデータを取り込んで確認すると、、、写っていました。流星痕もはっきりと。

ふたご座流星群の流星と流星痕 (2022/12/14 20:30頃)
ふたご座流星群の流星と流星痕 (2022/12/14 20:30頃)
Voigtlander Nokton 17.5mm F0.95 (F0.95) / Kenko-Tokina スカイメモS / OLYMPUS OM-D E-M1 Mark II (ISO6400, FHD, Super Fine, 24p), 露出: 1/24秒 / TMPGEnc Video Mastering Works 5 で画質調整。

肉眼ではツイート後に見失った流星痕ですが、動画をみると3分以上残っていて、風に流されて変形しながら淡く広がって消えていく様子が写っています。このくらい残っていると3回どころか30回くらい余裕で願い事言えちゃいそうですが、流星痕でもご利益あるんでしょうか?

というか、流星自体もむちゃくちゃ明るいですね… これは流星本体も見たかった。

2022/12/14 20:30頃に横浜で見えた流星
2022/12/14 20:30頃に横浜で見えた流星
上の動画より切り出し。

フレーミングを変える前に写野に入っていた-1.7等の火星と比べても段違いに明るいです。金星でもここまでにはならないような… -5等ぐらいはありそう?これは火球レベル?

書き込み中にふと見上げたのも何か違和感があったからかもしれません。上の動画では消してありますが元の動画に入っている音声にはカメラの隣で見ていた僕の息を呑むような音が入っていて、どうやら流星が流れ終わってから2秒後くらいに流星痕を見たようです。さらに6秒後にため息が入っていてたぶんこのくらいまで肉眼でも見えていたのだと思います。

ちなみに流星の色ですが、Voigtlander Nokton 17.5mm F0.95 はパープルフリンジがそこそこ出るレンズなので紫色の光が本当の色かどうかはわかりません。流れた直後の流星痕が緑っぽいのは実際の色かもしれませんが、肉眼では色まではわかりませんでした。

流星痕には数秒以下ですぐ消える短痕と数分以上発光し続ける永続痕とがあるそうです。

短痕は酸素原子の緑の光、永続痕は窒素分子の赤い光が主成分とのこと。

それにしても52年生きていてもまだまだ「生まれて初めて」があるものですね。元々流星にはあまり興味はなかったのですが(所詮は大気中での現象だし)、今まで天体撮影中に何度か大きな流星を見てきて、またああいうの見たいな、という気持ちが芽生えてきて今回は結構がっつり撮影&観望していました。次は超新星見たいな、肉眼で…

追記(2022/12/15 19:10): 富士山から「静止流星」として見えていた!?

上の動画に写ったのと同じも流星と思われるものを、藤井大地さんが富士と平塚から撮影した動画を公開していました。

なんと富士山からは「静止流星」として見えていました。ということは房総半島沖上空あたりから富士山にめがけて飛び込んできた?

既に同時観測の解析結果が公開されていて、やはり房総半島沖あたりに飛び込んで燃え尽きたようです。

横浜からだと方向が微妙でよくわかりませんでしたが、どうもふたご座流星群のものではなく「12月いっかくじゅう座流星群」の流星のようです。ていうかそんな流星群初めて知りました…

上のツイートの返信欄に関東各地から撮影した写真・動画が集まっていて興味深いです。

火星 (2022/12/10)

12月10日の夜に火星を撮りました。今年は火星の接近の年で12月1日が最接近だったのですが、忙しかったり曇ってたりでやっと撮れました。

今年は火星の赤緯が大きいためベランダの壁や天井に隠れてしまう時間帯が長く、観測時間が限られる上、冬場でシーイングが悪い上にマンションのコンクリートが昼間に溜めた熱や、ベランダに漏れる部屋の暖気などの影響もあり、まともに撮れるものかどうか… という迷いはあったものの、とにかく撮ってみなければわからないということで、撮りました。

日没後ベランダに機材を設置して木星を見てみましたが、やはりシーイングが悪く細部が解像しません。ピント合わせも困難。19:30頃から火星を撮り始めたのですが、ただでさえ不安定な像が、ピント調整のために僕が出入りする度に部屋の暖気や僕の体温で像が乱れ、火星面でのピント合わせは無理でした。

結局アルデバランを導入してライブビュー表示にストレッチをかけてミューロンの3本スパイダーに由来する6本の光条が見えるようにして、光条が1点でクロスするように調整することでピント合わせしました。

30本くらい動画を撮りましたが、まあまあ見れる写りなのは5本ぐらい。途中で stack & wavelet したものを見ると解像が悪くてLRGB撮影する意味がないと思い、途中からRGBだけ撮りました。

結果はこの通り。

火星 (2022/12/10 20:17)
火星 (2022/12/10 20:17)
高橋 ミューロン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 315), SharpCap 4.0.9268.0 / 露出 1/125秒 x 1500/3000 コマをスタック x3 を derotation / AutoStakkert!3 3.0.14, WinJUPOS 12.1.2, RegiStax 6.1.0.8, Lightroom Classic で画像処理

ここはほぼ連続してそこそこ写ったので、3本 de-rotation して仕上げました。大シルチスが正面を通過して西側に回った後で、西側にはサバ人の湾が見えています。*1 北極冠が大きく見えています。2年前の準大接近では地球との位置関係で北極付近が見えなかったのですが、今回はよく見えています。

もう一つ、前後の動画の写りが悪く de-rotation はできませんでしたが、一番よく写った動画から仕上げたもの。

火星 (2022/12/10 20:36)
火星 (2022/12/10 20:36)
高橋 ミューロン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 315), SharpCap 4.0.9268.0 / 露出 1/125秒 x 1500/3000 コマをスタック / AutoStakkert!3 3.0.14, WinJUPOS 12.1.2, RegiStax 6.1.0.8, Lightroom Classic で画像処理

よく写ってもこんなもので、視直径も17秒角弱ですし、なかなか厳しいです。

途中から雲が出てきて22時前には撤収しました。今月はチャンスがあれば懲りずに撮ってみるつもりですが、結果はあまり期待できなさそうです…

*1:惑星面の東西は、惑星の北極を上にした時に右側が東、左側が西、としています。惑星面上に日本地図をイメージするとわかりやすいと思います。

WBPP で違う日に撮った撮り増しデータを扱う

なんか前々回から突然ブログ書いても☆が付かなくなったんですが、何かあったんでしょうか?僕の知らないところで破門状が回ってたりするんでしょうか?それはともかく前回の記事で書き忘れたネタを。

天体撮影では総露光時間を増やすために複数の夜にまたがって同じ対象を撮影して、それらを全部スタックして一枚の写真に仕上げることがあります。導入位置のズレなどは自動処理で補正できますし、冷却カメラなら温度を固定して撮ればダークも使いまわしできるのですが、フラットはそうはいかないことがあります。

1夜目の撮影後にカメラを取り外すと、次の夜の撮影でカメラを取り付けた時にカメラの向き(光軸を軸とした回転角)を完全に一致させることが困難な場合があります。接眼部とカメラに印を付けて合わせるという手もありますが、ねじ込み式のパーツがあるとピッタリ締め込んだ時の位置が微妙に変わることがあります。

また、フラット補正にはレンズやセンサー上に落ちたホコリの影を消す効果もありますから、取り外したカメラの保管中にホコリが動いたり増えたり減ったりということがありますので、なるべく撮影前か後にカメラを取り外す前に撮ったフラットを使いたいところです。

ところが WBPP はデフォルトではどのフラットをどのライトに適用するかは自動で決まります。同じカメラで同じフィルターを使ったフレーム同士でマッチングさせるわけですが、同じ機材を使っていると違う日のフラットもライトも全部混ぜてスタックされてしまいます。

WBPP 2.0 から入った Grouping Keywords 機能を使えばこれを避けることができます。

WBPP の画面右端にある Grouping Keywords にチェックを入れて、FITS ファイルのヘッダの名前をリストに追加すると、そのヘッダに入っている値が同じもの同士でフラットやライトがグループ化され、同じグループ内のフレーム同士のみマッチングされるようになります。FITS ヘッダ以外にフレームのファイル名やフレームが保存されているフォルダのフォルダ名などでもグループ化できます。

前回のエントリの写真の処理ではこの機能を使いました。

ここでは 2022/9/26 の深夜に撮った分を SESSION_2022-09-27 というフォルダに、2022/10/20 の夜に撮った分を SESSION_2022-10-20 というフォルダに放り込んで、Grouping Keyword に SESSION を追加しました。これで、フォルダ名の SESSION_ に続く部分が SESSION キーワードの値として解釈され、フラットとライトが 2022-09-27 と 2022-10-20 の2つのグループに分けられます。

https://rna.sakura.ne.jp/share/WBPP-GroupingKeywords-01.png

Calibration タブの一覧にキーワード SESSION のカラムが追加されていて、どのようにグループ分けされたかが確認できます。2022/10/20 は L の撮り増しのみだったので、FLAT と LIGHT の L のみ 2022-10-20 のグループができました(一度実行済みなので BIAS, DARK, FLAT は master になっています)。

でもよく見たら DARK と BIAS もグループ化されてますね… これではもったいのですが、これはどうやらキーワードを含まないフォルダにバイアスとダークを放り込んでおけば全グループのフレームとマッチングしてくれるようです。

https://rna.sakura.ne.jp/share/WBPP-GroupingKeywords-02.png

ダークは L 用の15秒のダークと0.03秒のダークフラットのみ別のフォルダにまとめました。結果 SESSION の値は - (空欄の意味)になり、FLAT と LIGHT の L の Dark の列にチェックが入って(Dark が当たった状態)適切にマッチングされたことがわかります。

なお Integration では全グループの Calibration 済みフレームがスタックされるので、撮り増しの目的通りの動きになります。

https://rna.sakura.ne.jp/share/WBPP-GroupingKeywords-03.png

NGC253 ちょうこくしつ座銀河 (2022/9/26, 2022/10/20)

もう2ヶ月前になりますが、9月26日の夜に FSQ-85EDP の実写テストも兼ねて NGC253「ちょうこくしつ座銀河」を撮りました。この時は L, R, G, B, Ha 全て撮ったのですが、L の総露出時間が足りなくてかなりノイジーな仕上がりになってしまったので、10月20日の夜に L を撮り増しして再処理しました。

まずは結果から。

NGC253 ちょうこくしつ座銀河 (2022/9/27 00:17, 2022/10/20 22:31)
NGC253 ちょうこくしつ座銀河 (2022/9/27 00:17, 2022/10/20 22:31)
高橋 FSQ-85EDP / ZWO LRGB filter, Ha Filter / Vixen SX2, D30mm f130mm ガイド鏡 + ZWO ASI290MM + PHD2 2.6.10, 2.6.11 による自動ガイド / ZWO ASI294MM Pro (46Megapixel, Gain 300, -10℃), SharpCap 4.0.8949.0 / L: 15秒 x (64+120)コマ, R/G/B: 30秒 x 24コマ, Ha: 2分 x 7コマ, 総露出時間 96分 / PixInsight 1.8.9-1, Photoshop 2023, Lightroom Classic で画像処理

最初は DeepSkyStacker, FlatAid Pro, Photoshop, Lightroom Classic で画像処理していたのですが、せっかくなので PixInsight で再処理しました。ちなみに最初の結果はこちら。

NGC253 ちょうこくしつ座銀河 (2022/9/27 00:17, 2022/10/20 22:31)
DeepSkyStacker 4.2.6, FlatAid Pro 1.2.7, Photoshop 2023, Lightroom Classic で画像処理。他のデータは上と同じ。

色が全然違いますね。バックグラウンドをニュートラルグレーにする形で色調を調整しているのですが、高度が低いので大気の影響で赤っぽく写っているのかもしれません。

PI で処理した最初の写真は先日のアップデートで入った SPCC (Spectrophotometric Color Calibration)を使って色合わせした上で銀河内のHⅡ領域(いわゆる赤ポチ)を強調するためRにHαをブレンドしています。銀河の中心部の赤みが強くなっていますが、他は本来の色に近い色になっていると思います。

PI の SPCC は天体観測衛星で測定した恒星のスペクトルデータとセンサーやフィルターの分光特性を元に撮影データから本来の色を復元する機能です。詳細はだいこもん(id:snct-astro)さんの以下の記事を参照してください。

以下、撮影や画像処理の細かい話を。

撮影

この日の撮影は、元々は9月6日に FSQ-85EDP + フラットナー(1.01x) + ASI294MM Pro の実写テストで輝星のゴーストが結構出たのでフラットナーなしでの状況の確認と、実際の天体撮影でどの程度影響があるかをテストするのが目的でした。

フラットナーなしでの星像も確認したかったのでガイドエラーの影響を抑えるために短時間露出で多数のコマを撮る方法で撮りました。ちなみにフラットナーなしでも輝星のゴーストは出るのは確認したのですが、そのあたりはまた後日機会があればまとめたいと思います。

画像処理

だいたいこんな感じです。ダイアグラムはブログ上に書いた Markdown 風のテキストを Mermaid という JavaScript ライブラリを使って描画しています。

PixInsight

graph TD
    subgraph raws
    R_raws
    G_raws
    B_raws
    L_raws
    Ha_raws
    end
    subgraph flattened
    R
    G
    B
    L
    Ha
    end
    raws -- WBPP, ABE --> flattened
    R & G & B --- _a(( )) -- ChannelCombination --> RGB
    RGB -- SPCC, HistogramTransformation --> RGB_stretched
    L -- HistogramTransformation, TGVDenoise --> L1_stretched
    Ha -- HistogramTransformation --> Ha_stretched
    RGB_stretched & Ha_stretched --- _b(( )) -- NBRGBCombination, TGVDenoise --> RHaGB_stretched
    RHaGB_stretched -- ConvertToGrayscale --> L2_stretched
WBPP でのエラー

WBPP のところは実際には Local Normalization で失敗、Integration で PI が異常終了してしまい Image Registration から先は Local Normalization は省略して Integration を単体で実行しました。

Local Normalization は L/R/G/B の Reference frame selection の処理 Estimating global scale factors のところで「PSFScaleEstimator::EstimateScale(): Internal error: No reference image has been defined」というエラーがコンソールに出て reference frame が生成できず fail になります。なぜか Ha は OK なのですが、コマ数が少ないからでしょうか?

PSFScaleEstimator のエラーなんだからと Scale evaluation method というパラメータで PSFなんとか以外の選択肢 Multiscale analysis 選択してみたのですが、今度は「Unable to compute a valid scale estimate (channel 0)」というエラーが出てきてダメでした。

WBPP での Integration は B/G/Ha は大丈夫で、落ちるのはいつも L のところでした。コマ数が多いのでメモリが足りないのかと思い他のアプリを終了してメモリの空きを 25GB まで増やしたのですがやはりダメ。

ググると同様のトラブルに対してはハードウェア側を疑うコメントばかりで memtest86+ を実行せよとか言われてたので頭を抱えていましたが、試しに単体の Integration を実行すると普通に完了できたので、結局原因究明は諦めてそれで済ませました。ただ、これをやると WBPP で実行された plate solve の結果がファイルに反映されないようで、SPCC を実行する前に改めて ImageSolver を実行する必要が在りました。

ちなみに WBPP はモーダルウィンドウを閉じた時に設定が保存される仕様ですが*1 設定後一度もウィンドウを閉じずに実行開始して実行中に異常終了した場合は設定が全部消えます。必ず一度ウィンドウを閉じてから実行することをお勧めします。*2

また、WBPP は一度実行して設定を変えて再実行する際に生成済みのファイル(cache)をなるべく再利用する仕様ですが、実行中に異常終了するとそこまでで生成されたファイルは再利用されないようです。Pipeline タブの Active Steps で落ちる部分から先のチェックを外して一度正常に実行完了しておけば、そこまでに生成されたファイルは次回以降再利用されるようです。

SPCC

SPCC の準備や設定はだいこもんさんの記事を参考にしました。記事では Gaia DR3/SP のデータを complete set もしくは small set を全部ダウンロードしていましたが、small set だとやや星が足りないとのこと。

じゃあ complete set か、でも全部で70GBか… と思ったのですが、DLするデータファイルは星の等級毎に分かれているので、必要な分だけ落として、落とした分だけ Gaia Preference で設定すればOKでした。

横浜の空ではまともに写るのは16等ぐらいが限界なので checksums-sha256 と gdr3sp-1.0.0-01.xpsd から gdr3sp-1.0.0-06.xpsd までの19GB弱だけDLしました。

SPCC の設定でも Catalog Search の Automatic limit magnitude のチェックを外して Limit magnitude に15.9以下の値を設定しました。今回の写真で試した限りでは Auto でも大丈夫でしたが念のため。

ちなみにセンサーの指定は ZWO ASI294MM Pro の場合 Sony IMX492 を選びます。ASI290MM は IMX290 だったので IMX294 だとばかり思っていたので迷ってしまいました。

Hαのブレンド

IC405 勾玉星雲の処理ではHαのブレンドで StarNet2 を使っていました。

が、NGC253 の赤ポチは小さすぎて StarNet2 に恒星と誤認されてしまうのではないかと思い今回は NBRGBCombination で R に Ha を混ぜるだけにしました。せっかく SPCC で色合わせしたのに、星の色が合わなくなるのでは?と思ったのですが、そこは妥協しました。

ちなみにストレッチ前のHαとRGBをブレンドしたものにSPCCをかけてみるのを試しましたが赤ポチの色が抜けてしまって意図したようにはいきませんでした。

RGB画像から追加のL画像を作る


短時間露出のせいか、Lを184コマスタックしてもまだノイジーだったので、LRGB合成の際にLにブレンドするためにRGB(Haブレンド済み)画像からL画像を生成しました。これは単純に ConvertToGrayscale で変換しました。

Photoshop

LRGB合成と階調と色調とノイズ処理の調整は Photoshop でやりました。このあたりは様々なパラメータの微調整の結果をリアルタイムに見れないと難しいと感じたからです。RGB由来のLをブレンドするのもブレンドの比率を決めるのに不透明度のスライダを動かしながら画像のザラザラ具合を見ると楽でした。

全体の流れはこんな感じです。

graph TD
    L1_stretched ---> L_layer_group
    L2_stretched -- 不透明度40% --> L_layer_group
    RHaGB_stretched ---> LRHaGB_stretched
    L_layer_group -- 描画モード:輝度 --> LRHaGB_stretched
    LRHaGB_stretched -- Camera Raw --> result

階調と色調のノイズ処理の調整は Camera Raw でやっています。ノイズ除去、特に色ノイズの除去は Camera Raw でやるのが簡単で綺麗なようです。トーンカーブの調整はストレッチの微調整もさることながら、背景輝度より暗い部分を持ち上げて低輝度領域をフラットに近いカーブにして背景のノイズが目立たないようにしたいというのが大きな目的です。色調は彩度を少し盛ったり、それでカラーバランスの偏りが目立ったものを再調整する等です。

そうやってできた result を Lightroom Classic に読み込んでから最終調整したものが最初の写真です。Camera Raw の機能は LR とほぼ同じなのですが、いつも LR に読み込むと物足りない気がして LR で最終調整してしまいます。Camera Raw に戻ってもいいのですが、LR 上で作業する方が過去の写真との比較などがやりやすいのでそうしています。

なお、画像は最終的に 3840 x 3840 ピクセルにクロップして仕上げました。元々銀河の大きさに合わせてクロップするつもりで46Megapixelモードで撮ったのですが、低空で光害の影響が大きいこともあって、フォーサーズの写野(フルサイズの焦点距離900mm相当)といえども ABE してもなお背景にムラが残ってしまったのも理由の一つです。

最後に

BLANCA-80EDP から FSQ-85EDP への乗り換えはうまく行きそうです。接眼部も頑丈で冷却CMOSとEFWを取り付けても撓みは感じられません。ゴーストについても大抵の対象では大丈夫そうです。あとは馬頭星雲あたりを撮ってみてダメなら何か対策を考えます。

今回 PI で再処理したのは SPCC の実装がきっかけだったのですが、いい感じに仕上がるのがわかり、これだけでも PI を導入した甲斐があったと言って過言ではないかも。NGC253 は過去何度か撮りましたが、今まではなんか茶色っぽい地味な銀河になってしまっていたので、今回初めて満足できる仕上がりになりました。

*1:赤い×印のボタンを押すと保存、他に保存する手段はない、という挙動はどうかと思うのですが…

*2:ていうか実行前に保存する仕様にしてくれませんかね…

皆既月食・天王星食 撮影記

既にエントリにまとめた通り、11月8日に皆既月食天王星食を撮影しました。


このエントリでは撮影までの準備と撮影中のあれこれや反省点をまとめます。

方針を決める

今回は皆既月食天王星食が同時に起こるということで、どちらかに絞るのか、両方撮るのかというところから悩んでいました。両方撮るとなると赤道儀が2つしかなくて、しかも SX2 の方は自力で外に持ち出す手段が今のところなく、必然的にベランダでの撮影になります。

当日は月が北に寄っていて、ほぼ東北東の位置から月の出で、欠け始めの月は南向きのベランダからは撮れません。かといってマンションの北側の廊下の東の端に陣取ると皆既の月が撮れません。途中でベランダに移動するのは極軸合わせが間に合いそうにないのでナシ。

ということでまず月食の全過程を撮るのは諦めて、ベランダから皆既の前後のみ撮ることにしました。これで同時に天王星食を撮るのも現実的になります。

天王星食の方は、せっかく撮るからには天王星が円盤状に見えるだけのクローズアップで潜入と出現の過程をじっくり動画で撮りたいと思い、μ-180C の直焦点に CMOS カメラを付けて撮ることにしました。動画は等倍速でじっくり見れる30fpsで撮りたいし、青緑色の天王星と赤銅色の月面の色の対比を楽しみたいので、ASI294MM Pro で撮るのはナシにして、ASI290MC を選択。

できれば天王星の衛星が次々と掩蔽を起こす様子も撮れればと思ったのですが、1/30秒露出で映るかどうか… でも30fpsにはこだわりたいし、天王星露出オーバーになると少しずつ隠れていく様子が見えなくなるので、衛星は写ればラッキーぐらいの気持ちで行くことにしました。結果的には1/30s露出では衛星はノイズに埋もれてしまい、スタックして炙っても何も出てこなかったのですが…

うちの機材で μ-180C を載せられるのは SX2 だけなので、月食を撮る鏡筒はスカイメモSに載せることになります。当然カラーで撮りたいのですが、天王星食と並行してモノクロCMOSカメラでLRGB撮影なんてやってられないので OM-D E-M1 Mark II で撮ります。

FSQ-85EDP をスカイメモSに載せる

ここで迷ったのがどの鏡筒を使うか。以前と同じ BLANCA-80EDT で撮るか、今年買った FSQ-85EDP で撮るか、ということ。直焦点で月を撮る分にはどちらもたいして違いがないのですが、せっかくなので FSQ-85EDP で撮りたいという気持ちが強くありました。

ですが、BLANCA-80EDT は2.4kg(DX接眼部に換装)でスカイメモSの純正オプション「微動台座&アリガタプレート+バランスウエイト」(ドイツ式赤道儀にするオプション)に載せてもバランスしますが、FSQ-85EDP は4.6kg(K-ASTEC 鏡筒バンド一式込み)もあり、そのままでは載せられません。

ちなみに「微動台座&アリガタプレート+バランスウエイト」はビクセン規格アリミゾ付きの改造品で、重量は全部合わせて2.0kgあります。

これに FSQ-85EDP を載せるなら追加のウエイト(1kg)が必要になり、合計で7.6kg。耐荷重約5kg(ウエイト等込みの合計)のスカイメモSには文字通り荷が重すぎます。

しかし諦めきれず10月の末にこんなものを買いました。

Neewer のカーボン製ジンバル雲台 GM100 です。これでスカイメモSをフォーク型赤道儀にしようという目論見です。

似たようなジンバルは他の中国メーカーから色々出ていますが、カーボン製で軽いのと、Neewer はかなり長く続いているブランドで、過去にアルカクランプやカニ目レンチなどを買って概ね満足していたので、これにしました。

ジンバルの三脚への取り付けネジは3/8インチで、スカイメモS付属のショートプレートをねじ込んでスカイメモSに取付可能です。ショートプレートと合わせた重量は1.2kgで、FSQ-85EDP を載せると5.8kg。

ちなみに BLANCA-80EDT をドイツ式で載せると4.4kg。それに比べて1.4kg重く、さらに重心が前方に飛び出すことを考えると過積載には違いないのですが、でもダメ元で買ってしまいました。

ジンバルへの鏡筒の取り付けはアルカクランプになるのでアルカ互換のアリガタが必要になりますが、これは RedCat 51 の付属のアリガタが裏返すとアルカ互換になる優れものなので、それを使うつもりでした。が…

はい。「アルカあるある」ですが、相性問題が出てしまいました。ジンバル側のクランプをいくら締めてもアリガタを固定できません。どうやらアリガタの溝の断面の台形の斜めの部分の角度が微妙に違うようで、0.5mmほどの隙間ができてしまうようです。加えてこのアリガタ、M6ネジで固定するタイプなので、鏡筒バンドのベースプレート(TP-60-222)のM8ネジとは合いません。

ということで、アルカ互換アリミゾガチャを引くべくネットの海を彷徨っていたところ、三基光学館のオリジナルのアルカ互換アリガタ「アリガタレールA10-145」を見つけました。タカハシ互換の35mm間隔のM8ネジで固定するタイプで、これなら素直に取り付けられるはず。

早速発注しようかと思ったのですが、お店が相模原ということで、通販するより直接お店に行ったほうが早いかも?と思って営業日を確認したところ、サイトの更新が3月で止まっていることに気付きました。店長ブログの方も2月の「リハビリ開始です」を最後に更新が止まっています。Twitter で調べると3月20日に Sam さんがお店に寄った時はおやすみだったとのこと。サイトのカレンダーでは営業日だったはずなのですが…

ということで店長の様子が心配なのですが、一応三基のアリガタを発注しつつ、別のアリガタも探すことにしました。ちなみに発注後すぐ自動返信メールは届きましたが、その後今に至るまで音沙汰がありません…

さて、別のアリガタですが、M8ネジのアルカ互換アリガタは他には見当たらず、M6ネジのものしか見つけられませんでした。そこでM6ネジをなんとかM8ネジに変換する方法はないかと探して見つけたのがこちらです。

埋め込みナットと呼ばれる、形は中空のイモネジで内側にM6の雌ねじが切ってあり外側がM8の雄ねじになっているものです。ただ、この手の製品のレビューを見ると意外と割れやすいという記述もあったり… まあ、中にM6ネジが通っている状態ならなんとかなるのでは、と思い発注しました。ベースプレートの厚みが8mmなのではみ出さないように長さ6mmのものを選びました。

これが使えることを祈りつつ、注文したのはユニテックの「アルカスイスレールL」です。こちらは KYOEI-TOKYO に発注したところ、即日発送されて翌日に届きました。びっくり。皆既月食前ということで気を遣ってくれたのかも。

そしてこれらを組み上げてこうなりました。じゃん(個人情報保護のために背景はボカしてあります)。

「NEEWER GM-100 ジンバル雲台」を使ってスカイメモSにFSQ-85EDPを載せる
「NEEWER GM-100 ジンバル雲台」を使ってスカイメモSにFSQ-85EDPを載せる

ルカクランプとの相性は大丈夫でした。しっかり固定できます。過積載については、決して安定しているとは言えませんが、ピント合わせが不可能なほどではなく、鏡筒に触れても5秒くらいで揺れは収まる感じです。

テスト撮影では電子シャッターの1秒程度の露出なら問題なく撮れました。ただ風には滅法弱いのですが、これは BLANCA-80EDT でも相当弱かったので当日風が吹かないことを祈るのみです。スカイメモSでの追尾には問題なく、構図調整に使う正逆の2倍速も大丈夫でした。

ジンバルそのものはフリーストップの動きもスムースで、さすがに焦点距離450mmではクランプを締めた時に構図がズレるのですが、慣れればそれを見込んで構図調整することは可能でした。

アルカスイスレールの取り付け状況はこんな感じです。

M6-M8埋め込みナットを使って「ユニテック アルカスイスレールL」を「K-ASTEC TP-60-222」に取り付ける (1)M6-M8埋め込みナットを使って「ユニテック アルカスイスレールL」を「K-ASTEC TP-60-222」に取り付ける (2)
M6-M8埋め込みナットを使って「ユニテック アルカスイスレールL」を「K-ASTEC TP-60-222」に取り付ける

ベースプレートの K-ASTEC TP-60-222 の中心にはM8の貫通穴とネジ穴が交互に並んでいますが、ネジ穴の方に埋め込みナットをねじ込んで、そこにアルカレールの裏側からM6のキャップボルトをねじ込んで固定しました。

高速SDカードを発注する

機材は一通り揃ったのですが、撮影前日になって E-M1 Mark II で連写した時に SD カードの書き込みが遅くて書き込み待ちで連写が止まるのをなんとかしたいな、などと思い始めました。

月食の写真は stack & wavelet 処理して赤い月面のディテールを出したいと思っていたので一回80連写ぐらいはしたいのですが、昨年の月食では50コマ弱で連写が止まり、時間をあけて撮った分は欠け際の変化のせいなのか、月が動いたのをAS!3が追尾しきれなかったのかうまくスタックできず、結局前半の50コマ弱を選別せずに全部スタックすることになってしまいました。

今まで使っていたのは昔何気なく買った Transcend の SDXC カードで UHS-I, U3, V30 のもの。もっと速いカードはあるのか?と思って調べてみると、E-M1 Mark II では UHS-II の SDXC が使えるとのことで、実写テスト記事もありました。

U3 だの V30 だのの意味は SD Association のサイトに書いてありました。

V90 とかいうやつが最高なのですが、これは最低保証速度90MB/sという意味。ただ実写テストでは最大書込速度が90MB/sの最速UHS-1カードでも、RAWの連写は54コマまで、書込完了して次に連写できるようになるまで30秒程かかるとのこと。最大書込速度260MB/sのUHS-2のカードなら74コマ連写で10秒ほどで次の連写が可能。

ということで、UHS-II V90 で最大書込速度200MB/s超のカードで翌日の夕方までに届くものをヨドバシ.comで探して、KIOXIA EXCERIA PRO (UHS-2, U3, V90, 最大書込速度260MB)にしました。

https://www.yodobashi.com/product/100000001005731170/

普通のSDXCカードに比べるとかなりお高いのですが(税込13,300円)、色々使いみちもあると思うので買ってしまいました。

実際使ってみると確かに速くて、皆既中の1秒露出とかならいくらでも連写できそうでした。満月の撮影では最高連写速度での書き込みになりますが、60コマ程度連写できました。結局当日の撮影では64GBほぼ使い切りました。

天王星食の撮影

天王星食の方は新しい機材はないのですが、前々回のエントリにも書いたように追尾精度が足りないと「出現」の撮影で失敗するので、薄明がまだ残る17:20頃からドリフト法で極軸合わせを始めて18:00過ぎまでかけて追い込みました。誤差0.5分以下まで追い込んだと思います。

次に問題なのはADCの調整。天王星で調整するのは厳しそうなので、木星の高度が天王星の潜入時の高度と同じになる19:00頃に木星でプリズムの角度(2つのノブの開き具合)を調整しました。このときピントも合わせました。

木星天王星赤緯が異なるため高度が同じでもADCの向きは変わってくるので、撮影時にはADCのプリズムが水平になるように2つのノブを同じ方向に回転させて調整しました。ちなみに結局RとBに1ピクセルずつズレが残ったので、撮影した SER 動画を SER Player の機能で align したものを使って動画編集しました。

あとは前々回のエントリに書いた通りです。NVMe のSSDを使っていたにも関わらずフレームドロップがちょいちょい出たのは残念でしたが、動画は十分鑑賞できるものになったので満足しています。衛星が写らなかったのだけは残念ですが…

天王星食の撮影 (2022/11/8)
天王星食の撮影 (2022/11/8)

月食の撮影

月食の撮影については反省点がいくつもあります。一番は前回のエントリに書いたように、連続撮影の途中で FSQ-85EDP のピントをずらしてしまうというポカをやってしまったことです…

撮影は10分毎で途中でピントをチェックをする余裕はなくもなかったのですが、皆既中の月面でのピント合わせは暗すぎて無理で諦めてしまいました。今思えばバーティノフマスクを使って恒星でピント合わせする手もあったのですが…

SX2 の極軸合わせに時間を取られてスカイメモSの極軸合わせをする時間がなくなり、SX2 を横目で見て目分量で合わせてしまったのも危なかったのですが、こちらは意外となんとかなりました。しかし毎回構図の修正が必要で、それがピントをずらしてしまう要因の一つでした。とはいえ、極軸が追い込んであっても月の赤緯自体が結構動くのでどのみち赤緯方向の構図修正は必要で同じことだったかも…

もう一つ、こちらの鏡筒では天王星食の撮影ができなかったこと。本当は撮るつもりでいたのですが、実際に動画を撮影し始めてリアルタイム映像を見ていると決定的瞬間をリアルタイムに見たくなり目が離せなくなって撮るのをやめてしまいました。動画撮影中に狭いベランダを行き来して、うっかり鏡筒に体をぶつけたりするのが怖かったのもあります。

今思えばインターバルタイマーレリーズがあったのだから、ダメ元でもいいからタイマーを仕掛けて撮っておけばよかったんですね。実際10分毎の構図のズレは少なかったのでそれでも撮れていたと思います。でもとにかく忙しい撮影でしたし、動画撮影の方でいっぱいいっぱいだったのでそこまで頭が回りませんでした…

画像処理について補足

画像処理の勘所は前回と前々回のエントリに書きましたので、補足程度のことを。

月食の写真は、アルバムで連続で見る時に月の位置が揃ってないと欠け方の変化が見にくいので、月がぴったり画像の中心に来るようにクロップしたのですが、位置合わせは全部 Photoshop で手動でやりました。実はこれが一番キツかった…

AutoStakkert!3 でも、Photoshop でも、輝度重心を画像の中心にすることはできるのですが、月食の写真の場合は輝度重心が月の中心になりませんし、食の進み具合で輝度重心が変化してしまうので、自動での位置合わせは無理でした。

「差の絶対値」でレイヤーを重ねて目視で位置合わせしたのですが、月面の模様で合わせようとすると輪郭が合わなくなりました。スタックの誤差のばらつきが相当あるのに加え、2時間以上撮っていると月の秤動の影響もあるようです。

次こそは…

そんなわけで色々大変でした。まあ、次はもっと上手くやります。って、次っていつ?次は2235年6月2日だそうです。

天王星食に限らなくても惑星食と皆既月食が同時に起こるのはこれが次。日本では見えません。南米あたりで見えるようです。Stellarium でシミュレーションするとこんな感じ。

https://rna.sakura.ne.jp/share/stellarium-20220602-lunar-occultation-of-Uranus.jpg

う〜ん、楽しみですネ!!