Android 11 के Camera इमेज टेस्ट सुइट की रिलीज़ की जानकारी

इस पेज पर, Android 11 में कैमरा इमेज टेस्ट सुइट (आईटीएस) में हुए बदलावों के बारे में खास जानकारी दी गई है. ये बदलाव इन कैटगरी में आते हैं:

• हार्डवेयर में बदलाव
• एपीआई लेवल 1 के लिए ज़रूरी टेस्ट
• लाइट की पुष्टि की गई है
• सीन के नाम में बदलाव
• बदलावों और जोड़ों की जांच करना
• सीमित तौर पर कैमरे की जांच करने की सुविधा को बेहतर बनाया गया है

हार्डवेयर में बदलाव

Android 11 में, हार्डवेयर से जुड़े कई बदलाव किए गए हैं. इनसे, डिवाइस की कीमत कम करने और उपलब्धता बढ़ाने में मदद मिलेगी. ये बदलाव इन कैटगरी में आते हैं:

• अन्य मैन्युफ़ैक्चरर
• मैन्युफ़ैक्चरिंग के एक जैसे तरीके
• टैबलेट के लिए ज़्यादा विकल्प
• टैबलेट पर खोले जाने वाले आइटम की संख्या कम करना
• नया सेंसर फ़्यूज़न कंट्रोलर

अन्य मैन्युफ़ैक्चरर

Rahi Systems, हमारे मौजूदा सप्लायर MYWAY design के साथ-साथ, आईटीएस टेस्ट इनकलूज़र बनाने की ज़रूरी शर्तें पूरी करता है. ज़रूरी शर्तें पूरी करने वाले वेंडर के लिए, कंपनी की जानकारी इस तरह की होनी चाहिए:

• Rahi Systems Inc.
  48303 Fremont Blvd, Fremont CA 94538, USA
  rahisystems.com/products/android-device-testing-equipment/
  androidpartner@rahisystems.com
  +1-510-319-3802

• MYWAY डिज़ाइन
  4F., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

प्रॉडक्ट बनाने के यूनिफ़ाइड तरीके

Rev1 रेगुलर फ़ील्ड-ऑफ़-व्यू (RFoV) ITS-इन-अ-बॉक्स टेस्ट अटैचमेंट को फिर से डिज़ाइन किया गया है, ताकि वाइड फ़ील्ड-ऑफ़-व्यू (WFoV) बॉक्स और सेंसर फ़्यूज़न बॉक्स टेस्ट अटैचमेंट के ज़रिए इस्तेमाल किए जा रहे मैन्युफ़ैक्चरिंग तरीकों का इस्तेमाल किया जा सके. दोनों डिज़ाइन की सुविधाएं एक जैसी हैं. आसानी से पहचानने के लिए, डिज़ाइन को rev1a कहा जाता है. रीडिज़ाइन की मदद से, मैन्युफ़ैक्चरर सभी टेस्ट इनकलूज़र बनाने के लिए, एक तरह का प्लास्टिक स्टॉक कर सकते हैं. इसके अलावा, टैबलेट और लाइट होल्डर को फिर से डिज़ाइन किया गया है, ताकि टैबलेट और एलईडी लाइट बार में अलग-अलग तरह के बदलाव हो सकें.

नई जानकारी और मैकेनिकल ड्रॉइंग डाउनलोड करने के लिए, RFoV बॉक्स (rev1a) और WFoV बॉक्स (rev2.9) देखें.

टैबलेट के लिए ज़्यादा विकल्प

Samsung Galaxy Tab A 10.1 और Chuwi Hi9 Air 10.1 जैसे टैबलेट, सुझाए गए टैबलेट की सूची में जोड़े गए हैं. यह महत्वपूर्ण है कि कैप्चर की गई छवियों में बैंडिंग को हटाने के लिए स्क्रीन की चमक को समायोजित करने के लिए टैबलेट में पल्स विड्थ मॉड्यूलेशन (PWM) न हो.

सुझाए गए टैबलेट के बारे में नई जानकारी के लिए, टैबलेट से जुड़ी ज़रूरी शर्तें देखें.

टैबलेट को कम बार खोलना

Galaxy Tab A 10.1 का इस्तेमाल करने की अनुमति देने के लिए, RFoV (rev1a) और WFoV (rev2) टेस्ट इनकलूज़र, दोनों के लिए टैबलेट के खोलने की ऊंचाई को थोड़ा कम किया गया है. इन बदलावों को दिखाने वाले रिविज़न, rev1a.1 और rev2.9 हैं. इन ड्रॉइंग के लिए, RFoV बॉक्स (Rev1a) और WFoV बॉक्स (Rev2.9) देखें.

नया सेंसर फ़्यूज़न कंट्रोलर

सेंसर फ़्यूज़न कंट्रोलर के लिए, हार्डवेयर को फिर से डिज़ाइन किया गया है, ताकि इसे बेहतर तरीके से बनाया जा सके. नया कंट्रोलर Arduino पर आधारित है. इसमें कस्टम रूटिंग बोर्ड शील्ड है, जो Arduino के ऊपर माउंट होता है. पहली इमेज में शील्ड और दूसरी इमेज के साथ बाड़ के लिए मैकेनिकल ड्रॉइंग दिखाई गई है. नए कंट्रोलर को 5 V की एक ही सप्लाई से पावर मिलती है, जो सीधे मोटर को पावर देती है. इलेक्ट्रॉनिक्स को पूरी तरह से यूएसबी कनेक्टर से कंट्रोल किया जाता है. अलग से पावर सप्लाई की मदद से कंट्रोल इलेक्ट्रॉनिक्स और सर्वो मोटर को अलग-अलग रखा जा सकता है. इसके अलावा, एक कंट्रोलर ज़्यादा से ज़्यादा छह सर्वो मोटर को कंट्रोल कर सकता है.

पहली इमेज. Arduino शील्ड का टॉप व्यू

दूसरी इमेज. एनक्लोज़र का डिज़ाइन

Android 11, मौजूदा नियंत्रकों के साथ पुराने सिस्टम के साथ काम करता है. Arduino-आधारित कंट्रोलर की मदद से टेस्टिंग शुरू करने के लिए:

python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion

पहला एपीआई लेवल

Android 10 में, ITS टेस्ट को MANDATED और NOT_YET_MANDATED के तौर पर दिखाया जाता है. Android 10 डिवाइस के तौर पर लॉन्च करने के लिए, सभी MANDATED टेस्ट पास होने चाहिए. NOT_YET_MANDATED टेस्ट में गड़बड़ी हो सकती है, लेकिन सीटीएस की पुष्टि करने वाले टूल की रिपोर्टिंग के लिए, उन्हें PASS के तौर पर टेबल में शामिल किया जाता है. MANDATED की जांच की ज़रूरी शर्तें, अपग्रेड किए गए डिवाइसों पर भी लागू होती हैं. अपग्रेड किए गए डिवाइसों को सभी MANDATED टेस्ट पास करने की ज़रूरी शर्त की वजह से, टेस्ट को MANDATED टेस्ट में बदलने में देरी हुई. ऐसा इसलिए हुआ, क्योंकि पुराने डिवाइसों को भी टेस्ट पास करने होंगे.

Android 11 में, MANDATED टेस्ट, फ़ोन की प्रॉपर्टी से मिले पहले एपीआई लेवल के फ़्लैग के हिसाब से होते हैं. Android 11 पर अपग्रेड किए जा रहे डिवाइसों के लिए, जांच NOT_YET_MANDATED जांच के तौर पर की जाती है. इसका मतलब है कि कोई जांच पूरी न होने पर भी, उसे CtsVerifier.apk में PASS के तौर पर टेबल किया जा सकता है.

उदाहरण के लिए:

• Android 11 में, test_channel_saturation टेस्ट MANDATED उन डिवाइसों के लिए है जिनका पहला एपीआई लेवल 29 से ज़्यादा है.
• Android 10 में, सभी डिवाइसों के लिए test_channel_saturation टेस्ट MANDATED है.

सीन की लाइटिंग की पुष्टि करना

Android 11 में, सीन की लाइटिंग की पुष्टि करने के लिए, सीन के कोनों में मौजूद रोशनी का विश्लेषण किया जाता है. मैन्युअल तरीके से बनाए गए सभी सीन की लाइटिंग की पुष्टि की जाती है. साथ ही, टैबलेट पर बनाए गए सीन की पुष्टि, RFoV टेस्ट रिग में RFoV कैमरों और WFoV टेस्ट रिग में WFoV कैमरों के लिए की जाती है. अगर रोशनी का लेवल कम है, तो गड़बड़ी की सूचना दी जाती है और जांच पूरी नहीं हो पाती.

सीन के नाम में बदलाव

Android 10 की ज़्यादातर जांचों में, पहले सीन को शामिल किया जाता है. यह जांच में लगने वाले कुल समय का एक बड़ा हिस्सा होता है. अगर सीन 1 में कोई भी टेस्ट पास नहीं होता है, तो पूरे सीन को फिर से चलाना होगा. डिज़ाइन के हिसाब से, पूरे सीन को फिर से चलाने पर, मार्जिनल टेस्ट पास होने की संभावना कम हो जाती है. Android 11 में, पहले सीन को दो सीन, scene1_1 और scene1_2 में बांटकर, फिर से चलाने में लगने वाला समय कम हो जाता है.

यहां दी गई टेबल में, अलग-अलग सीन के लिए Pixel 4 के रीयर कैमरे के फ़ोटो खींचने में लगने वाले समय की जानकारी दी गई है. जांच की संख्या को टेस्ट के समय के हिसाब से बांटा जाता है, न कि जांच की संख्या के हिसाब से.

इसके अलावा, नाम को साफ़ करने की सुविधा भी है. सीन 2 को अक्षरों से और सीन 1 को संख्याओं से बांटा गया है. अलग-अलग एक्सटेंशन के नाम इस तरह हैं:

• एक ही चार्ट वाले सीन, लेकिन अलग-अलग टेस्ट: *_1,2,3
• अलग-अलग चार्ट वाले, लेकिन एक जैसे टेस्ट वाले सीन: *_a,b,c

बदलावों को टेस्ट करना

पहले एपीआई लेवल का इस्तेमाल करने के लिए अपडेट किए गए टेस्ट

Android 11 में, पहले एपीआई लेवल फ़्लैग का इस्तेमाल करने के लिए, नीचे दी गई टेबल में मौजूद टेस्ट को अपडेट किया जाता है. इन सभी टेस्ट में, एपीआई लेवल 29 का इस्तेमाल किया जाता है. हालांकि, test_tonemap_curve टेस्ट में एपीआई लेवल 30 का इस्तेमाल किया जाता है.

बदलावों के साथ टेस्ट

इस टेबल में दिए गए टेस्ट Android 11 में अपडेट किए गए हैं. बदलावों के बारे में जानकारी, बदलावों की जानकारी कॉलम में दी गई है.

नए टेस्ट

इस टेबल में दिए गए टेस्ट Android 11 में चालू हैं. टेबल में टेस्ट की खास जानकारी दी गई है. साथ ही, इन सेक्शन में इनके बारे में ज़्यादा जानकारी दी गई है.

scene0/test_vibration_restriction

इस टेस्ट के लिए किसी खास सीन की ज़रूरत नहीं होती. हालांकि, जांचा जा रहा डिवाइस (DUT), किसी कठोर सतह पर रखा गया हो या उस पर माउंट किया गया हो. इसमें, एक बॉक्स में आईटीएस टेस्टिंग के लिए बने कवर पर माउंट करना भी शामिल है.

दावा करना

• कैमरा इस्तेमाल करने के दौरान, कोई वाइब्रेशन नहीं हुआ

scene2_a/test_jpeg_quality

Method

JPEG फ़ाइल के अलग-अलग हिस्सों को दो-बाइट मार्कर से तय किया जाता है. ज़्यादा जानकारी के लिए, JPEG में देखें.

यह टेस्ट, JPEG कैप्चर से क्वांटिज़ेशन मैट्रिक्स निकालता है. JPEG कैप्चर में, क्वांटाइज़ेशन मैट्रिक के लिए मार्कर, [255, 219] क्रम है. मार्कर मिलने पर, सूची के अगले दो आइटम साइज़ होते हैं. आम तौर पर, JPEG DQT साइज़ मार्कर [0, 132] = 256*0+132 = 132 होता है. यह JPEG कैप्चर में DQT डेटा के साइज़ के हिसाब से होता है. एम्बेड किया गया डेटा इस फ़ॉर्मैट में होता है: [255, 219, 0, 132, 0 (ल्यूमा मार्कर), 8x8 ल्यूमा मैट्रिक्स, 1 (क्रोमा मार्कर), 8x8 क्रोमा मैट्रिक्स].

ल्यूमा मैट्रिक्स मार्कर के लिए 0 और क्रोमा मार्कर के लिए 1, कई डिवाइसों के लिए एक जैसा दिखता है. इनमें ऐसे फ़ोन भी शामिल हैं जो JPEG फ़ाइल में, दोनों मैट्रिक्स को अलग-अलग DQT सेक्शन में बांटते हैं. क्रोमा मैट्रिक्स की तुलना में लूमा मैट्रिक्स ज़्यादा अलग-अलग तरह के हो सकते हैं, क्योंकि क्रोमा और JPEG इमेज के मुकाबले, मानवीय आंख ल्यूमा के प्रति ज़्यादा संवेदनशील होती है.

यहां क्वालिटी फ़ैक्टर के लिए, निकाले गए ल्यूमा और क्रोमा मैट्रिक के सैंपल दिखाए गए हैं. ये क्वालिटी फ़ैक्टर, ITS टेस्ट रिग के साथ scene2_a को कैप्चर करने वाले Pixel 4 के पीछे वाले कैमरे के लिए 85 और 25 हैं. कम क्वालिटी की सेटिंग के लिए, मैट्रिक वैल्यू काफ़ी बढ़ जाती हैं (जिससे ज़्यादा कंप्रेसन का पता चलता है). ये मैट्रिक्स, स्क्रिप्ट के साथ सिर्फ़ तब प्रिंट किए जाते हैं, जब debug=True फ़्लैग लागू किया गया हो. ध्यान दें कि क्रोमा मैट्रिक की तुलना में, ल्यूमा मैट्रिक में एंट्री में ज़्यादा अंतर है.

    luma matrix (quality = 85)    chroma matrix (quality = 85)

    [[ 5  3  4  4  4  3  5  4]    [[ 5  5  5  7  6  7 14  8]
     [ 4  4  5  5  5  6  7 12]     [ 8 14 30 20 17 20 30 30]
     [ 8  7  7  7  7 15 11 11]     [30 30 30 30 30 30 30 30]
     [ 9 12 17 15 18 18 17 15]     [30 30 30 30 30 30 30 30]
     [17 17 19 22 28 23 19 20]     [30 30 30 30 30 30 30 30]
     [26 21 17 17 24 33 24 26]     [30 30 30 30 30 30 30 30]
     [29 29 31 31 31 19 23 34]     [30 30 30 30 30 30 30 30]
     [36 34 30 36 28 30 31 30]]     [30 30 30 30 30 30 30 30]]

    luma matrix (quality = 25)            chroma matrix (quality = 25)

    [[ 32  22  24  28  24  20  32  28]    [[ 34  36  36  48  42  48  94  52]
     [ 26  28  36  34  32  38  48  80]     [ 52  94 198 132 112 132 198 198]
     [ 52  48  44  44  48  98  70  74]     [198 198 198 198 198 198 198 198]
     [ 58  80 116 102 122 120 114 102]     [198 198 198 198 198 198 198 198]
     [112 110 128 144 184 156 128 136]     [198 198 198 198 198 198 198 198]
     [174 138 110 112 160 218 162 174]     [198 198 198 198 198 198 198 198]
     [190 196 206 208 206 124 154 226]     [198 198 198 198 198 198 198 198]
     [242 224 200 240 184 202 206 198]]     [198 198 198 198 198 198 198 198]]

तीसरे चित्र में, Pixel 4 के रियर कैमरे की औसत मैट्रिक वैल्यू और JPEG क्वालिटी की तुलना की गई है. JPEG क्वालिटी बढ़ने पर, कंप्रेशन का लेवल (लूमा/क्रोमा डीक्यूटी मैट्रिक्स औसत) कम हो जाता है.

तीसरी इमेज. Pixel 4 के पीछे वाले कैमरे के ल्यूमा/क्रोमा DQT मैट्रिक्स के औसत बनाम JPEG की क्वालिटी

एश्यर्ट

• [25, 45, 65, 86] के लिए, क्वालिटी में +20 में क्वांटाइज़ेशन की संख्या को कम करने का औसत 20% है.
• DQT मैट्रिक्स पेलोड वर्ग संख्याएं हैं.

चौथे चित्र में, ऐसे फ़ोन का उदाहरण दिया गया है जो टेस्ट में पास नहीं हुआ. ध्यान दें कि बहुत हल्की क्वालिटी वाली इमेज (jpeg.quality < 50) के लिए, क्वांटाइज़ेशन मैट्रिक्स में, कंप्रेस की गई कोई संख्या नहीं बढ़ती है.

चौथी इमेज. जांच न हो पाने का उदाहरण

scene2_d/e test_num_faces

चेहरे की पहचान करने वाले एल्गोरिदम की जांच को बेहतर बनाने के लिए, चेहरे की पहचान करने वाले दो नए सीन जोड़े गए हैं. कई कैमरों की बार-बार जांच करने पर, सबसे मुश्किल चेहरा scene2_d में सबसे बाईं ओर मौजूद चेहरा हो सकता है. खास तौर पर, इस मॉडल के चेहरे पर टोपी और दाढ़ी, दोनों हैं. चेहरे के सीन में कुछ नया देखने को मिला है. नए सीन को पांचवीं और छठी इमेज में दिखाया गया है.

पांचवी इमेज. सीन2_d

छठी इमेज. scene2_e

दावा करना

• num_faces == 3

scene2_e/test_continuous_picture

Method

test_continuous_picture टेस्ट में scene2_e का इस्तेमाल किया जाता है, लेकिन इसे किसी भी फ़ेस सीन के साथ चालू किया जा सकता है. इस टेस्ट में, कैप्चर करने के अनुरोध की पहली सेटिंग android.control.afMode = 4 (CONTINUOUS_PICTURE) के साथ वीजीए रिज़ॉल्यूशन के 50 फ़्रेम कैप्चर किए जाते हैं.

3A सिस्टम, 50 फ़्रेम कैप्चर करने के बाद सेट हो जाता है.

दावा करना

• कैप्चर खत्म होने पर, 3A एक साथ काम करने की स्थिति में है.

scene_change/test_scene_change

Method

एक नया टेस्ट चालू किया गया है, ताकि यह जांच की जा सके कि android.control.afSceneChange फ़्लैग, सीन बदलने के साथ पुष्टि किया गया है या नहीं. सीन बदलने के लिए, टैबलेट पर चेहरे का सीन दिखाया जाता है. इसके बाद, सीन बदलने के लिए टैबलेट को चालू और बंद किया जाता है. इस सीन में scene2_e का फिर से इस्तेमाल किया गया है. हालांकि, यह अलग सीन में है, क्योंकि इसमें टैबलेट कंट्रोल की ज़रूरत है.

इसके अलावा, मैन्युअल तरीके से जांच करने के लिए, कैमरे के सामने हाथ हिलाकर भी सीन बदला जा सकता है.

सातवीं इमेज में, टेस्ट का टाइमिंग डायग्राम दिखाया गया है. स्क्रीन के बंद होने और कैप्चर होने के बीच के समय को, पिछले कैप्चर से मिले इवेंट के नतीजों के आधार पर अडजस्ट किया जाता है.

सातवीं इमेज. test_scene_change के लिए टाइमिंग डायग्राम

शर्तों को बदलें:

• अगर सीन बदलता है और afSceneChange == 1 मौजूद होता है, तो टेस्ट के नतीजे के तौर पर PASS दिखता है.
• अगर सीन बदलने के दौरान afSceneChange == 0 है, तो सीन बदलने की प्रोसेस को पांच फ़्रेम पहले शुरू कर दिया जाता है, ताकि afSceneChange को एफ़आईआर सबमिट करने के लिए ज़्यादा समय मिल सके.
• अगर सीन में कोई बदलाव नहीं होता और afSceneChange == 1 मौजूद होता है, तो जांच के नतीजे के तौर पर FAIL दिखता है.
• अगर कोई सीन बदलाव नहीं होता है और afSceneChange == 0 है, तो कैप्चर में सीन बदलाव पाने के लिए, सीन बदलाव 30 फ़्रेम पहले शिफ़्ट हो जाता है.

दावा

• स्क्रीन (सीन) टॉगल.
• afSceneChange फ़्लैग [0, 1] में है.
• अगर कोई सीन नहीं बदलता है, तो 3A दिखता है. यह फ़ंक्शन test_continuous_picture की तरह ही काम करता है.
• अगर afSceneChange == 1 है, तो सीन की चमक कम या ज़्यादा होनी चाहिए.
• PASS में छह कोशिशों में, पिछले नतीजों के आधार पर समय बदला गया.

scene6/test_zoom

Method

android.control.zoomRatioRange की जांच करने के लिए, एक नया सीन ज़रूरी है, क्योंकि मौजूदा सीन में ऐसी कोई सुविधा नहीं है जिसे बड़ा किया जा सके (सीन [1, 2, 4]) या सीन में ऐसे कई ऑब्जेक्ट हैं जिनकी पहचान आसानी से नहीं की जा सकती, जिससे सुविधा निकालने में मुश्किल होती है (सीन 3).

आठवें चित्र में, सर्कल के सामान्य कलेक्शन वाला नया सीन दिखाया गया है. सर्कल के कलेक्शन की मदद से, डीयूटी/चार्ट को बीच में रखने से जुड़ी ज़रूरी शर्तों में बदलाव किया जा सकता है. साथ ही, कैप्चर की गई इमेज के बीचो-बीच एक सर्कल बनाया जा सकता है. इस सीन में, पूरे टैबलेट पर 9x5 के क्रम में काले बॉर्डर वाले गोले दिख रहे हैं. स्क्रीन की दिशा दिखाने के लिए ऊपर दाएं कोने में एक गोले को वर्ग से बदल दिया जाता है. सर्कल साइज़ में, 4000x3000 सेंसर के लिए करीब 7500 पिक्सल (radius=50pixels) का क्षेत्र होता है. यह सेंसर, करीब 80 डिग्री के फ़ील्ड ऑफ़ व्यू (एफ़ओवी) के साथ कैप्चर किया जाता है.

आठवीं इमेज. test_zoom सीन

नौवीं इमेज. Pixel 4 cam[0] zoom = [1, 3.33, 5.67, 8] images with found circle

नौवें चित्र में, Pixel 4 के पीछे वाले कैमरे से ली गई इमेज दिखाई गई हैं. इन इमेज में, ज़ूम को चार चरणों में 1 से 8 गुना तक बढ़ाया गया है. इमेज का यह सेट, फ़ोकस को बीच में रखने के लिए खास तौर पर कैप्चर नहीं किया गया है. हालांकि, फ़ोन के टेस्टिंग अपर्चर का इस्तेमाल दो ओपनिंग के साथ किया गया है, ताकि सामने और पीछे के दोनों कैमरों की जांच की जा सके. केंद्र से ऑफ़सेट की उम्मीद होती है और चार्ट टैबलेट के केंद्र से थोड़ा बाएं होने पर यह दिखता है. इसके अलावा, चार्ट में 8x से ज़्यादा के ज़ूम रेशियो के साथ टेस्ट करने के लिए ज़रूरी जानकारी दिखती है.

सर्कल ढूंढना

इस टेस्ट में, findContours का इस्तेमाल करके find_circle() का तरीका शामिल है. यह सभी कॉन्टूर ढूंढता है और कॉन्टूर की खोज को, इन चीज़ों की जांच करके, अपनी पसंद के सर्कल तक सीमित करता है:

• कंटूर का क्षेत्र 10 पिक्सेल से ज़्यादा होना चाहिए.
• कॉन्टूर में NUM_PTS >= 15 होना चाहिए.
• कॉन्टूर के बीच का हिस्सा काला होना चाहिए.
• कॉन्टूर, सर्कल जैसे होने चाहिए. इसका मतलब है कि उनका क्षेत्रफल, कॉन्टूर के पाई*r2 क्षेत्रफल के करीब होना चाहिए.

टेस्ट रेंज

android.control.zoomRatioRange को 10 चरणों में बांटा गया है.

• [1, 7] टेस्ट [1, 1.67, 2.33, 3, 3.67, 4.33, 5, 5.67, 6.33, 7]

अगर सर्कल, इमेज की सीमाओं को छूता है, तो ज़ूमिंग रुक जाती है. इस बात की जांच की जाती है कि टेस्ट (10x) में, ज़रूरत के मुताबिक ज़ूम लेवल पहुंच गया है या नहीं.

दावा करना

• हर ज़ूम सेटिंग में कम से कम एक सर्कल दिखता है.
• 10x या ज़्यादा से ज़्यादा android.control.zoomRatioRange का टेस्ट किया जाता है.
• ज़ूम के साथ वृत्त का दायरा स्केल किया गया (उम्मीद के मुताबिक आरटीओएल 10%).
• ज़ूम करने पर, सर्कल के बीच के हिस्से का ऑफ़सेट, बीच के स्केल से अलग हो जाता है (आरटीओएल, उम्मीद से 10% ज़्यादा).
• ज़ूम, ज़रूरत के मुताबिक ज़ूम लेवल (2x) तक पहुंच गया है.

कैमरे की सीमित टेस्टिंग में बढ़ोतरी

Android 11 में, इस टेबल में किए गए टेस्ट LIMITED कैमरों की जांच करते हैं. नए टेस्ट के अलावा, scene4/test_aspect_ratio_and_crop टेस्ट को अपडेट किया गया है, ताकि एपीआई लेवल 30 या उससे ज़्यादा वाले LIMITED डिवाइसों की जांच की जा सके.

10वें चित्र में, Android 11 ITS सीक्रेट डिकोडर ट्रैक दिखाया गया है. सीक्रेट डिकोडर रिंग, जिससे पता चलता है कि अलग-अलग टेस्ट में कौन-कौनसी सेटिंग तय की गई हैं. गेटिंग आसानी से देखने के लिए, अलग-अलग रंगों का इस्तेमाल करती है. मुख्य गेट आइटम ये हैं:

• MANUAL_SENSOR
• READ_3A *MANUAL SENSOR की ज़रूरत है
• COMPUTE_TARGET_EXPOSURES *MANUAL SENSOR की ज़रूरत है
• PER_FRAME_CONTROL
• RAW
• SENSORS *REALTIME
• MULTI_CAMERA

MANUAL SENSOR, READ_3A, COMPUTE_TARGET_EXPOSURES, और PER_FRAME_CONTROL ज़्यादातर टेस्ट को गेट करते हैं. इसके अलावा, LIMITED डिवाइसों के लिए चालू किए गए टेस्ट, हल्के हरे रंग में हाइलाइट किए जाते हैं.

10वीं इमेज. Android 11 के लिए सीक्रेट डिकोडर रिंग