WBPP का संपूर्ण मार्गदर्शक: इंटरफ़ेस, मास्टर कैलिब्रेशन फ़्रेम और एक्ज़ीक्यूशन पाइपलाइन

यह लेख 2021–2024 के दौरान लिए गए नोट्स से संकलित है। कुछ टूल या प्रक्रियाएँ तब से अपडेट हो चुकी हैं, इसलिए पढ़ते समय इसका ध्यान रखें; लेख में उल्लिखित कुछ इंटरफ़ेस, विकल्प और संस्करण-विशिष्ट व्यवहार (जैसे संस्करण 2.1.2 और 2.5) उस समय की स्थिति दर्शाते हैं। रही बात चलाते समय आने वाली त्रुटियों और ज्ञात बग की, तो उसके लिए अलग लेख “WBPP समस्या-निवारण” देखें।

WBPP (WeightedBatchPreprocessing) PixInsight का वह स्क्रिप्ट है जो “कैलिब्रेशन, स्टार रजिस्ट्रेशन और इंटीग्रेशन” को शुरू से आख़िर तक एक ही झटके में अपने-आप चला देता है — और यह हैरान कर देने वाली हद तक सुविधाजनक है। पिछले कुछ वर्षों में इसके संस्करण बार-बार बदले हैं, और मैंने भी समय-समय पर इस पर काफ़ी सारे बिखरे हुए नोट्स लिखे हैं; इस लेख में मैं उन्हें समेटकर एक अपेक्षाकृत पूरा विवरण बना रहा हूँ, जिसे तीन स्तरों में बाँटकर बताऊँगा: वे मूल अवधारणाएँ जो संस्करण बदलने पर भी ज़्यादा नहीं बदलतीं, मौजूदा एक्ज़ीक्यूशन पाइपलाइन, और वर्षों के दौरान संस्करणों में हुए कुछ महत्वपूर्ण बदलाव। आप चाहे कोई भी संस्करण इस्तेमाल कर रहे हों, पहले अवधारणाएँ मज़बूती से पकड़ लें — फिर इंटरफ़ेस कैसे भी बदले, घबराने की नौबत नहीं आएगी।

मूल अवधारणा एक: 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 ट्यूटोरियल वीडियो की सिफ़ारिश भी मैं ख़ूब करता हूँ, पर उनके साथ भी यही चेतावनी जोड़नी पड़ेगी: इंटीग्रेशन के नतीजे को सिर्फ़ संदर्भ के तौर पर लें।

मूल अवधारणा दो: पहचानिए कि Master फ़ोल्डर में कौन-सी फ़ाइलें असली परिणाम हैं

WBPP को पूरा चला लेने के बाद डिफ़ॉल्ट Master फ़ोल्डर के नीचे ढेर सारी फ़ाइलें पड़ी मिलती हैं, और बहुत से साथी यह नहीं पहचान पाते कि उनमें से उन्हें चाहिए कौन-सी। यहाँ थोड़ा समझा देता हूँ:

• लाल बॉक्स वाली छवि ही वह इंटीग्रेट हो चुका, तैयार मास्टर लाइट है जो आपको चाहिए।
• पीले बॉक्स वाली छवि Local Normalization का संदर्भ (Ref) चित्र है, मास्टर लाइट नहीं — दोनों को गड्डमड्ड न करें।
• बिना बॉक्स वाली छवियाँ मास्टर कैलिब्रेशन फ़्रेम हैं, जिनमें मास्टर फ़्लैट, मास्टर बायस (bias) और मास्टर डार्क शामिल हैं।

(हालाँकि पिछले खंड की बात याद रखें — यह “मास्टर लाइट” भी WBPP का प्रीव्यू ही है; ठीक-ठीक करना हो तो इसे ख़ुद एक बार दोबारा इंटीग्रेट करना ही चाहिए।)

मौजूदा एक्ज़ीक्यूशन पाइपलाइन: कलर कैमरे का पूरा पैकेज

WBPP एक ही क्लिक में आख़िर तक चला जाता है, पर पर्दे के पीछे दरअसल क्रम से चलने वाली स्वचालित प्रक्रियाओं की एक लंबी शृंखला होती है। कलर (OSC) कैमरे का उदाहरण लें तो पूरा एक्ज़ीक्यूशन क्रम इस तरह है:

1. Calibration File Integration: मास्टर कैलिब्रेशन फ़्रेम बनाना
2. Calibration: लाइट फ़्रेम को कैलिब्रेट करना
3. Cosmetic Correction: हॉट पिक्सेल या ख़राब लाइनें हटाना
4. Debayer: डीबायरिंग (RGB अलग करना)
5. Measurements: लाइट फ़्रेम मापना और उन्हें वेट देना
6. Reference frame selection: रजिस्ट्रेशन के लिए संदर्भ चित्र चुनना
7. Plate solving reference frames: संदर्भ चित्र की प्लेट सॉल्विंग (खगोलीय मापन)
8. Registration: स्टार रजिस्ट्रेशन
9. LN reference generation: Local Normalization का संदर्भ चित्र बनाना
10. Local Normalization: Local Normalization चलाना
11. Integration: लाइट फ़्रेम का इंटीग्रेशन
12. RGB Combination: RGB के तीनों चैनल दोबारा जोड़ना

ज़्यादा संक्षेप में कहें तो इसे आठ चरणों में भी समेटा जा सकता है: कैलिब्रेशन इमेज फ़ाइलें बनाना → इमेज कैलिब्रेशन → Cosmetic Correction → डीबायरिंग (RGB तीनों चैनल अलग करना) → स्टार रजिस्ट्रेशन → Local Normalization → इमेज इंटीग्रेशन → RGB तीनों चैनलों का संयोजन।

यहाँ दो चरणों पर कुछ और कहना बनता है: RGB पृथक्करण वर्ण विक्षेपण से पार पाने के लिए है (जिसमें तारों के किनारे दोनों तरफ़ अलग-अलग रंग के दिखते हैं), और इसकी क़ीमत यह है कि चलने में अतिरिक्त समय लगता है; Drizzle Integration अगर इस्तेमाल हो, तो यहाँ उसका मक़सद छवि को बड़ा करना नहीं, बल्कि आर्टिफ़ैक्ट से बचना है, इसलिए वह तभी सार्थक है जब पर्याप्त dither वाले फ़्रेम हों — आम तौर पर 50 फ़्रेम से कम हो तो उसे छोड़ा भी जा सकता है। साथ ही समय का असली अहसास भी बता दूँ: एक बार मैंने नब्बे लाख पिक्सेल वाली 360 छवियों को कैलिब्रेशन से लेकर Drizzle Integration 1x तक चलाया था, और उसमें भी एक घंटे से ज़्यादा लगा; पिक्सेल और ज़्यादा हों तो मामला और भी “रोमांचक” ही होगा।

मास्टर कैलिब्रेशन फ़्रेम: जहाँ WBPP की चतुराई दिखती है

कैलिब्रेशन फ़्रेम (flat, dark, bias वग़ैरह) को सँभालने के तरीक़े में WBPP ने कई सुविचारित इंतज़ाम छिपा रखे हैं — इतने कि उन पर एक अलग खंड बनता है।

कैलिब्रेशन फ़्रेम को WBPP के भीतर मूल फ़ाइलों से दोबारा बनाना ही सबसे अच्छा है। बहुत लोग कैलिब्रेशन के बाद पाते हैं कि लाइट फ़्रेम में गड़बड़ी है, और इसका मुख्य कारण अक्सर यह होता है कि उन्होंने “किसी दूसरे सॉफ़्टवेयर या प्रक्रिया से बनी Master फ़ाइलें” (मास्टर फ़्लैट/बायस/डार्क) लगा दी थीं। सबसे सुरक्षित तरीक़ा यह है कि कैलिब्रेशन फ़ाइलों की मूल फ़ाइलें WBPP में डाल दें और उसे Master दोबारा बनाने दें।

एक्सपोज़र समय में ज़रा-सा अंतर है? उसे Exposure tolerance पर छोड़ दीजिए। एक बार समूह में एक साथी ने पूछा था: वे Eqmod सिग्नल कंट्रोल से डार्क ले रहे थे, और विलंब की वजह से 5 सेकंड के डार्क असल में 4.980–5.02 सेकंड के बीच कहीं गिर सकते थे, इसलिए वे NINA से शूट करने पर जाना चाहते थे। दरअसल WBPP ने यह बहुत पहले से सोच रखा है: एक निश्चित समयांतर के भीतर आने वाले कैलिब्रेशन फ़्रेम को एक ही समूह में रखा जा सकता है, और WBPP उसी समूह के कैलिब्रेशन फ़्रेम पर जो प्रोसेसिंग होनी चाहिए वह अपने-आप कर देता है, साथ ही लाइट फ़्रेम के साथ अपने-आप जोड़ी भी बना देता है। यही सहनशीलता-मान Exposure tolerance है।

अलग-अलग दिनों में ली गई छवियों को Grouping Keywords से एक ही बार में निपटाइए। संस्करण बदलने के बाद WBPP में ग्रुपिंग की सुविधा जुड़ गई, इसलिए अलग-अलग तारीख़ों पर ली गई छवियाँ भी एक साथ डालकर एक ही बार में प्रोसेस की जा सकती हैं — बस Grouping Keywords में किसी कीवर्ड (जैसे तारीख़) से उन्हें वर्गीकृत कर दीजिए। जैसे मेरे उस फ़ाइल-समूह में हर दिन के फ़्लैट अलग थे, फिर भी WBPP तारीख़ के हिसाब से उन्हें अलग-अलग कैलिब्रेट कर पाया, और मुझे अलग-अलग तारीख़ों के लाइट और फ़्लैट की जोड़ी हाथ से एक-एक करके सेट नहीं करनी पड़ी — बेहद सुविधाजनक।

सिर्फ़ मास्टर कैलिब्रेशन फ़्रेम बनाने हैं? लाइट फ़्रेम डाले बिना भी काम चल जाएगा। यह ऐसा इस्तेमाल है जो बहुत से लोग नहीं जानते: बिना किसी लाइट फ़्रेम के, डार्क, बायस, फ़्लैट और फ़्लैट डार्क को WBPP में डाल दीजिए — वह समझदारी से, सही क्रम का पालन करते हुए इन कैलिब्रेशन फ़्रेम को मास्टर कैलिब्रेशन फ़्रेम में बदल देगा और उन्हें आपके बताए फ़ोल्डर में लिख देगा, जिससे तरह-तरह की अलग-अलग प्रक्रियाओं से उन्हें हाथ से बनाने की झंझट बच जाएगी।

Light पेज के विकल्प और गति बढ़ाने की तरकीबें

WBPP के Light पेज पर विकल्पों की एक पंक्ति है, जिन्हें उपयोगकर्ता अपनी ज़रूरत के मुताबिक़ चुन सकता है। डिफ़ॉल्ट स्थिति में subframe weighting के अलावा बाक़ी सब अनचेक रहते हैं।

चूँकि इन चरणों को चुना या छोड़ा जा सकता है, इसलिए एक व्यावहारिक सवाल खड़ा हो जाता है: जो प्रोसेसिंग ज़रूरी नहीं, उसे बंद कर देने से कितना समय बचता है? मैंने विदेश से मुफ़्त डाउनलोड होने वाले एक डेटा सेट पर सचमुच परीक्षण किया — कुल 372 छवियाँ, हर छवि एक करोड़ साठ लाख पिक्सेल की — और ग़ैर-ज़रूरी प्रोसेसिंग हटा देने के बाद समय लगभग 7 से 8 गुना तेज़ हो गया (25 मिनट 03 सेकंड बनाम 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 खोजकर Registry Editor खोलें, संबंधित जगह ढूँढ़कर LongPathsEnabled का मान 1 कर दें, और PixInsight दोबारा शुरू करने के बाद यह चेतावनी फिर नहीं आएगी।

ग़ैर-ASCII (जैसे चीनी) अक्षरों वाले पाथ से बचें। यही वजह है कि मैं फ़ाइल पाथ में ऐसे अक्षर रखने की सलाह नहीं देता। Windows पर, अगर फ़ाइल खोलने का डिफ़ॉल्ट प्रोग्राम PI है, तो ग़ैर-ASCII अक्षरों वाले पाथ की फ़ाइल पर डबल-क्लिक करते ही एक त्रुटि-संदेश आ जाता है, और उसमें दिखने वाले वे अटपटे चिह्न दरअसल वही चीनी अक्षर होते हैं। इसका जुगाड़ यह है: पाथ बदले बिना ही, फ़ाइल को खींचकर सीधे PI में छोड़ दीजिए — वह खुल जाएगी।

---

ऊपर की सारी बातें जोड़ लें तो WBPP की पूरी तस्वीर लगभग साफ़ हो जाती है: यह एक ताक़तवर स्वचालित प्रीप्रोसेसिंग इंजन है, पर आपको याद रखना होगा कि उसका इंटीग्रेशन परिणाम केवल एक प्रीव्यू है, आपको यह भी आना चाहिए कि कैलिब्रेशन को समूहों में कैसे बाँटें, कैश का सही इस्तेमाल कैसे करें, और काम शुरू करने से पहले क्या साफ़ करना है तथा कौन-सा वातावरण सेट करना है। अवधारणाएँ सही हों, तो बाक़ी बस अभ्यास की बात है।