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

इस पेज पर, एचएएल सबसिस्टम के बारे में बताया गया है. इसमें अनुरोध, कैमरा सबसिस्टम, स्टार्टअप और ऑपरेशन सीक्वेंस, हार्डवेयर लेवल, और इंटरैक्शन शामिल हैं.

अनुरोध

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

कैमरे के अनुरोध का मॉडल

पहली इमेज. कैमरा मॉडल.

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

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

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

कैमरा हार्डवेयर ऐब्स्ट्रैक्शन लेयर

दूसरी इमेज. कैमरा पाइपलाइन.

ध्यान दें कि ऊपर दिए गए डायग्राम में दिखाए गए कुछ इमेज प्रोसेसिंग ब्लॉक, शुरुआती रिलीज़ में अच्छी तरह से तय नहीं किए गए हैं. कैमरा पाइपलाइन इन बातों को मानकर चलती है:

  • रॉ बेयर आउटपुट को आईएसपी में प्रोसेस नहीं किया जाता.
  • आंकड़े, सेंसर डेटा के आधार पर जनरेट किए जाते हैं.
  • प्रोसेसिंग के अलग-अलग ब्लॉक, रॉ सेंसर डेटा को YUV में बदलते हैं. ये ब्लॉक किसी भी क्रम में हो सकते हैं.
  • एक से ज़्यादा स्केल और क्रॉप यूनिट दिखाए जाते हैं. हालांकि, सभी स्केलर यूनिट, आउटपुट रीजन कंट्रोल (डिजिटल ज़ूम) शेयर करती हैं. हालांकि, हर यूनिट का आउटपुट रिज़ॉल्यूशन और पिक्सल फ़ॉर्मैट अलग-अलग हो सकता है.

एपीआई के इस्तेमाल के बारे में खास जानकारी

Android कैमरा एपीआई का इस्तेमाल करने के तरीके के बारे में खास जानकारी. इन चरणों के बारे में ज़्यादा जानकारी के लिए, स्टार्टअप और ऑपरेशन के अनुमानित क्रम वाला सेक्शन देखें. इसमें एपीआई कॉल भी शामिल हैं.

  1. यह एक्सटेंशन, कैमरा डिवाइसों की जानकारी सुन सकता है और उन्हें गिन सकता है.
  2. डिवाइस खोलें और लिसनर को कनेक्ट करें.
  3. टारगेट किए गए इस्तेमाल के उदाहरण के लिए आउटपुट कॉन्फ़िगर करें. जैसे, इमेज कैप्चर करना या रिकॉर्डिंग करना.
  4. टारगेट किए गए इस्तेमाल के उदाहरण के लिए अनुरोध बनाएं.
  5. अनुरोधों और डेटा के अचानक बढ़ने की जानकारी कैप्चर/दोहराई जाती है.
  6. नतीजे का मेटाडेटा और इमेज का डेटा पाना.
  7. इस्तेमाल के उदाहरण बदलते समय, तीसरे चरण पर वापस जाएं.

एचएएल ऑपरेशन की खास जानकारी

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

कैमरा एचएएल की खास जानकारी

तीसरी इमेज. कैमरा एचएएल की खास जानकारी.

स्टार्टअप और काम करने का अनुमानित क्रम

इस सेक्शन में, कैमरा एपीआई का इस्तेमाल करते समय किए जाने वाले चरणों के बारे में पूरी जानकारी दी गई है. एचआईडीएल इंटरफ़ेस डेफ़िनिशन के लिए, platform/hardware/interfaces/camera/ पर जाएं.

कैमरा डिवाइसों की गिनती करना, उन्हें खोलना, और ऐक्टिव सेशन बनाना

  1. शुरू होने के बाद, फ़्रेमवर्क उन सभी कैमरा प्रोवाइडर की जानकारी इकट्ठा करना शुरू कर देता है जो ICameraProvider इंटरफ़ेस लागू करते हैं. अगर ऐसी सेवा देने वाली कोई कंपनी मौजूद है, तो फ़्रेमवर्क उससे कनेक्ट करने की कोशिश करता है.
  2. यह फ़्रेमवर्क, ICameraProvider::getCameraIdList के ज़रिए कैमरा डिवाइसों की गिनती करता है.
  3. फ़्रेमवर्क, ICameraProvider::getCameraDeviceInterface_VX_X को कॉल करके एक नया ICameraDevice इंस्टैंशिएट करता है.
  4. फ़्रेमवर्क, ICameraDevice::open को कॉल करके नया ऐक्टिव कैप्चर सेशन ICameraDeviceSession बनाता है.

कैमरे के चालू सेशन का इस्तेमाल करना

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

कुछ समय बाद, इनमें से कोई एक कार्रवाई होती है:

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

कैमरे के ऑपरेशन का फ़्लो

चौथी इमेज. कैमरे के चालू होने का फ़्लो.

हार्डवेयर लेवल

कैमरा डिवाइस, अपनी क्षमताओं के हिसाब से कई हार्डवेयर लेवल लागू कर सकते हैं. ज़्यादा जानकारी के लिए, हार्डवेयर लेवल की ज़रूरी शर्तें देखें.

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

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

पैरामीटर राज्य कंट्रोल की गई प्रॉपर्टी
android.control.aeMode OFF कोई नहीं.
ON android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (अगर उपलब्ध हो), और android.lens.filterDensity (अगर उपलब्ध हो).
ON_AUTO_FLASH इसमें ON की सभी सुविधाएं मिलेंगी. इसके अलावा, 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 OFF कोई नहीं.
WHITE_BALANCE_* android.colorCorrection.transform. अगर android.colorCorrection.mode को FAST या HIGH_QUALITY पर सेट किया गया है, तो प्लैटफ़ॉर्म के हिसाब से अडजस्टमेंट.
android.control.afMode OFF कोई नहीं
FOCUS_MODE_* android.lens.focusDistance
android.control.videoStabilization OFF कोई नहीं.
ON वीडियो स्टेबलाइज़ेशन की सुविधा लागू करने के लिए, android.scaler.cropRegion को अडजस्ट किया जा सकता है.
android.control.mode OFF AE, AWB, और AF बंद हैं.
AUTO AE, AWB, और AF की अलग-अलग सेटिंग का इस्तेमाल किया जाता है.
SCENE_MODE_* ऊपर दिए गए सभी पैरामीटर को बदल सकता है. 3A के अलग-अलग कंट्रोल बंद हैं.

इमेज प्रोसेसिंग ब्लॉक में मौजूद सभी कंट्रोल, एक ही सिद्धांत पर काम करते हैं. हर ब्लॉक में तीन मोड होते हैं:

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

कैमरा सबसिस्टम के लिए ज़्यादा से ज़्यादा फ़्रेम रेट कई बातों पर निर्भर करता है:

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

ये फ़ैक्टर, अलग-अलग आईएसपी और सेंसर के हिसाब से अलग-अलग हो सकते हैं. इसलिए, कैमरा HAL इंटरफ़ेस, बैंडविड्थ से जुड़ी पाबंदियों को जितना हो सके उतना आसान मॉडल में बदलने की कोशिश करता है. पेश किए गए मॉडल की ये विशेषताएं हैं:

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