★全く油断していたとしか言えません黎明期のZWOさんのカメラには「同一個体なのにロットによって別物」とかの難儀な個性があったのですが、近年は(飛躍的に技術が向上したのか)こうした品質のバラツキは耳にしなくなりました。素敵なことです。
ところが、油断していました。現在の主力カメラASI294MM-Proは大好きな機種なんですが、先日「同一個体なのに、いつのまにか性格が変貌した!?」と思しき事象を発見してしまいました。
詳細は上記の記事をお読み頂くとして、ざっくり言うと「本来HPC機能によって駆除されていた異常ピクセルが(いつのまにか)復活してる」という現象で「いつのまにかHPC機能は無効化されてしまった」気配です。もちろん、あぷらなーとは素人ですから複数の勘違いやミスも含まれている可能性は否定できませんが、せいぜい足掻いて見せましょう。
★可能性を絞り込む
前回の検証ごっこで、この怪現象は「最近酷使したセンサーの劣化ではなく、HPCの演算が無効化されている」ことに起因する気配が観察されました。通常なら、ここで販売店さんやメーカーさんに問い合わせをするべきところですが、ZWOさんからは『レビュー案件』を依頼されていない身なので、小心者の私としては恐れ多くて気が引けます。そこで、もう少し自力で試行錯誤して原因を絞り込んでみることにしました。
①SharpCapが余計なことをしているのではないか
現状で分かっているのは、『駆逐されたはずの異常ピクセルがゾンビのように復活した』という怪現象は2020年11月頃には起こっておらず、2022年5月頃には発現しているということだけです。それ以後は現在に至るまでこの現象が継続しています。数少ない情報源であるZWOさんの中国語版ASI294マニュアルには、意訳すると「HPC機能は、ほとんどのソフトが対応しており、デフォルトでONになっている」と記載されていますので、まず疑うべきは撮像ソフトでしょう。ZWOさんが言うところの「デフォルトでON」が撮像ソフト側で意図的に切られているかなんらかのバグで制御不能になっている可能性があるからです。
そこで、ZWOさんの純正アプリであるASICAPの最新版を用いて同条件のダークフレームを撮像し、不具合が解消しているかどうかテストしてみました。

※左から順に、2020年のSharpCap・現在のSharpCap・現在のASICAP
その結果、上記のように純正アプリでもSharpCapと同様に異常ピクセルが復活していることが分かりました。
どうやら犯人はSharpCapでは無さそうです。
②ネイティブドライバが中途半端に古いのではないか
現在使用しているネイティブドライバのバージョンは失念してしまったのですが、少なくとも最新版ではありません。ひょっとすると、たまたまバグの残ったバージョンのネイティブドライバを今まで使用していたのかもしれません。
そこで現時点での最新バージョンのドライバにアップデートして、同様の実験をしてみました。

※左から順に、2020年に使用していたバージョン・現在使用しているバージョン・最新のバージョン
その結果、上記のように最新版のネイティブドライバを使用しても状況が変わらないことが分かりました。
どうやらネイティブドライバが中途半端に古い訳でも無さそうです。
③ASCOMドライバではどうか
あぷらなーとは、あまり複雑な機材を使っていないので、色んな天文機材を一挙に扱えるASCOMはほとんど使っていません(PlayerOneのカメラをオートガイダー化する時のみは仕様の関係でASCOM制御してます)。
そこで、念のためネイティブドライバ制御をASCOMドライバ制御に代えてみるとどうなるかを実験してみました。

※左から順に、2020年頃のネイティブドライバ・現在使用しているネイティブドライバ・ASCOMドライバ
その結果、上記のようにASCOMドライバを使用しても状況が変わらないことが分かりました。
どうやらネイティブドライバのバグでは無さそうです。
★これが正常なら戦うのみ
前回の記事にも書いたように「素のデータであるべきRAWに補正を施して出力する」ことには賛否両論でしょうが、あぷらなーと個人としては「歓迎」する立場ですし、過去に検証ごっこした通り、現行の天体用カメラのほとんど全て(正確にはZWO製とPlayerOne製)にいわゆるピクセルマッピング系の異常ピクセル無効化機能(ZWOのHPC・PlayerOneのDPS)が実装されている状況からも、その有用性(星喰いなどを生じさせずに異常ピクセルのみを正確に弾く)が受け入れられていると考えます。
不思議なことにASI294MM-Proでこの機能が無効化されているのがバグでは無いのだとすれば自力でなんとかするしかありません。
ちなみに、過去にこの異常に気がつかなかったのは「油断していて再解析していなかった」のが原因ですが、PC内の過去データを漁ってみると、違和感を感じつつも「今日はコンディションが悪いなぁ」とか「今回の撮影対象は難敵だなぁ」と早とちりして奮闘していた痕跡が残されていました。奇しくも異常が生じはじめた2022年5月のことです。

久々に挑戦したM51子持ち銀河の画像が不可解なノイズまみれになり通常のダーク減算処理が通用しなかったため、「σクリップ」「ホットクール除去フィルタ」などの定番テクニックに加えて「クールファイル補正法」「手動ダーク減算法」「ダークあり画像と無し画像のブレンド」「低温ダークと高温ダークのブレンド」「(開発中の)ソフトウェアピクセルマッピング法」「(開発中の)深層学習デノイズ」その他
諸々の邪悪な処理を半泣きで行って格闘していたことを思い出しました。
しかし、今は違います。原因(というか状況)がハッキリした以上、最短経路は明確です。
『ソフトウェアピクセルマッピング法』でHPC機能を正確無比にシミュレートして『手持ちのカメラを2020年の性能に復元』するのです!
★RAW画像を観察するだけで駆逐対象座標を特定する
まずは、2020年に生きていた頃のHPC機能が『駆除対象』として記憶していた異常ピクセルの座標を求めることから開始しましょう。もちろん、本来は出荷前検査でカメラ内部にマル秘データとして記録されている情報でしょうから、普通に見ることはできませんし、当然のことながら秘密情報にアクセスしたりファームのリバースエンジニアリングなどはアウトです。そこで、「当時撮影したRAW画像を観察するだけで、時系列解析と補正パターンマッチングにより補正対象ピクセル座標を推定」する邪悪な自作プログラム『邪・我流道(ザ・ワールド)』の出番です。
過去ASI294のレビュー記事にも書きましたが、(自分がプログラムするなら、こうするという視点で)下記のような補正パターンを想定し、カメラ本体が補正込みで出力したRAW画像と総当たりでマッチングさせることで、補正パターンとその演算式を推定します。

前回記事でも書いたように、2020年5月に撮影したRAW画像を調べた結果、
下記のような補正であることが観察されました。

ここでは、駆除された異常ピクセル数が5328個であったことのみ示していますが、当然『邪・我流道』は、
異常ピクセルの座標も出力させることが可能です。

この座標はカメラ個体が同一である限り基本的には不変で、ライトフレームであろうがダークフレームであろうがフラットフレームであろうが同一の除去処理が行われている気配は検証ごっこ済みです。
あとは、この座標と演算式を自作画像処理プログラム『邪崇帝主(ジャスティス)』にロードして、最近のドライバがサボっているお仕事を代行すればいいのです。
★HPC無し画像を有り画像に変身させる
さて、このように任意画像に対して旧ドライバがやっていたお仕事を後から施すことができるようになりました。
では、昨日最新ドライバ+SharpCapで撮影した画像が『邪・我流道』+『邪崇帝主』の合わせ技でどうなったのか確かめてみましょう。
すると・・・
ででん!!
※左から順に、2020年頃のネイティブドライバ・現在使用しているネイティブドライバ・現在のネイティブドライバ+邪崇帝主
おお、僕の大切なASI294MM-Proくんが全盛期の強さを取り戻したぞ!!
なお、上図中にコメントしたように、厳密には昨日撮影した画像を2020年当時の品質まで完全復元することはできませんでした。ほんのチョッピリではありますが、製品出荷時には正常ピクセルだった(当然駆除対象外)物のうち一部が不良ピクセルに変質したようです。ひょっとすると、これが噂の『経年劣化』なのかもしれません。
でも大丈夫。次はその『不良化』したピクセルの座標を測定して、それもピクセルマッピング処理対象リストに加えれば良いだけです。
★過去の実写画像を救済できるか?
さて、楽しい趣味である星雲撮影遊びですから、解析データを眺めていても嬉しくありません。ここはやはり、過去(ドライバの更新でHPCが無効化されたせいで?)撃沈した星雲画像をサクッと救済できているべきでしょう。
①素の画像だと・・・
テスト処理対象に選んだのは下記の画像です。

これは、
10cmF5アクロマートStarQuest102SSに自作レデューサとASI294MM-Coolを装着し、-10℃・ゲイン300・32秒露光した256コマのライトフレームをコンポジットしたHα画像です。ダーク処理やフラット処理は施していません。撮影時のディザリングやコンポジット時のσクリップやホットクール除去フィルタ処理は一切使用していません。一見良く写っているように見えますが、拡大してみると下記のように
ホットピクセルが鏡筒の撓みなどの追尾エラーで流れて写ったいわゆる『白い縮緬ノイズ』(正式にはウォーキングノイズ)が盛大に出ています。

※黄丸で記した部分がホットピクセルによるノイズ。同様のノイズが画像内に多数見られる。
特に高輝度のホットピクセルによるノイズは、旧ドライバで運用していた時には生じていなかった現象です。(かつてのASI294MM-Proは超高性能で、アンプグローを気にしないならダーク無しでも鑑賞に堪える絵を吐いていました。)
②ダーク処理すると・・・
次に、同じライトフレームに対して、同温度・同ゲイン・同露光時間で撮像したダークフレーム256コマを用いてダーク処理をしてみましょう。旧ドライバでの運用では、冷却しても僅かに残ったホットピクセルがきれいに消えたはずです。

アンプグローも消えて、一見成功したように見えますが、拡大してみると下記のように
ホットピクセルが過補正となって生じた『にせクールピクセル』によって、いわゆる『黒い縮緬ノイズ』が盛大に出ています。

実は、
そもそも高輝度のホットピクセルは下記の3点の理由によりダーク減算が『効かない』強敵なのです。
・天体の光は「明るさがN倍になればショットノイズが√N倍に悪化」するが、「天体のシグナルはN倍に増えているので、ノイズは差し引き1/√N倍に減って見える」(正確にはS/N比が√N倍に向上する)ので問題ない。
・ホットピクセルも「明るさがN倍になればショットノイズが√N倍に悪化」するが「ダーク減算によりシグナルはゼロに引かれるため、ノイズはストレートに√N倍に悪化する」(明るさを補正しても、揺らぎとしてのノイズは消せない)
・あまりにも高輝度のホットピクセルは、それに重なった天体の光をトコロテン式に押し流してしまうため、補正しようが無い(一度おし流された情報は戻らない)。
そのため、ZWOのHPC機能やPlayerOneのDPS機能では「ダーク処理では補正不能な悪質なホットピクセルは、最初から無効化しておく」という重要な役割を持っていると考えていました。ところが、ASI294MM-Proはこの機能が無効化されたように見受けられるため、ダーク減算が不能となるピクセルが多発したという訳です。
③疑似HPCで処理すると・・・
今回『邪崇帝主』に改訂実装したソフトウェアピクセルマッピング機能は、いわば「正常動作していた時の演算を模倣し、異常画像を正常な画像に復元する」もので『疑似HPC機能』と言えるようなものです。したがって、2020年の頃のASI294MM-Proと同等の「ダーク減算が非常に良く効く」画像が得られるハズです。
では、早速実験してみましょう。
①②と同じライトフレームを用いてまずは普通にダーク減算を施し、その後『疑似HPC』を実行します。厳密には、ライトフレームとダークフレームの双方に『疑似HPC』を演算させた後でダーク減算を行うべき所ですが、数学的には「コンポジットさえしていなければ」ダーク減算後だろうがフラット除算後だろうが、極端に言えばデジタル現像やトーンカーブ修正などいかなる画像処理を施した後から演算させても同じ値が出ます。

これでは、違いが分かりませんので、
①②の画像と合わせて強拡大比較してみましょう。
すると・・・
ででん!!
うひゃー!
大成功♪♪
★真面目に再処理してみる
今回の検証ごっこ+実験により、ASI294MM-Proで撮影した過去画像は(怪しい処理でこねくり回さずとも)「もっと美しくなる」可能性が高くなりました。
一例として、先ほど実験台にしたバラ星雲を再処理して仕上げてみましょう。
すると、数分ほどの手抜き画像処理でもこんな感じに仕上がりました♪
ふはははは
ASI294MM-Proめ、こやつ見事に2020年当時の高性能機に戻りおったわ!!
★★★お約束★★★
①あぷらなーとは専門家ではないため、作業にミスや勘違いが含まれている可能性があります。
②メーカーさんからの情報ではないため、今回の考察ごっこはあくまでも推理遊びです。信用性はありません。
③異常ピクセルはあらかじめ駆除しておくべきかどうかは、あくまでもユーザーさんの好みや流儀次第です。
④HPCの仕様は公開されていませんので、ここで示したロジックは、あぷらなーと独自の妄想です。
⑤噂の「経年劣化」に関しては、さらなる検証ごっこが必要です。
htmx.process($el));"
hx-trigger="click"
hx-target="#hx-like-count-post-37328728"
hx-vals='{"url":"https:\/\/apranat.exblog.jp\/37328728\/","__csrf_value":"2a2c6f2ce1cce09178fd959cc406fa04d08e29546c2bff434f0feeb34b462f5eaf2e60047d68c5f62a33e05fb78341bcd6612fcfd8ce73f014e429696d7b2642"}'
role="button"
class="xbg-like-btn-icon">