पायथन में छवियों के साथ काम करना

आज की बातचीत का विषय यह है कि छवियों के साथ काम करने में पायथन ने अपने अस्तित्व के सभी वर्षों में क्या सीखा है। दरअसल, 1990 ImageMagick और GraphicsMagick से पुराने के अलावा, आधुनिक प्रभावी पुस्तकालय हैं। उदाहरण के लिए, तकिया और अधिक उत्पादक तकिया-सिमडी। मॉस्कोपिथॉन में उनके सक्रिय डेवलपर अलेक्जेंडर कारपिन्स्की ( हॉम ) ने पायथन में छवियों के साथ काम करने के लिए अलग-अलग पुस्तकालयों की तुलना की, बेंचमार्क प्रस्तुत किया और गैर-स्पष्ट विशेषताओं के बारे में बात की जो हमेशा पर्याप्त होती हैं। इस लेख में, रिपोर्ट की एक प्रतिलिपि आपको अपने आवेदन के लिए एक पुस्तकालय चुनने में मदद करेगी, और इसे यथासंभव कुशलता से काम करेगी।


स्पीकर के बारे में: अलेक्जेंडर कारपिन्स्की अपलोडकेयर में काम करता है और मक्खी पर त्वरित छवि संशोधन की सेवा में लगा हुआ है। वह पाइलोन में छवियों के साथ काम करने के लिए एक लोकप्रिय पुस्तकालय पिलो के विकास में शामिल है, और इस पुस्तकालय, पिलो-सिमडी के अपने स्वयं के कांटा विकसित कर रहा है , जो अधिकतम प्रदर्शन के लिए आधुनिक प्रोसेसर निर्देशों का उपयोग करता है।

पृष्ठभूमि

Uploadcare की छवि संशोधन सेवा एक सर्वर है जो एक छवि पहचानकर्ता और कुछ ऑपरेशनों के साथ एक HTTP अनुरोध प्राप्त करता है जो क्लाइंट को निष्पादित करने की आवश्यकता होती है। सर्वर को संचालन पूरा करना चाहिए और जितनी जल्दी हो सके जवाब देना चाहिए। क्लाइंट अक्सर एक ब्राउज़र के रूप में कार्य करता है।

पूरी सेवा को ग्राफिक्स लाइब्रेरी के आसपास एक आवरण के रूप में वर्णित किया जा सकता है। पूरे प्रोजेक्ट की गुणवत्ता ग्राफिक्स लाइब्रेरी की गुणवत्ता, प्रदर्शन और प्रयोज्य पर निर्भर करती है। यह अनुमान लगाना आसान है कि अपलोडकेयर पिलो को ग्राफिक्स लाइब्रेरी के रूप में उपयोग करता है।

पुस्तकालयों

हम संक्षेप में इस बात की समीक्षा करेंगे कि पायथन में किस तरह के ग्राफिक्स पुस्तकालय सामान्य रूप से बेहतर हैं, यह समझने के लिए कि बाद में क्या चर्चा की जाएगी।

तकिया

तकिया - पीआईएल (पायथन इमेजिंग लाइब्रेरी) का कांटा। यह एक बहुत पुरानी परियोजना है, जिसे 1995 में पायथन 1.2 के लिए जारी किया गया था। आप कल्पना कर सकते हैं कि वह कितने साल का है! कुछ बिंदु पर, पायथन इमेजिंग लाइब्रेरी को छोड़ दिया गया और इसका विकास रुक गया। पिलो का एक कांटा आधुनिक सिस्टम पर पायथन इमेजिंग लाइब्रेरी को स्थापित करने और बनाने के लिए बनाया गया था। धीरे-धीरे, पायथन इमेजिंग लाइब्रेरी में लोगों को जितने बदलावों की ज़रूरत पड़ी, और पिलो 2.0 बाहर आया, जिसने पायथन 3 के लिए समर्थन जोड़ा। इसे पिलो प्रोजेक्ट के एक अलग जीवन की शुरुआत माना जा सकता है।

तकिया पायथन के लिए एक देशी मॉड्यूल है, आधा कोड सी में लिखा है, आधा पायथन में। पायथन के सबसे विविध संस्करणों का समर्थन किया जाता है: 2.7, 3.3+, पेप, ।

तकिया-SIMD

यह मेरा तकिया का कांटा है, जो मई 2016 में सामने आता है। SIMD का अर्थ सिंगल इंस्ट्रक्शन, मल्टीपल डेटा है   - एक दृष्टिकोण जिसमें प्रोसेसर आधुनिक निर्देशों का उपयोग करके प्रति चक्र बड़ी संख्या में कार्य कर सकता है।

जब कोई प्रोजेक्ट अपना जीवन जीना शुरू करता है, तो पिलो-सिमडी शास्त्रीय अर्थों में एक कांटा नहीं है। यह पिलो के लिए एक प्रतिस्थापन है, अर्थात, आप एक पुस्तकालय को दूसरे के बजाय स्थापित करते हैं, अपने स्रोत कोड में एक पंक्ति नहीं बदलते हैं, और अधिक प्रदर्शन करते हैं।

तकिया-सिम को एसएसई 4 निर्देशों (डिफ़ॉल्ट) के साथ इकट्ठा किया जा सकता है। यह निर्देशों का एक सेट है जो लगभग सभी आधुनिक x86 प्रोसेसर में पाया जाता है। पिलो-सिमडी को एवीएक्स 2 निर्देश सेट के साथ भी इकट्ठा किया जा सकता है। निर्देशों का यह सेट है, हवेलवेल वास्तुकला से शुरू होता है, जो कि लगभग 2013 से है।

OpenCV

पायथन में छवियों के साथ काम करने के लिए एक और पुस्तकालय, जिसके बारे में आपने शायद सुना है ओपनसीवी (ओपन कंप्यूटर विजन)। यह 2000 से काम कर रहा है। पायथन बाइंडिंग शामिल है। इसका मतलब है कि बाध्यकारी लगातार प्रासंगिक है, पुस्तकालय और बाध्यकारी के बीच कोई समानता नहीं है।

दुर्भाग्यवश, यह लाइब्रेरी अभी तक PyPy में समर्थित नहीं है, क्योंकि OpenCV, खस्ता पर आधारित है, और numpy केवल हाल ही में PyPy के तहत काम करना शुरू किया है, और OpenCV में PyPy अभी भी समर्थित नहीं है।

VIPS

VIPS पर ध्यान देने लायक एक और लाइब्रेरी है। VIPS का मुख्य विचार यह है कि आपको छवि के साथ काम करने के लिए पूरी छवि को मेमोरी में लोड करने की आवश्यकता नहीं है। पुस्तकालय कुछ छोटे टुकड़ों को लोड कर सकते हैं, उन्हें संसाधित कर सकते हैं और सहेज सकते हैं। इस प्रकार, गीगापिक्सल छवियों को संसाधित करने के लिए, आपको गीगाबाइट मेमोरी को खर्च करने की आवश्यकता नहीं है।

यह एक पुरानी लाइब्रेरी है - 1993, लेकिन यह अपने समय से आगे निकल गया। लंबे समय तक इसके बारे में बहुत कम सुना गया था, लेकिन हाल ही में VIPS के लिए विभिन्न भाषाओं के लिए बाइंडर्स दिखाई देने लगे, जिनमें Go, Node.js, Ruby शामिल हैं।

लंबे समय से मैं इस लाइब्रेरी को आज़माना चाहता था, इसे महसूस करने के लिए, लेकिन मैं बहुत मूर्खतापूर्ण कारण से सफल नहीं हुआ। मैं यह पता नहीं लगा सका कि वीआईपीएस को कैसे स्थापित किया जाए, क्योंकि बाध्यकारी बहुत जटिल था। लेकिन अब (2017 में) पीवाईपीएस बाइंडिंग को वीआईपीएस के लेखक से ही जारी किया गया था, जिसके साथ अब कोई समस्या नहीं है। VIPS इंस्टॉल करना और उपयोग करना अब बहुत आसान है। समर्थित: पायथन 2.7, 3.3+, RuPu, RuPuZ।

ImageMagick & GraphicsMagick

यदि हम ग्राफिक्स के साथ काम करने के बारे में बात करते हैं, तो हम मदद नहीं कर सकते हैं लेकिन पुराने लोगों का उल्लेख कर सकते हैं - ImageMagick और GraphicsMagick पुस्तकालयों। उत्तरार्द्ध मूल रूप से अधिक प्रदर्शन के साथ ImageMagick का एक कांटा था, लेकिन अब उनका प्रदर्शन बराबर लगता है। जहां तक ​​मुझे पता है, उनके बीच कोई अन्य मूलभूत अंतर नहीं हैं। इसलिए, आप किसी भी, अधिक सटीक रूप से उपयोग कर सकते हैं, वह जिसे आप उपयोग करना पसंद करते हैं।

ये सबसे पुराने पुस्तकालय हैं जिनका मैंने आज (1990) उल्लेख किया है। इस समय के दौरान, पायथन के लिए कई बांध थे, और उनमें से लगभग सभी अब तक सुरक्षित रूप से मर चुके हैं। जो उपयोग किए जा सकते हैं, उनमें से हैं:

• छड़ी बंधन, जो ctypes पर बनाया गया है, लेकिन अब भी अपडेट नहीं किया गया है।
• पैगमैगिक बाइंडिंग Boost.Python का उपयोग करता है, इसलिए यह बहुत लंबे समय तक संकलन करता है और PyPy में काम नहीं करता है। लेकिन, फिर भी, आप इसका उपयोग कर सकते हैं, मैं कहूंगा कि यह वैंड के लिए बेहतर है।

उत्पादकता

जब हम छवियों के साथ काम करने के बारे में बात करते हैं, तो पहली चीज जो हमें दिलचस्पी देती है (कम से कम मेरे लिए) प्रदर्शन है, क्योंकि अन्यथा हम अपने हाथों से अजगर में कुछ लिख सकते हैं।

प्रदर्शन इतनी सरल बात नहीं है। आप बस यह नहीं कह सकते कि एक पुस्तकालय दूसरे की तुलना में तेज़ है। प्रत्येक लाइब्रेरी में फ़ंक्शन का एक सेट होता है, और प्रत्येक फ़ंक्शन एक अलग गति से काम करता है।

तदनुसार, केवल यह कहना सही है कि किसी विशेष लाइब्रेरी में एक फ़ंक्शन का प्रदर्शन अधिक या कम है। या आपके पास एक एप्लिकेशन है जिसे कार्यक्षमता के एक निश्चित सेट की आवश्यकता है, और आप इस कार्यक्षमता के लिए विशेष रूप से एक बेंचमार्क बनाते हैं, और कहते हैं कि इस तरह की लाइब्रेरी आपके आवेदन के लिए तेजी से (धीमी) काम करती है।

परिणाम की जांच करना महत्वपूर्ण है।

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

हाल ही में, पिलो और ओपनसीवी के प्रदर्शन की तुलना करते हुए एक लेख में, मैं इस कोड में आया हूं:

from PIL import Image, ImageFilter.BoxBlur im.filter(ImageFilter.BoxBlur(3)) ... import cv2 cv2.blur(im, ksize=(3, 3)) ... 

यह वहाँ लगता है, और वहाँ, BoxBlur, और वहाँ, और वहाँ, तर्क 3, लेकिन वास्तव में परिणाम अलग है। क्योंकि पिलो (3) में यह धब्बा त्रिज्या है, और OpenCV में ksize = (3, 3) कर्नेल आकार है, अर्थात मोटे तौर पर, व्यास। इस स्थिति में, OpenCV का सही मान 3 * 2 + 1, अर्थात (7, 7) होगा।

क्या समस्या है?

ग्राफिक्स के साथ काम करते समय प्रदर्शन आम तौर पर एक समस्या क्यों है? क्योंकि किसी भी ऑपरेशन की जटिलता कई मापदंडों पर निर्भर करती है, और सबसे अक्सर जटिलता उनमें से प्रत्येक के साथ रैखिक रूप से बढ़ती है। और अगर, उदाहरण के लिए, इनमें से तीन कारक हैं, और जटिलता रैखिक प्रत्येक पर निर्भर करती है, तो क्यूब में जटिलता प्राप्त होती है।

उदाहरण: ओपनसीवी में गाऊसी धब्बा।



बाईं ओर 3 का त्रिज्या है, दाईं ओर 30 है। जैसा कि आप देख सकते हैं, गति में अंतर 10 गुना से अधिक है।

जब मैंने अपने आवेदन में गाऊसी कलंक को जोड़ने के कार्य का सामना किया, तो मुझे खुशी नहीं हुई कि, काल्पनिक रूप से, एक ऑपरेशन में 900 एमएस खर्च किए जा सकते हैं। आवेदन में प्रति मिनट हजारों ऐसे ऑपरेशन हैं, और एक पर इतना समय खर्च करना अव्यावहारिक है। इसलिए, मैंने इस मुद्दे का अध्ययन किया और तकिया में गाऊसी धब्बा लागू किया, जो त्रिज्या के सापेक्ष निरंतर समय में काम करता है। यही है, केवल छवि का आकार गाऊसी धब्बा के प्रदर्शन को प्रभावित करता है।

लेकिन यहां मुख्य बात यह नहीं है कि कुछ तेजी से या धीमी गति से काम करता है।

मैं यह बताना चाहता हूं कि जब आप किसी तरह का सिस्टम बना रहे हैं, तो यह समझना जरूरी है कि आउटपुट की जटिलता किन मापदंडों पर निर्भर करती है। फिर आप इस जटिलता से निपटने के लिए इन मापदंडों या अन्य तरीकों से सीमित कर सकते हैं।

संभवतः सबसे आम ऑपरेशन हम छवियों के साथ करते हैं, जिसके बाद वे खोले जाते हैं।



ग्राफ 8 और 1.25 गुना कम करके छवि के संचालन के लिए विभिन्न पुस्तकालयों के प्रदर्शन (अधिक बेहतर) को दर्शाता है।

PIL के लिए, 17 Mpx / s के परिणाम का अर्थ है कि एक iPhone (12 Mpx) से फोटो को एक सेकंड से भी कम समय में 1.25 गुना कम किया जा सकता है। इस तरह का प्रदर्शन एक गंभीर अनुप्रयोग के लिए पर्याप्त नहीं है जो इन कार्यों का एक बहुत कुछ करता है।

मैंने रिसाइज़ के प्रदर्शन को अनुकूलित करना शुरू कर दिया, और पिलो 2.7 में मैं उत्पादकता में एक दो गुना वृद्धि हासिल करने में कामयाब रहा, और पिल्लो 4.3 में - तीन गुना (पिल्लो 5.3 का संस्करण वर्तमान में प्रासंगिक है, लेकिन इसमें आकार का प्रदर्शन समान है)।

लेकिन रिसाइज़ ऑपरेशन एक ऐसी चीज़ है जो SIMD पर बहुत अच्छी तरह से फिट बैठता है। यह एकल निर्देश, कई डेटा तक पहुंचता है, और इसलिए, पिलो-सिमडी के वर्तमान संस्करण में, मैं समान संसाधनों का उपयोग करके मूल पायथन इमेजिंग लाइब्रेरी की तुलना में रिसाइज़ गति को 19 गुना बढ़ाने में सक्षम था।

यह OpenCV आकार के प्रदर्शन से काफी अधिक है। लेकिन तुलना पूरी तरह से सही नहीं है, क्योंकि OpenCV एक बॉक्स फ़िल्टर के साथ आकार बदलने की थोड़ी कम गुणवत्ता वाली विधि का उपयोग करता है, और तकिया-सिमडी में, आकार परिवर्तन का उपयोग करके कार्यान्वित किया जाता है।

यह उन ऑपरेशनों की एक अपूर्ण सूची है जो नियमित तकिया की तुलना में तकिया-सिमडी में त्वरित हैं।

• आकार: 4 से 7 बार।
• धुंधला: 2.8 बार।
• कोर 3 × 3 या 5 × 5: 11 बार का अनुप्रयोग।
• अल्फा चैनल द्वारा गुणन और विभाजन: 4 और 10 बार।
• अल्फा रचना: 5 बार।

मैंने पहले ही कहा है कि कोई यह नहीं कह सकता है कि कुछ पुस्तकालय दूसरे की तुलना में तेजी से काम करते हैं, लेकिन आप कुछ ऐसे कार्यों का समूह बना सकते हैं जो आपके लिए हितकारी हों। मैंने ऐसे ऑपरेशन का एक सेट चुना जो मेरे आवेदन में दिलचस्प हैं, एक बेंचमार्क बनाया और ऐसे परिणाम प्राप्त किए।



यह पता चला कि इस सेट पर पिलो-सिमडी पिलो की तुलना में 2 गुना तेज काम करता है। बहुत अंत में वैंड है (याद रखें कि यह इमेजमैजिक है)।

लेकिन मुझे कुछ और में दिलचस्पी थी - ओपनसीवी और वीआईपीएस परिणाम में इतने खराब क्यों हैं, क्योंकि ये पुस्तकालय हैं जो प्रदर्शन के लिए भी डिज़ाइन किए गए हैं? यह पता चला कि ओपनसीवी के मामले में, पाइप का उपयोग करके स्थापित बाइनरी ओपनसीवी विधानसभा को धीमी जेपीईजी कोडेक के साथ इकट्ठा किया गया था (विधानसभा के लेखक को सूचित किया गया था, यह समस्या 2018 के लिए पहले ही हल हो गई है)। यह libjpeg के साथ बनाया गया है, जबकि अधिकांश सिस्टम, कम से कम डेबियन-आधारित, libjpeg-टर्बो का उपयोग करते हैं, जो कि कई गुना तेज है। यदि आप स्वयं स्रोत से OpenCV का निर्माण करते हैं, तो प्रदर्शन अधिक होगा।

VIPS के मामले में, स्थिति अलग है। मैंने VIPS के लेखक से संपर्क किया, उसे यह मानदंड दिखाया, और हमने लंबे समय तक और फलदायी रूप से पत्र-व्यवहार किया। उसके बाद, VIPS के लेखक ने VIPS में ही कई जगह पाए, जहाँ निष्पादन इष्टतम मार्ग पर नहीं था, और उन्हें सही किया।

यदि आप वर्तमान संस्करण के स्रोतों से OpenCV का निर्माण करते हैं, और मास्टर से VIPS, जो पहले से ही है, प्रदर्शन का क्या होगा।

यहां तक ​​कि अगर आपको किसी प्रकार का मानदंड मिलता है, तो यह एक तथ्य नहीं है कि सब कुछ इस गति के साथ आपके मशीन पर बिल्कुल काम करेगा।

बेंचमार्क का सेट

मेरे द्वारा बात किए गए सभी बेंचमार्क परिणाम पृष्ठ पर पाए जा सकते हैं। यह एक अलग मिनी-प्रोजेक्ट है जहां मैं बेंचमार्क लिखता हूं कि मुझे खुद पिलो-सिमडी को विकसित करने, उन्हें चलाने और परिणाम पोस्ट करने की आवश्यकता है।

GitHub के पास टेस्टिंग फ्रेमवर्क वाली एक परियोजना है जहां हर कोई अपने स्वयं के बेंचमार्क की पेशकश कर सकता है या मौजूदा लोगों को ठीक कर सकता है।

समानांतर काम

अब तक मैं शुद्ध प्रदर्शन के बारे में बात कर रहा हूं, जो कि एकल प्रोसेसर कोर पर है। लेकिन हम सभी लंबे समय से अधिक कोर के साथ सिस्टम तक पहुंच रखते हैं, और मैं उन्हें निपटाना चाहूंगा। यहाँ मुझे यह कहना है कि वास्तव में पिलो सभी का एकमात्र पुस्तकालय है जो कार्य समानांतर का उपयोग नहीं करता है। मैं यह समझाने की कोशिश करूंगा कि ऐसा क्यों होता है। एक या दूसरे रूप में अन्य सभी पुस्तकालय इसका उपयोग करते हैं।

प्रदर्शन मेट्रिक्स

प्रदर्शन के मामले में, हम 2 मापदंडों में रुचि रखते हैं:

1. एक ऑपरेशन के निष्पादन का वास्तविक समय। एक ऑपरेशन (या संचालन का एक क्रम) है, और आप सोच रहे हैं कि इस अनुक्रम को किस वास्तविक समय (दीवार घड़ी) पर निष्पादित किया जाएगा। यह पैरामीटर डेस्कटॉप पर महत्वपूर्ण है, जहां एक उपयोगकर्ता है जिसने कमांड दिया है और परिणाम की प्रतीक्षा कर रहा है।
   
2. पूरे सिस्टम (वर्कफ़्लो) के माध्यम से। जब आपके पास ऑपरेशन का एक सेट है जो चल रहा है, या कई स्वतंत्र संचालन हैं, और आपके हार्डवेयर पर इन ऑपरेशनों को संसाधित करने की गति आपके लिए महत्वपूर्ण है। यह मीट्रिक एक सर्वर पर अधिक महत्वपूर्ण है जहां कई क्लाइंट हैं, और आपको उन सभी की सेवा करने की आवश्यकता है। एक ग्राहक की सेवा में लगने वाला समय महत्वपूर्ण है, लेकिन कुल बैंडविड्थ से थोड़ा कम है।
   

इन दो मैट्रिक्स के आधार पर, हम समानांतर संचालन के विभिन्न तरीकों पर विचार करते हैं।

समानांतर काम के तरीके

1. आवेदन स्तर पर , जब आप आवेदन स्तर पर तय करते हैं कि संचालन अलग-अलग थ्रेड्स में संसाधित होते हैं। उसी समय, एक ऑपरेशन का वास्तविक निष्पादन समय नहीं बदलता है, क्योंकि पहले की तरह, एक कोर संचालन के एक क्रम में लगा हुआ है। सिस्टम का थ्रूपुट कोर की संख्या के अनुपात में बढ़ता है, अर्थात बहुत अच्छा है।

2. ग्राफिक संचालन के स्तर पर - यह वही है जो वास्तव में ग्राफिक पुस्तकालयों के बहुमत में है। जब किसी ग्राफिक लाइब्रेरी को किसी प्रकार का ऑपरेशन प्राप्त होता है, तो यह आवश्यक संख्या में धागे का निर्माण करता है, एक ऑपरेशन को कई छोटे लोगों में विभाजित करता है, और उन्हें निष्पादित करता है। उसी समय, वास्तविक निष्पादन समय कम हो जाता है - एक ऑपरेशन तेज होता है। लेकिन थ्रूपुट कोर की संख्या के साथ रैखिक रूप से नहीं बढ़ता है । ऐसे ऑपरेशन हैं जो समानांतर नहीं हैं, और एक हड़ताली उदाहरण पीएनजी फाइलों का डिकोडिंग है - इसे किसी भी तरह से समानांतर नहीं किया जा सकता है। इसके अलावा, थ्रेड्स, विभाजन कार्यों को बनाने के लिए ओवरहेड है, जो बैंडविड्थ को रैखिक रूप से बढ़ने की अनुमति नहीं देता है।

3. प्रोसेसर कमांड और डेटा के स्तर पर । हम एक विशेष तरीके से डेटा तैयार करते हैं और विशेष कमांड का उपयोग करते हैं ताकि प्रोसेसर उनके साथ तेजी से काम कर सके। यह SIMD दृष्टिकोण है, जो वास्तव में, तकिया-सिमडी में उपयोग किया जाता है। रियल-टाइम रनटाइम कम हो रहा है, थ्रूपुट बढ़ रहा है - यह एक जीत-जीत विकल्प है ।

समानांतर काम को कैसे संयोजित किया जाए

यदि हम किसी तरह समानांतर काम को संयोजित करना चाहते हैं, तो SIMD एक ऑपरेशन के अंदर समानांतरकरण के साथ अच्छी तरह से काम करता है, और SIMD एक अनुप्रयोग के अंदर समानांतरकरण के साथ अच्छी तरह से काम करता है।

लेकिन आवेदन के अंदर और ऑपरेशन के अंदर समानांतर एक दूसरे के साथ संगत नहीं हैं। यदि आप ऐसा करने की कोशिश करते हैं, तो आपको दोनों दृष्टिकोणों से सहमति मिल जाएगी। ऑपरेशन का वास्तविक समय वही होगा जो एक कोर पर था, और सिस्टम का थ्रूपुट बढ़ जाएगा, लेकिन कोर की संख्या के संबंध में रैखिक रूप से नहीं।

बहु सूत्रण

यदि हम थ्रेड्स के बारे में बात कर रहे हैं, तो हम सभी पायथन में लिखते हैं और जानते हैं कि इसमें एक जीआईएल है जो दो थ्रेड्स को एक ही समय में चलने से रोकता है। पायथन एक सख्ती से एकल-पिरोया भाषा है।

बेशक, यह सच नहीं है, क्योंकि जीआईएल वास्तव में पायथन में दो थ्रेड को निष्पादित करने से रोकता है, और यदि कोड किसी अन्य भाषा में लिखा गया है और इसके संचालन के दौरान पायथन आंतरिक संरचनाओं का उपयोग नहीं करता है, तो यह कोड जीआईएल जारी कर सकता है और इस तरह दुभाषिया को मुक्त कर सकता है। अन्य कार्यों के लिए।

कई ग्राफिक्स लाइब्रेरी अपने काम के दौरान जीआईएल जारी करते हैं, जिसमें पिलो, ओपनसीवी, पाइविप्स, वैंड शामिल हैं। केवल एक pgmagick मुक्त नहीं करता है। यही है, आप कुछ संचालन करने के लिए सुरक्षित रूप से थ्रेड बना सकते हैं, और यह बाकी कोड के साथ समानांतर में काम करेगा।

लेकिन सवाल उठता है: कितने धागे बनाने के लिए?

यदि हम प्रत्येक कार्य के लिए अनंत संख्या में धागे बनाते हैं, तो वे बस सभी मेमोरी और पूरे प्रोसेसर को लेते हैं - हमें कोई प्रभावी काम नहीं मिलेगा। मैंने एक विशेष नियम तैयार किया।

नियम N + १

उत्पादक कार्य के लिए, आपको N + 1 श्रमिकों से अधिक नहीं बनाने की आवश्यकता है, जहां N मशीन पर कोर या प्रोसेसर थ्रेड्स की संख्या है, और कार्यकर्ता प्रसंस्करण में शामिल प्रक्रिया या धागा है।

प्रक्रियाओं का सबसे अच्छा उपयोग किया जाता है, क्योंकि एक ही दुभाषिया के भीतर भी अड़चनें और ओवरहेड हैं।

उदाहरण के लिए, हमारे आवेदन में, एन + 1 उदाहरण बवंडर का उपयोग किया जाता है, जिसके बीच का संतुलन नग्नेक्स द्वारा किया जाता है। यदि टॉर्नेडो का उल्लेख किया गया है, तो चलो अतुल्यकालिक ऑपरेशन के बारे में बात करते हैं।

अतुल्यकालिक ऑपरेशन

वह समय जो ग्राफिक लाइब्रेरी वास्तव में उपयोगी कार्य करता है - इमेज प्रोसेसिंग - और इसका उपयोग इनपुट / आउटपुट के लिए किया जाना चाहिए, यदि आपके पास उन्हें एप्लिकेशन में है। अतुल्यकालिक रूपरेखाएं यहां बहुत प्रासंगिक हैं।

लेकिन एक समस्या है - जब हम किसी प्रकार की प्रोसेसिंग कहते हैं, तो इसे सिंक्रोनाइज़ कहा जाता है। भले ही पुस्तकालय उस समय जीआईएल जारी करता है, लेकिन इवेंट लूप अभी भी अवरुद्ध है।

 @gen.coroutine def get(self, *args, **kwargs): im = process_image(...) ... 

सौभाग्य से, यह समस्या एक सिंगल थ्रेड के साथ एक थ्रेडपूल एक्ज़ीक्यूटर बनाकर हल करना बहुत आसान है, जिस पर इमेज प्रोसेसिंग शुरू होती है। यह कॉल पहले से ही एसिंक्रोनस रूप से हो रहा है।

 @run_on_executor(executor=ThreadPoolExecutor(1)) def process_image(self, ... @gen.coroutine def get(self, *args, **kwargs): im = yield process_image(...) ... 

संक्षेप में, एक कार्यकर्ता के साथ एक कतार यहां बनाई गई है जो ग्राफिकल ऑपरेशन करती है, और ईवेंट लूप अवरुद्ध नहीं है और चुपचाप दूसरे धागे में समानांतर में चलता है।

इनपुट / आउटपुट

एक अन्य विषय जिसे मैं ग्राफिक ऑपरेशंस की चर्चा में छूना चाहूंगा वह है इनपुट / आउटपुट। तथ्य यह है कि हम ग्राफिक्स लाइब्रेरी का उपयोग करके शायद ही कभी किसी प्रकार की छवि बनाते हैं। सबसे अधिक बार, हम उन छवियों को खोलते हैं जो हमारे पास एन्कोडेड फ़ाइलों (JPEG, PNG, BMP, TIFF, आदि) के रूप में उपयोगकर्ताओं से आई हैं।

तदनुसार, एक अच्छे अनुप्रयोग के निर्माण के लिए ग्राफिक्स लाइब्रेरी में फाइलों से इनपुट / आउटपुट के लिए कुछ अच्छाइयाँ होनी चाहिए।

आलसी लोडिंग

इस तरह का पहला बंज आलसी लोडिंग है। यदि, उदाहरण के लिए, तकिया में आप एक छवि खोलते हैं, तो इस समय छवि का डिकोडिंग नहीं होता है। आपको एक ऑब्जेक्ट के साथ लौटाया जाता है जो दिखता है जैसे कि छवि पहले से ही भरी हुई है और काम कर रही है। आप इसके गुणों को देख सकते हैं और इस छवि के गुणों के आधार पर निर्णय ले सकते हैं कि क्या आप इसके साथ आगे काम करने के लिए तैयार हैं, यदि उपयोगकर्ता ने डाउनलोड किया है, उदाहरण के लिए, आपकी सेवा को तोड़ने के लिए एक गीगापिक्सल चित्र।

 >>> from PIL import Image >>> %time im = Image.open() Wall time: 1.2 ms >>> im.mode, im.size ('RGB', (2152, 1345)) 

यदि आप तय करते हैं कि आगे क्या करना है, तो लोड करने के लिए स्पष्ट या अंतर्निहित कॉल का उपयोग करके, यह छवि डिकोड हो गई है। पहले से ही इस समय आवश्यक मात्रा में मेमोरी आवंटित की जाती है।

 >>> from PIL import Image >>> %time im = Image.open() Wall time: 1.2 ms >>> im.mode, im.size ('RGB', (2152, 1345)) >>> %time im.load() Wall time: 73.6 ms 

टूटी हुई तस्वीर मोड

उपयोगकर्ता द्वारा जेनरेट की गई सामग्री के साथ काम करने के दौरान दूसरे बान की जरूरत होती है जो टूटी हुई तस्वीर मोड है। उपयोगकर्ताओं से हमें प्राप्त होने वाली फ़ाइलों में अक्सर प्रारूप के साथ कुछ विसंगतियां होती हैं, जिसमें वे एन्कोडेड होते हैं।

ये विसंगतियां विभिन्न कारणों से होती हैं। कभी-कभी यह नेटवर्क पर एक संचरण त्रुटि है, कभी-कभी यह कुछ प्रकार के कुटिल कोडेक्स होते हैं जो छवि को एन्कोड करते हैं। डिफ़ॉल्ट रूप से, पिल्लो, जब यह उन छवियों को देखता है जो प्रारूप को अंत तक फिट नहीं करते हैं, तो बस एक अपवाद को फेंकता है।

 from PIL import Image Image.open('trucated.jpg').save('trucated.out.jpg') IOError: image file is truncated (143 bytes not processed) 

लेकिन उपयोगकर्ता इस तथ्य के लिए दोषी नहीं है कि उसकी तस्वीर टूट गई है, वह अभी भी परिणाम प्राप्त करना चाहता है। सौभाग्य से, पिलो में एक टूटी हुई तस्वीर मोड है। हम एक सेटिंग बदलते हैं, और पिलो अधिकतम सभी डिकोडिंग त्रुटियों को अनदेखा करने की कोशिश करता है जो छवि में हैं। तदनुसार, उपयोगकर्ता कम से कम कुछ देखता है।

 from PIL import Image, ImageFile ImageFile.LOAD_TRUNCATED_IMAGES = True Image.open('trucated.jpg').save('trucated.out.jpg') 

यहां तक ​​कि एक फसली तस्वीर अभी भी कुछ नहीं से बेहतर है - सिर्फ एक पृष्ठ जिसमें त्रुटि है।

सारांश तालिका

ऊपर दी गई तालिका में, मैंने उन पुस्तकालयों में इनपुट / आउटपुट से संबंधित सभी चीजें एकत्र की हैं, जिनके बारे में मैं बात कर रहा हूं। विशेष रूप से, मैंने विभिन्न प्रारूपों के कोडेक्स की गिनती की जो पुस्तकालयों में हैं। यह पता चला कि OpenCV में वे ImageMagick में सबसे कम, सबसे अधिक हैं। ऐसा लगता है कि ImageMagick में आप किसी भी छवि को खोल सकते हैं, जो आपके सामने आती है। VIPS में 12 देशी कोडेक्स हैं, लेकिन VIPS एक मध्यवर्ती के रूप में ImageMagick का उपयोग कर सकते हैं। मैंने परीक्षण नहीं किया है कि यह कैसे काम करता है, आशा है कि यह निर्बाध है।

तकिया में 17 कोडेक्स हैं। यह अब एकमात्र पुस्तकालय है जिसमें कोई EXIF ​​ऑटो-रोटेट नहीं है। लेकिन अब यह एक छोटी समस्या है, क्योंकि आप अपने आप को EXIF ​​पढ़ सकते हैं और उसके अनुसार छवि को घुमा सकते हैं। यह एक छोटे स्निपेट का सवाल है, जो आसानी से Google है और अधिकतम 20 लाइनें लेता है।

OpenCV की विशेषताएं

यदि आप इस तालिका को ध्यान से देखते हैं, तो आप देख सकते हैं कि OpenCV में, वास्तव में, इनपुट / आउटपुट के साथ सब कुछ इतना अच्छा नहीं है। इसमें कम से कम कोडेक्स, कोई आलसी लोडिंग नहीं है, और आप EXIF ​​और रंग प्रोफ़ाइल नहीं पढ़ सकते हैं।

लेकिन यह सब नहीं है। वास्तव में, OpenCV में अधिक विशेषताएं हैं। जब हम बस एक तस्वीर खोलते हैं, तो cv2.imread(filename) कॉल JPEG फ़ाइलों को EXIF ​​(तालिका देखें) के अनुसार घुमाता है, लेकिन PNG फ़ाइलों के अल्फा चैनल को अनदेखा करता है - बल्कि एक अजीब व्यवहार!

सौभाग्य से, OpenCV का एक ध्वज है: cv2.imread(filename, flags=cv2.IMREAD_UNCHANGED) ।

यदि आप IMREAD_UNCHANGED ध्वज निर्दिष्ट करते हैं, तो OpenCV PNG फ़ाइलों के लिए अल्फा चैनल को छोड़ देता है, लेकिन EXIF ​​के अनुसार JPEG फ़ाइलों को बदलना बंद कर देता है। यही है, एक ही ध्वज दो अलग-अलग गुणों को प्रभावित करता है। जैसा कि तालिका से देखा जा सकता है, ओपनसीवी में EXIF ​​पढ़ने की क्षमता नहीं है, और यह पता चलता है कि इस ध्वज के मामले में JPEG को घुमाना बिल्कुल भी असंभव है।

क्या होगा यदि आप पहले से नहीं जानते हैं कि आपकी छवि किस प्रारूप की है और आपको जेपीईजी के लिए पीएनजी और ऑटो-रोटेट दोनों के लिए अल्फा चैनल की आवश्यकता है? ऐसा करने के लिए कुछ भी नहीं - OpenCV उस तरह काम नहीं करता है।

OpenCV के कारण इस तरह की समस्याएं इस पुस्तकालय के नाम पर हैं। इसमें कंप्यूटर दृष्टि और छवि विश्लेषण के लिए बहुत अधिक कार्यक्षमता है। वास्तव में, OpenCV को सत्यापित स्रोतों के साथ काम करने के लिए डिज़ाइन किया गया है। यह, उदाहरण के लिए, एक बाहरी निगरानी कैमरा है जो एक सेकंड में एक बार छवियों को हटाता है और 5 साल तक एक ही प्रारूप और एक ही रिज़ॉल्यूशन में ऐसा करता है। I / O समस्या में परिवर्तनशीलता की कोई आवश्यकता नहीं है।

OpenCV कार्यक्षमता की आवश्यकता वाले लोगों को वास्तव में उपयोगकर्ता सामग्री कार्यक्षमता की आवश्यकता नहीं है।

लेकिन क्या होगा यदि आपके एप्लिकेशन को अभी भी उपयोगकर्ता सामग्री के साथ काम करने के लिए कार्यक्षमता की आवश्यकता है, और उसी समय आपको प्रसंस्करण और आंकड़ों के लिए OpenCV की सभी शक्ति की आवश्यकता है?



इसका समाधान पुस्तकालयों को संयोजित करना है। तथ्य यह है कि ओपनसीवी को खसखस ​​के आधार पर बनाया गया है, और पिलो में पिलो से एक खस्ता सरणी में छवियों को निर्यात करने के सभी साधन हैं। यही है, हम संख्यात्मक सरणी का निर्यात करते हैं, और ओपनसीवी इस छवि के साथ काम करना जारी रख सकता है, जैसा कि अपने स्वयं के साथ। यह बहुत आसानी से किया जाता है:

 import numpy from PIL import Image ... pillow_image = Image.open(filename) cv_image = numpy.array(pillow_image) 

इसके अलावा, जब हम OpenCV (प्रसंस्करण) का उपयोग करके जादू करते हैं, तो हम एक और तकिया विधि कहते हैं और OpenCV से छवि को वापस तकिया प्रारूप में आयात करते हैं। तदनुसार, I / O का फिर से उपयोग किया जा सकता है।

 import numpy from PIL import Image ... pillow_image = Image.fromarray(cv_image, "RGB") pillow_image.save(filename) 

इस प्रकार, यह पता चला है कि हम तकिया से इनपुट / आउटपुट का उपयोग करते हैं, और ओपनसीवी से प्रसंस्करण करते हैं, अर्थात, हम दो दुनियाओं में से सबसे अच्छा लेते हैं।

आशा है कि यह आपको एक लोडेड ग्राफिक्स एप्लिकेशन बनाने में मदद करता है।

आप पायथन में कुछ अन्य विकास रहस्य सीख सकते हैं, अमूल्य और कभी-कभी अप्रत्याशित अनुभव से सीख सकते हैं, और सबसे महत्वपूर्ण बात यह है कि आप अपने कार्यों पर बहुत जल्द मॉस्को पायथन कॉन्फ ++ में चर्चा कर सकते हैं। उदाहरण के लिए, शेड्यूल में ऐसे नामों और विषयों पर ध्यान दें।

• डोनाल्ड व्हाईट एक कहानी के साथ कि लोकप्रिय पुस्तकालयों, चाल और चालाक का उपयोग करके गणित को 10 गुना तेज कैसे बनाया जाए, और कोड समझ और समर्थित है।
• आंद्रेई पोपोव भारी मात्रा में डेटा एकत्र करने और उन्हें खतरों के लिए विश्लेषण करने के बारे में है।
• एफ्रिम माटोसियन ने अपनी रिपोर्ट में "पायथन को फिर से तेज करें" आपको बताएगा कि बस से संदेशों को संसाधित करने वाले डेमन के प्रदर्शन को कैसे बढ़ाया जाए।

22 और 23 अक्टूबर को यहां क्या चर्चा होगी, इसकी पूरी सूची में शामिल होने का समय है।