वेब वर्कर से इमेज प्रोसेसिंग की बुनियाद
वेब वर्कर भारी काम UI थ्रेड के बाहर करते हैं। इमेज प्रोसेसिंग में मतलब है कटआउट चल सकता है जबकि UI प्रतिक्रियाशील रहे — डिवाइस मेमोरी और CPU की सीमाओं के अंदर।
यह नहीं बदलता कि पिक्सेल कहाँ जाते हैं — बदलता है ब्राउज़र लोकल काम कैसे बाँटता है।
मुख्य थ्रेड में यूजर-इंटरफ़ेस कार्य है
एक ब्राउज़र पेज आम तौर पर मुख्य थ्रेड पर जावास्क्रिप्ट चलाता है। वह धागा लेआउट, पेंटिंग और इनपुट का भी समन्वय करता है। यदि एक लंबी गणना उस पर कब्जा कर लेती है, तो क्लिक में देरी हो सकती है, एनीमेशन बंद हो सकता है, और ब्राउज़र चेतावनी दे सकता है कि पृष्ठ अनुत्तरदायी है।
अनुमान शुरू होने से पहले ही एक छवि संपादक के पास कई मुख्य-थ्रेड जिम्मेदारियां होती हैं:
- फ़ाइल चयन, पेस्ट, या ड्रॉप प्राप्त करें;
- डिकोड करें और एक छवि प्रदर्शित करें;
- अद्यतन प्रगति और त्रुटि स्थिति;
- पूर्वावलोकन कैनवास बनाएं;
- ब्रश मूवमेंट को जोड़ें और मिटाएं संभालें;
- डाउनलोड या क्लिपबोर्ड क्रियाएँ तैयार करें।
सेगमेंटेशन मॉडल के संख्यात्मक कार्य को एक ही थ्रेड पर रखने से वे कार्य सीधे प्रतिस्पर्धा में आ जाएंगे। एक कार्यकर्ता एक स्पष्ट सीमा बनाता है।
संदेश-आधारित सीमा
संपादक और कार्यकर्ता सामान्य चर साझा नहीं करते हैं। वे संदेश भेजकर संवाद करते हैं। एक सरलीकृत प्रवाह इस तरह दिखता है:
- संपादक किसी कार्यकर्ता का निर्माण या पुन: उपयोग करता है।
- यह कार्यकर्ता से अनुमान रनटाइम और मॉडल आरंभ करने के लिए कहता है।
- यह छवि डेटा तैयार करता है और एक अनुमान अनुरोध भेजता है।
- कार्यकर्ता डेटा को मॉडल के अपेक्षित इनपुट में परिवर्तित करता है।
- कार्यकर्ता मॉडल चलाता है और मुखौटा मूल्य उत्पन्न करता है।
- यह मास्क या परिणाम डेटा वापस भेजता है।
- संपादक पूर्वावलोकन को संयोजित करता है और परिशोधन या निर्यात को सक्षम बनाता है।
संदेशों में सही अनुरोध के जवाब से मेल खाने के लिए पर्याप्त संदर्भ शामिल होना चाहिए। यह तब मायने रखता है जब कोई उपयोगकर्ता पिछला कार्य समाप्त होने से पहले दूसरी छवि चुनता है। इंटरफ़ेस को नए स्रोत पर पुराना परिणाम प्रदर्शित करने से बचना चाहिए।
छवि डेटा की प्रतिलिपि बनाना और स्थानांतरित करना
छोटा टेक्स्ट संदेश भेजना सस्ता है. यदि ब्राउज़र को संपूर्ण बफ़र की प्रतिलिपि बनानी पड़े तो लाखों पिक्सेल मान भेजना महंगा हो सकता है। वेब एपीआई इसके बजाय कुछ बाइनरी बफ़र्स का स्वामित्व स्थानांतरित कर सकते हैं। एक हस्तांतरित बफ़र प्रेषक पक्ष पर प्रयोग करने योग्य डुप्लिकेट को बनाए रखे बिना रिसीवर के लिए उपलब्ध हो जाता है।
वह अनुकूलन एक डिज़ाइन बाधा के साथ आता है: स्थानांतरण के बाद, प्रेषक उसी बफर का उपयोग नहीं कर सकता है जैसे कि उसके पास अभी भी डेटा है। एक संपादक एक अलग प्रदर्शन प्रतिनिधित्व बनाए रख सकता है, एक समर्पित अनुमान बफर बना सकता है, या बाद में इसकी आवश्यकता के अनुसार पुनर्निर्माण कर सकता है।
प्रत्येक कार्यान्वयन बिल्कुल उन्हीं स्थानों पर स्थानांतरण का उपयोग नहीं करता है। सामान्य सबक यह है कि थ्रेड पृथक्करण से डेटा मूवमेंट गायब नहीं होता है। छवि आयाम, बफ़र आकार और रूपांतरणों की संख्या अभी भी विलंबता और मेमोरी को प्रभावित करती है।
Easy Background Remover कार्यकर्ता में क्या डालता है
Easy Background Remover ऑन-डिवाइस सेगमेंटेशन के लिए ब्राउज़र अनुमान रनटाइम के साथ एक वेब वर्कर का उपयोग करता है। भारी स्वचालित कटआउट चरण एक मुखौटा तैयार करता है। संपादक तब मिश्रित परिणाम प्रदर्शित करता है और सीपीयू-कैनवास ब्रश शोधन का समर्थन करता है।
यह पृथक्करण विफलताओं को अधिक उपयोगी सीमा प्रदान करता है। यदि कार्यकर्ता प्रारंभ नहीं कर सकता है या अनुमान के दौरान क्रैश हो जाता है, तो इंटरफ़ेस एकमात्र सिग्नल के रूप में स्थायी रूप से जमे हुए टैब पर भरोसा करने के बजाय कार्यकर्ता से संबंधित त्रुटि की रिपोर्ट कर सकता है।
यह स्थानीय-प्रसंस्करण दावे को भी समझने योग्य रखता है। किसी एक्सटेंशन पृष्ठ से अपने स्वयं के कार्यकर्ता को पिक्सेल भेजना ब्राउज़र वातावरण के भीतर संचार है, न कि रिमोट कटआउट एपीआई पर अपलोड करना। पहले सत्र में पुन: प्रयोज्य मॉडल परिसंपत्ति को अलग से डाउनलोड किया जा सकता है; देखें किसी मॉडल को पहले डाउनलोड क्यों चलाएं।
कोई कार्यकर्ता तत्काल गणना नहीं करता
कर्मचारी प्रतिक्रियाशीलता में सुधार करते हैं, न कि कच्ची डिवाइस क्षमता में। ब्राउज़र जो प्रदान कर सकता है उसके अनुसार मॉडल अभी भी सीपीयू, जीपीयू, या अन्य रनटाइम संसाधनों का उपभोग करता है। एक बड़े इनपुट में अभी भी अधिक समय लग सकता है और छोटे इनपुट की तुलना में अधिक मेमोरी की आवश्यकता होती है।
कई सीमाएँ बनी हुई हैं:
- मॉडल आरंभीकरण की वास्तविक लागत होती है;
- कॉपी किए जाने पर पिक्सेल बफ़र्स दोनों तरफ मेमोरी पर कब्जा कर लेते हैं;
- आकार बदलने और प्रारूप रूपांतरण में समय लगता है;
- कम मेमोरी वाले उपकरण बड़ी छवियों के साथ संघर्ष कर सकते हैं;
- अधिक कर्मचारी विवाद को कम करने के बजाय बढ़ा सकते हैं;
- निर्यात और कैनवास अपडेट में अभी भी मुख्य थ्रेड शामिल हो सकता है।
पाँच छवियों के लिए पाँच अनुमान कार्यकर्ता शुरू करना स्वचालित रूप से पाँच गुना तेज़ नहीं है। कर्मचारी एक ही मशीन साझा करते हैं। समानांतर नौकरियां मेमोरी बैंडविड्थ और निष्पादन संसाधनों के लिए प्रतिस्पर्धा कर सकती हैं, जबकि प्रत्येक मॉडल इंस्टेंस की अपनी मेमोरी लागत हो सकती है।
प्रगति रिपोर्टिंग सहयोगात्मक है
एक कार्यकर्ता स्थिति संदेश भेज सकता है, लेकिन यह स्वचालित रूप से नहीं जानता कि कौन सा प्रगति प्रतिशत सटीक लगेगा। मॉडल डाउनलोड, रनटाइम इनिशियलाइज़ेशन, इनपुट तैयारी, अनुमान, मास्क रूपांतरण और पूर्वावलोकन रेंडरिंग अलग-अलग समय के साथ अलग-अलग चरण हैं।
कुछ चरणों में मापने योग्य बाइट गिनती होती है। एक एकल मॉडल निष्पादन केवल “प्रारंभ” और “समाप्त” को उजागर कर सकता है। इसलिए एक सहज प्रतिशत जो समान रूप से आगे बढ़ता है वह सटीक माप के बजाय कॉस्मेटिक हो सकता है।
उपयोगी प्रगति यूआई जब भी संभव हो चरण का नाम देता है: मॉडल तैयार करना, छवि संसाधित करना, या परिणाम बनाना। यह स्पिनर को बिना किसी स्पष्टीकरण के छोड़ने के बजाय विफलता और रद्दीकरण को भी संभालता है।
रद्दीकरण एक स्पिनर को छुपाने से कहीं अधिक है
यदि उपयोगकर्ता किसी छवि को बंद कर देता है या फिर से शुरू करता है, तो इंटरफ़ेस पुराने अनुरोध से अंतिम प्रतिक्रिया को अनदेखा कर सकता है। अंतर्निहित गणना को तुरंत रोकने के लिए रनटाइम से अतिरिक्त समर्थन की आवश्यकता हो सकती है या कार्यकर्ता को समाप्त करने और पुनः बनाने की आवश्यकता हो सकती है।
किसी कर्मचारी को समाप्त करना निर्णायक है, लेकिन यह उसकी आरंभिक स्थिति को त्याग देता है। अगले कार्य के लिए मॉडल को फिर से लोड और आरंभ करने की आवश्यकता हो सकती है। एक छोटे ऑपरेशन के लिए, परिणाम को पुराना चिह्नित करना हर चीज़ को नष्ट करने की तुलना में सस्ता हो सकता है।
सही विकल्प मेमोरी दबाव, संचालन अवधि और रनटाइम क्षमताओं पर निर्भर करता है। उपयोगकर्ता के दृष्टिकोण से, महत्वपूर्ण नियम यह है कि पुराने कार्य को वर्तमान संपादन के ऊपर नहीं लिखना चाहिए।
##त्रुटियों को भी सीमा लांघनी पड़ती है
किसी कार्यकर्ता के अंदर एक अपवाद सामान्य मुख्य-थ्रेड अपवाद नहीं बनता है। कार्यकर्ता को प्रयोग योग्य त्रुटियों की रिपोर्ट करनी चाहिए, और संपादक को कार्यकर्ता-स्तर की विफलताओं पर ध्यान देना चाहिए।
अच्छा त्रुटि प्रबंधन कम से कम अलग करता है:
- मॉडल परिसंपत्ति अनुपलब्ध;
- मॉडल आरंभीकरण विफल;
- छवि डिकोड या इनपुट तैयारी विफल;
- अनुमान विफल;
- कार्यकर्ता अप्रत्याशित रूप से रुक गया;
- परिणाम अब वर्तमान अनुरोध से संबंधित नहीं है।
यह सामान्य “कुछ गलत हो गया” की तुलना में अधिक कार्रवाई योग्य है, खासकर जब पहली बार सेटअप और सामान्य छवि प्रसंस्करण के अलग-अलग उपाय होते हैं।
कार्यकर्ता आउटपुट अभी भी केवल पहला मुखौटा है
थ्रेड आर्किटेक्चर अपने आप में एक अस्पष्ट किनारे में सुधार नहीं करता है। कार्यकर्ता तकनीकी रूप से मान्य मुखौटा लौटा सकता है जिसमें अभी भी फर, पारदर्शी सामग्री, संकीर्ण पट्टियाँ, या वांछित छाया नहीं है। वे विभाजन और आशय वाले प्रश्न हैं।
संपादक का काम अनुमान के बाद फिर से शुरू होता है: मास्क को कार्यशील समन्वय प्रणाली में स्केल करना, एक पूर्वावलोकन संकलित करना, उपयोगकर्ता को इसे परिष्कृत करने देना और वर्तमान स्थिति को निर्यात करना। मास्क रिज़ॉल्यूशन बनाम पूर्वावलोकन आकार बताता है कि उन समन्वय प्रणालियों को भ्रमित क्यों नहीं किया जाना चाहिए।
एक संक्षिप्त मानसिक मॉडल
संदेश विंडो के पीछे कार्यकर्ता को एक स्थानीय विशेषज्ञ के रूप में सोचें:
- संपादक बातचीत का मालिक है;
- कार्यकर्ता भारी अनुमान कार्य का मालिक है;
- बाइनरी छवि डेटा एक परिभाषित सीमा को पार करता है;
- कार्यकर्ता एक मुखौटा लौटाता है, हर किनारे के बारे में पूर्ण निर्णय नहीं;
- संपादक वर्तमान स्थिति, समीक्षा, परिशोधन और निर्यात के लिए जिम्मेदार रहता है।
पिक्सेल के मॉडल के दृश्य के लिए, ऑन-डिवाइस कटआउट मॉडल क्या देखता है के साथ जारी रखें। संपूर्ण व्यावहारिक अवलोकन के लिए, देखें स्थानीय पृष्ठभूमि हटाना कैसे काम करता है।