本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文This site is available in English.View in English이 사이트는 한국어로도 제공됩니다.한국어로 보기Diese Website ist auch auf Deutsch verfügbar.Auf Deutsch ansehenEste sitio web también está disponible en español.Ver en españolQuesto sito è disponibile anche in italiano.Visualizza in italianoCe site est également disponible en français.Afficher en françaisEste site também está disponível em português.Ver em portuguêsDeze website is ook beschikbaar in het Nederlands.In het Nederlands bekijkenЭтот сайт также доступен на русском языке.Смотреть на русскомयह वेबसाइट हिन्दी में भी उपलब्ध है।हिन्दी में देखेंهذا الموقع متاح أيضًا باللغة العربية.عرض بالعربيةSitus ini juga tersedia dalam bahasa Indonesia.Lihat dalam bahasa IndonesiaBu site Türkçe olarak da mevcut.Türkçe görüntüleTa strona jest dostępna także po polsku.Wyświetl po polskuTrang web này cũng có phiên bản tiếng Việt.Xem bằng tiếng Việtاین وب‌سایت به فارسی هم در دسترس است.مشاهده به فارسی

WBPP トラブルシューティング:よくあるエラーと既知のバグ

前処理とスタッキング2022.04初期のノート

本記事は 2022〜2025 年のノートをまとめたもので、一部のツールやワークフローはすでに更新されています。読む際にはその点にご留意ください。文中のエラーメッセージやバージョン固有の挙動は、いずれも当時記録したままのものです。WBPP のインターフェイス、マスターキャリブレーションフレーム、通常の実行フローについては、姉妹篇の「WBPP 完全ガイド」をご参照ください。

WBPP をワンクリックで最後まで走らせるのはたしかに気持ちいいのですが、実際に使ってみると、途中で止まったり、エラーを吐いたり、結果がどうもおかしかったりする場面に必ず出くわします。本記事では、この数年で私が遭遇し、そして最もよく質問されてきた WBPP のトラブルを、いくつかのカテゴリに分けてトラブルシューティングのハンドブックとしてまとめました。診断の心構えから、いくつかの具体的な既知のバグまでを取り上げます。

トラブルシューティングの第一歩:まず Process Console を見る

PixInsight の処理で問題が起きたとき、真っ先に思い出すべきなのは、いつだって Process Console を確認することです。エラーがどこで、どんな種類で発生したのかを教えてくれる、すべての診断の出発点です。

とはいえ WBPP はスクリプトなので、スクリプトが実行されていない状態では console は畳まれてしまい、選択もできません。ですから console を見たいときは、たいていまず WBPP を閉じる必要があります。面倒に聞こえますが、これが多くの問題にとって唯一の手がかりの源なのです——このあと紹介するいくつかのバグの解決も、すべては console のあの一行の赤い文字から始まりました。

キャリブレーション段階の失敗とバグ

キャリブレーションが失敗(failed)——まず PI を閉じて開き直す。 WBPP を実行して、最初のキャリブレーション(マスターキャリブレーションフレームを使う段階)でいきなり失敗し、status が赤い failed を表示したら、まず全体のフローを一時停止し、PI を閉じてから WBPP を開き直してもう一度実行してみてください。このキャリブレーション失敗のエラーは、たいていそれで消えます。OSC 画像を処理していたとき、私はこのバグに少なくとも四回以上遭遇しましたが、毎回この手で解決してきました。

WBPP のキャリブレーション段階で status が赤い failed を表示している画面

フラットのキャリブレーションがずっとエラーになる——手動の分割処理に戻す。 一部のバージョンの WBPP にはバグがあり、フラットのキャリブレーションが延々とエラーになることがあります。こういうときは、自分で一歩ずつ手動で処理できることが大切になります。ついでに Pre-Process の手順をおさらいしておきましょう:

  1. Calibrationlight − dark / ((flat − flat dark) * med(flat))
  2. Cosmetic Correction
  3. Debayer:ベイヤー配列を内挿する
  4. Star Alignment
  5. NSG
  6. Integration

WBPP のフラットキャリブレーションエラーと、手動の分割処理手順の参考

自動化が当てにならないときは、フローをばらして手動で走らせるほうが、かえって問題がどのステップにあるのかを突き止めやすくなります。

パスの問題:File I/O Error の二つの可能性

Windows で WBPP を使っていて、キャリブレーション段階(calibration)で File I/O Error が出たときは、たいてい次の二つの原因のどちらかです:

  1. ファイルパス+ファイル名が長すぎてシステムの上限を超えているため、短くする必要がある。
  2. 出力先フォルダに書き込めない、たとえば出力先をシステムフォルダに設定してしまっている。

WBPP のキャリブレーション段階で File I/O Error が出ているエラー画面

一つ目が最もよくあるケースです。「パスが長すぎる」を根本から治すには、Windows で長いパスのサポートを有効にする(regedit で LongPathsEnabled を 1 に設定する)とよいでしょう。あわせて、日本語や中国語など非 ASCII 文字を含むパスを避けることもお勧めします。この二つの環境の下準備の詳しい操作は、「WBPP 完全ガイド」の Windows 環境設定の節に書いてあるので、ここでは繰り返しません。

RA/DEC 座標の「60 秒が繰り上がっていない」バグ

これは最も厄介で、なおかつ単独で取り上げる価値のある問題です。症状は千差万別なのに、根本原因は同じ——FITS Header の中の赤経/赤緯の座標で、秒の値が「60」になっているのに繰り上がっていないからです。

私はこれに二度、それぞれ違う形で遭遇しました。

一度目:WBPP がファイルを読み込めない。 WBPP を閉じて Process Console を見ると、ある js スクリプトの一行が「無効な座標」を報告していました。当時は WBPP のバグだと思い込み、エラーメッセージをネットで検索してみて、ようやく PixInsight Forum で同じエラー報告をいくつか見つけました——座標の問題が原因で画像が WBPP に読み込めなくなっていたのです。方向性はつかめたものの、それでも数百枚のライトフレームの中から問題の画像を突き止めるのに一時間かかりました。その画像の OBJCTDEC 座標が間違っていたのです。PI で FITSHeader プロセスを開き、OBJCTDEC までスクロールして、「繰り上がるべきなのに繰り上がっていない」数値を書き換えました——この例では -69 26 60-69 27 0 に変更しました——すると、この一枚は問題なく読み込まれ、その後のファイルもこれに足を引っ張られることはなくなりました。

FITSHeader プロセスで繰り上がっていない OBJCTDEC 座標を修正する

二度目:ファイルが追加できず、console が too much recursion を報告。 その後もう一度、WBPP にファイルを追加しようとしたときにソフトが固まり、結局まったくファイルが追加されない、ということがありました。WBPP を閉じて Console を見ると、赤い InternalError: too much recursion でした。WBPP を開き直すと、一部のファイルはすでに読み込まれていて、一部は読み込まれていない。読み込まれなかったものを調べると、案の定またしても FITS Header の異常——今回は DEC-46 01 60 と表示されており、秒の「60」は -46 02 00 に繰り上がるべきものでした。WBPP はこの種の異常な値を読み込んだ瞬間に固まり、しかも後続の画像まで巻き込んで読み込めなくしてしまいます。同じように FITS Header を開いて秒を手動で繰り上げ、直してからファイルを追加し直せば大丈夫でした。すべてのファイルが正常に読み込まれると、WBPP は自動で診断メッセージを出します。たとえば「60 of 60 light frames were added」といった具合です。

console に InternalError: too much recursion のエラーメッセージが出ている

FITS Header の DEC フィールドに異常値 -46 01 60 が表示されている

**共通の結論:**この、座標が自動で繰り上がらない問題は、私がこれまで見てきたかぎり、ほぼすべて MDL(リモート制御)を撮影ソフトに使っている状況で発生しています。ただし、ほかの撮影ソフトでも同じ不具合が起こる可能性は否定できません。ですから、WBPP が固まってファイルが追加できないときは、まず Process Console でエラーの種類を確認し、次に RA/DEC の Header に「60 秒が繰り上がっていない」バグがないかをチェックする。手動で修正すれば、たいていは解決します。

パフォーマンス:フルパッケージはなぜこんなに時間がかかるのか

最後に、厳密にいえば「エラー」ではないものの、なかなかに人を苦しめる問題について——WBPP のフルパッケージは、とにかく遅すぎるのです。私はかつて、HDR にしたい五枚の画像のためにフルパッケージをまるまる四時間走らせたことがあります(当時のマシンは AMD R5-4650G、DDR4 3200 32GB、Gen4 SSD、画像は 2400 万画素。この手の待ち時間は、本当にパソコンを買い替えたくなります)。

WBPP のフルパッケージが四時間かかっている実行画面

なかでも特に時間を食うのが次の二つです:

  1. Separated RGB:カラー写真の RGB チャンネルを分けて処理し、色ズレ(色収差)を取り除く。
  2. Local Normalization:画像の中でいちばん良い数枚を参照として選び、ほかの画像に Local Normalization をかける。

この二つをオフにすれば、WBPP は格段に速くなります。速度のためにこの二つを犠牲にするかどうかは、あなたが仕上がりにどこまで求めるか次第です——「どのステップをオフにすると、どれだけ時間を節約でき、品質はどれだけ落ちるか」の実測については、「WBPP 完全ガイド」に 7〜8 倍の高速化を示す一組のデータを載せてあるので、そちらを参照してください。


このトラブルシューティング・ハンドブックの心構えをまとめておきます:何かあったら、まず Process Console を見る。キャリブレーションが failed なら PI を閉じて開き直す。フラットのキャリブレーションがいつまでもエラーになるなら手動の分割処理に戻す。File I/O Error はたいていパスが長すぎるかフォルダに書き込めないかのどちらか。読み込めない・固まる・recursion を報告する、というときは FITS Header の RA/DEC に 60 秒が繰り上がっていないところがないか確認する。この数手を覚えておけば、WBPP のたいていの気難しさには対処できます。