अनुरोध
ऐप्लिकेशन फ़्रेमवर्क, कैप्चर किए गए नतीजों के लिए कैमरा सबसिस्टम को अनुरोध भेजता है. एक अनुरोध, नतीजों के एक सेट से मेल खाता है. अनुरोध में, उन नतीजों को कैप्चर और प्रोसेस करने से जुड़ी सभी कॉन्फ़िगरेशन जानकारी शामिल होती है. इसमें रिज़ॉल्यूशन और पिक्सल फ़ॉर्मैट जैसी चीज़ें शामिल हैं. जैसे, मैन्युअल सेंसर, लेंस, और फ़्लैश कंट्रोल; 3A ऑपरेटिंग मोड; RAW से YUV प्रोसेसिंग कंट्रोल; और आंकड़े जनरेट करना. इससे, नतीजों के आउटपुट और प्रोसेसिंग पर ज़्यादा कंट्रोल मिलता है. एक साथ कई अनुरोध किए जा सकते हैं. साथ ही, अनुरोध सबमिट करने पर कोई रुकावट नहीं आती. अनुरोधों को हमेशा उसी क्रम में प्रोसेस किया जाता है जिस क्रम में वे मिलते हैं.
पहली इमेज. कैमरा मॉडल
एचएएल और कैमरा सबसिस्टम
कैमरा सबसिस्टम में, कैमरा पाइपलाइन में मौजूद कॉम्पोनेंट के लिए लागू किए गए सिस्टम शामिल होते हैं. जैसे, 3A एल्गोरिदम और प्रोसेसिंग कंट्रोल. कैमरा HAL, आपको इन कॉम्पोनेंट के वर्शन लागू करने के लिए इंटरफ़ेस उपलब्ध कराता है. अलग-अलग डिवाइस बनाने वाली कंपनियों और इमेज सिग्नल प्रोसेसर (आईएसपी या कैमरा सेंसर) वेंडर के बीच, क्रॉस-प्लैटफ़ॉर्म कंपैटिबिलिटी बनाए रखने के लिए, कैमरा पाइपलाइन मॉडल वर्चुअल होता है. यह किसी भी असली आईएसपी से सीधे तौर पर मेल नहीं खाता. हालांकि, यह असली प्रोसेसिंग पाइपलाइन के जैसा ही है, ताकि इसे अपने हार्डवेयर से आसानी से मैप किया जा सके. इसके अलावा, यह इतना ऐब्स्ट्रैक्ट है कि इसमें कई अलग-अलग एल्गोरिदम और ऑपरेशन के क्रम का इस्तेमाल किया जा सकता है. इससे क्वालिटी, कार्यक्षमता या अलग-अलग डिवाइसों पर काम करने की क्षमता पर कोई असर नहीं पड़ता.
कैमरा पाइपलाइन, ट्रिगर को भी सपोर्ट करती है. ऐप्लिकेशन फ़्रेमवर्क, ऑटो-फ़ोकस जैसी सुविधाओं को चालू करने के लिए, इन ट्रिगर को शुरू कर सकता है. यह ऐप्लिकेशन फ़्रेमवर्क को सूचनाएं भी वापस भेजता है. इससे ऐप्लिकेशन को ऑटो-फ़ोकस लॉक या गड़बड़ियों जैसे इवेंट की सूचना मिलती है.
दूसरी इमेज. कैमरा पाइपलाइन
कृपया ध्यान दें कि ऊपर दिए गए डायग्राम में दिखाई गई इमेज प्रोसेसिंग के कुछ ब्लॉक, शुरुआती रिलीज़ में अच्छी तरह से तय नहीं किए गए हैं. कैमरा पाइपलाइन इन बातों को मानकर चलती है:
- रॉ बेयर आउटपुट को आईएसपी में प्रोसेस नहीं किया जाता.
- आंकड़े, सेंसर से मिले रॉ डेटा के आधार पर जनरेट किए जाते हैं.
- प्रोसेसिंग के अलग-अलग ब्लॉक, रॉ सेंसर डेटा को YUV में बदलते हैं. ये ब्लॉक किसी भी क्रम में हो सकते हैं.
- एक से ज़्यादा स्केल और क्रॉप यूनिट दिखाए जाते हैं. हालांकि, सभी स्केलर यूनिट, आउटपुट रीजन कंट्रोल (डिजिटल ज़ूम) शेयर करती हैं. हालांकि, हर यूनिट का आउटपुट रिज़ॉल्यूशन और पिक्सल फ़ॉर्मैट अलग-अलग हो सकता है.
एपीआई के इस्तेमाल के बारे में खास जानकारी
Android Camera API का इस्तेमाल करने के चरणों के बारे में खास जानकारी यहां दी गई है. इन चरणों के बारे में ज़्यादा जानकारी के लिए, स्टार्टअप और ऑपरेशन के अनुमानित क्रम वाला सेक्शन देखें. इसमें एपीआई कॉल भी शामिल हैं.
- यह एक्सटेंशन, कैमरा डिवाइसों की जानकारी सुन सकता है और उन्हें गिन सकता है.
- डिवाइस खोलें और लिसनर को कनेक्ट करें.
- टारगेट किए गए इस्तेमाल के उदाहरण के लिए आउटपुट कॉन्फ़िगर करें. जैसे, इमेज कैप्चर करना, रिकॉर्डिंग करना वगैरह.
- टारगेट किए गए इस्तेमाल के उदाहरण के लिए अनुरोध बनाएं.
- अनुरोधों और डेटा ट्रांसफ़र की संख्या को कैप्चर/दोहराना.
- नतीजे का मेटाडेटा और इमेज का डेटा पाएं.
- इस्तेमाल के उदाहरण बदलते समय, तीसरे चरण पर वापस जाएं.
एचएएल ऑपरेशन की खास जानकारी
- कैप्चर करने के लिए एसिंक्रोनस अनुरोध, फ़्रेमवर्क से आते हैं.
- HAL डिवाइस को अनुरोधों को क्रम से प्रोसेस करना होगा. साथ ही, हर अनुरोध के लिए, आउटपुट नतीजे का मेटाडेटा और एक या उससे ज़्यादा आउटपुट इमेज बफ़र जनरेट करें.
- अनुरोधों और नतीजों के लिए, पहले आओ, पहले पाओ का सिद्धांत लागू होता है. साथ ही, बाद के अनुरोधों में जिन स्ट्रीम का रेफ़रंस दिया गया है उनके लिए भी यही सिद्धांत लागू होता है.
- किसी अनुरोध के सभी आउटपुट के लिए टाइमस्टैंप एक जैसे होने चाहिए, ताकि फ़्रेमवर्क ज़रूरत पड़ने पर उन्हें एक साथ मैच कर सके.
- कैप्चर कॉन्फ़िगरेशन और स्थिति (3A रूटीन को छोड़कर) से जुड़ी सभी जानकारी, अनुरोधों और नतीजों में शामिल होती है.
तीसरी इमेज. कैमरा एचएएल की खास जानकारी
स्टार्टअप और ऑपरेशन के अनुमानित क्रम की जानकारी
इस सेक्शन में, कैमरा एपीआई का इस्तेमाल करते समय किए जाने वाले ज़रूरी चरणों के बारे में पूरी जानकारी दी गई है. एचआईडीएल इंटरफ़ेस की परिभाषाओं के लिए, कृपया platform/hardware/interfaces/camera/ देखें.
कैमरा डिवाइसों की गिनती करना, उन्हें खोलना, और चालू सेशन बनाना
- शुरू होने के बाद, फ़्रेमवर्क उन सभी कैमरा प्रोवाइडर की जानकारी इकट्ठा करना शुरू कर देता है जो
ICameraProviderइंटरफ़ेस लागू करते हैं. अगर ऐसी सेवा देने वाली कंपनी या कंपनियां मौजूद हैं, तो फ़्रेमवर्क कनेक्शन बनाने की कोशिश करेगा. - फ़्रेमवर्क,
ICameraProvider::getCameraIdList()के ज़रिए कैमरा डिवाइसों की गिनती करता है. - फ़्रेमवर्क,
ICameraProvider::getCameraDeviceInterface_VX_X()को कॉल करके एक नयाICameraDeviceइंस्टैंशिएट करता है. - फ़्रेमवर्क,
ICameraDevice::open()को कॉल करके नया चालू कैप्चर सेशन ICameraDeviceSession बनाता है.
कैमरे का चालू सेशन इस्तेमाल करना
- फ़्रेमवर्क, एचएएल डिवाइस को इनपुट/आउटपुट स्ट्रीम की सूची के साथ
ICameraDeviceSession::configureStreams()कॉल करता है. - फ़्रेमवर्क, इस्तेमाल के कुछ उदाहरणों के लिए डिफ़ॉल्ट सेटिंग का अनुरोध करता है. इसके लिए,
ICameraDeviceSession::constructDefaultRequestSettings()को कॉल किया जाता है.ICameraDevice::openकेICameraDeviceSessionबनाने के बाद, ऐसा कभी भी हो सकता है. - फ़्रेमवर्क, डिफ़ॉल्ट सेटिंग के किसी एक सेट के आधार पर सेटिंग के साथ, HAL को पहला कैप्चर अनुरोध बनाता है और भेजता है. साथ ही, इसमें कम से कम एक आउटपुट स्ट्रीम होती है, जिसे फ़्रेमवर्क ने पहले रजिस्टर किया था. इसे
ICameraDeviceSession::processCaptureRequest()के साथ HAL को भेजा जाता है. जब तक HAL अगले अनुरोध को भेजने के लिए तैयार नहीं हो जाता, तब तक उसे इस कॉल को वापस भेजने से रोकना होगा. - फ़्रेमवर्क, ज़रूरत के मुताबिक अन्य इस्तेमाल के उदाहरणों के लिए, डिफ़ॉल्ट सेटिंग बफ़र पाने के लिए अनुरोध और कॉल
ICameraDeviceSession::constructDefaultRequestSettings()सबमिट करता रहता है. - जब किसी अनुरोध को कैप्चर करना शुरू किया जाता है (सेंसर, कैप्चर के लिए एक्सपोज़ होना शुरू हो जाता है), तब HAL,
ICameraDeviceCallback::notify()को SHUTTER मैसेज के साथ कॉल करता है. इसमें फ़्रेम नंबर और एक्सपोज़र शुरू होने का टाइमस्टैंप शामिल होता है. अनुरोध के लिए, पहलेprocessCaptureResult()कॉल से पहले इस सूचना वाले कॉलबैक का होना ज़रूरी नहीं है. हालांकि, किसी ऐप्लिकेशन को कैप्चर के लिए तब तक कोई नतीजा नहीं मिलता, जब तक उस कैप्चर के लिएnotify()को कॉल नहीं किया जाता. - पाइपलाइन में कुछ समय लगने के बाद, HAL, फ़्रेमवर्क को
ICameraDeviceCallback::processCaptureResult()के साथ कैप्चर किए गए डेटा को वापस भेजना शुरू कर देता है. ये जवाब उसी क्रम में मिलते हैं जिस क्रम में अनुरोध सबमिट किए गए थे. कैमरा एचएएल डिवाइस की पाइपलाइन डेप्थ के आधार पर, एक साथ कई अनुरोध किए जा सकते हैं.
कुछ समय बाद, इनमें से कोई एक नतीजा दिखेगा:
- फ़्रेमवर्क, नए अनुरोध सबमिट करना बंद कर सकता है. साथ ही, मौजूदा कैप्चर के पूरा होने का इंतज़ार कर सकता है. जैसे, सभी बफ़र भर गए हैं और सभी नतीजे मिल गए हैं. इसके बाद, वह
ICameraDeviceSession::configureStreams()को फिर से कॉल कर सकता है. इससे, इनपुट/आउटपुट स्ट्रीम के नए सेट के लिए, कैमरा हार्डवेयर और पाइपलाइन रीसेट हो जाती है. पिछली स्ट्रीम के कॉन्फ़िगरेशन का इस्तेमाल करके, कुछ स्ट्रीम फिर से इस्तेमाल की जा सकती हैं. इसके बाद, फ़्रेमवर्क पहले कैप्चर अनुरोध से HAL तक काम करता रहता है. ऐसा तब होता है, जब कम से कम एक रजिस्टर की गई आउटपुट स्ट्रीम मौजूद हो. (ऐसा न होने पर, सबसे पहलेICameraDeviceSession::configureStreams()ज़रूरी है.) - कैमरे का सेशन खत्म करने के लिए, फ़्रेमवर्क
ICameraDeviceSession::close()को कॉल कर सकता है. जब फ़्रेमवर्क से कोई अन्य कॉल चालू न हो, तब इस फ़ंक्शन को किसी भी समय कॉल किया जा सकता है. हालांकि, जब तक सभी कैप्चर पूरे नहीं हो जाते, तब तक कॉल ब्लॉक हो सकता है. इसका मतलब है कि सभी नतीजे मिल गए हैं और सभी बफ़र भर गए हैं.close()कॉल के वापस आने के बाद, HAL सेICameraDeviceCallbackको और कॉल करने की अनुमति नहीं है.close()कॉल शुरू होने के बाद, फ़्रेमवर्क किसी अन्य HAL डिवाइस फ़ंक्शन को कॉल नहीं कर सकता. - गड़बड़ी या अन्य एसिंक्रोनस इवेंट के मामले में, HAL को सही गड़बड़ी/इवेंट मैसेज के साथ
ICameraDeviceCallback::notify()को कॉल करना होगा. डिवाइस में हुई गंभीर गड़बड़ी की सूचना मिलने के बाद, HAL को इस तरह काम करना चाहिए जैसे उस परclose()को कॉल किया गया हो. हालांकि, एचएएल कोnotify()को कॉल करने से पहले, सभी लंबित कैप्चर रद्द करने या पूरे करने होंगे, ताकि जबnotify()को गंभीर गड़बड़ी के साथ कॉल किया जाए, तो फ़्रेमवर्क को डिवाइस से आगे के कॉलबैक न मिलें.close()के अलावा अन्य तरीकों को, गंभीर गड़बड़ी के मैसेज सेnotify()तरीके के वापस आने के बाद -ENODEV या NULL दिखाना चाहिए.
चौथी इमेज. कैमरे के काम करने का फ़्लो
हार्डवेयर लेवल
कैमरा डिवाइस, अपनी क्षमताओं के आधार पर कई हार्डवेयर लेवल लागू कर सकते हैं. ज़्यादा जानकारी के लिए, हार्डवेयर लेवल की ज़रूरी शर्तें देखें.
ऐप्लिकेशन कैप्चर करने के अनुरोध, 3A कंट्रोल, और प्रोसेसिंग पाइपलाइन के बीच इंटरैक्शन
3A कंट्रोल ब्लॉक में मौजूद सेटिंग के आधार पर, कैमरा पाइपलाइन ऐप्लिकेशन के कैप्चर अनुरोध में मौजूद कुछ पैरामीटर को अनदेखा करती है. इसके बजाय, यह 3A कंट्रोल रूटीन से मिली वैल्यू का इस्तेमाल करती है. उदाहरण के लिए, जब ऑटो-एक्सपोज़र चालू होता है, तो सेंसर के एक्सपोज़र टाइम, फ़्रेम की अवधि, और सेंसिटिविटी पैरामीटर को प्लैटफ़ॉर्म के 3A एल्गोरिदम से कंट्रोल किया जाता है. साथ ही, ऐप्लिकेशन की ओर से तय की गई वैल्यू को अनदेखा कर दिया जाता है. 3A रूटीन के ज़रिए फ़्रेम के लिए चुनी गई वैल्यू, आउटपुट मेटाडेटा में रिपोर्ट की जानी चाहिए. यहां दी गई टेबल में, 3A कंट्रोल ब्लॉक के अलग-अलग मोड और इन मोड से कंट्रोल की जाने वाली प्रॉपर्टी के बारे में बताया गया है. इन प्रॉपर्टी की परिभाषाओं के लिए, platform/system/media/camera/docs/docs.html फ़ाइल देखें.
| पैरामीटर | राज्य | कंट्रोल की गई प्रॉपर्टी |
|---|---|---|
| android.control.aeMode | बंद | कोई नहीं |
| चालू है | android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (if supported) android.lens.filterDensity (if supported) | |
| 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 | बंद | कोई नहीं |
| WHITE_BALANCE_* | android.colorCorrection.transform. अगर android.colorCorrection.mode की वैल्यू FAST या HIGH_QUALITY है, तो प्लैटफ़ॉर्म के हिसाब से बदलाव किए जाते हैं. | |
| android.control.afMode | बंद | कोई नहीं |
| FOCUS_MODE_* | android.lens.focusDistance | |
| android.control.videoStabilization | बंद | कोई नहीं |
| चालू है | वीडियो स्टेबलाइज़ेशन की सुविधा लागू करने के लिए, android.scaler.cropRegion को अडजस्ट कर सकता है | |
| android.control.mode | बंद | AE, AWB, और AF बंद हैं |
| ऑटो | AE, AWB, और AF की अलग-अलग सेटिंग का इस्तेमाल किया जाता है | |
| SCENE_MODE_* | ऊपर दिए गए सभी पैरामीटर को बदल सकता है. 3A के अलग-अलग कंट्रोल बंद हैं. |
आकृति 2 में इमेज प्रोसेसिंग ब्लॉक में मौजूद सभी कंट्रोल, एक ही सिद्धांत पर काम करते हैं. आम तौर पर, हर ब्लॉक में तीन मोड होते हैं:
- बंद है: प्रोसेसिंग ब्लॉक करने की यह सुविधा बंद है. डेमोज़ेक, रंग में सुधार करने, और टोन कर्व अडजस्टमेंट वाले ब्लॉक को बंद नहीं किया जा सकता.
- तेज़: इस मोड में, प्रोसेसिंग ब्लॉक से आउटपुट फ़्रेम रेट पर कोई असर नहीं पड़ता. हालांकि, इस मोड में सबसे अच्छी क्वालिटी का आउटपुट मिलता है. आम तौर पर, इसका इस्तेमाल झलक देखने या वीडियो रिकॉर्ड करने के मोड के लिए किया जाता है. इसके अलावा, इसका इस्तेमाल स्थिर इमेज के लिए बर्स्ट कैप्चर के लिए भी किया जाता है. कुछ डिवाइसों पर, यह मोड बंद मोड के बराबर हो सकता है. इसका मतलब है कि फ़्रेम रेट को कम किए बिना कोई प्रोसेसिंग नहीं की जा सकती. वहीं, कुछ डिवाइसों पर यह मोड, HIGH_QUALITY मोड के बराबर हो सकता है. इसका मतलब है कि सबसे अच्छी क्वालिटी में भी फ़्रेम रेट कम नहीं होता.
- HIGH_QUALITY: इस मोड में, प्रोसेसिंग ब्लॉक को सबसे अच्छी क्वालिटी का नतीजा देना चाहिए. इसके लिए, आउटपुट फ़्रेम रेट को ज़रूरत के हिसाब से कम किया जा सकता है. आम तौर पर, इसका इस्तेमाल अच्छी क्वालिटी की इमेज कैप्चर करने के लिए किया जाता है. कुछ ब्लॉक में, मैन्युअल कंट्रोल शामिल होता है. इसे FAST या HIGH_QUALITY के बजाय चुना जा सकता है. उदाहरण के लिए, कलर करेक्शन ब्लॉक, कलर ट्रांसफ़ॉर्म मैट्रिक्स के साथ काम करता है. वहीं, टोन कर्व अडजस्टमेंट, किसी भी ग्लोबल टोन मैपिंग कर्व के साथ काम करता है.
कैमरा सबसिस्टम के लिए ज़्यादा से ज़्यादा फ़्रेम रेट कई बातों पर निर्भर करता है:
- आउटपुट इमेज स्ट्रीम के लिए अनुरोध किए गए रिज़ॉल्यूशन
- इमेजर पर बिनिंग/स्किपिंग मोड की उपलब्धता
- इमेजर इंटरफ़ेस का बैंडविड्थ
- अलग-अलग आईएसपी प्रोसेसिंग ब्लॉक का बैंडविड्थ
ये फ़ैक्टर, अलग-अलग आईएसपी और सेंसर के हिसाब से अलग-अलग हो सकते हैं. इसलिए, कैमरा HAL इंटरफ़ेस, बैंडविड्थ से जुड़ी पाबंदियों को जितना हो सके उतना आसान मॉडल में बदलने की कोशिश करता है. पेश किए गए मॉडल की ये विशेषताएं हैं:
- इमेज सेंसर को हमेशा सबसे कम रिज़ॉल्यूशन में आउटपुट देने के लिए कॉन्फ़िगर किया जाता है. यह रिज़ॉल्यूशन, ऐप्लिकेशन के अनुरोध किए गए आउटपुट स्ट्रीम के साइज़ के हिसाब से तय होता है. सबसे छोटा रिज़ॉल्यूशन, अनुरोध की गई सबसे बड़ी आउटपुट स्ट्रीम के साइज़ के बराबर होना चाहिए.
- कोई भी अनुरोध, कॉन्फ़िगर की गई किसी भी या सभी आउटपुट स्ट्रीम का इस्तेमाल कर सकता है. इसलिए, सेंसर और आईएसपी को इस तरह कॉन्फ़िगर किया जाना चाहिए कि वे एक ही समय में, एक ही कैप्चर को सभी स्ट्रीम पर स्केल कर सकें.
- जिन अनुरोधों में JPEG स्ट्रीम शामिल नहीं होती हैं उनके लिए, JPEG स्ट्रीम को प्रोसेस की गई YUV स्ट्रीम की तरह इस्तेमाल किया जाता है. जिन अनुरोधों में सीधे तौर पर JPEG स्ट्रीम का रेफ़रंस दिया जाता है उनके लिए, JPEG स्ट्रीम को JPEG स्ट्रीम की तरह इस्तेमाल किया जाता है.
- JPEG प्रोसेसर, कैमरे की बाकी पाइपलाइन के साथ-साथ काम कर सकता है. हालांकि, यह एक बार में एक से ज़्यादा कैप्चर प्रोसेस नहीं कर सकता.