इस पेज का अनुवाद Cloud Translation API से किया गया है.

एचएएल सबसिस्टम

अनुरोध

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

चित्र 1. कैमरा मॉडल

एचएएल और कैमरा सबसिस्टम

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

कैमरा पाइपलाइन उन ट्रिगर्स का भी समर्थन करती है जिन्हें ऐप फ्रेमवर्क ऑटो-फोकस जैसी चीजों को चालू करने के लिए शुरू कर सकता है। यह ऐप फ्रेमवर्क पर नोटिफिकेशन भी भेजता है, ऑटो-फोकस लॉक या त्रुटियों जैसी घटनाओं के बारे में ऐप्स को सूचित करता है।

चित्र 2. कैमरा पाइपलाइन

कृपया ध्यान दें, ऊपर दिए गए चित्र में दिखाए गए कुछ छवि प्रसंस्करण ब्लॉक प्रारंभिक रिलीज़ में अच्छी तरह से परिभाषित नहीं हैं। कैमरा पाइपलाइन निम्नलिखित धारणाएँ बनाती है:

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

एपीआई उपयोग का सारांश
यह एंड्रॉइड कैमरा एपीआई का उपयोग करने के चरणों का एक संक्षिप्त सारांश है। एपीआई कॉल सहित इन चरणों के विस्तृत विवरण के लिए स्टार्टअप और अपेक्षित ऑपरेशन अनुक्रम अनुभाग देखें।

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

एचएएल ऑपरेशन सारांश

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

चित्र 3. कैमरा एचएएल सिंहावलोकन

स्टार्टअप और अपेक्षित संचालन क्रम

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

गणना करना, कैमरा डिवाइस खोलना और एक सक्रिय सत्र बनाना

आरंभीकरण के बाद, फ्रेमवर्क किसी भी मौजूदा कैमरा प्रदाता को सुनना शुरू कर देता है जो ICameraProvider इंटरफ़ेस को लागू करता है। यदि ऐसे प्रदाता या प्रदाता मौजूद हैं, तो फ्रेमवर्क कनेक्शन स्थापित करने का प्रयास करेगा।
फ्रेमवर्क ICameraProvider::getCameraIdList() के माध्यम से कैमरा उपकरणों की गणना करता है।
फ्रेमवर्क संबंधित ICameraProvider::getCameraDeviceInterface_VX_X() कॉल करके एक नया ICameraDevice तैयार करता है।
नया सक्रिय कैप्चर सत्र ICameraDeviceSession बनाने के लिए फ्रेमवर्क ICameraDevice::open() को कॉल करता है।

एक सक्रिय कैमरा सत्र का उपयोग करना

फ्रेमवर्क एचएएल डिवाइस पर इनपुट/आउटपुट स्ट्रीम की सूची के साथ ICameraDeviceSession::configureStreams() को कॉल करता है।
फ्रेमवर्क ICameraDeviceSession::constructDefaultRequestSettings() पर कॉल के साथ कुछ उपयोग मामलों के लिए डिफ़ॉल्ट सेटिंग्स का अनुरोध करता है। यह ICameraDeviceSession ICameraDevice::open द्वारा बनाए जाने के बाद किसी भी समय हो सकता है।
फ्रेमवर्क डिफ़ॉल्ट सेटिंग्स के सेटों में से एक के आधार पर सेटिंग्स के साथ एचएएल को पहला कैप्चर अनुरोध बनाता है और भेजता है, और कम से कम एक आउटपुट स्ट्रीम के साथ जो फ्रेमवर्क द्वारा पहले पंजीकृत किया गया है। इसे ICameraDeviceSession::processCaptureRequest() के साथ HAL को भेजा जाता है। एचएएल को इस कॉल के रिटर्न को तब तक ब्लॉक करना होगा जब तक कि यह अगला अनुरोध भेजने के लिए तैयार न हो जाए।
फ्रेमवर्क अनुरोध सबमिट करना जारी रखता है और आवश्यकतानुसार अन्य उपयोग के मामलों के लिए डिफ़ॉल्ट सेटिंग्स बफ़र्स प्राप्त करने के लिए ICameraDeviceSession::constructDefaultRequestSettings() को कॉल करता है।
जब किसी अनुरोध का कैप्चर शुरू होता है (सेंसर कैप्चर के लिए एक्सपोज़ करना शुरू कर देता है), HAL शटर संदेश के साथ ICameraDeviceCallback::notify() को कॉल करता है, जिसमें फ़्रेम नंबर और एक्सपोज़र की शुरुआत के लिए टाइमस्टैम्प शामिल होता है। यह सूचित कॉलबैक अनुरोध के लिए पहली processCaptureResult() कॉल से पहले नहीं होता है, लेकिन कैप्चर के लिए किसी एप्लिकेशन को कोई परिणाम तब तक डिलीवर नहीं किया जाता है जब तक कि उस कैप्चर के लिए notify() को कॉल न किया जाए।
कुछ पाइपलाइन विलंब के बाद, HAL ICameraDeviceCallback::processCaptureResult() के साथ पूर्ण कैप्चर को फ्रेमवर्क में वापस करना शुरू कर देता है। इन्हें उसी क्रम में लौटाया जाता है जिस क्रम में अनुरोध सबमिट किए गए थे। कैमरा एचएएल डिवाइस की पाइपलाइन गहराई के आधार पर, एक साथ कई अनुरोध उड़ान में हो सकते हैं।

कुछ समय बाद, निम्न में से एक घटित होगा:

फ़्रेमवर्क नए अनुरोध सबमिट करना बंद कर सकता है, मौजूदा कैप्चर के पूरा होने की प्रतीक्षा कर सकता है (सभी बफ़र भरे हुए हैं, सभी परिणाम वापस आ गए हैं), और फिर ICameraDeviceSession::configureStreams() फिर से कॉल करें। यह इनपुट/आउटपुट स्ट्रीम के नए सेट के लिए कैमरा हार्डवेयर और पाइपलाइन को रीसेट करता है। पिछले कॉन्फ़िगरेशन से कुछ स्ट्रीम का पुन: उपयोग किया जा सकता है। यदि कम से कम एक पंजीकृत आउटपुट स्ट्रीम बनी रहती है, तो रूपरेखा पहले कैप्चर अनुरोध से एचएएल तक जारी रहती है। (अन्यथा, ICameraDeviceSession::configureStreams() पहले आवश्यक है।)
कैमरा सत्र समाप्त करने के लिए फ्रेमवर्क ICameraDeviceSession::close() कॉल कर सकता है। इसे किसी भी समय कॉल किया जा सकता है जब फ्रेमवर्क से कोई अन्य कॉल सक्रिय नहीं है, हालांकि कॉल तब तक ब्लॉक हो सकती है जब तक कि सभी इन-फ़्लाइट कैप्चर पूरे नहीं हो जाते (सभी परिणाम वापस आ गए, सभी बफ़र्स भर गए)। close() कॉल रिटर्न के बाद, एचएएल से ICameraDeviceCallback पर कोई और कॉल की अनुमति नहीं है। एक बार close() कॉल चालू होने पर, फ़्रेमवर्क किसी अन्य एचएएल डिवाइस फ़ंक्शंस को कॉल नहीं कर सकता है।
किसी त्रुटि या अन्य अतुल्यकालिक घटना के मामले में, HAL को उचित त्रुटि/घटना संदेश के साथ ICameraDeviceCallback::notify() कॉल करना होगा। एक घातक डिवाइस-व्यापी त्रुटि अधिसूचना से लौटने के बाद, एचएएल को ऐसे कार्य करना चाहिए जैसे कि उस पर close() कॉल किया गया हो। हालाँकि, HAL को notify() कॉल करने से पहले या तो सभी बकाया कैप्चर को रद्द करना होगा या पूरा करना होगा, ताकि एक बार notify() को घातक त्रुटि के साथ कॉल करने के बाद, फ्रेमवर्क को डिवाइस से आगे कॉलबैक प्राप्त न हो। घातक त्रुटि संदेश से notify() विधि वापस आने के बाद close() के अलावा अन्य विधियों को -ENODEV या NULL वापस आना चाहिए।

चित्र 4. कैमरा परिचालन प्रवाह

हार्डवेयर स्तर

कैमरा उपकरण अपनी क्षमताओं के आधार पर कई हार्डवेयर स्तरों को लागू कर सकते हैं। अधिक जानकारी के लिए, समर्थित हार्डवेयर स्तर देखें।

एप्लिकेशन कैप्चर अनुरोध, 3ए नियंत्रण और प्रोसेसिंग पाइपलाइन के बीच इंटरेक्शन

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

पैरामीटर	राज्य	गुण नियंत्रित
android.control.aeMode	बंद	कोई नहीं
	पर	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (यदि समर्थित हो) android.lens.filterDensity (यदि समर्थित हो)
	ON_AUTO_FLASH	सब कुछ चालू है, साथ ही android.flash.firingPower, android.flash.firingTime, और android.flash.mode
	ON_ALWAYS_FLASH	ON_AUTO_FLASH के समान
	ON_AUTO_FLASH_RED_EYE	ON_AUTO_FLASH के समान
android.control.awbMode	बंद	कोई नहीं
	श्वेत संतुलन_*	android.colorCorrection.transform. यदि android.colorCorrection.mode तेज़ या उच्च गुणवत्ता वाला है तो प्लेटफ़ॉर्म-विशिष्ट समायोजन।
android.control.afMode	बंद	कोई नहीं
	संकेन्द्रित विधि_*	android.lens.focusDistance
android.control.videoस्थिरीकरण	बंद	कोई नहीं
	पर	वीडियो स्थिरीकरण लागू करने के लिए android.scaler.cropRegion को समायोजित कर सकते हैं
android.control.mode	बंद	AE, AWB और AF अक्षम हैं
	ऑटो	व्यक्तिगत AE, AWB और AF सेटिंग्स का उपयोग किया जाता है
	दृश्य मोड_*	ऊपर सूचीबद्ध सभी मापदंडों को ओवरराइड कर सकते हैं। व्यक्तिगत 3A नियंत्रण अक्षम हैं.

चित्र 2 में इमेज प्रोसेसिंग ब्लॉक के सभी नियंत्रण एक समान सिद्धांत पर काम करते हैं, और आम तौर पर प्रत्येक ब्लॉक में तीन मोड होते हैं:

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

कैमरा सबसिस्टम द्वारा समर्थित अधिकतम फ़्रेम दर कई कारकों पर निर्भर करती है:

आउटपुट छवि स्ट्रीम के अनुरोधित रिज़ॉल्यूशन
इमेजर पर बिनिंग/स्किपिंग मोड की उपलब्धता
इमेजर इंटरफ़ेस की बैंडविड्थ
विभिन्न आईएसपी प्रसंस्करण ब्लॉकों की बैंडविड्थ

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

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