★青いのが生えてきた!
みなさま、あけましておめでとうございます。新年早々、七転八倒しているあぷらなーとです。
ところで、今オファーされているレビュー『案件』のひとつをこなすためには、どうしても未経験のカメラを準備する必要がありました。・・・というわけで、愛用している赤いのに加えて青いのが生えてきました。

はい。
IMX585を搭載する『スティック糊タイプ』の非冷却カラーCMOSカメラQHY5Ⅲ585Cです!
スペック的にはPlayerOneのUranus-Cとほぼ同じです。当然、高性能カメラであることが期待され、テンションが上がります♪
★想定内の個性
巷では「QHYこそ変な加工をしてない素のRAW画像を吐く通好みのカメラだ」という噂をよく耳にしていましたので、ZWOのHPCやPlayerOneのDPSに相当するピクセルマッピング的な処理は施されていないかも、とは予想していました。そこで、まずはダークフレームの時系列解析を行い、ホットピクセルなどの雰囲気を確かめてみることにしました。

※左:Uranus-Cのノイズ特性 右:QHY5Ⅲ585Cのノイズ特性
UranusCではゴッソリと排除された不良ピクセルが元気よく暴れている様子が分かります。
この特性と非冷却機である点を考えると、ホットピクセル起因のノイズを排除するのは苦戦しそうです。
それでも、いざとなれば自作プログラム『邪崇帝主(ジャスティス)』で『ソフトウェアピクセルマッピング』すれば楽勝だと思っていました。この時点では・・・。
ところが、全く油断していたとしか言いようがありません。
★なにかがおかしい
新しいカメラが生えてくると、自然とテンションが上がるもの。雲が流れる悪条件下でもノリノリでテスト撮影を楽しんでいました。ところが、年末年始で一気に5000枚近く撮った星雲画像を仮処理していた最中に、なにやら異変に気づきました。
「ダークが合わないのは想定内。しかし、ここまで合わないものなのか?!」
とんでもない量の残存固定ノイズが残ってしまう画像があるのです。下記は失敗画像を得る過程でどんなダーク減算が行われたのかを調べてみた時のものです。

上の画像の通り、全く同じ条件で撮ったはずのライトフレームとダークフレームなのですが、なんとホットピクセルの位置が大幅にずれているダークフレームによりダーク処理が撃沈した画像が多数存在していることに気づいてしまったのです。当然、ライトフレーム中のホットピクセルと違う位置からホットピクセルを引こうとするのですから、処理後の画像には「無傷で生き残ったホットピクセル」と「誤爆されてクールピクセル化した可哀想ピクセル」が同居することになります。ところが、よく見るとそのズレが全てY方向に16ピクセルで揃っているのです。
「ホットピクセル達が一斉に移動している!?」
そんな馬鹿げたことが起こるはずがありません。ROI(クロップ)しているならまだしも、今回はフル画素を使った撮影しかしていないからです。
★犯人は誰だ?
では、一体何がいけなかったのでしょうか? ここで、主に想像したのは下記の5つです。
①カメラが壊れた
これは恐怖過ぎます。なにしろ、ファーストライトの準備中に慌てて新品のQHY585くんを地面に落下させてしまったのですから、壊れてても不思議はありません。もし、保証が効かなかったとすれば、泣きながらもう一匹をポチるしかありません。それなりのお値段がするカメラですからお財布に大ダメージです。
②ドライバのバグ
年の瀬に悪戦苦闘したASI294MM-Proくんの謎でももそうでしたが、ここは怪しいですね。
でも、もしそうなら、メーカーさんか販売店さんに問い合わせをして、アップデートを待つしかありません。
③SharpCapのバグ
実際の操作はSharpCapで行っていますので、当然可能性はあります。この場合は不具合報告をしつつ緊急措置として別な撮像ソフトを使う必要がありますが、慣れるまでは大変そうです。
④自分のミス
ほとんどのケースでは犯人は使う側の人間です。
撮像パラメータの設定ミス・使用PCごとにソフト環境が異なる・規格外のケーブルの使用、などなどです。
今回もこの可能性が高かったため、半泣きで記録されているパラメータを調べる必要があります。
⑤仕様
ひょっとすると隠された暗黙のルールが存在していて、あぷらなーとが見つけられていないだけかもしれません。
初チャレンジのカメラですから、独自の文化を理解できてないならそのルールを見つけて慣れるしかありません。
⑤自然現象・超常現象
これだとお手上げです。もはや、祈るしかありません。
さて、撮像パラメータを変えてみる・撮像PCを変えてみる・接続ケーブルを変えてみる・撮像時の気温を変えてみる・OSを変えてみる、などなど色々やってみても有効な差異は見られませんでした。
ところが・・・
★ふと気になったこと
実は、先日天体実写していた際に違和感は感じていました。他のカメラと異なりQHY5Ⅲ585Cはライブビュー画面を見ながらのピント合わせ作業が異常に難しいのです。具体的にはピント操作をした時に像が一瞬遅れて表示されるような感触。そこで、昼間の風景をライブビューしたときにもそうなのか試していたときのことです。このカメラをSharpCapで使ったときには見慣れない設定パラメータがあるのですが、そのひとつが「スチルモードに設定」という設定です。
この機能が指す意味はよく分かりません。初めて目にしたときは、SharpCapを使う際に最初に押すライブビューボタンの逆(プレビュー画像を消して撮影だけをする)だろうと安易に考えて、気にとめませんでした。ところが、実際には不思議なことに「スチルモード」をONにしてもライブビューされたままです。ただし見えている映像の挙動のみが大幅に変わりました。具体的には、スチルモードをONにするとローリングシャッター特有の『コンニャク現象』(ローリング歪み)が盛大に出て、動く被写体がグニャグニャになるのです。
「これは怪しい!」
そこで、「スチルモード」をONにした場合のダークとOFFにした場合のダークを見比べてみると、怪現象と同じくそれぞれのホットピクセルの座標が16ピクセルズレていることが判明しました。
ちなみに、実際の撮影ではライトフレームの撮影ではシーケンサを用いずに撮影をしていましたが、ダークフレームの撮影では「現場でマウス操作で直接撮影した場合」と「シーケンサを用いて、寝てる間に自動撮影させた場合」が混在していました。他社カメラでは、どちらで撮影しても同じ像が得られていたので全く気にとめてなかったのですが、どうも今回のカメラでは像が変化する可能性が浮上してきました。要するに、手動操作で撮ったライトフレームに対して自動操作で撮ったダークフレームを用いるとホットピクセルの座標が16ピクセル分ズレて破綻するという疑惑です。
そこで「ではシーケンサを使って撮った画像にはスチルモードONの記録が残っているはずだ」と考えて撮影時の設定ログとして自動記録されているファイルをチェックすると・・・

SharpCapをライブビューモードで動かしつつ設定オプションでスチルモードをONーOFFさせると、その設定が記録されていますが、なんと、
シーケンサ(撮影手順を順序立てて予約しバッチ処理するSharpCapの機能)を用いて自動撮影させた際には「スチルモード」という項目自体が消されているのです。そこで、SharpCapのシーケンサで組まれているスクリプトのブロックを確認してみると、ありました!

つまり
「QHY5Ⅲ585Cはカメラ単体でスチルモードのON-OFFが指定できるが、SharpCapのシーケンサ制御で運用すると強制的にスチルモードONにされる。ただし、その事実はログから消されている。」というカラクリのようです。

では
『ダメなダーク』により撃沈した馬頭星雲の画像が『良いダーク』によってどう変わるか見てみましょう。
ででん!

※左:不具合が起こる組み合わせ 右:良好な組み合わせ
めでたし、めでたし♪
★暫定的な結論「なぜ16ピクセル分ズレるのか」に関しては今後の謎解き課題として、とりあえず今回の暫定的結論ををまとめておきます。
①SharpCapでQHY5Ⅲ585Cを運用した挙動は
スチルモードOFFで撮影した画像を基準(正常画像)にするとき
★スチルモードONでは画像全体が16ピクセル分だけ上方シフトして保存される
★シーケンサで自動撮影すると画像全体が16ピクセル分だけ上方シフトして保存される
②SharpCapでQHY5Ⅲ585Cを運用する場合は、下記に留意する必要がある
<ダーク減算が成功する組み合わせ>
ライトフレーム:手動でスチルモードOFF撮影
ダークフレーム:手動でスチルモードOFF撮影
ライトフレーム:手動でスチルモードON撮影
ダークフレーム:手動でスチルモードON撮影
ライトフレーム:シーケンサで自動撮影
ダークフレーム:手動でスチルモードON撮影
ライトフレーム:手動でスチルモードON撮影
ダークフレーム:シーケンサで自動撮影
ライトフレーム:シーケンサで自動撮影
ダークフレーム:シーケンサで自動撮影
<ダーク減算が不能となる組み合わせ>
ライトフレーム:手動でスチルモードOFF撮影
ダークフレーム:手動でスチルモードON撮影
ライトフレーム:手動でスチルモードON撮影
ダークフレーム:手動でスチルモードOFF撮影
ライトフレーム:シーケンサで自動撮影
ダークフレーム:手動でスチルモードOFF撮影
ライトフレーム:手動でスチルモードOFF撮影
ダークフレーム:シーケンサで自動撮影
★★★お約束★★★
①あぷらなーとは素人のため、今回の解釈が正しい保証はありません
②本記事は特定のカメラやソフトを非難もしくは賛辞するものではありません
③念のため、シーケンサの処理内容を色々と変えて(いわゆるノーコードで処理ブロックを組み直すだけ)みましたが動作が不安定だったため、成功にはいたっていません
④あぷらなーとはMATLABが大好きでPythonが大の苦手なので、SharpCapのスクリプト記述に関しては深入りしたくありません
⑤「なぜ16ピクセル分ズレるのか」に関しては、もはや好奇心だけの課題となったため後回しにします
⑥「他のカメラについてはどうなのだ」に関しては、そのうち手持ちのCMOSカメラ全てについてチェック予定です
※とりあえず、同一センサー(IMX585)を用いたUranus-Cでは、問題が無いことを確認しています
直接的な答えではなかったとはいえ、X上で皆様からいただいた有用なアドバイスや貴重な関連情報が、今回の謎を解く上で強力なヒントとなりました。本当にありがとうございました!!