WBPP 트러블슈팅: 자주 나타나는 오류와 알려진 버그

이 글은 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에는 버그가 있어, 플랫 캘리브레이션이 계속 오류가 나게 됩니다. 이럴 때는 스스로 한 단계 한 단계 수동으로 처리할 줄 아는 것이 중요해집니다. 겸사겸사 Pre-Process 단계를 복습해 두겠습니다:

1. Calibration: light − dark / ((flat − flat dark) * med(flat))
2. Cosmetic Correction
3. Debayer: 베이어 배열에 보간을 수행
4. Star Alignment
5. NSG
6. Integration

자동화를 믿을 수 없을 때는 흐름을 분해하여 수동으로 돌리는 편이, 오히려 문제가 어느 단계에 있는지를 짚어내기가 더 쉽습니다.

경로 문제: File I/O Error의 두 가지 가능성

Windows에서 WBPP를 사용하다가 캘리브레이션 단계(calibration)에서 File I/O Error가 뜨면, 대개 다음 두 가지 원인 중 하나입니다:

1. 파일 경로에 파일명을 더한 길이가 너무 길어서 시스템 제한을 넘어, 줄여야 하는 경우.
2. 대상 폴더에 쓸 수 없는 경우, 예를 들어 출력 위치를 시스템 폴더로 설정한 경우.

첫 번째가 가장 흔한 경우입니다. 「경로가 너무 긴」 문제를 근본적으로 고치려면, Windows에서 긴 경로 지원을 활성화하면(regedit에서 LongPathsEnabled를 1로 설정) 됩니다. 아울러 한국어나 중국어 등 비 ASCII 문자를 포함하는 경로를 피하는 것도 권합니다. 이 두 가지 환경 사전 설정의 자세한 조작은 〈WBPP 사용 완전 해설〉의 Windows 환경 설정 절에 써 두었으니, 여기서는 반복하지 않겠습니다.

RA/DEC 좌표 「60초가 자리 올림되지 않은」 버그

이것은 가장 까다롭고, 또 단독으로 끄집어내어 다룰 가치가 있는 문제입니다. 증상은 천차만별인데 근본 원인은 하나이기 때문입니다—FITS Header 안의 적경/적위 좌표에서, 초 값이 「60」이 되었는데도 자리 올림이 되지 않은 것입니다.

저는 서로 다른 형태로 두 번 겪었습니다.

첫 번째: WBPP가 파일을 로드하지 못함. WBPP를 닫고 Process Console을 보니, 어떤 js 스크립트의 한 줄이 「무효한 좌표(invalid coordinates)」를 보고하고 있었습니다. 당시에는 WBPP의 버그라고 여겨, 오류 메시지를 인터넷에서 검색해 보고 나서야 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초가 자리 올림되지 않은」 버그가 없는지 확인하십시오. 수동으로 수정하면 대개 해결됩니다.

성능: 풀 패키지는 왜 이렇게 오래 걸리는가

마지막으로, 엄밀히 말하면 「오류」는 아니지만 꽤나 사람을 괴롭히는 문제에 대해—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의 웬만한 까다로운 성깔은 다 상대할 수 있습니다.