हमने OpenCV को WindowsRT में कैसे पोर्ट किया

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

पहला दृष्टिकोण

CMake-आधारित लाइब्रेरी इन्फ्रास्ट्रक्चर ने कई बार कई प्लेटफार्मों पर स्थानांतरण का अनुभव किया है, लेकिन इस बार ब्लिट्जक्रेग विफल रहा। जैसा कि यह निकला, cmake (तब अभी भी 2.8.11) विंडोज आरटी के तहत विजुअल स्टूडियो के लिए परियोजनाओं की पीढ़ी का समर्थन नहीं करता है। नेटवर्क के खुले स्थानों पर एक वर्कअराउंड बहुत तेज़ी से पाया गया: विंडोज के लिए विजुअल स्टूडियो के लिए प्रोजेक्ट्स बनाने के बजाय, आप मेक-फाइल जनरेटर में से एक का उपयोग कर सकते हैं। तब बनाने के लिए आप मेक, एनएमके या निंजा का उपयोग कर सकते हैं, आपको बस एआरएम संकलक के साथ विधानसभा के लिए पर्यावरण को कॉन्फ़िगर करने की आवश्यकता है।

मौजूदा कोड को संकलित करने के संघर्ष में, कई छोटी बारीकियां सामने आई हैं। विशेष रूप से, ARM आर्किटेक्चर के लिए एक नियमित Win32 एप्लिकेशन का निर्माण हेडर फ़ाइलों और विज़ुअल स्टूडियो प्रोजेक्ट्स के स्तर पर सीमित है। इसलिए, cmake परीक्षण फ़ाइलों और हमारे परीक्षणों को सफलतापूर्वक संकलित करने के लिए, हमें एक हैक करना था - कंपाइलर कमांड लाइन में _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE मैक्रो जोड़ें। यह प्लेटफ़ॉर्म सत्यापन को दबा देता है। पुस्तकालय के साथ संयोजन के रूप में विकसित होने वाले सभी परीक्षणों और उदाहरणों के लिए भी यही सच है।

मैक्रोज़ और संकलन कुंजियों के साथ सभी समस्याओं को हल करने के लिए, लाइब्रेरी में एक छद्म टूलकिन फ़ाइल जोड़ी गई थी। "छद्म" इस तथ्य के कारण कि यह संकलक, ओएस, प्लेटफ़ॉर्म, आदि के लिए पथ निर्दिष्ट नहीं करता है, लेकिन केवल आवश्यक ध्वज और मैक्रोज़ जोड़ता है। इसके अलावा, मुझे विंडोज प्लेटफॉर्म एसडीके स्थापित करना था। यह ARM के लिए C और C ++ रनटाइम से कुछ और स्टैटिक लाइब्रेरी लाता है।

हाईगुई मॉड्यूल के निर्माण को अंत तक लाने की कोशिश में, मुझे वीडियो और खिड़कियों के साथ काम करने के लिए कुछ हिस्सों का बलिदान करना पड़ा - सिस्टम पुस्तकालयों में लिंकिंग के लिए आवश्यक कार्य नहीं हैं। विंडोज आरटी पर विंडोज, जीडीआई, वीडियो फॉर विंडोज और कॉम के कुछ हिस्सों के लिए पुराने एपीआई के लिए कोई समर्थन नहीं है। मुझे भी FFmpeg'a के लिए समर्थन छोड़ना पड़ा। यह एक अच्छा और पोर्टेबल पुस्तकालय है, लेकिन इसके एकीकरण के लिए अतिरिक्त प्रयासों की आवश्यकता होती है। नतीजतन, हम बिना खिड़कियों के और बिना वीडियो I / O के रह गए। विंडोज एक बड़ा नुकसान नहीं है, अंतिम समर्थन बनाने के बजाय केवल प्रोटोटाइप और डीबगिंग के लिए उनके समर्थन की आवश्यकता होती है। और वीडियो इनपुट-आउटपुट, इसके विपरीत, एक बहुत ही आवश्यक चीज है, और यह उस पर काम करने लायक था।

एक जोड़े ने और अधिक कस लिया - और परीक्षणों को सफलतापूर्वक इकट्ठा किया गया और लगभग सफलतापूर्वक एक एआरएम-टैबलेट पर चलाया गया। लेकिन मुख्य पुस्तकालय के सफल संकलन और परीक्षण भी आधी लड़ाई नहीं है। OpenCV के अलावा, मैं भी Android के लिए कोडांतरक और आंतरिक में किए गए अनुकूलन की एक बड़ी संख्या को स्थानांतरित करना चाहता था और नए प्लेटफॉर्म के लिए जीसीसी को संकलित करने के लिए डिज़ाइन किया गया था, इंटेल टीबीबी के लिए समर्थन जोड़ता हूं, फिर भी वीडियो I / O का समर्थन करता हूं, और बहुत कुछ।

वीडियो I / O

विंडोज आरटी के लिए सक्रिय विकास वीडियो I / O से शुरू हुआ। विंडोज एक्सपी के साथ शुरू, अगला मल्टीमीडिया एपीआई, माइक्रोसॉफ्ट मीडिया फाउंडेशन, विंडोज ऑपरेटिंग सिस्टम में दिखाई दिया। जैसा कि यह जल्दी से निकला, यह एआरएम के साथ टैबलेट पर वीडियो के लिए एकमात्र एपीआई है। Cv के लिए नया कार्यान्वयन :: VideoCapture ने डेस्कटॉप और टैबलेट पीसी दोनों के लिए महान लाभ का वादा किया। उस समय OpenCV के पास पहले से ही विंडोज पर वीडियो के साथ काम करने के लिए कुछ बैकएंड का समर्थन था, जिसमें पुराना डायरेक्ट शो भी शामिल था। Cv का कार्यान्वयन :: DirectShow पर आधारित VideoCapture , VideoInput लाइब्रेरी का उपयोग करके किया गया था। यह आशा की गई थी कि VideoInput परियोजना जीवित थी और शायद, मीडिया फाउंडेशन द्वारा समर्थित किसी तरह। लेकिन एक शव परीक्षा से पता चला कि इस परियोजना को लंबे समय के लिए छोड़ दिया गया था, और यहां तक ​​कि पुस्तकालय की हमारी प्रति मूल की तुलना में बहुत आगे निकल गई। काम में एक बड़ी सफलता CodeProject पर एक खोज थी। सुदूर पूर्व एवगेनी पेरेगुडा के हमारे हमवतन ने मीडिया फाउंडेशन को ओपनसीवी (!) के साथ अपने प्रोजेक्ट में एकीकृत करने के लिए अपनी वीडियोइन्पुट जैसी लाइब्रेरी को लागू किया। किए गए काम के लिए बहुत-बहुत धन्यवाद।

हमने नए cv :: VIdeoCapture कार्यान्वयन के लिए प्रकाशित कोड को आधार के रूप में उपयोग करने का निर्णय लिया। अनुकूलन की प्रक्रिया में, मुझे कोडांतरक आवेषण से छुटकारा पाना था और कुछ कॉल को बदलना था जो एआरएम से लिंक नहीं हो सकते थे। इसके अलावा, पाइपलाइन के निर्माण को थोड़ा संशोधित करने के बाद, यह वीडियो फ़ाइलों को पढ़ने और लिखने को जोड़ने के लिए निकला। डेस्कटॉप पर, नया cv :: VideoCapture ने कैमरे के साथ ठीक काम किया, लेकिन टैबलेट पर हमें एक अप्रिय आश्चर्य हुआ। Win32 सबसिस्टम के लिए इकट्ठे हुए ARM के लिए आवेदन में, MediaFoundation पाइपलाइन को सामान्य रूप से आरंभ किया गया था, लेकिन वीडियो प्राप्त करना संभव नहीं था: पाइपलाइन लटका हुआ था और कैमरे से कोई फ्रेम नहीं आया था। कंटेनर में काम करने के लिए बनाए गए एप्लिकेशन में, एक और विसंगति देखी गई थी। MFEnumDeviceSources फ़ंक्शन के साथ कैमरों की गणना करने से कैमरे के इंटरफेस के लिए एक सूचक के बजाय कचरे का एक गुच्छा और NULL वापस आ गया। जैसा कि यह जल्द ही स्पष्ट हो गया है, पहले मामले में सिस्टम ब्रोकर को दोष देना है, जो कैमरे और अन्य उपकरणों तक पहुंच अधिकारों की निगरानी करता है। हमारे पास एक Win32 एप्लिकेशन है जिसमें एक प्रकट नहीं है, इसलिए हम कैमरे तक पहुंच की अनुमति नहीं दे सकते हैं। दूसरे मामले में, समस्या MFEnumDeviceSource फ़ंक्शन के कार्यान्वयन में या इसके अभाव में निहित है। यह कंटेनर अनुप्रयोगों के लिए निषिद्ध कार्यों की सूची में सूचीबद्ध है और, कई अन्य लोगों के विपरीत, जिन्हें प्रतिबंधित किया गया है, बिल्कुल भी लागू नहीं किया गया है। अधिक सटीक रूप से, लिंक त्रुटियों को खत्म करने के लिए, एक स्टब कहा जाता है जो विवरण में इंटरफ़ेस और कचरा के लिए एक संकेतक के बजाय NULL देता है। नतीजतन, हम डेस्कटॉप सिस्टम के लिए मीडिया फाउंडेशन का समर्थन करने में कामयाब रहे, लेकिन एआरएम पर सवाल खुला रहा।

अनुकूलन

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

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

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

लेकिन असेंबलर के साथ, सब कुछ बहुत खराब निकला। Microsoft से संकलक के नए संस्करण x86_64 और ARM के लिए इनलाइन असेंबलर का समर्थन नहीं करते हैं, इसलिए मुझे विचार को सिंटैक्स में अंतर को जल्दी से ठीक करने और कोडांतरक कोड को स्थानांतरित करने से इनकार करना पड़ा। हम कंपाइलर इंट्रिनिक्स का उपयोग करके सबसे महत्वपूर्ण भागों को फिर से लिखते हैं, लेकिन यहां तक ​​कि कुछ आश्चर्य भी थे। स्टूडियो कंपाइलर के पास निर्देशों के VFPv3 (एआरएम के लिए एक फ्लोटिंग पॉइंट के साथ गणित का हार्डवेयर कार्यान्वयन) के लिए आंतरिक नहीं है और उन्हें स्पष्ट रूप से उपयोग करने का एकमात्र सामान्य तरीका पूरी तरह से कोडांतरक में फ़ंक्शन को लागू करना और इस तरह के कार्यों को एक अलग एश फाइल में स्थानांतरित करना है। एक अलग असेंबलर संकलन के साथ दृष्टिकोण हमें बिल्कुल भी पसंद नहीं आया, क्योंकि बिल्ड इंफ्रास्ट्रक्चर में महत्वपूर्ण संशोधनों की आवश्यकता थी। यह भी महत्वपूर्ण है कि कंपाइलर असेंबलर फ़ंक्शंस को एम्बेड करने और उनके कॉल के किसी भी अनुकूलन को करने से इनकार करता है। समस्या केवल __emit कीवर्ड का उपयोग करके हल की गई थी। यह आपको C या C ++ कोड के किसी भी ब्लॉक में मशीन कोड का एक मनमाना टुकड़ा डालने की अनुमति देता है। निर्देशों के कॉल समझौतों और opcodes को जानने के बाद, आप किसी भी लापता आंतरिक रचना कर सकते हैं।

Win32 एपीआई सफाई

ओपनसीवी तैयार करने के लिए अंतिम चरण कंटेनरीकृत अनुप्रयोगों के लिए प्रमाणन परीक्षा पास करना था। यह बाज़ार में सभी अनुप्रयोगों के लिए एक शर्त है।
सबसे पहले, मुझे लिंकर के झंडे के साथ / ऐपकनेक्टर जोड़ना था। इसके बाद प्रयुक्त सिस्टम एपीआई की स्ट्रिपिंग आ गई। Win32 कॉल के सभी एएनएसआई संस्करण, साथ ही साथ कुछ फ़ंक्शन जिसमें Ex संस्करण है, जैसे कि InitializeCriticalSection, अपमान के तहत गिर गया।

GetTempFileName फ़ंक्शन पर विशेष ध्यान दिया जाना चाहिए, जो कि Win32 API द्वारा पहली नज़र में ध्यान देने योग्य नहीं था। OpenCV में, इसका उपयोग टेम्पपाइल कॉल में किया जाता है। GetTempFileName में एक उपयुक्त समकक्ष नहीं है जिसका उपयोग किसी कंटेनर में किया जा सकता है। एकमात्र विकल्प पाया जाता है जो विंडोज़ रनटाइम लाइब्रेरी से कॉल करता है। फ़ंक्शन का कोड यहां लिया गया है , और यहां एक नियमित एप्लिकेशन का निर्माण करते समय विंडोज रनटाइम से कैसे लिंक किया जाए।

GetTempFileName के अलावा, TLS (थ्रेड लोकल स्टोरेज) के साथ इंटरैक्शन फ़ंक्शन के लिए कोई प्रतिस्थापन नहीं था। लेकिन इस मामले में, विकल्प काफी जल्दी मिल गया था और जहां वे बिल्कुल इंतजार नहीं करते थे - सी ++ 11। नए सी ++ मानक में टीएलएस डेटा के साथ काम करने के लिए उपकरण शामिल हैं, जिसने हमें सिस्टम-निर्भर एपीआई से भाषा निर्माणों में जाने की अनुमति दी।

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

निरंतर एकीकरण

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

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

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



विंडोज 8 के साथ टैबलेट पर ओपनसीवी के साथ मार्केटप्लेस के लिए आवेदन उदाहरण

निष्कर्ष

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

अब, जाहिरा तौर पर, बहुत लोकप्रिय मंच नहीं होने के कारण, विंडोज रनटाइम के लिए समर्थन के विकास में ग्राहक की रुचि काफी कम हो गई है और समुदाय से उत्साही लोगों के लिए आसानी से पारित हो गई है। यदि आप Windows RT पर OpenCV विकसित करने में रुचि रखते हैं, तो हमसे जुड़ें ( OpenCV योगदान कैसे करें , http://itseez.com/jobs/ )!