छवियों का चयन: Blink और SubframeSelector में से सही चुनाव कैसे करें

पूरी रात शूटिंग करने के बाद हार्ड डिस्क में दसियों से लेकर सैकड़ों लाइट फ़्रेम पड़े रहते हैं, और इसके बाद सामने आने वाला पहला सवाल यही होता है: किन्हें रखें और किन्हें फेंकें? PixInsight में इस काम के लिए दो रास्ते खुले हैं — एक यह कि Blink के सहारे अपनी आँखों से देखा जाए, और दूसरा यह कि SubframeSelector (आगे संक्षेप में SS) से सॉफ़्टवेयर को ही मात्रात्मक अंक देने दिए जाएँ। इस लेख में मैंने पिछले कुछ वर्षों में छवियों के चयन को लेकर बनी अपनी कुछ समझ समेटी है, और इन दोनों औज़ारों की अपनी-अपनी जगह तथा व्यवहार में मैं ख़ुद क्या चुनाव करता हूँ, इस पर बात की है।

शुरुआती लोग: पहले अपनी आँखों और अपने दिमाग़ पर भरोसा करें

बहुत-से लोग शुरू से ही जल्दबाज़ी में SS पर चढ़ बैठते हैं और हर छवि के FWHM, SNRWeight, Noise जैसे आँकड़े फैलाकर उनका अध्ययन करने लगते हैं। लेकिन अगर आपके फ़्रेम की संख्या ज़्यादा नहीं है (जैसे 50 से 100 फ़्रेम से भी कम), तो सच कहूँ तो SS ज़रूरी नहीं कि बहुत काम आए; Blink से एक बार तेज़ी से नज़र दौड़ा लेना उलटे ज़्यादा तेज़ पड़ता है।

इससे भी ज़रूरी बात यह है कि इन मापे गए मानों के बीच कोई अनिवार्य संबंध होता ही नहीं। जब तक कोई मान बिलकुल बेतुका न हो — जैसे पूरे फ़्रेम में एक भी तारा न हो — तब तक अकेले आँकड़े देखना आँखों से किए गए फ़ैसले के मुक़ाबले न तो ज़्यादा भरोसेमंद है, न ही ज़रूरी है कि ज़्यादा तेज़ हो।

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

सबसे विशिष्ट उदाहरण है “S/N अनुपात ऊँचा, मगर तस्वीर की गुणवत्ता ख़राब” वाली स्थिति। इसका एक आम कारण यह होता है कि पतले बादलों के चलते तारों की संख्या घट जाती है, जिससे S/N अनुपात का आँकड़ा ऊपर खिंच जाता है, जबकि असल में वह फ़्रेम काम का नहीं होता। ऐसी स्थिति में सही फ़ैसला करने के लिए और भी चरों को साथ में देखना पड़ता है; मगर इसकी जगह इंसानी दिमाग़ और आँखें हों, तो अकसर एक सेकंड में ही दिख जाता है कि यह फ़्रेम अच्छा नहीं है।

तो, पहले अपने दिमाग़ और अपनी आँखों पर भरोसा कीजिए, और अपनी खींची हुई तस्वीरों को ज़रा ठीक से देखिए।

Blink के चरण में जिन छवियों को मैं सीधे बाहर कर देता हूँ

Blink की इस चौकी पर कुछ ऐसी क़िस्म की छवियाँ हैं जिन्हें देखते ही मैं सीधे छाँट देता हूँ, बिना और झिझके:

1. फ़िल्टर व्हील का अवरोध
2. तारों का गंभीर खिंचाव (trailing)
3. उससे भी गंभीर खिंचाव
4. गंभीर फ़ोकस चूक (तारों के बीचोबीच काला छेद दिखने लगता है)
5. बादलों से इतना ढका हुआ कि पिंड लगभग दिखता ही नहीं
6. वेधशाला की छत का फ़्रेम में आ जाना

एक क़िस्म और है, कुछ ज़्यादा टेढ़ी और अब तक न बताई गई: बड़े अपर्चर से खींची गईं और ऊपर से ऊँचाई के पतले बादलों से प्रभावित छवियाँ। इस तरह की छवियों की झंझट यह है कि आम तौर पर इंटीग्रेशन पूरा करके RGB जोड़ लेने के बाद ही समस्या पकड़ में आती है — तारे फैल जाते हैं। अगर पूरे बैच में सामान्य छवियों की संख्या ऊँचाई के बादलों से प्रभावित छवियों से ज़्यादा नहीं है, तो फैले हुए तारों वाली इन छवियों को बाहर करके दोबारा शूट करने के अलावा कोई चारा नहीं बचता।

SubframeSelector की जगह: मात्रा में आँकना और भार देना

तो क्या SS बेकार है? बिलकुल नहीं। SS का बुनियादी काम है तय की गई शर्तों के अनुसार, या फिर मापे गए मानों के आधार पर हर छवि का भार बदलकर उन्हें आउटपुट करना। दूसरे शब्दों में, उसका असली मोल “आपके लिए दो में से एक चुनकर छाँट देने” में नहीं है, बल्कि “मूल रूप से पास हो चुकी हर छवि को अलग-अलग भार देने” में है, ताकि वे अलग-अलग योगदान के साथ इंटीग्रेशन में शामिल हों।

SS काफ़ी सारे पैरामीटर माप सकता है। उदाहरण के लिए, अगर आप तारों के आकार के आधार पर आकलन करना चाहें, तो eccentricity (तारे की उत्केंद्रता) नाम के पैरामीटर का सहारा ले सकते हैं। यह मापता है कि तारे की रूपरेखा कितनी विकृत हुई है: किसी दीर्घवृत्ताकार तारे की रूपरेखा के लिए दीर्घ अक्ष का व्यास a और लघु अक्ष का व्यास b मान लें (जहाँ a, b से बड़ा या उसके बराबर हो); तब उत्केंद्रता (1 − b² / a²) के वर्गमूल के बराबर होती है, और तारे का लंबाई-चौड़ाई अनुपात b / a होता है। उत्केंद्रता 0 के जितना क़रीब होगी, तारा उतना ही गोल; 1 के जितना क़रीब, उतना ही ज़्यादा खिंचा हुआ।

व्यवहार में मैं जाँची गई छवियों को तारों की गोलाई के क्रम में लगाता हूँ, और उसके बाद Blink पर लौटकर देखता हूँ कि जिन छवियों की गोलाई कम निकली, उनका माजरा आख़िर क्या है — और हाँ, साथ में देखने के लिए दूसरे पैरामीटर भी हैं।

अब मैं ख़ुद क्या करता हूँ

सच कहूँ तो, Blink की इस चौकी को छोड़कर — जहाँ आज भी मैं ख़ुद अपनी आँखों से देखता हूँ — बाक़ी सारा आकलन का काम मैंने लगभग पूरा का पूरा कंप्यूटर के हवाले कर दिया है। लेख में SS का प्रदर्शन करना दरअसल इसलिए है कि सब लोग उसके काम करने का तर्क समझ लें; असली मौक़े पर मैं कंप्यूटर से कई पैरामीटर मिलाकर अपने आप छवियों को भार दिलवाता हूँ, और फिर उपयुक्त पिक्सेल रिजेक्शन (rejection) एल्गोरिदम तथा पैरामीटर के साथ इंटीग्रेशन करता हूँ।

ऐसा करने का मक़सद यह है कि मूल रूप से पास हो चुकी हर छवि उचित भार के साथ इंटीग्रेशन में शामिल हो और अपना बनता हिस्सा अदा करे, ताकि खींची गई छवियों और जमा हुए कुल एक्सपोज़र समय का बेहतरीन इस्तेमाल हो सके और खगोलीय पिंड की छवि का S/N अनुपात जितना संभव हो उतना ऊपर उठे।

तो पूरे प्रवाह को यूँ समझा जा सकता है: Blink (आँखें चौकी पर, कचरा फ़्रेम बाहर) → कंप्यूटर के हवाले, मात्रा में आँकना और भार देना → इंटीग्रेशन। आँखें उन कामों को सँभालती हैं जिनका फ़ैसला एक सेकंड में हो जाता है, और कंप्यूटर उन कामों को जिनमें भार की सटीक गणना करनी पड़ती है — हर कोई अपनी-अपनी जगह पर।