Řešení problémů s WBPP: časté chyby a známé bugy
Tento článek jsem sestavil z poznámek z let 2022–2025; některé nástroje nebo postupy se od té doby aktualizovaly, takže to mějte při čtení na paměti. Chybové zprávy a chování jednotlivých verzí uvedené v textu jsou zaznamenané tak, jak vypadaly v té době. Rozhraní WBPP, kalibrační master snímky a běžný průběh zpracování najdete v doprovodném článku „The Complete Guide to WBPP“.
Spustit WBPP jedním kliknutím od začátku do konce je sice příjemné, ale při skutečném používání se vždy najde situace, kdy se to zasekne, vyhodí chybu, nebo výsledek prostě nesedí. V tomto článku jsem shrnul kategorie problémů s WBPP, na které jsem za ty roky narazil – a na které se mě nejčastěji ptají – do praktické příručky pro řešení problémů: od diagnostického myšlení až po několik konkrétních známých bugů.
První krok při řešení problémů: nejdřív se podívejte do Process Console
Když se při zpracování v PixInsight něco pokazí, první věc, na kterou byste měli vždy pomyslet, je podívat se do Process Console. Ukáže vám, kde chyba nastala a o jaký typ chyby jde – je to výchozí bod veškeré diagnostiky.
WBPP je ale skript, a dokud skript neběží, console je sbalená a nedá se označit. Když se tedy chcete na console podívat, často musíte nejdřív zavřít WBPP. Zní to nepohodlně, ale u řady problémů je to jediný zdroj vodítek – rozluštění několika bugů níže začalo pokaždé právě u toho jednoho červeného řádku v console.
Selhání a bugy ve fázi kalibrace
Kalibrace selhala (failed) – nejdřív zavřete PI a otevřete ho znovu. Pokud při spuštění WBPP hned první kalibrace (s použitím master kalibračních snímků) selže a status ukazuje červené „failed“, můžete celý proces pozastavit, zavřít PI, znovu otevřít WBPP a spustit to ještě jednou – tato chyba kalibrace pak obvykle zmizí. Při zpracování OSC snímků jsem na tento bug narazil minimálně čtyřikrát a pokaždé jsem ho vyřešil právě tímto trikem.
Snímky flat pořád dávají chybu kalibrace – přepněte zpět na ruční postup po krocích. Některé verze WBPP mají bug, který stále způsobuje chybu kalibrace snímků flat. V takové chvíli je důležité umět si to zpracovat sami ručně krok za krokem. Zároveň si připomeňme kroky Pre-Process:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: interpolace podle Bayerovy matice
- Star Alignment
- NSG
- Integration
Když se na automatizaci nedá spolehnout, rozdělení procesu a jeho ruční provedení naopak lépe pomůže určit, ve kterém kroku problém vězí.
Problémy s cestami: dvě možné příčiny File I/O Error
Když ve Windows používáte WBPP a ve fázi kalibrace (calibration) vyskočí File I/O Error, obvykle jde o jednu z těchto dvou příčin:
- Cesta k souboru spolu s názvem souboru je příliš dlouhá a překračuje systémový limit, takže je potřeba ji zkrátit.
- Do cílové složky nelze zapisovat, například když je výstup nastavený do systémové složky.
První je nejčastější. Abyste problém „cesta je příliš dlouhá“ vyřešili natrvalo, můžete ve Windows zapnout podporu dlouhých cest (v regedit nastavte LongPathsEnabled na 1); dále doporučuji vyhýbat se cestám se znaky mimo ASCII (například čínskými). Podrobný postup pro tato dvě nastavení prostředí jsem popsal v části o nastavení prostředí Windows v článku „The Complete Guide to WBPP“, takže ho tady nebudu opakovat.
Bug se souřadnicemi RA/DEC: „60 sekund bez přenosu“
Tohle je nejzáludnější problém a zároveň ten, který nejvíc stojí za samostatný výklad, protože jeho příznaky jsou nejrůznější, ale kořenová příčina je pořád stejná: souřadnice rektascenze/deklinace ve FITS Header mají hodnotu sekund „60“, která se nepřenesla do vyšší jednotky.
Narazil jsem na to dvakrát, pokaždé v jiné podobě.
Poprvé: WBPP nedokázal načíst soubor. Zavřel jsem WBPP a podíval se do Process Console, kde jsem zjistil, že nějaký řádek js skriptu hlásí „neplatné souřadnice“. V tu chvíli jsem si myslel, že jde o bug WBPP, vzal jsem chybovou zprávu a vyhledal ji na internetu – a teprve tehdy jsem na PixInsight Forum našel několik stejných hlášení o chybě. Ukázalo se, že právě problém se souřadnicemi bránil načtení snímku do WBPP. I se směrem, který jsem už měl, mi trvalo hodinu, než jsem mezi několika stovkami light snímků vypátral ten problematický: jeho souřadnice OBJCTDEC byla chybná. V PI jsem otevřel proces FITSHeader, přejel na OBJCTDEC a upravil hodnotu, která se „měla přenést, ale nepřenesla se“ – v tomto případě jsem -69 26 60 změnil na -69 27 0 – a tenhle snímek se pak bez problémů načetl a další soubory už jím nebyly zablokované.
Podruhé: soubory se nedaly přidat, console hlásila too much recursion. Později jsem na to narazil znovu: při přidávání souborů do WBPP se software zasekl a nakonec se nepřidal vůbec žádný soubor. Zavřel jsem WBPP, podíval se do Console a tam bylo červené InternalError: too much recursion. Po opětovném otevření WBPP jsem zjistil, že část souborů se načetla a část ne; při kontrole těch nenačtených jsem opět narazil na anomálii ve FITS Header – tentokrát DEC ukazovalo -46 01 60, kde se sekundy „60“ měly přenést na -46 02 00. Jakmile WBPP načte takovou anomální hodnotu, zasekne se a strhne s sebou i všechny následující snímky, které se pak taky nenačtou. Stejně tak stačí otevřít FITS Header, ručně přenést sekundy a po opravě soubory znovu přidat. Když se všechny soubory úspěšně načtou, WBPP automaticky vyskočí s diagnostickou zprávou, například „60 of 60 light frames were added“.
Společný závěr: tenhle problém s automatickým nepřenášením souřadnic jsem doteď skoro vždycky viděl v situacích, kdy je snímacím softwarem MDL (vzdálené ovládání), ale nedá se vyloučit, že stejnou vadu může mít i jiný snímací software. Takže kdykoli se WBPP zasekne a soubory nejde přidat, nejdřív zkontrolujte v Process Console typ chyby a pak se podívejte, jestli Header RA/DEC nemá bug „60 sekund bez přenosu“ – po ruční opravě se to většinou vyřeší.
Výkon: proč velký komplet běží tak dlouho
Nakonec ještě jeden problém, který přísně vzato není „chyba“, ale je pořádně vyčerpávající – velký komplet WBPP je prostě příliš pomalý. Jednou jsem kvůli pěti snímkům, ze kterých jsem chtěl udělat HDR, nechal velký komplet běžet celé čtyři hodiny (tehdejší stroj měl AMD R5-4650G, DDR4 3200 32GB, Gen4 SSD, snímky po 24 megapixelech – takové čekání vážně nutí přemýšlet o novém počítači).
Obzvlášť hodně času zabírají dvě místa:
- Separated RGB: samostatné zpracování kanálů RGB barevného snímku kvůli odstranění chromatické vady.
- Local Normalization: výběr několika nejlepších snímků jako reference a aplikace Local Normalization na ostatní snímky.
Pokud tyto dvě položky zrušíte, bude WBPP mnohem rychlejší. Jestli je kvůli rychlosti obětovat, závisí na vašich nárocích na výsledné dílo – co se týče reálného měření „které kroky vypnout, kolik času se ušetří a kolik kvality se ztratí“, mám v článku „The Complete Guide to WBPP“ soubor dat ukazující 7–8násobné zrychlení, na které se můžete podívat.
Shrňme si myšlenkový postup téhle příručky pro řešení problémů: když něco nesedí, nejdřív se podívejte do Process Console; když kalibrace skončí jako failed, zavřete PI a otevřete ho znovu; když snímky flat pořád dávají chybu kalibrace, přepněte zpět na ruční postup po krocích; File I/O Error většinou znamená příliš dlouhou cestu nebo nezapisovatelnou složku; a když se něco nenačte, zasekne se nebo hlásí recursion, zkontrolujte, jestli RA/DEC ve FITS Header nemá bug se 60 sekundami bez přenosu. Osvojte si těchhle pár triků a s většinou vrtochů WBPP si poradíte.