मैंने देखा है कि एक नया डेटा संरचना सीवी :: mATX उदाहरण के लिए नई OpenCV संस्करण के लिए जोड़ा गया है, संकलन समय में ज्ञात आकार के छोटे मैट्रिक्स लिए करना,लाभ :: mATX
cv::Matx31f // matrix 3x1 of float type
documentation की जांच मैंने देखा कि अधिकांश मैट्रिक्स ऑपरेशंस उपलब्ध हैं, लेकिन फिर भी मुझे पुराने सीवी :: मैट के बजाय इस नए प्रकार का उपयोग करने के फायदे नहीं दिख रहे हैं।
मुझे मैट के बजाय मैटक्स का उपयोग कब करना चाहिए?
यह स्मृति प्रबंधन के बारे में है और बर्बाद नहीं कर रहा है (कुछ मामलों में महत्वपूर्ण) स्मृति या किसी ऑब्जेक्ट के लिए स्मृति का आरक्षण जो आप बाद में उपयोग करेंगे।
इस तरह मैं इसे समझता हूं - कोई और बेहतर स्पष्टीकरण दे सकता है।
संक्षिप्त उत्तर: सीवी :: मैट अपने डेटा को स्टोर करने के लिए ढेर का उपयोग करता है, जबकि सीवी :: मैटक्स स्टैक का उपयोग करता है।
एक सीवी :: मैट गतिशील स्मृति आवंटन (ढेर पर) का उपयोग करता है। यह बड़ी मैट्रिक्स (छवियों की तरह) के लिए उपयुक्त है और आपको मैट्रिक्स की उथली प्रतियों जैसी चीजें करने देता है, जो सीवी :: मैट का डिफ़ॉल्ट व्यवहार है।
हालांकि, छोटी मैट्रिक्स के लिए सीवी :: मैटक्स के लिए डिज़ाइन किया गया है, ढेर आवंटन स्टैक पर एक ही चीज़ करने की तुलना में बहुत महंगा होगा। मैंने गणित के एक ब्लॉक को सीवी :: मैट के बजाय स्टैक-आवंटित प्रकारों (जैसे सीवी :: प्वाइंट और सीवी :: मैटक्स) का उपयोग करने के लिए स्विच करके 75% से अधिक प्रोसेसिंग समय को कम किया है।
मेरा मानना है कि लूप अनोलिंग द्वारा भी अधिक प्रदर्शन प्राप्त किया जाता है, जो गतिशील आकार के मैट्रिक्स के लिए नहीं किया जा सकता है। – emu
यह देर से उत्तर दिया गया है, लेकिन यह अभी भी एक दिलचस्प सवाल है!
डोम का जवाब काफी सटीक है, और उपयोगकर्ता 1460044 में ढेर/ढेर संदर्भ भी दिलचस्प है।
देखने के एक व्यावहारिक बिंदु से, मैं का उपयोग नहीं होताMatx (या Vec), अगर सिवाय यह पूरी तरह से आवश्यक थे। MATX का प्रमुख लाभ
समस्या है, अंत में आप एक Mat करने के लिए अपने Matx डेटा स्थानांतरित करने के लिए सामान का सबसे करना होगा, और हां, तो आप ढेर पर फिर से वापस हो जाएगा। दूसरी ओर, एक Matx का 'कूल प्रारंभ "एक सामान्य चटाई में किया जा सकता:
// Matx initialization:
Matx31f A(1.f,2.f,3.f);
// Mat initialization:
Mat B = (Mat_<float>(3,1) << 1.f, 2.f, 3.f);
इसके अलावा, वहाँ प्रारंभ में एक फर्क सामान (ढेर/ढेर से परे) है। यदि आप Matx31 में 5 मान डालने का प्रयास करते हैं, तो यह Mat_::operator<< को 5 मानों के साथ कॉल करते समय केवल तीन तीन स्टोर करेगा, यह क्रैश (रनटाइम अपवाद) होगा।
[1] कुशल यदि आपके प्रोग्राम को ~ 10 से कम तत्वों के बहुत सारे मैट्रिक्स बनाना है। उस मामले में Matx matrices का उपयोग करें।
वहाँ 2 अन्य कारणों का मैं पसंद कर रहे हैं MatxMat रहे हैं:
पठनीयता: कोड को पढ़ने के लोगों को तुरंत उदाहरण के लिए, मैट्रिक्स के आकार देख सकते हैं:
cv::Matx34d transform = ...;
यह स्पष्ट है कि यह एक 3x4 मैट्रिक्स है, इसलिए इसमें 3 डी रूपांतरण प्रकार (आर, टी) है, जहां आर एक रोटेशन मैट्रिक्स है (जैसा कि कहने के विपरीत, अक्ष-कोण) है। इसी तरह, transform(i,j) बनाम transform.at<double>(i,j) के साथ तत्व का उपयोग करना अधिक स्वाभाविक है।
आसान डिबगिंग। चूंकि Matx के तत्वों को ज्ञात लंबाई की एक सरणी में ढेर पर आवंटित किया गया है, आईडीई या डिबगर्स कोड के माध्यम से कदम उठाने पर पूरी सामग्री को अच्छी तरह से प्रदर्शित कर सकते हैं।
प्रलेखन में बहुत बारीकी से देख के बिना, एक कह सकते हैं कि संकलन समय पर आकार जानने निश्चित रूप से कई फायदे हैं, तो डायनामिक आबंटित स्मृति के सभी प्रतिस्थापन के पहले है संकलन समय सरणियों, द्वारा जो इस तरह के छोटे स्पष्ट रूप से परिभाषित मैट्रिक्स के लिए एक स्पष्ट अनुकूलन है। कहा जा रहा है कि, आपका प्रश्न यह स्पष्ट रूप से उत्तर देता है: * "ज्ञात आकार के छोटे matrices के लिए इरादा" *। छवि परिवर्तन या कैमरा अंशांकन में उपयोग के रूप में परिवर्तन matrices के बारे में सोचो। –
लेकिन अभी भी मैट (3,1, सीवी_32 एफसी 1) –
डालने से पुराने प्रकार के मैट के साथ किया जा सकता है, इसलिए, गतिशील स्मृति आवंटन पर संकलन समय सरणी का उपयोग करने के स्पष्ट अनुकूलन के बारे में मेरा पूरा पहला पैराग्राफ। बेशक यह सिर्फ एक अनुकूलन है और कोई अतिरिक्त कार्यक्षमता नहीं है, लेकिन वास्तव में यह लाभ आपको मिलता है। आप वास्तव में सख्त 3x4 मैट्रिक्स के लिए गतिशील रूप से स्मृति आवंटित नहीं करना चाहते हैं। –