क्यों कंप्यूटर दृष्टि व्यवहार में बहुत कम प्रयोग किया जाता है

वास्तव में, "मशीन विजन" को कॉल करना अधिक सही होगा, लेकिन मुझे लगता है कि यह स्पष्ट होगा कि अगर कोई नहीं जानता है तो यह वीडियो निगरानी नहीं है, बल्कि कैमरों का उपयोग करके किसी चीज की मान्यता या माप है। ऐसे कई कार्य और क्षेत्र हैं जहाँ कंप्यूटर की दृष्टि बहुत लोकप्रिय होगी और इसका उपयोग हर जगह किया जा सकता है, लेकिन व्यवहार में इसका उपयोग बहुत ही कम किया जाता है।

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

क्षेत्र की गणना का कार्य जटिल लग सकता है। यदि आप सख्ती से गणितीय रूप से दृष्टिकोण करते हैं, तो हाँ, उदाहरण के लिए, एक वर्ग या आयत के क्षेत्र की गणना करना चौड़ाई से लंबाई को गुणा करना बहुत आसान है और यह तैयार है यदि त्रिकोण थोड़ा अधिक जटिल है, लेकिन अन्य घुंघराले आकार बहुत मुश्किल हो सकते हैं।
मेरा क्षेत्र गणना एल्गोरिथ्म इतना सरल है कि इसे बिना किसी पुस्तकालय आदि के लागू किया जा सकता है। वस्तुतः कोड की दस लाइनें, वास्तव में यह केवल कैमरा अंशांकन के साथ सबसे सरल गति डिटेक्टर है। कैमरा कठोरता से उस जगह से ऊपर तय किया जाता है जहां उत्पादों की आपूर्ति की जाती है, एक पृष्ठभूमि चित्र लिया जाता है (उत्पादन के बिना), उदाहरण के लिए, एक सफेद तालिका, पिक्सल के रंग एक सरणी में संचालित होते हैं। अगला, एक नमूना परोसा जाता है या मेज पर रखा जाता है, उदाहरण के लिए किसी प्रकार का बॉक्स। अगला, एक बॉक्स के साथ एक दूसरा शॉट लिया जाता है, दूसरे फ्रेम के रंगों को दूसरे सरणी में लिखा जाता है और फिर रंग मूल्यों की तुलना की जाती है, विभिन्न पिक्सेल की संख्या को जोड़ा जाता है। फिर इस नमूने को एक टेप उपाय के साथ मापा जाता है, इसका क्षेत्र कार्यक्रम में दर्ज किया जाता है, और एक पिक्सेल के क्षेत्र की गणना की जाती है, अर्थात। क्षेत्र को पिक्सेल की संख्या से विभाजित किया गया है। वह पूरा अंशांकन है। इसके अलावा, यह किसी भी आकार और आकार के किसी भी उत्पाद को प्रस्तुत करने के लिए पर्याप्त है, बदले हुए पिक्सेल की संख्या निर्धारित की जाती है, और अंशांकन के दौरान पाए जाने वाले एक पिक्सेल के क्षेत्र से गुणा किया जाता है, मुझे उम्मीद है कि सब कुछ स्पष्ट है। इसके अलावा, उत्पाद स्थानांतरित कर सकते हैं, उदाहरण के लिए, एक कन्वेयर पर, क्षेत्र को सही ढंग से मापा जाएगा, आपको केवल हथियाने की आवश्यकता है आंदोलन के लिए फ़्रेम को कैलिब्रेट करें, अर्थात। कई फ़्रेमों को छोड़ दें, जिसमें आंदोलन की दिशा में कैमरे के किनारों के साथ पिक्सेल परिवर्तन होते हैं, ताकि फ्रेम में प्रवेश करने और छोड़ने पर उत्पादों पर कब्जा न हो।

यह एल्गोरिदम 100% काम कर रहा है और अभ्यास में परीक्षण किया गया है। बेशक, कई बिंदु हैं जैसे कि ऑप्टिकल शोर, प्रकाश व्यवस्था आदि को फ़िल्टर करना, जो माप की त्रुटि को दृढ़ता से प्रभावित करता है, लेकिन यह सब सफलतापूर्वक प्रोग्रामेटिक रूप से हल किया जाता है (रंग गुणांक, आदि का ऑटो-करेक्शन) और हार्डवेयर - जो तुरंत शारीरिक रूप से फ़िल्टर कर सकते हैं। उत्पादन स्थितियों के तहत, स्थिर प्रकाश आसानी से बंद हिस्से में महसूस किया जाता है जहां कैमरा स्थापित किया गया है।
व्यवहार में, स्टेशनरी उत्पादों के लिए त्रुटि 1% से कम है और मोबाइल उत्पादों के लिए 3% तक है।

कई घटनाक्रम हैं, उदाहरण के लिए, ओपन सीवी ( ओपन कंप्यूटर विज़न ), वैसे, हैबे पर इस पुस्तकालय के इतिहास के बारे में एक पोस्ट है , छवियों, संख्याओं, चेहरों आदि के लिए कई मान्यता प्रणालियां हैं, यह सब तैयार है और इसका उपयोग किया जा सकता है।
लेकिन व्यवहार में, बहुत कम कंप्यूटर दृष्टि समाधान का उपयोग किया जाता है। लेकिन जो सबसे दिलचस्प है वह यह है कि इन सभी कार्यों को अलग-अलग, लेकिन बहुत अलग तरीकों से हल किया जाता है, अन्य उपकरणों का उपयोग करना, और बहुत अधिक महंगा। गिनती के लिए इस उपकरण की विफलता, मरम्मत की लागत, या नए लोगों के अधिग्रहण के कारण मैंने जिन प्रणालियों को पेश किया उनमें से अधिकांश को उद्यमों में स्थापित किया गया था। मैंने इस उपकरण को कार्रवाई में नहीं देखा, मैंने केवल सेंसर, यांत्रिकी, इलेक्ट्रॉनिक्स, आदि की संख्या देखी। ग्राहकों की समीक्षाओं के अनुसार, पुरानी प्रणालियों ने बदतर, धीमी और कुछ बड़ी त्रुटि के साथ भी काम किया। इसके अलावा, USD में कम से कम 4 शून्य वाले ऐसे उपकरणों की लागत, इस तथ्य के बावजूद कि "कंप्यूटर विज़न" वाली प्रणाली बहुत सस्ती है, और सब कुछ पूरी तरह से $ 1000 से कम के कंप्यूटर, कैमरा और सॉफ़्टवेयर के साथ खर्च होता है, तो आप $ 500 से भी निवेश कर सकते हैं। एक तैयार समाधान है। एक बड़ी कंप्यूटर शक्ति की आवश्यकता नहीं है, यह सबसे सस्ती नेटबुक पर भी बिना ब्रेक के काम करेगा। क्षेत्र के अलावा, आप उत्पादों के रंग, सतह दोष, विवाह / लड़ाई और बहुत कुछ निर्धारित कर सकते हैं।

हाल ही में मैंने प्रोग्रामिंग दृष्टिकोण और विशेष रूप से सॉफ्टवेयर समाधान डिजाइन करने के बारे में हैबे पर " क्रच प्रोग्रामर " पढ़ा, और मैं इस उदाहरण का उपयोग किसी अन्य टीम द्वारा इसी तरह की परियोजना को लागू करने के दौरान क्रच के बारे में बात करने के लिए करना चाहता हूं। मुझे इस टीम के प्रोग्रामरों के साथ बात करने का मौका मिला और मैंने वहां जो भी किया उसे देखकर मैं बहुत हैरान था। एल्गोरिदम का कड़ाई से गणितीय उपयोग किया जाता है, तीसरे पक्ष के पुस्तकालयों का एक समूह, उच्च गणित, सैकड़ों कक्षाओं के साथ ओओपी का उल्लेख नहीं करना आदि। आकार, निर्देशांक, स्थिति आदि के प्रकार को निर्धारित करने के लिए। वे OpenCV का उपयोग करते हैं (जो मैंने ऊपर लिखा था), और क्षेत्र की गणना जटिल सूत्रों द्वारा की जाती है, पक्षों, कोण, वक्रता, आदि के साथ। नतीजतन, उत्पाद बहुत टेढ़ा हो गया, इसके लिए बहुत अधिक कंप्यूटर शक्ति की आवश्यकता होती है और व्यवहार में, बहुत खराब तरीके से काम करता है, यह एक विशिष्ट प्रकार के उत्पाद के लिए लंबी और जटिल सेटिंग्स लेता है और बहुत कुछ त्रुटि का उल्लेख नहीं करता है जो 10% तक पहुंचता है। मैं वास्तव में OpenCV के बारे में बात नहीं करना चाहता, क्योंकि यह एक अलग मुद्दा है, मैं सिर्फ इतना कहूंगा कि कई चीजें वहां बहुत खराब थीं, कम से कम उन्होंने बुरी तरह से काम किया या बिल्कुल भी काम नहीं किया, यह लगभग 5 साल पहले था, जब यह अभी भी इंटेल का था, तो मुझे लगता है कि इंटेल ने इसे क्यों छोड़ दिया और इसे ओपन में गिरा दिया स्रोत। लेकिन जो बात मुझे सबसे ज्यादा अखरती थी, वह यह थी कि कुछ प्रोग्रामर इस विचार को भी अनुमति नहीं देते हैं कि समाधान ज्यादा सरल और अधिक विश्वसनीय हो सकता है। यह एक छोटी सी कंपनी थी, लेकिन कई प्रख्यात कंपनियां जो ऐसे प्रोग्रामर को रखती हैं, वे भी पाप करती हैं।

नतीजतन, कई परियोजनाएं अलग हो जाती हैं, समय को बाहर खींचती है और सबसे बुरी बात यह है कि यह कुटिल और छोटी गाड़ी उत्पादों को बदल देती है। और बहुत बार, खराब कोड या प्रोग्रामर के कारण नहीं, बल्कि खराब एल्गोरिदम और शुरुआत से ही डिजाइन करने के लिए एक खराब दृष्टिकोण के कारण।
मैंने इस उदाहरण को इस तथ्य के लिए प्रेरित किया है कि अब अधिक से अधिक प्रोग्रामर, सब कुछ सरल करने के बजाय, सब कुछ उलझा देते हैं, ओओपी का उपयोग करते हैं, डिज़ाइन, आदि जहां आम तौर पर किसी भी पक्ष की जरूरत नहीं होती है, और तब जब यह अभी भी है या बिल्कुल भी नहीं है। चमकीले सिर श्रेणियों, वस्तुओं और वर्गों से इतने अधिक भरे होते हैं कि कई लोग अब अलग तरह से नहीं सोच सकते हैं। अमूर्तता को जटिल करने की आवश्यकता नहीं है, लेकिन सिस्टम को सरल बनाने के लिए, मुख्य रूप से समझ को सरल बनाने और दूसरी तरफ से देखने के लिए। एक और समस्या यह है कि बहुत से लोग गलत पुस्तकालयों और गलत तकनीकों का चयन करते हैं। मुझे ऐसे प्रोग्रामर्स से विशेष रूप से डर लगता है, जिन्होंने न्यूफ़ंगल की पुस्तकें पढ़ी हैं और, ओओपी पर कई कार्यशालाओं का दौरा किया है, खुद को पेशेवर मानते हैं और यह बताना चाहते हैं कि इसे "सही ढंग से" कैसे करना है, आदि, वे विशाल यूएमएल आरेख का निर्माण कर सकते हैं, मॉडल बना सकते हैं, कुछ लिख सकते हैं। तब अमूर्त (खाली) कक्षाएं, बिना किसी कार्यक्षमता के, आदि। उसी समय वे आविष्कार नहीं कर सकते हैं और ऐसा कुछ करते हैं जो वास्तव में काम करता है। अक्सर, ऐसे लोग वास्तविक "अस्थि प्रोग्रामर" होते हैं जो अस्थि वास्तुकला के साथ अस्थि परियोजनाएं उत्पन्न करते हैं, यह कुछ ऐसा है जैसे " वास्तुकला के अंतरिक्ष यात्री " (डी। स्पोलस्की)। बेशक, यह शुरुआती को लग सकता है कि यह बहुत अच्छा है, आदि। लेकिन यह आमतौर पर ऐसा नहीं होता है, क्योंकि इनमें से अधिकांश परियोजनाएं विफल हो जाती हैं, अन्य मामलों में वे बहुत विस्तारित होते हैं, जब तक कि ग्राहक एक गैर-काम करने वाले उत्पाद के लिए भुगतान करने के लिए तैयार है, लेकिन अंत में यह अभी भी अलग हो जाता है या किसी अन्य टीम द्वारा पत्राचार किया जाता है। बेशक, अपवाद हैं और अच्छे उत्पाद सामने आते हैं, ऐसा होता है कि खराब कोड को दोष देना है, एक अच्छा एल्गोरिथ्म और टूल के साथ, लेकिन यह बहुत कम बार होता है, कम से कम मेरे व्यवहार में, छोटे नहीं, ऐसे बहुत कम मामले थे।
ओओपी पाठ्यक्रम को छूना पसंद नहीं करेगा, क्योंकि मुझे डर है कि बहुत लंबी चर्चा होगी जो किसी के लिए बेकार है, यह एक अलग विषय है, मैं इस प्रसिद्ध चर्चा के लेखकों से काफी हद तक सहमत हूं: ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग विफल क्यों हुई । OOP, और विशेष रूप से OO डिज़ाइन ऊपर से नीचे तक, केवल बहुत बड़ी और बहुत जटिल परियोजनाओं में लागू होता है, लेकिन सभी में नहीं, ऐसी बहुत कम परियोजनाएँ हैं। और अधिकांश मामलों में डिजाइन, आपको बुनियादी कार्यक्षमता और बुनियादी प्रोटोटाइप के साथ नीचे से शुरू करने की आवश्यकता है, जैसे कि पहले परिणाम प्राप्त करने के बाद, सब कुछ मौलिक रूप से बदल सकता है, विषय क्षेत्र और समस्या का सार अधिक स्पष्ट हो जाएगा, "बग सुविधाओं" का उल्लेख नहीं करने के लिए (कई अच्छी प्रौद्योगिकियां बग के लिए धन्यवाद प्रकट हुईं जो बाद में उत्कृष्ट "विशेषताएं" बन गईं)। और निश्चित रूप से, सबसे महत्वपूर्ण बात यह है कि समस्या को हल करने के लिए सही एल्गोरिदम चुनना है। यदि परियोजना बहुत जटिल है, और सिर में फिट नहीं होती है, तो ज्यादातर मामलों में ओओपी, यूएमएल, और डिजाइनिंग, मॉडलिंग, आदि के लिए सिस्टम। सभी समान, वे सबसे अधिक संभावना है कि समस्या को हल नहीं करेंगे और कुछ भी सरल करेंगे, बल्कि इसे जटिल भी करेंगे। इसलिए, एक बहुत ही जटिल, लेकिन वास्तव में कार्य प्रणाली बनाने के लिए, इसे कई परियोजनाओं, दिशाओं या पुस्तकालयों में विभाजित करना बेहतर है और इस सभी अर्थव्यवस्था के बीच डेटा विनिमय के प्रवाह को कम करना है। याद रखें कि सरल सब कुछ सरल है।

मुझे लगता है कि "कंप्यूटर विजन" का प्रयोग बहुत कम किया जाता है, क्योंकि इस क्षेत्र में विशेषज्ञों की सहायता के बिना कोई अच्छा उद्योग समाधान और अच्छा कार्यान्वयन नहीं है जिसे आसानी से स्थापित और कॉन्फ़िगर किया जा सके। और जो बहुत महंगे हैं या प्रचारित नहीं हैं और उनके बारे में बहुत कम लोग जानते हैं।