WBPP 疑難排解：常見錯誤與已知 Bug

本文整理自 2022–2025 年的筆記，部分工具或流程已有更新，閱讀時請留意；文中的錯誤訊息與版本行為皆為當時記錄。WBPP 的介面、主校正場與正常執行流程，請參閱另一篇〈WBPP 使用全解〉。

WBPP 一鍵到底固然爽快，但真正在用的時候，總會遇到卡住、報錯、或結果不對勁的狀況。這篇把我這幾年碰過、也最常被問到的幾類 WBPP 問題整理成一份排錯手冊，從診斷心法談到幾個具體的已知 Bug。

排錯第一步：先看 Process Console

PixInsight 處理出問題時，第一個該想到的永遠是查看 Process Console。它會告訴你錯誤發生在哪、是什麼類型的錯誤，是所有診斷的起點。

不過 WBPP 是腳本，在腳本未執行的狀態下，console 會被收起且無法選取。所以想看 console，往往得先關閉 WBPP。這聽起來麻煩，卻是很多問題唯一的線索來源——後面幾個 Bug 的破解，全都是從 console 的那行紅字開始的。

校正階段的失敗與 Bug

校正失敗（failed）——先關掉 PI 再重開。 如果執行 WBPP 時，一開始的校正（使用主校正場）就失敗，status 顯示紅色的 failed，可以先暫停整個流程，關閉 PI 後重新打開 WBPP 再執行一次，這個校正失敗的錯誤通常就會消失。我在處理 OSC 影像時，這個 Bug 至少遇過四次以上，每次都是用這招解決的。

平場一直校正錯誤——改回手動分程序。 某些版本的 WBPP 有 Bug，會一直導致平場校正錯誤。這種時候，懂得自己手動一步一步處理就很重要。順便複習一下 Pre-Process 的步驟：

1. Calibration：light − dark / ((flat − flat dark) * med(flat))
2. Cosmetic Correction
3. Debayer：對 Bayer 矩陣做內插
4. Star Alignment
5. NSG
6. Integration

當自動化靠不住時，把流程拆開手動跑，反而更能定位問題出在哪一步。

路徑問題：File I/O Error 的兩種可能

在 Windows 下用 WBPP，如果校正階段（calibration）跳出 File I/O Error，通常是這兩種原因之一：

1. 檔案路徑加檔名太長，超過系統限制需要縮短。
2. 目標資料夾無法寫入，例如把輸出設在系統資料夾。

第一種是最常見的。要根治「路徑太長」，可以在 Windows 開啟長路徑支援（regedit 把 LongPathsEnabled 設為 1）；另外也建議避免使用中文路徑。這兩項環境前置設定的詳細操作，我寫在〈WBPP 使用全解〉的 Windows 環境設定一節，這裡就不重複了。

RA/DEC 座標「60 秒未進位」Bug

這是最刁鑽、也最值得單獨拉出來講的一個問題，因為它的症狀千奇百怪，但根因是同一個：FITS Header 裡的赤經／赤緯座標，秒數出現了「60」卻沒有進位。

我遇過兩次不同版本的表現。

第一次：WBPP 無法載入檔案。 關閉 WBPP 去看 Process Console，發現某個 js 腳本某一行報「無效座標」。當下以為是 WBPP 的 Bug，把錯誤訊息拿去網路上搜，才在 PixInsight Forum 找到幾則一樣的報錯——原來是座標問題導致影像無法載入 WBPP。有了方向，我還是在數百張亮場裡花了一個小時，才揪出那張有問題的影像：它的 OBJCTDEC 座標不對。在 PI 裡打開 FITSHeader 程序，滑到 OBJCTDEC，把「本該進位卻沒進位」的數值改掉——例子是把 -69 26 60 改成 -69 27 0——這張就順利載入了，後面的檔案也不再被它卡住。

第二次：檔案加不進去，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」。

**共同結論：**這個座標沒有自動進位的問題，我目前看到幾乎都發生在以 MDL（遠端控制）為拍攝軟體的狀況下，但不能排除其他拍攝軟體也可能有同樣的毛病。所以，只要遇到 WBPP 卡住、檔案無法加入，先去查 Process Console 確認錯誤類型，再檢查 RA/DEC 的 Header 有沒有「60 秒未進位」的 Bug，手動修正後多半就能解決。

效能：大全套為什麼跑這麼久

最後談個嚴格說不算「錯誤」、但很折磨人的問題——WBPP 大全套實在太慢。我曾為了五張要做 HDR 的影像，讓大全套跑了整整四個小時（當時的機器是 AMD R5-4650G、DDR4 3200 32GB、Gen4 SSD，影像 2400 萬畫素，這種等待真的會讓人想換電腦）。

其中特別吃時間的有兩處：

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 大多數的脾氣你都對付得了。