WBPP 완전 가이드: 인터페이스, 마스터 캘리브레이션 프레임, 그리고 실행 파이프라인
이 글은 2021–2024년의 메모를 정리한 것입니다. 일부 도구나 워크플로는 그 사이에 업데이트되었으므로, 읽으실 때 유의해 주시기 바랍니다. 본문에서 언급하는 일부 인터페이스, 옵션, 버전별 동작(예를 들어 2.1.2, 2.5 버전)은 모두 당시의 상태입니다. 실행 중에 마주치는 오류와 알려진 버그에 관해서는 별도의 글 〈WBPP 문제 해결〉을 참고하시기 바랍니다.
WBPP(WeightedBatchPreprocessing)는 PixInsight에서 「캘리브레이션, 정합, 인테그레이션」을 한 번에 끝까지 자동으로 처리해 주는 스크립트로, 놀라울 만큼 편리합니다. 최근 몇 년간 개정이 잦아, 저도 여기저기 단편적인 메모를 써 왔습니다. 이 글에서는 그것들을 정리해 비교적 완결된 하나의 설명으로 엮어, 세 가지 층위로 나누어 이야기합니다. 버전이 바뀌어도 크게 변하지 않는 핵심 개념, 현행 실행 흐름, 그리고 역대 버전의 몇 가지 중요한 변화입니다. 어떤 버전을 쓰고 있든, 먼저 개념을 확실히 잡아 두면 인터페이스가 어떻게 바뀌어도 당황하지 않게 됩니다.
핵심 개념 1: WBPP가 인테그레이션한 결과물은 프리뷰일 뿐이다
이것은 제가 가장 먼저 말씀드리고 싶은 점이자, 동시에 가장 많은 분이 놓치는 점이기도 합니다.
저 자신도 함정에 빠진 적이 있습니다. 언젠가 Drizzle Integration을 사용한 뒤, 별의 중심(과포화된 부분)이 새까맣게 변해 있는 것을 발견했습니다. 원인을 추적해 보니, 주범은 다름 아닌 WBPP로 인테그레이션을 한 것이었습니다.
WBPP가 편리한 것은 편리하지만, 그것이 자동으로 인테그레이션해 출력하는 마스터 라이트에 대한 공식의 입장은 매우 분명합니다—그것은 「달성 가능한 결과」를 손쉽게 확인하기 위한 프리뷰일 뿐이며, 다 쓰고 나면 버려야 하는 것으로, 정식 결과물로 삼아서는 안 됩니다. 공식이 포럼에 남긴 답변을 아래에 발췌합니다.
The integrated image generated by WBPP is just a convenience preview of the achievable image, but it should always be deleted/ignored, and the integration should always be done manually with the registered frames. This is the only way to obtain an optimal integrated image with full control over the normalization, pixel rejection and noise reduction tasks.
공식은 심지어 반쯤 농담 삼아, 이 말을 「n+1번, 여기서 n은 이미 무한대에 가깝다」라고 할 만큼 반복하고 싶다고까지 말합니다. 즉, WBPP가 생성하는 마스터 라이트는 정식 용도로 써서는 안 되며, 어디까지나 프리뷰일 뿐이고, 최상의 결과는 수동 Image Integration으로 픽셀 리젝션과 S/N 비를 최적화해야 비로소 얻을 수 있다는 것입니다.
그래서 저의 습관은 이렇습니다. WBPP는 「스타 레지스트레이션(정합)」 단계까지만 쓰고, 진짜 인테그레이션은 Image Integration의 수동 처리로 되돌립니다. 정공법인 프로세스 분할—캘리브레이션(WBPP에 맡김), 정합(Star Alignment), 인테그레이션(Image Integration)—은 단계가 몇 개 늘어나기는 하지만, 일단 문제가 생겼을 때 어느 공정이 망가졌는지 밝혀내기가 한결 쉽습니다. 이것은 훗날 저의 확고한 지론이 되었습니다. 초기에 일본 동호인분이 만든 그 두 편의 매우 상세한 WBPP 강좌 동영상도 저는 크게 추천합니다만, 마찬가지로 이 한마디는 덧붙여 두고 싶습니다—인테그레이션 결과는 참고 정도로만, 이라고.
핵심 개념 2: Master 폴더 안에서 어느 것이 결과물인지 구분하기
WBPP를 완전히 다 실행하고 나면, 기본 Master 폴더 아래에는 한 무더기의 파일이 놓이게 되어, 어느 것이 자신이 원하는 것인지 구분하지 못하는 분이 많습니다. 여기서 설명해 두겠습니다.
- 빨간 박스 안의 이미지가 바로 여러분이 원하는, 인테그레이션이 완료된 마스터 라이트입니다.
- 노란 박스 안의 이미지는 Local Normalization의 참조(Ref) 이미지이지, 마스터 라이트가 아닙니다. 혼동하지 마시기 바랍니다.
- 박스가 없는 이미지는 마스터 캘리브레이션 프레임으로, 여기에는 마스터 플랫, 마스터 바이어스(bias), 마스터 다크가 포함됩니다.
(다만 앞 절에 이어서, 이 「마스터 라이트」도 여전히 WBPP의 프리뷰 성격이므로, 제대로 하려면 역시 직접 한 번 더 인테그레이션해야 합니다.)
현행 실행 흐름: 컬러 카메라의 풀코스
WBPP는 원클릭으로 끝까지 달리지만, 그 이면에서는 실제로 순서대로 실행되는 긴 자동화 프로세스의 연쇄가 돌아가고 있습니다. 컬러(OSC) 카메라를 예로 들면, 완전한 실행 순서는 다음과 같습니다.
- Calibration File Integration: 마스터 캘리브레이션 프레임을 제작
- Calibration: 라이트 프레임을 캘리브레이션
- Cosmetic Correction: 핫 픽셀이나 불량 라인을 제거
- Debayer: 디베이어링(RGB 분리)
- Measurements: 라이트 프레임을 측정하여 가중치를 부여
- Reference frame selection: 정합에 쓸 참조 이미지를 선정
- Plate solving reference frames: 참조 이미지를 플레이트 솔빙(천체 측정)
- Registration: 스타 레지스트레이션(정합)
- LN reference generation: Local Normalization의 참조 이미지를 생성
- Local Normalization: Local Normalization을 실행
- Integration: 라이트 프레임을 인테그레이션
- RGB Combination: RGB 3채널을 다시 합성
좀 더 간결하게 말하면, 여덟 단계로 압축할 수도 있습니다. 캘리브레이션 이미지 파일 제작 → 이미지 캘리브레이션 → Cosmetic Correction → 디베이어링(RGB 3채널 분리) → 스타 레지스트레이션 → Local Normalization → 이미지 인테그레이션 → RGB 3채널 합성.
여기서 두 단계에 대해 몇 마디 덧붙일 만합니다. RGB 분리는 색분산(별 가장자리가 양쪽으로 다른 색으로 보이는 현상)을 극복하기 위한 것으로, 그 대가로 실행 시간이 더 걸립니다. Drizzle Integration을 사용하는 경우, 여기서의 목적은 이미지를 확대하는 것이 아니라 아티팩트를 피하는 것이므로, 충분한 dither 장수가 확보되어야 비로소 의미가 있으며, 일반적으로 50장 미만이라면 사실 하지 않아도 됩니다. 덧붙여 실제 시간 감각도 말씀드리면, 저는 예전에 900만 화소 이미지 360장을 캘리브레이션부터 Drizzle Integration 1x까지 통으로 처리한 적이 있는데, 한 시간 남짓 걸렸습니다. 화소가 더 높으면 더 「스릴 넘칠」 뿐입니다.
마스터 캘리브레이션 프레임: WBPP가 똑똑한 부분
WBPP는 캘리브레이션 프레임(flat, dark, bias 등)의 처리에 세심한 설계를 여럿 숨겨 두고 있어, 한 절을 따로 할애해 이야기할 가치가 있습니다.
캘리브레이션 프레임은 WBPP 안에서 원본 파일로부터 다시 만드는 것이 가장 좋습니다. 캘리브레이션 후 라이트 프레임에 문제가 생겼다고 느끼는 분이 적지 않은데, 그 주된 원인은 대개 「다른 소프트웨어나 프로세스로 만든 Master 파일」(Master flat/bias/dark)을 적용한 데 있습니다. 가장 안전한 방법은 캘리브레이션 파일의 원본을 WBPP에 넣어, WBPP가 Master를 새로 만들도록 하는 것입니다.
노출 시간에 미세한 오차가 있다? Exposure tolerance에 맡기세요. 예전에 어떤 동호인이 그룹에서 이런 질문을 한 적이 있습니다. 그는 Eqmod 신호 제어로 다크를 촬영하고 있었는데, 지연 문제 때문에 5초짜리 다크가 실제로는 4.980–5.02초 사이에 걸리는 경우가 있어 NINA로 촬영을 바꾸고 싶다는 것이었습니다. 사실 WBPP는 진작에 이를 내다보고 있었습니다. 일정한 시간 차 이내의 캘리브레이션 프레임은 동일 그룹으로 지정할 수 있고, WBPP는 같은 그룹의 캘리브레이션 프레임에 대해 해야 할 처리를 자동으로 수행하며, 라이트 프레임과도 자동으로 페어링해 줍니다. 이 허용값이 바로 Exposure tolerance입니다.
다른 날에 촬영한 이미지는 Grouping Keywords로 한 번에 해결. 개정 후 WBPP에는 그룹 분류 기능이 추가되어, 서로 다른 날짜에 촬영한 이미지라도 한꺼번에 넣어 함께 처리할 수 있습니다—Grouping Keywords에서 키워드(예를 들어 날짜)로 분류하기만 하면 됩니다. 제 그 파일 묶음처럼 날마다 플랫이 다르더라도, WBPP는 날짜별로 자동으로 나누어 캘리브레이션해 주므로, 서로 다른 날짜의 라이트와 플랫 짝을 일일이 수동으로 설정할 필요가 없어 매우 편리합니다.
마스터 캘리브레이션 프레임만 만들고 싶다? 라이트 프레임을 넣지 않아도 됩니다. 이것은 모르는 분이 많은 사용법입니다. 라이트 프레임이 없는 상태에서 다크, 바이어스, 플랫, 플랫 다크를 WBPP에 넣으면, WBPP는 올바른 순서에 따라 이 캘리브레이션 프레임들을 똑똑하게 마스터 캘리브레이션 프레임으로 완성하여 지정한 폴더로 출력해 주므로, 여러 가지 다른 프로세스로 일일이 수작업으로 만드는 수고를 덜어 줍니다.
Light 페이지 옵션과 속도 향상 팁
WBPP의 Light 페이지에는 한 줄로 늘어선 옵션이 있어, 사용자가 필요에 따라 체크할 수 있습니다. 기본 상태에서는 subframe weighting을 제외하고 모두 체크가 해제되어 있습니다.
이 단계들을 취사선택할 수 있다는 점에서 실용적인 질문이 하나 떠오릅니다. 필요 없는 처리를 꺼 두면 시간을 얼마나 절약할 수 있을까요? 해외에서 자유롭게 다운로드할 수 있는 데이터 한 세트로 실측해 보았습니다. 1600만 화소 이미지, 총 372장. 필요 없는 처리를 걷어 내니 시간이 대략 7~8배 빨라졌고(25분 03초 vs. 03분 30초), 이미지 품질의 저하는 아주 미미했습니다—로컬 머신에서 약 15% 차이, 네트워크를 거쳐 압축한 뒤에는 거의 분간이 되지 않습니다. 마감에 쫓기거나 우선 대략 훑어보고 싶은 상황이라면, 이 트레이드오프는 꽤 남는 장사입니다.
어느 단계가 가장 시간을 많이 잡아먹는지, 어느 것을 끄는 게 가장 효과적인지에 관해서는 〈WBPP 문제 해결〉 글에서 다시 다루겠습니다.
버전 변화: 이것들은 나중에 추가된 것
WBPP는 지난 몇 년간 적지 않은 기능을 더해 왔습니다. 중요한 분기점 몇 가지를 정리해 둘 테니, 손에 든 버전과 대조해 보실 때 참고하시기 바랍니다.
2.1.2 버전에서의 몇 가지. 이 버전부터 주목할 만한 점이 셋 있습니다. 첫째, 캘리브레이션 후 라이트 프레임에 문제가 생기는 것은 흔히 외부에서 만든 Master 파일을 섞어 쓴 탓입니다(앞서 언급). 둘째, Dark frame optimization은 주로 라이트와 다크의 길이가 맞지 않을 때(예를 들어 20분 라이트에 30분 다크) 사용하는 것으로, 장시간 노출에 여러 장이 있는 것이 최적의 전제이며, 이 옵션은 라이트 프레임 파일을 클릭해야만 보입니다. 셋째, CCD를 쓰는 분은 사용하면서 점차 defect, 특히 column defect가 나타나는데, 과거에는 defect map을 만들어 제거해야 해서 매우 손이 많이 갔지만, WBPP는 이에 대처할 Linear Pattern Subtraction을 마련했습니다.
Execution Monitor(실행 모니터 창). 비교적 새 버전으로 업데이트하면, WBPP는 실행 중에 WBPP Execution Monitor라는 창을 띄워, 지금 어느 단계까지 진행되었고 어떤 작업을 했는지 알려 줍니다. 내용은 위아래로 스크롤하거나 드래그할 수도 있습니다. 구 버전에서는 사용자가 현재 console을 응시하는 것 말고는 진행 상황을 알 방법이 전혀 없어서, 전부 다 돌거나 오류로 멈추기를 기다려야 비로소 console로 확인할 수 있는 형편이었습니다.
Cache(캐시) 기능(2.5 버전 이후). 이것은 매우 핵심적인 개선입니다. 풀코스를 다 돌린 뒤 오류나 기대에 못 미치는 부분을 발견해 설정 몇 가지를 바꿨다고 해서, 정말 전체를 다시 돌려야 할까요? 그럴 필요 없습니다. WBPP의 캐시는 이렇게 판단합니다—바꾼 설정이 이미지에 영향을 주지 않는 한, 지난번 캐시 결과를 그대로 사용합니다. 정말로 영향이 미치는 부분의 이미지만 다시 처리되므로, 두 번째 실행 시간이 크게 단축됩니다.
log 폴더 안의 재현 가능한 스크립트. 최신 버전 WBPP는 실행 후 log 폴더에 상세한 log와 실행 스크립트를 남깁니다. PI의 Script Editor로 스크립트를 읽어 들여 컴파일하고 실행하면, Process Container가 하나 떠서 그 안에 WBPP 메인 창 Pipeline 서브메뉴의 모든 프로세스 ICON이 담겨 있으며, 하나하나 PI에서 단독으로 열 수 있습니다. 이것은 디버깅에 더없이 편리합니다—예를 들어 Cosmetic Correction이 왜 제대로 실행되지 않았는지, 혹은 효과가 없었는지 알아보고 싶다면, 여기서 그 단계를 열어 파라미터 문제인지 아니면 프로그램 버그인지 확인할 수 있습니다. 또 다른 용도로는, 전처리에 익숙하지 않은 분이 이 방법으로 WBPP의 각 단계 프로세스와 파라미터를 읽어 내어, 자신이 수동으로 실행할 때의 참고 템플릿으로 삼을 수 있습니다.
WBPP를 열고 나서 첫 단계는, 사실 파일을 불러오는 것이 아닙니다
마지막으로 가장 기본적이면서도 가장 틀리기 쉬운 부분으로 돌아가 봅시다. WBPP를 연 뒤의 첫 단계는, 서둘러 「라이트, 다크, 플랫, 바이어스 파일을 불러오는」 것이 아닙니다.
WBPP는 지난번 사용 내용을 보존하는 몇 안 되는 스크립트입니다. 이전에 써 본 적이 있다면 모든 설정이 그대로 남아 있습니다. 그래서 첫 단계는 파일 목록을 지우는 것이어야 합니다. 다른 파라미터도 함께 지울지는 필요에 따라 판단하시면 됩니다.
그리고 두 번째 단계는 빠뜨리기 쉽고 많은 강좌 동영상에서도 언급하지 않습니다—Purge Cache를 누르는 것입니다. 앞서 캐시(2.5 버전 이후)의 장점을 말씀드렸습니다. 일부 파라미터만 바꿀 때 WBPP는 바뀐 부분만 돌리고 나머지는 캐시를 사용합니다. 그러나 반대로, 이미 한 번 돌렸고 그 캐시 내용이 더는 필요 없을 때는, 그것들을 전부 지워야 합니다. 그러지 않으면 새 파일을 실행할 때 캐시 내용이 중복되어 예기치 못한 오류가 생길 수 있습니다.
Windows 사용자를 위한 환경 사전 설정
Windows에서 WBPP를 돌린다면, 처음부터 처리해 두는 것이 좋은 환경 설정이 두 가지 있습니다. 나중에 생길 영문 모를 오류의 무더기를 덜 수 있습니다(관련 오류 메시지와 진단은 〈WBPP 문제 해결〉에 자세히 실려 있습니다).
긴 경로(롱 패스) 지원을 켜기. 어떤 업데이트 이후, Windows의 WBPP는 256자를 넘는 경로를 생성할 수 없다며 롱 패스 경고를 자주 띄우게 되었습니다. 저 자신도 경로가 너무 길어서 WBPP가 출력한 파일이 손상된(파일을 저장할 수 없었기 때문) 적이 있습니다. 해결책은 작업 표시줄에서 regedit을 검색해 레지스트리 편집기를 열고, 해당 위치를 찾아 LongPathsEnabled의 값을 1로 바꾸는 것입니다. PixInsight를 재시작하면 이 경고는 더 이상 나타나지 않습니다.
한국어나 중국어 등 비 ASCII(비 서유럽어권) 문자를 포함한 경로를 피하기. 이것도 제가 파일 경로에 한국어나 중국어 같은 비 ASCII 문자를 쓰지 말라고 권하는 이유입니다. Windows에서 파일의 기본 실행 프로그램이 PI로 되어 있으면, 비 ASCII 문자를 포함한 경로의 파일을 더블클릭하는 것만으로 오류 메시지가 뜨는데, 아래 예에서 깨져 보이는 부분이 사실은 원래 중국어 문자입니다. 우회 방법은, 경로를 바꾸지 않은 채 파일을 그대로 드래그해 PI에 끌어다 넣으면 열립니다.
이상을 이어 붙이면 WBPP의 전모가 대체로 뚜렷해집니다. 그것은 강력한 자동 전처리 엔진이지만, 그 인테그레이션 결과물이 프리뷰일 뿐임을 잊지 말고, 어떻게 그룹을 나누어 캘리브레이션하는지, 어떻게 캐시를 잘 활용하는지, 그리고 작업을 시작하기 전에 무엇을 지우고 어떤 환경을 설정해 두어야 하는지를 알아 두어야 합니다. 개념이 맞으면, 나머지는 숙련도의 문제입니다.