Khắc phục sự cố WBPP: các lỗi thường gặp và những bug đã biết

Bài viết này được tổng hợp từ những ghi chú trong giai đoạn 2022–2025; một số công cụ hoặc quy trình đã có cập nhật, bạn hãy lưu ý khi đọc. Các thông báo lỗi và hành vi theo từng phiên bản nêu trong bài đều được ghi lại đúng như lúc đó. Về giao diện của WBPP, các master hiệu chỉnh và quy trình chạy bình thường, bạn hãy xem bài viết cùng bộ “The Complete Guide to WBPP”.

Chạy một mạch WBPP chỉ với một cú nhấp thì đúng là sướng tay, nhưng khi thực sự bắt tay vào dùng, kiểu gì cũng gặp cảnh nó đứng máy, báo lỗi, hoặc cho ra kết quả trông không ổn. Bài này gom mấy nhóm vấn đề của WBPP mà tôi từng gặp trong những năm qua — cũng là những vấn đề tôi bị hỏi nhiều nhất — thành một cuốn cẩm nang khắc phục sự cố, từ tư duy chẩn đoán cho tới vài bug đã biết rất cụ thể.

Bước đầu tiên khi gỡ lỗi: xem Process Console trước

Khi việc xử lý trong PixInsight gặp trục trặc, điều đầu tiên bạn nên nghĩ tới luôn luôn là xem Process Console. Nó cho biết lỗi xảy ra ở đâu và thuộc loại nào, đó là điểm khởi đầu của mọi chẩn đoán.

Có điều WBPP là một script, và khi script chưa chạy thì console bị thu lại và không thể chọn được. Vậy nên muốn xem console thì thường phải đóng WBPP trước đã. Nghe thì phiền, nhưng với nhiều vấn đề thì đó lại là nguồn manh mối duy nhất — cách gỡ mấy con bug ở phần sau đều bắt đầu từ đúng dòng chữ đỏ đó trong console.

Những thất bại và bug ở giai đoạn hiệu chỉnh

Hiệu chỉnh thất bại (failed) — hãy đóng PI rồi mở lại trước đã. Nếu khi chạy WBPP mà bước hiệu chỉnh đầu tiên (dùng master hiệu chỉnh) đã thất bại ngay, status hiện chữ failed màu đỏ, bạn có thể tạm dừng toàn bộ quy trình, đóng PI rồi mở lại WBPP và chạy thêm một lần nữa; lỗi hiệu chỉnh thất bại này thường sẽ biến mất. Khi xử lý ảnh OSC, tôi đã gặp bug này ít nhất bốn lần, và lần nào cũng giải quyết được bằng đúng chiêu đó.

Màn hình status hiện chữ failed màu đỏ ở giai đoạn hiệu chỉnh của WBPP

Frame flat cứ liên tục lỗi hiệu chỉnh — quay lại xử lý thủ công từng bước. Một số phiên bản WBPP có bug khiến việc hiệu chỉnh frame flat liên tục báo lỗi. Những lúc như vậy, biết tự tay xử lý từng bước một trở nên rất quan trọng. Nhân tiện, chúng ta ôn lại các bước của Pre-Process:

Calibration: light − dark / ((flat − flat dark) * med(flat))
Cosmetic Correction
Debayer: nội suy trên ma trận Bayer
Star Alignment
NSG
Integration

Lỗi hiệu chỉnh frame flat trong WBPP, cùng phần tham khảo các bước xử lý thủ công

Khi không thể tin vào tự động hóa, việc tách quy trình ra để chạy tay lại giúp khoanh vùng vấn đề nằm ở bước nào dễ hơn.

Vấn đề đường dẫn: hai khả năng gây ra File I/O Error

Khi dùng WBPP trên Windows, nếu giai đoạn hiệu chỉnh (calibration) báo File I/O Error thì thường là do một trong hai nguyên nhân sau:

Đường dẫn cộng với tên tệp quá dài, vượt giới hạn của hệ thống nên cần rút ngắn lại.
Không ghi được vào thư mục đích, ví dụ khi bạn đặt đầu ra vào một thư mục hệ thống.

Màn hình lỗi File I/O Error xuất hiện ở giai đoạn hiệu chỉnh của WBPP

Nguyên nhân thứ nhất là phổ biến nhất. Muốn trị tận gốc chuyện “đường dẫn quá dài”, bạn có thể bật hỗ trợ đường dẫn dài trong Windows (dùng regedit đặt LongPathsEnabled thành 1); ngoài ra cũng nên tránh những đường dẫn chứa ký tự ngoài ASCII (ví dụ chữ Trung). Thao tác chi tiết của hai bước chuẩn bị môi trường này tôi đã viết trong mục thiết lập môi trường Windows của bài “The Complete Guide to WBPP”, ở đây không nhắc lại nữa.

Bug tọa độ RA/DEC “60 giây không được nhớ lên hàng trên”

Đây là vấn đề hóc búa nhất, và cũng là vấn đề đáng tách riêng ra bàn nhất, bởi triệu chứng của nó muôn hình vạn trạng mà nguyên nhân gốc thì chỉ có một: trong FITS Header, tọa độ xích kinh / xích vĩ có phần giây hiện ra “60” nhưng lại không được nhớ lên hàng trên.

Tôi từng gặp hai lần, ở hai phiên bản khác nhau và với biểu hiện khác nhau.

Lần thứ nhất: WBPP không nạp được tệp. Đóng WBPP rồi xem Process Console, tôi thấy một dòng nào đó trong một script js báo “tọa độ không hợp lệ”. Lúc ấy tôi cứ tưởng là bug của WBPP, đem thông báo lỗi lên mạng tìm, rồi mới thấy trên PixInsight Forum vài bài báo lỗi y hệt — hóa ra chính vấn đề tọa độ khiến ảnh không nạp được vào WBPP. Có hướng rồi, tôi vẫn phải mất một tiếng lục trong mấy trăm frame light mới lôi ra được tấm ảnh có vấn đề: tọa độ OBJCTDEC của nó bị sai. Mở process FITSHeader trong PI, kéo xuống tới OBJCTDEC, sửa lại con số “đáng lẽ phải nhớ lên hàng trên mà lại không nhớ” — ví dụ ở đây là đổi -69 26 60 thành -69 27 0 — thế là tấm này nạp được trơn tru, và các tệp phía sau cũng không còn bị nó chặn lại nữa.

Dùng process FITSHeader sửa tọa độ OBJCTDEC chưa được nhớ lên hàng trên

Lần thứ hai: tệp không thêm vào được, console báo too much recursion. Về sau tôi lại gặp một lần nữa: khi thêm tệp vào WBPP thì phần mềm treo cứng, kết quả là chẳng tệp nào được thêm vào cả. Đóng WBPP rồi xem Console thì thấy dòng đỏ InternalError: too much recursion. Mở lại WBPP mới thấy một phần tệp đã nạp, một phần thì chưa; kiểm tra những tệp chưa nạp, quả nhiên lại là FITS Header bất thường — lần này DEC hiện -46 01 60, phần giây “60” lẽ ra phải nhớ lên thành -46 02 00. Chỉ cần WBPP đọc phải một giá trị bất thường kiểu này là treo, còn kéo theo cả những ảnh phía sau cũng không nạp được. Vẫn là mở FITS Header rồi tự tay nhớ phần giây lên hàng trên, sửa xong thì thêm lại tệp là được. Khi mọi tệp đều nạp thành công, WBPP sẽ tự động hiện thông báo chẩn đoán, ví dụ “60 of 60 light frames were added”.

Thông báo lỗi InternalError: too much recursion xuất hiện trong console

Trường DEC trong FITS Header hiện giá trị bất thường -46 01 60

Kết luận chung: vấn đề tọa độ không tự nhớ lên hàng trên này, cho tới nay tôi thấy hầu như đều xảy ra khi phần mềm chụp là MDL (điều khiển từ xa), nhưng không thể loại trừ khả năng các phần mềm chụp khác cũng mắc chứng tương tự. Vậy nên, hễ WBPP bị treo, tệp không thêm vào được thì hãy xem Process Console trước để xác định loại lỗi, rồi kiểm tra Header của RA/DEC xem có dính bug “60 giây không được nhớ lên hàng trên” hay không; sửa tay xong thì phần lớn trường hợp là giải quyết được.

Hiệu năng: vì sao gói đầy đủ chạy lâu đến thế

Cuối cùng là một vấn đề mà nói cho chặt chẽ thì không phải “lỗi”, nhưng lại hành người ta ghê gớm — gói đầy đủ của WBPP thực sự quá chậm. Tôi từng vì năm tấm ảnh cần làm HDR mà để gói đầy đủ chạy tròn bốn tiếng (máy khi đó là AMD R5-4650G, DDR4 3200 32GB, SSD Gen4, ảnh 24 triệu điểm ảnh; kiểu chờ đợi này thật sự khiến người ta muốn đổi máy tính).

Màn hình chạy gói đầy đủ của WBPP mất bốn tiếng

Trong đó có hai chỗ đặc biệt ngốn thời gian:

Separated RGB: xử lý riêng từng kênh RGB của ảnh màu để khử quang sai màu.
Local Normalization: chọn vài tấm tốt nhất trong loạt ảnh làm ảnh tham chiếu, rồi chạy Local Normalization cho những ảnh còn lại.

Nếu tắt hai mục này, WBPP sẽ nhanh hơn rất nhiều. Có nên hy sinh chúng để đổi lấy tốc độ hay không thì tùy vào yêu cầu của bạn với thành phẩm — về phần đo thực tế cho câu hỏi “tắt những bước nào, tiết kiệm được bao nhiêu thời gian, mất bao nhiêu chất lượng”, trong bài “The Complete Guide to WBPP” tôi có một bộ số liệu cho thấy mức tăng tốc 7–8 lần để bạn tham khảo.

Tóm lại tinh thần của cuốn cẩm nang gỡ lỗi này: có chuyện gì thì xem Process Console trước; hiệu chỉnh báo failed thì đóng PI rồi mở lại; frame flat cứ lỗi hiệu chỉnh mãi thì quay về xử lý thủ công từng bước; File I/O Error phần lớn là do đường dẫn quá dài hoặc thư mục không ghi được; không nạp được, bị treo, báo recursion thì đi kiểm tra RA/DEC trong FITS Header xem có chỗ nào 60 giây chưa được nhớ lên hàng trên. Thuộc kỹ mấy chiêu này thì phần lớn tính khí thất thường của WBPP bạn đều đối phó được.