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 大多数的脾气你都对付得了。