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: 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 कर दीजिए); साथ ही ग़ैर-ASCII (जैसे चीनी) अक्षरों वाले पाथ से बचने की भी सलाह है। वातावरण की इन दोनों पूर्व-तैयारियों का विस्तृत तरीक़ा मैंने “WBPP का संपूर्ण मार्गदर्शक” के Windows वातावरण-सेटिंग वाले खंड में लिखा है, इसलिए यहाँ दोहरा नहीं रहा।

RA/DEC निर्देशांक का “60 सेकंड अगले अंक में नहीं चढ़े” वाला बग

यह सबसे टेढ़ी, और अलग से चर्चा के सबसे ज़्यादा लायक़ समस्या है, क्योंकि इसके लक्षण तरह-तरह के होते हैं पर जड़ हर बार एक ही रहती है: FITS Header में मौजूद विषुवांश / क्रांति (RA/DEC) निर्देशांक में सेकंड का मान “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, और छवियाँ दो करोड़ चालीस लाख पिक्सेल की; इस तरह के इंतज़ार से सचमुच कंप्यूटर बदल डालने का मन करने लगता है)।

इनमें ख़ास तौर पर समय खाने वाली दो जगहें हैं:

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 के ज़्यादातर नख़रों से आप निपट लेंगे।