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

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

दूसरी इमेज. कैमरा पाइपलाइन
कृपया ध्यान दें कि ऊपर दिए गए डायग्राम में दिखाए गए कुछ इमेज प्रोसेसिंग ब्लॉक, शुरुआती रिलीज़ में ठीक से नहीं दिखाए गए हैं. कैमरा पाइपलाइन ये मानकर चलती है:
- आईएसपी में, आरएडब्ल्यू बेयर आउटपुट को प्रोसेस नहीं किया जाता.
- आंकड़े, सेंसर के रॉ डेटा के आधार पर जनरेट होते हैं.
- सेंसर के रॉ डेटा को YUV में बदलने वाले अलग-अलग प्रोसेसिंग ब्लॉक, किसी भी क्रम में हो सकते हैं.
- एक से ज़्यादा स्केल और काट-छांट करने वाली यूनिट दिखने पर, सभी स्केलर यूनिट, आउटपुट क्षेत्र के कंट्रोल (डिजिटल ज़ूम) को शेयर करती हैं. हालांकि, हर यूनिट का आउटपुट रिज़ॉल्यूशन और पिक्सल फ़ॉर्मैट अलग-अलग हो सकता है.
एपीआई के इस्तेमाल की खास जानकारी
यहां Android Camera API का इस्तेमाल करने के तरीके के बारे में खास जानकारी दी गई है. एपीआई कॉल के साथ-साथ, इन चरणों के बारे में ज़्यादा जानकारी के लिए,
स्टार्टअप और ऑपरेशन के अनुमानित क्रम वाला सेक्शन देखें.
- कैमरा डिवाइसों को सुनना और उनकी गिनती करना.
- डिवाइस खोलें और लिसनर को कनेक्ट करें.
- टारगेट किए गए इस्तेमाल के उदाहरण (जैसे, स्टिल कैप्चर, रिकॉर्डिंग वगैरह) के लिए आउटपुट कॉन्फ़िगर करें.
- टारगेट किए गए इस्तेमाल के उदाहरण के लिए अनुरोध बनाएं.
- अनुरोधों और बर्स्ट को कैप्चर/दोहराएं.
- नतीजे का मेटाडेटा और इमेज का डेटा पाएं.
- इस्तेमाल के उदाहरणों को स्विच करते समय, तीसरे चरण पर वापस जाएं.
एचएएल के ऑपरेशन की खास जानकारी
- कैप्चर के लिए एसिंक्रोनस अनुरोध, फ़्रेमवर्क से आते हैं.
- एचएएल डिवाइस को अनुरोधों को क्रम से प्रोसेस करना चाहिए. साथ ही, हर अनुरोध के लिए, आउटपुट के नतीजे का मेटाडेटा और एक या उससे ज़्यादा आउटपुट इमेज बफ़र बनाएं.
- अनुरोधों और नतीजों के लिए, पहले आओ पहले पाओ का नियम लागू होता है. साथ ही, यह नियम उन स्ट्रीम पर भी लागू होता है जिनका रेफ़रंस बाद के अनुरोधों में दिया गया है.
- किसी अनुरोध के सभी आउटपुट के लिए टाइमस्टैंप एक जैसे होने चाहिए, ताकि ज़रूरत पड़ने पर फ़्रेमवर्क उन्हें एक साथ मैच कर सके.
- कैप्चर कॉन्फ़िगरेशन और स्टेटस (3A रूटीन को छोड़कर) को अनुरोधों और नतीजों में शामिल किया जाता है.

तीसरी इमेज. Camera HAL के बारे में खास जानकारी
स्टार्टअप और ऑपरेशन का अनुमानित क्रम
इस सेक्शन में, कैमरा एपीआई का इस्तेमाल करते समय, ज़रूरी चरणों के बारे में पूरी जानकारी दी गई है. HIDL इंटरफ़ेस की परिभाषाओं के लिए, कृपया platform/hardware/interfaces/camera/ देखें.
कैमरा डिवाइसों की जानकारी पाना, उन्हें खोलना, और चालू सेशन बनाना
- शुरू होने के बाद, फ़्रेमवर्क उन सभी कैमरा प्रोवाइडर के लिए सुनना शुरू कर देता है जो
ICameraProvider
इंटरफ़ेस को लागू करते हैं. अगर कोई सेवा देने वाली कंपनी या कंपनियां मौजूद हैं, तो फ़्रेमवर्क उनसे कनेक्ट करने की कोशिश करेगा. - फ़्रेमवर्क,
ICameraProvider::getCameraIdList()
के ज़रिए कैमरा डिवाइसों की जानकारी देता है. - फ़्रेमवर्क, संबंधित
ICameraProvider::getCameraDeviceInterface_VX_X()
को कॉल करके एक नयाICameraDevice
इंस्टैंशिएट करता है. - फ़्रेमवर्क, नया ऐक्टिव कैप्चर सेशन ICameraDeviceSession बनाने के लिए
ICameraDevice::open()
को कॉल करता है.
चालू कैमरा सेशन का इस्तेमाल करना
- फ़्रेमवर्क, एचएएल डिवाइस पर इनपुट/आउटपुट स्ट्रीम की सूची के साथ
ICameraDeviceSession::configureStreams()
को कॉल करता है. - फ़्रेमवर्क,
ICameraDeviceSession::constructDefaultRequestSettings()
को कॉल करके, कुछ इस्तेमाल के उदाहरणों के लिए डिफ़ॉल्ट सेटिंग का अनुरोध करता है.ICameraDevice::open
केICameraDeviceSession
बनाने के बाद, ऐसा कभी भी हो सकता है. - फ़्रेमवर्क, डिफ़ॉल्ट सेटिंग के किसी एक सेट के आधार पर सेटिंग के साथ, एचएएल को पहला कैप्चर अनुरोध बनाता है और भेजता है. साथ ही, कम से कम एक आउटपुट स्ट्रीम के साथ, जिसे फ़्रेमवर्क ने पहले रजिस्टर किया है. इसे
ICameraDeviceSession::processCaptureRequest()
के साथ, एचएएल को भेजा जाता है. HAL को इस कॉल को तब तक ब्लॉक करना होगा, जब तक वह अगला अनुरोध भेजने के लिए तैयार न हो जाए. - ज़रूरत के हिसाब से, इस्तेमाल के अन्य उदाहरणों के लिए डिफ़ॉल्ट सेटिंग बफ़र पाने के लिए, फ़्रेमवर्क अनुरोध सबमिट करता रहता है और
ICameraDeviceSession::constructDefaultRequestSettings()
को कॉल करता रहता है. - जब किसी अनुरोध को कैप्चर करना शुरू किया जाता है (सेंसर कैप्चर के लिए एक्सपोज़र शुरू करता है), तो एचएएल, SHUTTER मैसेज के साथ
ICameraDeviceCallback::notify()
को कॉल करता है. इसमें फ़्रेम नंबर और एक्सपोज़र शुरू होने का टाइमस्टैंप शामिल होता है. यह सूचना देने वाला कॉलबैक, अनुरोध के लिए पहलेprocessCaptureResult()
कॉल से पहले होने की ज़रूरत नहीं है. हालांकि, किसी कैप्चर के लिए तब तक कोई नतीजा डिलीवर नहीं किया जाता, जब तक उस कैप्चर के लिएnotify()
कॉल नहीं किया जाता. - पाइपलाइन में कुछ देरी होने के बाद, एचएएल
ICameraDeviceCallback::processCaptureResult()
के साथ फ़्रेमवर्क में कैप्चर किए गए डेटा को वापस भेजना शुरू कर देता है. ये उसी क्रम में दिखाए जाते हैं जिस क्रम में अनुरोध सबमिट किए गए थे. कैमरा एचएएल डिवाइस की पाइपलाइन डेप्थ के आधार पर, एक साथ कई अनुरोध किए जा सकते हैं.
कुछ समय बाद, इनमें से कोई एक स्थिति होगी:
- फ़्रेमवर्क, नए अनुरोध सबमिट करना बंद कर सकता है. साथ ही, मौजूदा कैप्चर के पूरा होने (सभी बफ़र भर जाने और सभी नतीजे मिलने) का इंतज़ार कर सकता है. इसके बाद,
ICameraDeviceSession::configureStreams()
को फिर से कॉल कर सकता है. इससे, इनपुट/आउटपुट स्ट्रीम के नए सेट के लिए, कैमरे के हार्डवेयर और पाइपलाइन को रीसेट किया जाता है. कुछ स्ट्रीम को पिछले कॉन्फ़िगरेशन से फिर से इस्तेमाल किया जा सकता है. अगर कम से कम एक रजिस्टर की गई आउटपुट स्ट्रीम बची है, तो फ़्रेमवर्क पहले कैप्चर अनुरोध से लेकर एचएएल तक काम करता रहेगा. (अन्यथा, पहलेICameraDeviceSession::configureStreams()
की ज़रूरत होती है.) - कैमरा सेशन खत्म करने के लिए, फ़्रेमवर्क
ICameraDeviceSession::close()
को कॉल कर सकता है. इसे किसी भी समय तब कॉल किया जा सकता है, जब फ़्रेमवर्क से कोई दूसरा कॉल चालू न हो. हालांकि, कॉल तब तक ब्लॉक हो सकता है, जब तक सभी इन-फ़्लाइट कैप्चर पूरे नहीं हो जाते (सभी नतीजे वापस आ जाते हैं, सभी बफ़र भर जाते हैं).close()
कॉल वापस आने के बाद, HAL सेICameraDeviceCallback
पर कोई और कॉल करने की अनुमति नहीं है.close()
कॉल शुरू होने के बाद, हो सकता है कि फ़्रेमवर्क किसी दूसरे 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 (अगर काम करता है) 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 | बंद | कोई नहीं |
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 सेटिंग का इस्तेमाल किया जाता है | |
SCENE_MODE_* | ऊपर दिए गए सभी पैरामीटर को बदल सकता है. 3A के अलग-अलग कंट्रोल बंद हैं. |
दूसरे चित्र में, इमेज प्रोसेसिंग ब्लॉक के सभी कंट्रोल एक जैसे सिद्धांत पर काम करते हैं. आम तौर पर, हर ब्लॉक में तीन मोड होते हैं:
- बंद है: प्रोसेसिंग ब्लॉक बंद है. डेमोज़ेक, रंग में सुधार करने, और टोन कर्व अडजस्टमेंट ब्लॉक को बंद नहीं किया जा सकता.
- तेज़: इस मोड में, प्रोसेसिंग ब्लॉक, बंद मोड की तुलना में आउटपुट फ़्रेम रेट को धीमा नहीं कर सकता. हालांकि, इस पाबंदी के तहत, सबसे अच्छी क्वालिटी का आउटपुट मिलना चाहिए. आम तौर पर, इसका इस्तेमाल, स्क्रीन की झलक देखने या वीडियो रिकॉर्ड करने के मोड के लिए किया जाता है. इसके अलावा, स्टिल इमेज के लिए बर्स्ट कैप्चर मोड में भी इसका इस्तेमाल किया जा सकता है. कुछ डिवाइसों पर, यह OFF मोड के बराबर हो सकता है. इसका मतलब है कि फ़्रेम रेट को धीमा किए बिना कोई प्रोसेसिंग नहीं की जा सकती. कुछ डिवाइसों पर, यह HIGH_QUALITY मोड के बराबर हो सकता है. इसका मतलब है कि सबसे अच्छी क्वालिटी में भी फ़्रेम रेट धीमा नहीं होता.
- HIGH_QUALITY: इस मोड में, प्रोसेसिंग ब्लॉक से सबसे अच्छी क्वालिटी का नतीजा मिलना चाहिए. इसके लिए, ज़रूरत के हिसाब से आउटपुट फ़्रेम रेट को धीमा किया जा सकता है. आम तौर पर, इसका इस्तेमाल अच्छी क्वालिटी की फ़ोटो कैप्चर करने के लिए किया जाता है. कुछ ब्लॉक में मैन्युअल कंट्रोल होता है. इसे FAST या HIGH_QUALITY के बजाय चुना जा सकता है. उदाहरण के लिए, कलर करेक्शन ब्लॉक में कलर ट्रांसफ़ॉर्म मैट्रिक का इस्तेमाल किया जा सकता है, जबकि टोन कर्व अडजस्टमेंट में किसी भी तरह के ग्लोबल टोन मैपिंग कर्व का इस्तेमाल किया जा सकता है.
कैमरे के सबसिस्टम से ज़्यादा से ज़्यादा फ़्रेम रेट मिल सकता है. यह कई बातों पर निर्भर करता है:
- आउटपुट इमेज स्ट्रीम के लिए अनुरोध किए गए रिज़ॉल्यूशन
- इमेजर पर बाइनिंग/स्किपिंग मोड की उपलब्धता
- इमेजर इंटरफ़ेस की बैंडविड्थ
- अलग-अलग आईएसपी प्रोसेसिंग ब्लॉक का बैंडविड्थ
अलग-अलग आईएसपी और सेंसर के बीच ये फ़ैक्टर काफ़ी अलग-अलग हो सकते हैं. इसलिए, कैमरा एचएएल इंटरफ़ेस, बैंडविड्थ की पाबंदियों को जितना हो सके उतना आसान मॉडल में बदलने की कोशिश करता है. यहां दिए गए मॉडल में ये विशेषताएं हैं:
- ऐप्लिकेशन के अनुरोध किए गए आउटपुट स्ट्रीम साइज़ के हिसाब से, इमेज सेंसर को हमेशा सबसे कम रिज़ॉल्यूशन के लिए कॉन्फ़िगर किया जाता है. सबसे छोटे रिज़ॉल्यूशन का मतलब है कि वह कम से कम उतना ही बड़ा हो जितना कि अनुरोध की गई सबसे बड़ी आउटपुट स्ट्रीम का साइज़.
- किसी भी अनुरोध में, फ़िलहाल कॉन्फ़िगर की गई किसी भी या सभी आउटपुट स्ट्रीम का इस्तेमाल किया जा सकता है. इसलिए, सेंसर और आईएसपी को कॉन्फ़िगर किया जाना चाहिए, ताकि एक ही समय पर सभी स्ट्रीम में एक कैप्चर को स्केल किया जा सके.
- जिन अनुरोधों में JPEG स्ट्रीम शामिल नहीं होतीं उनके लिए, ये प्रोसेस की गई YUV स्ट्रीम की तरह काम करती हैं. जिन अनुरोधों में इनका सीधे तौर पर रेफ़रंस दिया जाता है वे JPEG स्ट्रीम के तौर पर काम करती हैं.
- JPEG प्रोसेसर, कैमरे की बाकी पाइपलाइन के साथ-साथ चल सकता है. हालांकि, एक बार में एक से ज़्यादा कैप्चर प्रोसेस नहीं किए जा सकते.