اختبارات ITS للكاميرا

تقدّم هذه الصفحة قائمة شاملة بالاختبارات ضمن "مجموعة اختبارات الصور" (ITS) الخاصة بالكاميرا، والتي تشكّل جزءًا من أداة التحقّق من "مجموعة اختبارات التوافق" (CTS) الخاصة بنظام التشغيل Android. اختبارات ITS هي اختبارات وظيفية، ما يعني أنّها لا تقيس جودة الصورة، ولكنّها تُثبت أنّ جميع وظائف الكاميرا المُعلَن عنها تعمل كما هو متوقّع. يتيح هذا المستند للمطوّرين والمختبِرين فهم ما تفعله الاختبارات الفردية وكيفية تصحيح أخطاء الاختبار.

تحظر تقنية ITS للكاميرا الاختبارات حسب خصائص الكاميرا المطلوبة ومستوى واجهة برمجة التطبيقات و مستوى فئة أداء الوسائط (MPC). بالنسبة إلى مستوى واجهة برمجة التطبيقات، يستخدم ITS ro.product.first_api_level لفرض قيود على الاختبارات التي تمت إضافتها في مستوى معيّن من واجهة برمجة التطبيقات والتيتهدف إلى فحص تجارب المستخدمين السلبية للوظائف في مستويات واجهة برمجة التطبيقات الأقل. يستخدم فريق ITS ro.vendor.api_level لفرض قيود على اختبارات الميزات التي تمت إضافتها في مستوى معيّن من واجهة برمجة التطبيقات وتتطلّب إمكانات أجهزة جديدة. إذا تم تحديد ro.odm.build.media_performance_class لجهاز معيّن، تتطلّب ITS إجراء اختبارات معيّنة استنادًا إلى مستوى MPC.

يتم تجميع الاختبارات حسب المشهد على النحو التالي:

  • scene0: تسجيل البيانات الوصفية والارتعاش والجيروسكوب والاهتزاز
  • scene1: التعريض، والحساسية، وتعويض قيمة التعريض (EV)، وتنسيق YUV مقارنةً بتنسيقَي JPEG وRAW
  • scene2: اختبارات التعرّف على الوجوه التي تتطلّب مشاهد ملونة
  • scene3: تحسين نطاق الشبكة، حركة العدسة
  • scene4: نسبة العرض إلى الارتفاع والاقتصاص ومجال الرؤية
  • scene5: تظليل العدسة
  • scene6: التكبير/التصغير
  • scene7: تبديل الكاميرات المتعدّدة
  • scene8: التعرّض التلقائي للضوء (AE) وتوازن اللون الأبيض التلقائي (AWB) قياس المنطقة
  • scene9: ضغط JPEG
  • scene_extensions: إضافات الكاميرا
  • scene_tele: تبديل العدسة المقرّبة
  • scene_flash: الفلاش التلقائي، الحد الأدنى لمعدل عرض اللقطات
  • scene_video: انخفاض معدّل عرض اللقطات
  • sensor_fusion: توقيت الكاميرا والجيروسكوب
  • feature_combination: مجموعات الميزات
  • scene_ip: تطابق الصور بين تطبيق الكاميرا التلقائي و تطبيق Jetpack Camera (JCA)

اطّلِع على الأقسام الفردية للحصول على وصف لكل مشهد.

scene0

لا تتطلّب الاختبارات أي معلومات محدّدة عن المشهد. ومع ذلك، يجب أن يكون الهاتف ثابتًا لاختبار أداة التحكّم الدوراني والاهتزاز.

test_jitter

يقيس هذا المقياس الارتعاش في الطوابع الزمنية للكاميرا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: هناك فرق بين اللقطات لا يقل عن 30 ملي ثانية.

في الشكل التالي، لاحِظ النطاق الصغير للمحور y. إنّ الارتعاش صغير في الواقع في هذا الرسم البياني.

رسم بياني لاختبار_التشويش

الشكل 1: رسم بياني لاختبار_التشويش

test_metadata

يختبر صحة إدخالات البيانات الوصفية، من خلال الاطّلاع على نتائج الالتقاط وعلى عناصر خصائص الكاميرا. يستخدم هذا الاختبار auto_capture_request قيم التعريض والزيادة لأنّ محتوى الصورة ليس مُهمًا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتوفّر مستوى الجهاز وعلامات rollingShutterSkew وframeDuration وtimestampSource وcroppingType وblackLevelPattern وpixel_pitch و"مجال الرؤية" (FoV) و"المسافة الفائقة التركيز"، كما أنّ قيمها صالحة.

test_request_capture_match

يختبر هذا الاختبار ما إذا كان الجهاز يكتب قيمًا صحيحة للتعريض والاستفادة من خلال قراءة البيانات الوصفية لالتقاط الصور.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تتطابق قيم البيانات الوصفية التي يتم طلبها وتسجيلها في جميع اللقطات.

test_sensor_events

بالنسبة إلى الأجهزة التي تعلن عن توفّر ميزة دمج بيانات المستشعرات، يتحقّق هذا الاختبار مما إذا كان الجهاز يُجري طلبات بحث ويطبع أحداث المستشعرات. أدوات الاستشعار المتوقّعة هي مقياس التسارع والجيروسكوب ومقياس المغناطيسية. لا يعمل هذا الاختبار إلا إذا كانت الشاشة مشغّلة، ما يعني أنّ الجهاز ليس في وضع الاستعداد.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتم تلقّي أحداث كل جهاز استشعار.

test_solid_color_test_pattern

يختبر هذا الاختبار ما إذا كان يتم إنشاء أنماط اختبارية للألوان الصلبة بشكل صحيح لإيقاف صوت الكاميرا. إذا كانت ميزة كتم صوت الكاميرا متاحة، يجب أن تكون أنماط اختبار الألوان الكاملة متاحة. إذا لم تكن ميزة كتم صوت الكاميرا متاحة، لا يتم اختبار أنماط اختبار الألوان الثابتة إلا إذا تم الإعلان عن هذه الميزة.

إذا كانت الصور الأولية متاحة، يتم أيضًا اختبار عملية تحديد الألوان. الألوان التي يتم اختبارها هي الأسود والأبيض والأحمر والأزرق والأخضر. بالنسبة إلى الكاميرات التي لا تتيح استخدام الصور الخام، يتم اختبار اللون الأسود فقط.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تظهر أنماط الاختبار الصلبة المتوافقة باللون الصحيح، وهناك اختلاف منخفض في الصورة.

test_test_pattern

يختبر المَعلمة android.sensor.testPatternMode لالتقاط اللقطات لكل نمط اختبار صالح ويتحقّق من أنّه يتم إنشاء اللقطات بشكلٍ صحيح للألوان الثابتة والأشرطة الملونة. يتضمّن هذا الاختبار الخطوات التالية:

  1. التقاط صور لجميع أنماط الاختبار المتوافقة
  2. تُجري عملية تحقّق من صحة نمط اختبار الألوان الثابتة وأشرطة الألوان.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تمّ إنشاء أنماط الاختبار المتوافقة بشكلٍ صحيح.

مثال على test_test_patterns

الشكل 2: مثال على test_test_patterns

test_tonemap_curve

يختبر هذا الاختبار تحويل نمط الاختبار من تنسيق RAW إلى تنسيق YUV باستخدام خريطة نغمات خطية. يتطلب هذا الاختبار من android.sensor.testPatternMode = 2 (COLOR_BARS) إنشاء android.sensor.testPatternMode = 2 (COLOR_BARS) لإنشاء نمط صورة مثالي لتحويل مخطّط الألوان. للتحقّق من أنّ مسار المعالجة يتضمّن مخرجات ألوان مناسبة باستخدام خريطة نغمات خطية ومدخلات صور مثالية (يعتمد على test_test_patterns).

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يبدو تنسيق YUV وتنسيق RAW متشابهَين.

مثال على ملف test_tonemap_curve الخام

الشكل 3: مثال على بيانات test_tonemap_curve الأولية

مثال على YUV في test_tonemap_curve

الشكل 4: مثال على YUV في test_tonemap_curve

test_unified_timestamp

لاختبار ما إذا كانت أحداث كاميرا الاستشعار والحركة في النطاق الزمني نفسه

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تكون الطوابع الزمنية للحركة بين الطوابع الزمنية للصورتَين.

test_vibration_restriction

يختبر هذا الاختبار ما إذا كان الجهاز يعمل على النحو المتوقّع.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: لا يهتز الجهاز عند كتم صوت الكاميرا باستخدام واجهة برمجة التطبيقات restriction API.

scene1_1

scene1 هو مخطّط رمادي. يجب أن يغطي الرسم البياني الرمادي ‎30% من مركز مجال رؤية الكاميرا. من المتوقّع أن يواجه الرسم البياني الرمادي 3A (AE و AWB وAF) بشكل معتدل لأنّ المنطقة المركزية لا تتضمّن أي ميزات. ومع ذلك، يحدِّد طلب الالتقاط المشهد بأكمله الذي يتضمّن ميزات كافية لتلاقي تقنية 3A.

يمكن اختبار كاميرات RFoV في منصة اختبار WFoV أو RFoV. إذا تم اختبار كاميرا RFoV في جهاز اختبار WFoV، يتم تكبير الرسم البياني بمقدار 2/3 لتحديد بعض الحدود للرسم البياني الرمادي في مجال الرؤية للمساعدة في تقارب 3A. للحصول على وصف أكثر تفصيلاً لأجهزة اختبار الكاميرا، يُرجى الاطّلاع على Camera ITS-in-a-box.

مثال على المشهد 1

الشكل 5: الرسم البياني المخصّص للمشهد 1 بالحجم الكامل (على يمين الصفحة)، والرسم البياني المخصّص للمشهد 1 بحجم مُعدَّل بنسبة ‎2/3 (على يمين الصفحة)

test_ae_precapture_trigger

يختبر آلة حالة AE عند استخدام عامل تشغيل الالتقاط المُسبَق. تسجيل خمسة طلبات يدوية مع إيقاف ميزة "التصغير الذكي" يحتوي الطلب الأخير على عامل تشغيل مسبق لالتقاط الصور باستخدام الذكاء الاصطناعي، والذي يجب تجاهله لأنّ ميزة الذكاء الاصطناعي غير مفعّلة.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتقارب الإجراء الإحصائي.

test_auto_vs_manual

تبدو الاختبارات التي تم فيها التقاط لقطات تلقائية ويدويًا متشابهة.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تتوافق نتائج ميزة "توازن اللون الأبيض" اليدوية وعمليات التحويل التي تم الإبلاغ عنها في كل عملية تسجيل مع نتائج ميزة "توازن اللون الأبيض" التلقائية estimate من خوارزمية 3A في الكاميرا.

مثال على اختبار test_auto_vs_manual التلقائي

الشكل 6: مثال على اختبار test_auto_vs_manual التلقائي

مثال على موازنة اللون الأبيض test_auto_vs_manual

الشكل 7: مثال على موازنة اللون الأبيض test_auto_vs_manual

مثال على تحويل موازنة اللون الأبيض اليدوي في test_auto_vs_manual

الشكل 8: مثال على تحويل موازنة اللون الأبيض اليدوي test_auto_vs_manual

test_black_white

يختبر هذا الاختبار ما إذا كان الجهاز ينتج صورًا بالأبيض والأسود بالكامل. يتم التقاط صورتَين، الأولى بدرجة اكتساب منخفضة جدًا ووقت تعريض قصير، ما يؤدي إلى التقاط صورة سوداء، والثانية بدرجة اكتساب عالية جدًا ووقت تعريض طويل، ما يؤدي إلى التقاط صورة بيضاء.

واجهات برمجة التطبيقات التي تم اختبارها:

تمرير: لإنشاء صور بالأبيض والأسود تحتوي قنوات الصور البيضاء المشبعة على قيم RGB‏ [255, 255, 255] مع هامش خطأ أقل من 1% .

test_black_white، مثال على اللون الأسود

الشكل 9: اختبار_أبيض_أسود، مثال على اللون الأسود

مثال على تحويل موازنة اللون الأبيض اليدوي في test_auto_vs_manual

الشكل 10: نموذج test_black_white باللون الأبيض

مثال على مخطّط القيمة المتوسطة لاختبار_الأسود_الأبيض

الشكل 11: test_black_white، مثال على وسيط الرسم البياني

test_burst_capture

للتحقّق من أنّ مسار المعالجة الكامل لالتقاط الصور يمكنه مواكبة سرعة التقاط الصور بالحجم الكامل ووقت وحدة المعالجة المركزية

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتم التقاط سلسلة من الصور بالحجم الكامل، والتحقّق من معدّل تقطُّع اللقطات ودرجة سطوع الصورة.

test_burst_sameness_manual

التقاط 5 دفعات من 50 صورة باستخدام إعدادات الالتقاط اليدوي والتحقّق من أنّها كلها متطابقة استخدِم هذا الاختبار لتحديد ما إذا كانت هناك لقطات متقطعة تمّت معالجتها بشكلٍ مختلف أو تتضمّن عيوبًا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: الصور متطابقة من حيث الشكل وقيم RGB.

تعذُّر: تعرِض هذه الحالة ارتفاعًا أو انخفاضًا في الرسم البياني لمتوسط نموذج RGB في بداية كل ذروة.

  • يكون التفاوت% 3 عندما يكون first_API_level أقل من 30
  • يكون الحدّ المسموح به للخطأ% 2 عندما يكون first_API_level >= 30

test_burst_sameness_manual_mean

الشكل 12: مثال على متوسّط test_burst_sameness_manual

test_burst_sameness_manual_plot_means

الشكل 13: test_burst_sameness_manual_plot_means

test_crop_region_raw

لاختبار أنّه لا يمكن اقتصاص أحداث RAW

واجهات برمجة التطبيقات التي تم اختبارها:

مقبولة: يتم اقتصاص صور YUV من المنتصف، ولكن لا يتم اقتصاص صور RAW.

مثال على اقتصاص الصورة من ملف test_crop_region_raw comp raw

الشكل 14: مثال على اقتصاص الصورة الأولي في عنصر test_crop_region_raw comp

test_crop_region_raw comp raw full example

الشكل 15: مثال كامل على اختبار_منطقة_الاقتصاص_الخام comp raw.

مثال على اقتصاص YUV في comp test_crop_region_raw

الشكل 16: مثال على اقتصاص YUV في comp test_crop_region_raw

مثال على test_crop_region_raw_yuv_full

الشكل 17: مثال كامل على تنسيق YUV في test_crop_region_raw

test_crop_regions

اختبارات تفيد بأنّ مناطق الاقتصاص تعمل تلتقط صورة كاملة وتُنشئ رقعًا من خمسة مناطق مختلفة (الزوايا والوسط). التقاط صور تم ضبطها للاقتصاص في المناطق الخمس تقارن قيم الصورة المُقتطعة وصورة الإصلاح.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تتطابق صورة المنطقة التي تم اقتصاصها مع القسم الذي يتوافق مع صورة الاقتصاص.

test_ev_compensation

يختبر هذا الاختبار تطبيق تعويض قيمة التعريض (EV). يتألّف الاختبار من قسم أساسي وقسم متقدّم.

يختبر القسم الأساسي تطبيق التعويض عن الإضاءة الكهربائية باستخدام نطاق تم إنشاؤه باستخدام CONTROL_AE_COMPENSATION_STEP. يتم تسجيل ثمانية لقطات لكل قيمة تعويض.

يزيد القسم المتقدّم من التعرّض للضوء في ثماني خطوات، ويتحقّق من قياس السطوع مقارنةً بالسطوع المتوقّع. يتم احتساب القيم المتوقّعة من سطوع الصورة بدون تطبيق تعويض EV، وتمتلئ القيمة المتوقّعة إذا تجاوزت القيم المحسوبة نطاق قيمة الصورة الفعلية. يفشل الاختبار إذا لم تتطابق القيم المتوقّعة والقيم المقاسة أو إذا تمّت زيادة تعريض الصور للضوء خلال خمس خطوات.

واجهات برمجة التطبيقات التي تم اختبارها:

القسم الأساسي: تعرض الصور زيادة في الإضاءة بدون تعريضها بشكل مفرط في غضون خمس خطوات.

test_ev_compensation_basic

الشكل 18: test_ev_compensation_basic

تمرير القسم المتقدّم: لالتقاط زيادة في الإضاءة مع زيادة إعداد التعويض عن EV. تحتوي اللقطات الثمانية التي تم التقاطها لكل إعداد من إعدادات تعويض مستوى الإضاءة الكهربية (EV) على قيم ثابتة للّون الأسود.

test_ev_compensation_advanced_plot_means

الشكل 19: test_ev_compensation_advanced_plot_means

test_exposure_x_iso

اختبارات يتم من خلالها تحقيق تعريض ثابت مع اختلاف درجة ISO ووقت التعريض تلتقط سلسلة من اللقطات التي تم اختيار درجة ISO ووقت التعريض فيها لموازنة بعضها. يجب أن تكون النتائج بنفس درجة السطوع، ولكن مع مرور الوقت، يجب أن تزداد ضوضاء الصورة. للتحقّق من أنّ قيم متوسطات وحدات البكسل في العيّنة قريبة من بعضها التحقّق مما إذا كانت الصور لا يتم حصرها بقيمة 0 أو 1 (ما يجعلها تبدو كخطوط مسطّحة) يمكن أيضًا إجراء الاختبار باستخدام صور RAW من خلال ضبط العلامة debug في ملف الإعدادات.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تتمتع الصور بدرجة السطوع نفسها، ولكنّها تصبح أكثر تشويشًا عند استخدام قيمة ISO أعلى. تكون مستويات RGB مسطّحة عندما تكون قيمة ISO*exposure ثابتة على مستوى مساحة gain التي تم اختبارها.

آلية حدوث الخطأ: في الشكل التالي، مع زيادة قيم مُضاعِف الكسب (المحور x)، تبدأ قيم متوسط مستوى طائرة RGB المعدَّلة (المحور y) بالانحراف عن قيم مُضاعِف الكسب المنخفض.

test_exposure_plot_means

الشكل 20: test_exposure_plot_means

test_exposure_mult=1.00.jpg

الشكل 21: test_exposure_mult=1.00

test_exposure_mult=64.00

الشكل 22: test_exposure_mult=64.00

test_latching

اختبارات تُثبت الإعدادات (مستوى الإضاءة والكسب) في الإطار الأيمن لكل من كاميرات FULL و LEVEL_3 تلتقط سلسلة من اللقطات باستخدام طلبات متتالية، ويختلف المَعلمات في طلب الالتقاط بين اللقطات. للتحقّق من أنّ الصور تضمّن الخصائص المتوقّعة

واجهات برمجة التطبيقات التي تم اختبارها:

مقبولة: الصور [2 و3 و6 و8 و10 و12 و13] لها قيمة ISO أو تعريض زائدة وتظهر بمعدّلات RGB أعلى في الرسم البياني بالشكل التالي.

مثال على معنى رسم test_latching

الشكل 23: مثال على معنى الرسم البياني test_latching

test_latching i=00

الشكل 24: test_latching i=00

test_latching i=01

الشكل 25: test_latching i=01

test_latching i=02

الشكل 26: test_latching i=02

test_latching i=03

الشكل 27: test_latching i=03

test_latching i=04

الشكل 28: test_latching i=04

test_latching i=05

الشكل 29: test_latching i=05.

test_latching i=06

الشكل 30: test_latching i=06

test_latching i=07

الشكل 31: test_latching i=07.

test_latching i=08

الشكل 32: test_latching i=08

test_latching i=09

الشكل 33: test_latching i=09.

test_latching i=10

الشكل 34: test_latching i=10.

test_latching i=11

الشكل 35: test_latching i=11.

test_latching i=12

الشكل 36: test_latching i=12.

test_linearity

يختبر هذا الاختبار إمكانية عكس معالجة الجهاز إلى وحدات بكسل خطية. لالتقاط تسلسل من اللقطات مع توجيه الجهاز إلى هدف موحّد.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يجب أن تزيد قيم R وG وB بشكل خطي مع زيادة الحساسية.

مثال على معنى رسم "اختبار_الاستقامة"

الشكل 37: مثال على معنى الرسم البياني test_linearity

test_locked_burst

يختبر هذا الاختبار قفل 3A ووضع "التقاط الصور المتسلسلة بتنسيق YUV" (باستخدام الإعداد التلقائي). تم تصميم هذا الاختبار لاجتيازه حتى على الأجهزة المحدودة التي لا تتضمّن MANUAL_SENSOR أو PER_FRAME_CONTROLS. يتحقّق الاختبار من اتساق صورة YUV، في حين يتم التحقّق من معدّل عرض اللقطات في CTS.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تبدو عمليات الالتقاط متّسقة.

مثال على test_locked_burst frame0

الشكل 38: مثال على test_locked_burst frame0

مثال على test_locked_burst frame1

الشكل 39: مثال على الإطار 1 من test_locked_burst

test_locked_burst_frame2

الشكل 40: مثال على test_locked_burst frame2

scene1_2

scene 1_2 هو نسخة متطابقة من scene 1_1 من الناحية الوظيفية، وتستخدم بنية مشهد فرعي لتقليل المدة الطويلة لفيديو scene 1.

test_param_color_correction

يختبر هذا الإجراء تطبيق مَعلمات android.colorCorrection.* عند ضبطها. التقاط لقطات بقيم مختلفة للتحويل والتحسين، واختبار ما إذا كانت تبدو مختلفة وفقًا لذلك يتم اختيار التحويل والتعزيزات لجعل الناتج أحمر أو أزرق بشكل متزايد. يستخدم خريطة نغمات خطية.

ربط الدرجات اللونية هو تقنية تُستخدَم في معالجة الصور لربط مجموعة من الألوان بمجموعة أخرى من أجل تقريب مظهر الصور ذات النطاق العالي الديناميكية في وسيط يمتلك نطاقًا ديناميكيًا محدودًا.

واجهات برمجة التطبيقات التي تم اختبارها:

تمرير: يتم تعزيز قيم R وB وفقًا للتحويل.

مثال على مخطّط "متوسّطات اختبار_مَعلمة_تصحيح_الألوان"

الشكل 41: مثال على معنى الرسم البياني test_param_color_correction

في الرسومات التالية، يمثّل محور x طلبات الالتقاط: 0 = الوحدة، و1 = التعزيز الأحمر، و2 = التعزيز الأزرق.

مثال على test_param_color_correction req=0 unity

الشكل 42: مثال على test_param_color_correction req=0 unity

مثال على مَعلمة test_param_color_correctness التي تتطلب القيمة 1 لتعزيز اللون الأحمر

الشكل 43: مثال على مقياس test_param_color_correctness الذي يتطلب req=1 لتعزيز اللون الأحمر

مثال على test_param_color_correction req=2 blue boost

الشكل 44: مثال على طلب تحسين اللون test_param_color_correction‏ req=2 باللون الأزرق

test_param_flash_mode

يختبر تطبيق المَعلمة android.flash.mode. يتم ضبط سطوع التصوير يدويًا على الجانب المظلم، بحيث يكون واضحًا ما إذا كان الفلاش قد تم تفعيله أم لا، ويتم استخدام خريطة نغمات خطية. التحقّق من المركز باستخدام صورة المربّع لمعرفة ما إذا كان هناك انتقال تدريجي كبير تم إنشاؤه للتحقّق مما إذا كان الفلاش قد تم تفعيله

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتضمّن مركز صورة المربّع تدرجًا كبيرًا، ما يعني أنّه تم تفعيل فلاش الكاميرا.

مثال على test_param_flash_mode 1

الشكل 45: مثال على test_param_flash_mode 1

مثال على مربّع test_param_flash_mode 1

الشكل 46: مثال على مربّع واحد من test_param_flash_mode

مثال على test_param_flash_mode_2

الشكل 47: مثال على test_param_flash_mode 2

مثال على مربّع 2 من test_param_flash_mode

الشكل 48: مثال على مربّعتَين في test_param_flash_mode

test_param_noise_reduction

يختبر هذا الإجراء تطبيق المَعلمة android.noiseReduction.mode بشكلٍ صحيح عند ضبطها. التقاط صور عندما تكون الكاميرا مضاءة بشكل خافت يستخدم هذا الوضع مكاسب تمثيلية عالية لمحاولة ضمان أن تكون الصورة الملتقطة مشوشة. يلتقط الجهاز ثلاث صور، واحدة بدون ميزة "تقليل الضوضاء" وأخرى سريعة وأخرى عالية الجودة. تلتقط أيضًا صورة بدرجة استفادة منخفضة وميزة "تقليل الضوضاء" غير مفعّلة، وتستخدم متغير هذه الصورة كأساس. وكلما ارتفعت نسبة الإشارة إلى التشويش (SNR)، زادت جودة الصورة.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يختلف معدّل SNR حسب أوضاع تقليل الضوضاء المختلفة ويتصرف بشكل مشابه للرسم البياني التالي:

مثال على رسم منحنيات SNR في دالة test_param_noise_reduction

الشكل 49: مثال على رسم SNRs في مخطط test_param_noise_reduction

‫0: إيقاف، 1: سريع، 2: عالي الجودة، 3: منخفض، 4: جودة منخفضة جدًا

مثال على test_param_noise_reduction high gain nr=0

الشكل 50: مثال على مَعلمة test_param_noise_reduction ذات الكسب العالي nr=0

مثال على test_param_noise_reduction high gain nr=1

الشكل 51: مثال على مَعلمة test_param_noise_reduction ذات الكسب العالي nr=1

مثال على test_param_noise_reduction high gain nr=2

الشكل 52: مثال على مَعلمة test_param_noise_reduction ذات الكسب العالي nr=2

مثال على test_param_noise_reduction high gain nr=3

الشكل 53: مثال على مَعلمة test_param_noise_reduction ذات الكسب العالي nr=3

مثال على انخفاض مستوى كسب مقياس test_param_noise_reduction

الشكل 54: مثال على انخفاض الكسب في مَعلمة test_param_noise_reduction

test_param_shading_mode

يختبر تطبيق المَعلمة android.shading.mode.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتم تبديل أوضاع التظليل وتعديل خرائط تظليل العدسة على النحو المُتوقّع.

مثال على خريطة تظليل العدسة test_param_shading_mode، الوضع 0، حلقة 0

الشكل 55: خريطة تظليل العدسة test_param_shading_mode، مثال على وضع 0 وحلقة 0

مثال على خريطة تظليل العدسة test_param_shading_mode، الوضع 1، حلقة 0

الشكل 56: خريطة تظليل العدسة test_param_shading_mode، مثال على وضع 1 حلقة 0

مثال على خريطة تظليل العدسة test_param_shading_mode، الوضع 2، حلقة 0

الشكل 57: خريطة تظليل العدسة test_param_shading_mode، مثال على وضع 2 حلقة 0

test_param_tonemap_mode

يختبر تطبيق المَعلمة android.tonemap.mode. تُطبِّق منحنيات مختلفة لوحة الألوان على كل قناة من قنوات R وG وB، وتتحقّق من تعديل الصور الناتجة على النحو المتوقّع. يتكوّن هذا الاختبار من اختبارَين، test1 وtest2.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور:

  • test1: تحتوي كلتا الصورتَين على خريطة نغمات خطية، ولكن الصورة n=1 ذات منحدر أشد انحدارًا. قناة G (الأخضر) أكثر سطوعًا في صورة n=1.
  • test2: خريطة النغمة نفسها، ولكن بطول مختلف الصور متطابقة.

‫test_param_tonemap_mode with n=0

الشكل 58: test_param_tonemap_mode مع n=0

‫test_param_tonemap_mode with n=1

الشكل 59: test_param_tonemap_mode مع n=1

test_post_raw_sensitivity_boost

التحقّق من زيادة الحساسية الأساسية بعد إجراء التحسين التقاط مجموعة من الصور الأولية وصور YUV بدرجة حساسية مختلفة، ونشر مجموعة من تحسينات الحساسية الأولية، والتحقّق مما إذا كان متوسط وحدات البكسل الناتجة يتطابق مع إعدادات الطلب

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تصبح الصور الأوّلية أكثر قتامة مع زيادة التحسين، بينما يظلّ سطوع صور YUV ثابتًا.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

الشكل 60: مثال على test_post_raw_sensitivity_boost raw s=3583 boost=0100

مثال على test_post_raw_sensitivity_boost raw s=1792 boost=0200

الشكل 61: مثال على test_post_raw_sensitivity_boost raw s=1792 boost=0200

مثال على test_post_raw_sensitivity_boost raw s=0896 boost=0400

الشكل 62: مثال على test_post_raw_sensitivity_boost raw s=0896 boost=0400

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

الشكل 63: مثال على test_post_raw_sensitivity_boost raw s=0448 boost=0800

مثال على test_post_raw_sensitivity_boost raw s=0224 boost=1600

الشكل 64: مثال على test_post_raw_sensitivity_boost raw s=0224 boost=1600

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

الشكل 65: مثال على test_post_raw_sensitivity_boost raw s=0112 boost=3199

مثال على القيمة المتوسطة للرسم البياني الأوّلي لاختبار_التحسين_الأوّلي_للحساسية

الشكل 66: مثال على مخطّط القيمة المتوسطة للرسم البياني الأوّلي لـ test_post_raw_sensitivity_boost

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

الشكل 67: مثال على test_post_raw_sensitivity_boost YUV s=0112 boost=3199

مثال على test_post_raw_sensitivity_boost YUV s=0448 boost=0800

الشكل 68: مثال على test_post_raw_sensitivity_boost YUV s=0448 boost=0800

مثال على test_post_raw_sensitivity_boost YUV s=0896 boost=0400

الشكل 69: مثال على test_post_raw_sensitivity_boost YUV s=0896 boost=0400

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

الشكل 70: مثال على test_post_raw_sensitivity_boost YUV s=1792 boost=0200

مثال على test_post_raw_sensitivity_boost YUV s=3585 boost=0100

الشكل 71: مثال على test_post_raw_sensitivity_boost YUV s=3585 boost=0100

test_post_raw_sensitivity_boost_yuv_plot_means

الشكل 72: test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

تلتقط مجموعة من الصور الأولية مع زيادة وقت التعرّض وتقيس قيم البكسل.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور: تؤدي زيادة حساسية الضوء (ISO) إلى زيادة حساسية وحدات البكسل للضوء، وبذلك تتحرك الرسمة البيانية نحو اليسار.

مثال على test_raw_exposure ISO=55

الشكل 73: مثال على test_raw_exposure ISO=55

القيمة 10⁰ هي 1 ملي ثانية، والقيمة 10¹ هي 10 ملي ثانية، والقيمة 10⁻¹ هي 0.1 ملي ثانية.

مثال على test_raw_exposure ISO=132

الشكل 74: مثال على test_raw_exposure ISO=132

مثال على test_raw_exposure ISO=209

الشكل 75: مثال على test_raw_exposure ISO=209

مثال على test_raw_exposure ISO=286

الشكل 76: مثال على test_raw_exposure ISOs=286

مثال على test_raw_exposure ISO=363

الشكل 77: مثال على test_raw_exposure ISO=363

test_raw_exposure_s=440

الشكل 78: مثال على test_raw_exposure ISO=440

test_reprocess_noise_reduction

الاختبارات التي يتم تطبيق android.noiseReduction.mode عليها لطلبات إعادة المعالجة التقاط صور تمت إعادة معالجتها عندما تكون الإضاءة في الكاميرا خافتة يستخدم هذا المقياس مكاسب تمثيلية عالية للتحقّق من أنّ صورة الالتقاط مشوشة. تلتقط هذه الميزة ثلاث صور تمت إعادة معالجتها، لإظهار الجودة العالية والسرعة ووضع "إلغاء الضوضاء" غير مفعَّل. تلتقط هذه الطريقة صورة تمت إعادة معالجتها بدرجة منخفضة من التحسين مع إيقاف ميزة "تقليل الضوضاء"، وتستخدم التباين الناتج عن ذلك كقيمة مرجعية.

واجهات برمجة التطبيقات التي تم اختبارها:

النتيجة: FAST >= OFF وHQ >= FAST وHQ >> OFF

رسم بياني نموذجي لنسبة SNR مقارنةً بوضع NR

الشكل 79: مثال على رسم بياني نموذجي لنسبة SNR مقارنةً بوضع NR

test_tonemap_sequence

يختبر تسلسل لقطات باستخدام منحنيات مختلفة لخريطة الدرجات اللونية. التقاط 3 لقطات يدوية باستخدام خريطة درجات لونية خطية التقاط 3 لقطات يدوية باستخدام خريطة النغمة التلقائية احتساب الفرق بين كل زوج متتالٍ من اللقطات

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تظهر ثلاثة إطارات متطابقة متبوعة بمجموعة مختلفة من ثلاثة إطارات متطابقة.

مثال على test_tonemap_sequence i=0

الشكل 80: مثال على test_tonemap_sequence i=0

مثال على test_tonemap_sequence i=1

الشكل 81: مثال على test_tonemap_sequence i=1

مثال على test_tonemap_sequence i=2

الشكل 82: مثال على test_tonemap_sequence i=2

مثال على test_tonemap_sequence i=3

الشكل 83: مثال على test_tonemap_sequence i=3

مثال على test_tonemap_sequence_i=4

الشكل 84: مثال على test_tonemap_sequence i=4

مثال على test_tonemap_sequence i=5

الشكل 85: مثال على test_tonemap_sequence i=5

test_yuv_jpeg_all

اختبارات لمعرفة ما إذا كانت جميع الأحجام والتنسيقات المسجّلة لالتقاط الصور تعمل يستخدم طلبًا يدويًا مع خريطة نغمات خطية لكي يبدو تنسيقا YUV وJPEG متطابقَين عند تحويلهما بواسطة وحدة image_processing_utils. لا يتم حفظ الصور تلقائيًا، ولكن يمكن حفظها من خلال تفعيل debug_mode.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تبلغ قيمة فرق جذر متوسط المربع (RMS) (قيمة إشارة) في جميع مراكز الصور الحد الأقصى المسموح به في الصور المحوَّلة بتنسيق RGB مقارنةً بنسبة% 3 من دقة YUV الصورة الأعلى.

مثال على test_yuv_jpeg_all

الشكل 86: مثال على test_yuv_jpeg_all

test_yuv_plus_dng

اختبارات لمعرفة ما إذا كانت الأحجام والتنسيقات المسجّلة لالتقاط الصور تعمل بشكل صحيح

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يُكمِل الاختبار ويعرض الصور المطلوبة.

مثال على test_yuv_plus_dng

الشكل 87: مثال على test_yuv_plus_dng

scene1_3

scene 1_3 هو نسخة متطابقة من scene 1_1 من الناحية الوظيفية، وتستخدم بنية مشهد فرعي لتقليل المدة الطويلة لفيديو scene 1.

test_capture_result

يختبر ما إذا كانت البيانات الصالحة تظهر في عناصر CaptureResult. يتألّف الاختبار من عملية التقاط تلقائية وعملية التقاط يدوية وعملية التقاط تلقائية ثانية.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: البيانات الوصفية صالحة لجميع عمليات الالتقاط ولا تتسرّب الإعدادات اليدوية إلى عملية الالتقاط التلقائية الثانية. يعرض هذا الخيار تصحيح تشويش العدسة لصور الالتقاط.

test_capture_result_plot_lsc_auto_ch0

الشكل 88: test_capture_result_plot_lsc_auto_ch0

test_dng_noise_model

للتحقّق من صحة مَعلمات نموذج DNG الخام يعرض الرسم البيانيvariabilitymeasured لجزء مركزي من البطاقة الرمادية في اللقطات الأوّلية التي تم التقاطها على مدار مجموعة من الحساسيات، ويقارن هذه القيم بالاختلاف المتوقع عند كل حساسية من خلال نموذج الضوضاء DNG في HAL للكاميرا (استنادًا إلى مَعلمتَي O وS اللتين يتم إرجاعهما في عناصر نتيجة الالتقاط). للاطّلاع على مزيد من التفاصيل حول نموذج الضوضاء في DNG، نزِّل المستند التالي حول نموذج الضوضاء في DNG.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تكون مَعلمات نموذج DNG الخام صحيحة. تتطابق قيم RGB المتوقّعة مع قيم RGB الفعلية التي تم قياسها.

test_dng_noise_model_plog

الشكل 89: test_dng_noise_model_plog

test_jpeg

الاختبارات التي تم فيها تحويل صور YUV وصور JPEG على الجهاز تبدو متشابهة. يأخذ الاختبار% 10 من وسط الصورة ويحسب قيمة RGB، ويتحقّق من أنّها متطابقة.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: إذا كان متوسّط الفرق في قيم RGB بين كل صورة أقل من %3

test_jpeg_fmt=jpg.jpg

الشكل 90: test_jpeg_fmt=jpg.jpg

test_jpeg=fmt=yuv.jpg

الشكل 91: test_jpeg=fmt=yuv.jpg

test_raw_burst_sensitivity

تلتقط مجموعة من الصور الأولية مع زيادة المكاسب وتقيس الضوضاء. التقاط الصور بتنسيق RAW فقط في وضع "التقاط الصور المتتالية"

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: كل لقطة أكثر تشويشًا من اللقطة السابقة، لأنّ الكسب يزداد.

يستخدم التباين في خلية شبكة الإحصاءات المركزية.

test_raw_burst_sensitivity_variance

الشكل 92: test_raw_burst_sensitivity_variance

test_raw_sensitivity

تلتقط مجموعة من الصور الأولية بحساسيات متزايدة وتقيس الضوضاء (التباين) في مركز ‎10% من الصورة. اختبارات تُظهر أنّ كل لقطة أكثر ضوضاء من اللقطة السابقة

واجهات برمجة التطبيقات التي تم اختبارها:

المرور: يزداد التباين مع كل لقطة.

test_raw_sensitivity_variance

الشكل 93: test_raw_sensitivity_variance

test_yuv_plus_jpeg

يختبر هذا الاختبار التقاط إطار واحد بتنسيقَي YUV وJPEG. يستخدم طلبًا يدويًا مع خريطة نغمات خطية لكي يبدو تنسيقا YUV وJPEG متطابقَين عند تحويلهما بواسطة وحدة image_processing_utils.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: الصور بتنسيقَي YUV وJPEG متشابهة ويقلّ الفرق بينهما في RMS (قيمة الإشارة) عن% 1.

‫test_yuv_plus_jpeg بتنسيق JPEG

الشكل 94: اختبار test_yuv_plus_jpeg بتنسيق JPEG

‎test_yuv_plus_jpeg بتنسيق YUV

الشكل 95: اختبار test_yuv_plus_jpeg بتنسيق YUV

test_yuv_plus_raw

اختبارات لالتقاط إطار واحد كإخراج ثنائي القيمة (ثنائي القيمة بسعة 10 بت و12 بت) وYUV ، إذا كان ذلك متاحًا يستخدم طلبًا يدويًا مع خريطة درجات لونية خطية، لذا من المتوقّع أن يكون تنسيقا raw و YUV متطابقَين. تقارن قيم RGB في وسط 10% من الصور التي تم تحويلها إلى نموذج RGB. السجلّاتandroid.shading.mode

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: الصور بتنسيق YUV والصور الأولية متشابهة ويقلّ الفرق بينهما في RMS (قيمة الجذر المتوسط المربّع للإشارة) عن% 3.5.

test_yuv_plus_raw_shading=1_raw.jpg

الشكل 96: test_yuv_plus_raw_shading=1_raw.jpg

test_yuv_plus_raw_shading=1_yuv.jpg

الشكل 97: test_yuv_plus_raw_shading=1_yuv.jpg

test_sensitivity_priority

اختبارات CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY على مستوى إعدادات ISO المختلفة لتأكيد وجود ارتباط بين ISO الأعلى و مستويات الضوضاء المتزايدة

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يؤدي ارتفاع قيمة ISO إلى زيادة مستويات التشويش.

اختبار معايير التخطّي

يتم تخطّي اختبار test_sensitivity_priority.py في حال استيفاء أي من الشارَتَين التاليتَين:

test_exposure_time_priority

اختبارات CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY على مدار أوقات تعريض مختلفة، للتحقّق من مستوى سطوع ثابت في النطاق حيث يمكن أن تُعوِّض سرعة ISO

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون السطوع ثابتًا (ضمن حدود التسامح) على مدار أوقات التعريض إذا كان مقياس ISO ضمن نطاق التعويض.

معايير اختبار التخطّي

يتم تخطّي اختبار test_exposure_time_priority في حال استيفاء أي من الشارَتَين التاليتَين:

scene2_a

scene2_a تظهر فيها ثلاثة وجوه على خلفية رمادية وملابس محايدة. يتم اختيار الوجوه لتضمين مجموعة كبيرة من درجات لون البشرة. يجب أن يكون الرسم البياني في الوضع الصحيح لكي تعمل ميزة "التعرّف على الوجوه" على النحو الأمثل.

مثال على scene2_a

الشكل 98: مثال على scene2_a

test_autoframing

يختبر سلوك وضع "استخدام الإطارات التلقائية" في جهاز الكاميرا. يُجري تكبيرًا كبيرًا لكي لا تظهر أي من الوجوه في المشهد، ويفعّل وضع "التعديل التلقائي لإطار الفيديو" من خلال ضبط AUTOFRAMING في CaptureRequest على True، ويتحقّق مما إذا كان بإمكانه رصد كل الوجوه في المشهد الأصلي عند تقارب الحالة (أي عند ضبط AUTOFRAMING_STATE في CaptureResult على AUTOFRAMING_STATE_CONVERGED).

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تم رصد الوجوه الثلاثة.

test_display_p3

اختبارات Display P3 الالتقاط بتنسيق JPEG باستخدام واجهة برمجة التطبيقات ColorSpaceProfiles يُجري هذا الاختبار للتأكّد من أنّ ملف JPEG الذي تم التقاطه يحتوي على ملف ICC مناسب في العنوان وأنّ الصورة تحتوي على ألوان خارج نطاق sRGB.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يحتوي ملف JPEG على ملف ICC Display P3 وألوان خارج نطاق sRGB.

test_effects

تلتقط هذه الوظيفة لقطة لتأثيرات الكاميرا المتوافقة وتتحقّق مما إذا تم إنشاؤها بشكل صحيح. لا يتحقّق الاختبار إلا من التأثيرَين OFF وMONO، ولكنه يحفظ الصور لجميع التأثيرات المتوافقة.

واجهات برمجة التطبيقات التي تم اختبارها:

تمرير: لالتقاط صورة المشهد مع التأثيرات OFF وصورة أحادية اللون مع ضبط التأثيرات على MONO.

test_effects_MONO

الشكل 99: test_effects_MONO

test_exposure_keys_consistent

يقارن هذا الاختبار متوسط درجة الإضاءة لصورة تم التقاطها مع تفعيل ميزة "ضبط تلقائي للتعريض" مقارنةً بتصوير تم التقاطه بدون تفعيل هذه الميزة ويطبّق يدويًا مَعلمات التعريض (الحساسية، ووقت التعريض، ومدة اللقطة، وزيادة الحساسية بعد معالجة الصور الخام) التي تم تلقيها في CaptureResult لصورة تم التقاطها مع تفعيل ميزة "ضبط تلقائي للتعريض".

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: الفرق النسبي في مستوى الإضاءة بين اللقطتَين أقل من 4%.

test_format_combos

اختبار مجموعات مختلفة من تنسيقات الإخراج

واجهات برمجة التطبيقات التي تم اختبارها:

تم بنجاح: تم تسجيل جميع التركيبات بنجاح.

test_num_faces

اختبار ميزة "التعرّف على الوجوه"

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتم العثور على ثلاثة وجوه.

مثال 1 على وضع التعرّف على الوجوه test_num_faces

الشكل 100: مثال على وضع 1 لميزة "التعرّف على الوجوه" باستخدام مَعلمة test_num_faces

test_reprocess_uv_swap

يُجري هذا الاختبار للتأكّد من أنّ إعادة معالجة YUV لا تؤدي إلى تبديل مساحتَي U وV. ويتم رصد ذلك من خلال احتساب مجموع الاختلافات المطلقة (SAD) بين الصورة التي تمت إعادة معالجتها وصورة تم التقاطها بدون إعادة معالجتها. إذا أدّى تبديل مساحتَي الإخراج U وV للقطة التي تمت إعادة معالجتها إلى زيادة في قياس SAD، يُفترض أنّ مساحتَي الإخراج تحتويان على مساحتَي U وV الصحيحتَين.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: لم يتم تبديل مستوىَي U وV.

test_reprocess_uv_swap

الشكل 101: مثال على test_reprocess_uv_swap

scene2_b

test_preview_num_faces

يختبر هذا الاختبار ميزة "التعرّف على الوجوه" في المعاينة مع زيادة تنوّع درجات لون البشرة في مشاهد الوجوه.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يرصد ثلاثة وجوه تتضمّن معالم الوجه في مربّعات إحاطة الوجه.

test_num_faces_fd_mode_1

الشكل 102: مثال على وضع 1 للتعرّف على الوجوه test_num_faces

test_yuv_jpeg_capture_sameness

التقاط صورتَين باستخدام أكبر تنسيقَين شائعَين من YUV وJPEG بنسبة عرض إلى ارتفاع مماثلة لأكبر تنسيق JPEG، ودرجة دقة لا تتجاوز ‎1920×1440 ضبط jpeg.quality على 100 وتسجيل طلب سطحَين تحوّل كلتا الصورتَين إلى صفائف RGB وتحسب الفرق في متوسّط مربّع الجذر الثلاثي الأبعاد (RMS) بين الصورتَين.

بالإضافة إلى ذلك، يتحقق هذا الاختبار من أنّ نواتج YUV لجميع حالات استخدام البث المتوافقة متشابهة بشكل معقول مع YUV في حالة الاستخدام STILL_CAPTURE.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تختلف صور YUV وJPEG الخاصة بحالة الاستخدام STILL_CAPTURE بنسبة أقل من ‎3% من RMS (قيمة الجذر المتوسط للمربّع لإشارة). تختلف صور YUV لجميع حالات الاستخدام المتوافقة بنسبة أقل من ‎10% من RMS مقارنةً بصور YUV الخاصة بحالة الاستخدام STILL_CAPTURE.

scene2_c

test_num_faces

يختبر ميزة التعرّف على الوجوه مع زيادة تنوع درجات لون البشرة في مشاهد الوجوه.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتم العثور على ثلاثة وجوه.

test_num_faces_fd_mode_1

الشكل 103: مثال على وضع التعرّف على الوجوه test_num_faces

test_jpeg_capture_perf_class

يختبر وقت استجابة التقاط الصور بتنسيق JPEG لفئة الأداء S كما هو محدّد في القسم 2.2.7.2 الكاميرا في مستند CDD.

اجتياز: يجب أن يكون وقت استجابة التقاط الكاميرا 2 بتنسيق JPEG أقل من 1000 ملي ثانية بدرجة دقة 1080p ، وذلك وفقًا لما يتم قياسه من خلال اختبار أداء الكاميرا CTS في ظروف الإضاءة ITS (3000K) لكلتا الكاميرتَين الأساسيتَين.

test_camera_launch_perf_class

يختبر وقت استجابة تشغيل الكاميرا لفئة الأداء S كما هو محدّد في الفقرة 2.2.7.2 الكاميرا في مستند CDD.

اجتياز: يجب أن يكون وقت استجابة بدء تشغيل الكاميرا2 (فتح الكاميرا إلى أول إطار معاينة) أقل من 600 ملي ثانية كما تم قياسه من خلال اختبار أداء الكاميرا في CTS في ظل ظروف الإضاءة ITS (3000K) لكلتا الكاميرتَين الأساسيتَين.

test_default_camera_hdr

اختبارات لضمان أنّ ميزة الالتقاط التلقائية للكاميرا هي دقة HDR فائقة للأداء الفئة 15 على النحو المحدّد في الفقرة 2.2.7.2 الكاميرا في CDD

اجتياز: يجب أن تكون ميزة التقاط حزمة الكاميرا التلقائية هي ميزة "النطاق العالي الديناميكية الفائق" لجهاز ينتمي إلى فئة الأداء 15.

scene2_d

test_preview_num_faces

يختبر هذا الاختبار ميزة "التعرّف على الوجوه" في المعاينة مع زيادة تنوّع درجات لون البشرة في مشاهد الوجوه.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يعثر على ثلاثة وجوه تتضمّن معالم الوجه في مربّعات إحاطة الوجه.

scene2_e

test_continuous_picture

يتم التقاط 50 لقطة بدقة VGA باستخدام الإعداد الأول لطلب الالتقاط android.control.afMode = 4 (CONTINUOUS_PICTURE).

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يستقر نظام 3A بحلول نهاية عملية التقاط 50 لقطة.

test_num_faces

يختبر ميزة التعرّف على الوجوه مع زيادة تنوع درجات لون البشرة في مشاهد الوجوه.

واجهات برمجة التطبيقات التي تم اختبارها:

تمرير: يرصد 3 وجوه.

scene2_f

scene2_f يعرض ثلاثة وجوه على خلفية بيضاء وملابس بيضاء. أن تتضمّن الوجوه مجموعة كبيرة من درجات لون البشرة وأن يكون هناك تباين عالٍ بينها وبين الخلفية

مثال على scene2_f

الشكل 104: مثال على scene2_f

test_preview_num_faces

يختبر ميزة التعرّف على الوجوه مع زيادة تنوع درجات لون البشرة في مشاهد الوجوه.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يرصد ثلاثة وجوه تتضمّن معالم الوجه في مربّعات إحاطة الوجه.

test_num_faces_fd_mode_1

الشكل 105: مثال على test_num_faces_fd_mode_1

scene2_g

scene2_g لديه ثلاثة وجوه في الملف الشخصي بخلفية بيضاء وملابس بيضاء. تتضمّن الوجوه مجموعة كبيرة من درجات لون البشرة وتُظهر تباينًا عاليًا مع الخلفية.

scene2_g.png

الشكل 106: مثال على scene2_g

test_preview_num_faces

يختبر ميزة التعرّف على الوجوه مع زيادة تنوع درجات لون البشرة في مشاهد الوجوه.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يعثر على ثلاثة وجوه تتضمّن معالم الوجه في مربّعات إحاطة الوجه.

test_preview_num_faces

الشكل 107: مثال على test_preview_num_faces

scene3

يستخدم scene3 مخطّط ISO12233، وتستخدم معظم الاختبارات طريقة استخراج مخطّط لتحديد المخطّط في المشهد. لهذا السبب، لا تحتوي معظم الصور المحفوظة على حدود مثل الصور الخاصة بالمشهد 1 أو 2 أو 4، بل تحتوي على الرسم البياني فقط. يجب أن يكون الرسم البياني بالاتجاه الصحيح لكي يعمل أداة البحث عن الرسم البياني على النحو الأمثل.

test_edge_enhancement

يختبر هذا الإجراء تطبيق المَعلمة android.edge.mode بشكلٍ صحيح. تلتقط هذه الوظيفة الصور التي لا تتم إعادة معالجتها لكل وضع من أوضاع الحواف، وتُظهر حدة الصورة الناتجة والبيانات الوصفية لنتيجة الالتقاط. تعالج طلب الالتقاط باستخدام مَعلمة وضع الحواف والحساسية ووقت التعرّض والمسافة إلى التركيز وسطح الإخراج.

مقبول: يكون وضع HQ (2) أكثر حدة من وضع OFF (0). وضع FAST (1) أكثر حدة من وضع OFF أن يكون وضع HQ أكثر حدة أو يساوي وضع FAST

واجهات برمجة التطبيقات التي تم اختبارها:

مَعلمات الكاميرا المتأثرة:

  • EDGE_MODE

test_edge_enhancement_edge=0

الشكل 108: مثال على test_edge_enhancement edge=0

مثال على test_edge_enhancement edge=1

الشكل 109: مثال على test_edge_enhancement edge=1 (الوضع السريع)

مثال على test_edge_enhancement edge=2

الشكل 110: مثال على test_edge_enhancement edge=2 (وضع الجودة العالية)

test_flip_mirror

يختبر هذا الاختبار ما إذا كانت الصورة موجَّهة بشكل صحيح وفقًا للمتطلبات الواردة في 7.5.2 الكامير ا الأمامية في مستند CDD.

يمكن التعرّف على الصور المنعكسة أو المقلّبة أو المُدرَجة من خلال علامة الماسة بالقرب من المركز.

مقبول: لم يتم قلب الصورة أو عكسها أو تدويرها.

مثال على تصحيح المشهد test_flip_mirror

الشكل 111: مثال على تصحيح المشهد test_flip_mirror

test_imu_drift

يختبر هذا الاختبار ما إذا كانت وحدة القياس بالقصور الذاتي (IMU) تُصدر بيانات ثابتة لمدة 30 ثانية عندما يكون الجهاز ثابتًا ويتم تسجيل معاينة عالية الدقة.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور:

  • يكون انحراف أداة الاستشعار الدوراني أقل من 0.01 راديان خلال وقت الاختبار.
  • يجب أن يكون التباين في قراءة أداة الاستشعار الدوراني أقل من 1E-7 rad2/s2/Hz خلال وقت الاختبار.
  • يكون انحراف متّجه الدوران أقل من 0.01 راديان خلال وقت الاختبار.
  • (لم يتم فرض هذا الشرط بعد) يجب أن يكون انحراف أداة الاستشعار الدوراني أقل من درجة واحدة في الثانية.

مثال على انحراف الجيروسكوب test_imu_drift

الشكل 112: مثال على انحراف أداة الاستشعار test_imu_drift

مثال على انحراف متّجه الدوران test_imu_drift

الشكل 113: مثال على انحراف متجه الدوران test_imu_drift

test_landscape_to_portrait

يختبر ما إذا كانت ميزة إلغاء الوضع الأفقي/العمودي تعمل بشكل صحيح في أجهزة الاستشعار المخصّصة للوضع الأفقي.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يحدِّد الاختبار موقع رسم بياني بالدرجة المتوقعة للدوران (0 درجة عند إيقاف إيقاف الوضع الأفقي/العمودي، 90 درجة عند تفعيله).

مثال على test_landscape_to_portrait

الشكل 114: مثال على دالة test_landscape_to_portrait

test_lens_movement_reporting

لاختبار ما إذا كان يتم الإبلاغ عن علامة حركة العدسة بشكل صحيح لالتقاط سلسلة من 24 صورة، يتم التقاط أول 12 لقطة على مسافة التركيز المثلى (كما حدّدها الجيل الثالث من تكنولوجيا الذكاء الاصطناعي) وآخر 12 لقطة على مسافة التركيز الدنيا. في حوالي الإطار 12، تتحرّك العدسة مما يؤدي إلى انخفاض الحدة. وتستقر الحدة في النهاية عندما تتحرّك عدسة الفحص إلى الموضع النهائي.

يجب ضبط علامة حركة العدسة في جميع اللقطات التي تكون فيها الحدة متوسطة إلى حادة في اللقطات القليلة الأولى عندما تكون العدسة ساكنة في أقرب مسافة تركيز، وفي اللقطات القليلة الأخيرة عندما تكون العدسة ساكنة في أقرب مسافة تركيز. لا يهمّ الإطار المحدّد الذي تتحرّك فيه العدسة، فالمهم هو تأكيد علامة الحركة عندما تتحرّك عدسة الكاميرا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: علامة حركة العدسة هي True في الإطار الذي يتضمّن تغييرًا في الحدة.

آليات حدوث الأعطال:

  • لا يتمّ تأكيد lens_moving: True (android.hardware.camera2.CaptureResult#LENS_STATE = 1) في test_log.DEBUG إلا في اللقطات التي لا تتغيّر فيها درجة الحدّة.
  • إنّ اللقطات التي تحتوي على lens_moving: False (android.hardware.camera2.CaptureResult#LENS_STATE = 0) في test_log.DEBUG تختلف في درجة الحدة مقارنةً باللقطات القليلة الأولى عند المسافة البؤرية المثلى أو اللقطات القليلة الأخيرة عند الحد الأدنى لشدَّة التركيز.

test_reprocess_edge_enhancement

يختبر ما إذا كانت طرق إعادة المعالجة المتوافقة لتحسين الحواف تعمل بشكلٍ سليم. تعالج هذه الوظيفة طلب الالتقاط باستخدام وضع محدّد لإعادة معالجة الحواف، وتقارن بين الأوضاع المختلفة للالتقاط مع إيقاف أوضاع إعادة معالجة الحواف.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: درجة الحدة في أوضاع الحواف المختلفة صحيحة. الصورة HQ (الوضع 2) أكثر وضوحًا من الصورة OFF (الوضع 0)، والتحسين بين الأوضاع المختلفة مشابه.

مثال على رسم test_reprocess_edge_enhancement

الشكل 115: مثال على رسم بياني لاختبار_إعادة_المعالجة_تحسين_الحواف

scene4

يتكون الرمز scene4 من دائرة سوداء على خلفية بيضاء داخل مربّع.

يمكن أن تكون الاختبارات في scene4 حسّاسة للّحافة، لذا بدءًا من الإصدار Android 15، يمكنك استخدام check_alignment.py في دليل tools لتفعيل التحقّق من محاذاة DUT والرسم البياني.

مثال على المشهد 4

الشكل 116: مثال على المشهد 4

test_30_60fps_preview_fov_match

اختبارات للتأكّد من أنّ معاينة الفيديوهات التي يتم عرضها بمعدّل 30 لوحة في الثانية أو 60 لوحة في الثانية لها مجال العرض نفسه يُسجِّل الاختبار فيديوهَين، أحدهما بمعدّل 30 لقطة في الثانية والآخر بمعدّل 60 لقطة في الثانية. يتم اختيار لقطة تمثيلية من كل فيديو وتحليلها للتأكّد مما يلي: أنّ التغييرات في مجال الرؤية في الفيديوَين ضمن المواصفات اختبارات للتأكّد من أنّ تناسب الدائرة يظل ثابتًا وأنّ مركز الدائرة يظل مستقرًا وأنّ نصف قطر الدائرة يظل ثابتًا

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: لا يتم تمديد الصور، ولا يختلف مركز الصور عن بعضها بأكثر من %3، ولا يزيد الحد الأقصى لتغيير نسبة العرض إلى الارتفاع بين الفيديوهات التي يتم عرضها بمعدل 30 أو 60 لقطة في الثانية عن 7.5%.

آليات حدوث الأعطال:

  • يختلف حجم الدائرة في الفيديو الذي تم تسجيله بمعدّل 30 لقطة في الثانية عن حجم الدائرة في الفيديو الذي تم تسجيله بمعدّل 60 لقطة في الثانية.
  • تم تشويه الدائرة في الصورة التي تم التقاطها من خلال مسار المعالجة.
  • تم اقتصاص الدائرة في الصورة التي تم التقاطها بسبب نسبة عرض إلى ارتفاع مفرطة طلب الالتقاط الذي يقلّل من ارتفاع الصورة أو عرضها.
  • تحتوي الدائرة في الصورة التي تم التقاطها على انعكاس في وسطها ولا تبدو مليئة بالكامل.

test_aspect_ratio_and_crop

يُجري هذا الفحص اختبارًا لمعرفة ما إذا كانت الصور مشوّهة أو تم اقتصاصها بشكل غير متوقّع في مسار الصور. التقاط صور لدائرة في جميع التنسيقات التحقّق من أنّ الدائرة ليست مشوّهة، وأنّ الدائرة لا تتحرك من وسط الصورة، وأنّ الدائرة لا تغيّر حجمها بشكل غير صحيح مع نسب عرض إلى ارتفاع أو درجات دقة مختلفة

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: لا يتم تمديد الصور، ولا يختلف مركز الصور عن بعضها بأكثر من %3، ويتم الاحتفاظ بأكبر مجال ممكن للرؤية.

آليات حدوث الأعطال:

  • الكاميرا غير محاذية للدائرة المعروضة على الجهاز اللوحي في منتصف المشهد الذي تم التقاطه.
  • تم تشويه الدائرة في الصورة التي تم التقاطها من خلال مسار المعالجة.
  • يتم اقتصاص الصورة ذات الدقة المنخفضة مرتين في مسار معالجة الصور، ما يؤدي إلى اختلاف زاوية الرؤية بين الصور العالية الدقة والمنخفضة الدقة.
  • تم اقتصاص الدائرة في الصورة التي تم التقاطها بسبب نسبة عرض إلى ارتفاع مفرطة طلب الالتقاط الذي يقلّل من ارتفاع الصورة أو عرضها.
  • تحتوي الدائرة في الصورة التي تم التقاطها على انعكاس في وسطها ولا تبدو مليئة بالكامل.

test_multi_camera_alignment

يختبر مَعلمات معايرة الكاميرا ذات الصلة بوضع الكاميرا في أنظمة الكاميرات المتعدّدة. باستخدام الكاميرات الفرعية المتعدّدة، يتم التقاط صورة باستخدام إحدى الكاميرات. يحدِّد مركز الدائرة. تعرِض هذه السمة مركز الدائرة على إحداثيات الكرة الأرضية لكل كاميرا. تقارن هذه السمة الفرق بين مراكز دوائر الكاميرات في إحداثيات العالم. تتم إعادة إسقاط إحداثيات سطح الأرض إلى إحداثيات البكسل ومقارنتها بالإحداثيات الأصلية كأحد إجراءات التحقّق من الصحة. تقارن أحجام الدوائر للتحقّق مما إذا كانت أطوال التركيز للكاميرات مختلفة.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تكون مراكز الدوائر وأحجامها على النحو المتوقّع في الصور المعروضة مقارنةً بالصور التي تم التقاطها باستخدام بيانات معايرة الكاميرا وطول البعد البؤري.

آليات حدوث الأعطال:

  • LENS_INTRINSIC_CALIBRATION وLENS_POSE_TRANSLATION و LENS_POSE_ROTATION هي قيم التصميم وليست بيانات المعايرة الفعلية.
  • نظام الكاميرا غير مناسب لإعداد الاختبار، على سبيل المثال، اختبار نظام كاميرا بزاوية واسعة وزاوية عريضة جدًا باستخدام منصة اختبار RFoV لمزيد من المعلومات، يُرجى الاطّلاع على الأسئلة الشائعة حول حزمة ITS للكاميرا (السؤال 1).

test_preview_aspect_ratio_and_crop

على غرار اختبار test_aspect_ratio_and_crop للصور الثابتة، يتحقّق هذا الاختبار من تنسيقات المعاينة المتوافقة للتأكّد من عدم تمديد أو اقتصاص frames المعاينة بشكل غير ملائم. التحقّق من أنّ نسبة العرض إلى الارتفاع للدائرة لا تتغيّر، وأنّ الصور المقتطعة تحافظ على وضع الدائرة في وسط الإطار، وأنّ حجم الدائرة لا يتغيّر بتنسيق ثابت أو بدرجات دقة مختلفة (التحقّق من مجال الرؤية)

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: لا يتم تمديد الصور، ولا يختلف مركز الصور عن بعضها بأكثر من %3، ويتم الاحتفاظ بأكبر مجال ممكن للرؤية.

test_preview_stabilization_fov

التحقّق من أحجام المعاينة المتوافقة للمساعدة في ضمان اقتصاص مجال الرؤية بشكل مناسب يُسجِّل الاختبار فيديوهَين، أحدهما يتضمّن ميزة "تثبيت الصورة أثناء المعاينة" ON، والآخر يتضمّن ميزة "تثبيت الصورة أثناء المعاينة" OFF. يتم اختيار إطار تمثيلي من كل فيديو، ويتم تحليله للتأكّد من أنّ التغييرات في مجال الرؤية في الفيديوَين ضمن المواصفات.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تظل نسبة العرض إلى الارتفاع للدائرة ثابتة تقريبًا، ويظل موقع قلب الدائرة ثابتًا، ولا يتغيّر حجم الدائرة بأكثر من %20.

test_video_aspect_ratio_and_crop

التقاط فيديوهات لدائرة داخل مربّع على جميع تنسيقات الفيديو استخراج اللقطات الرئيسية والتأكّد من عدم تغيُّر نسبة العرض إلى الارتفاع للدائرة، تحافظ الصور المقتطعة على وضع الدائرة في المنتصف، ولا يتغيّر حجم الدائرة لتنسيق ثابت أو بدرجة دقة مختلفة (التحقّق من مجال الرؤية)

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: لا يتم تمديد إطارات الفيديو، ولا يختلف مركز الإطارات عن الإطارات الأخرى بنسبة تزيد عن %3، ويتم الحفاظ على أكبر مجال ممكن للعرض.

scene5

يتطلّب scene5 مشهدًا رماديًا مضاءً بشكلٍ موحّد. ويتم ذلك من خلال أداة موزّعة للضوء توضع فوق عدسة الكاميرا. ننصحك باستخدام الناشر التالي: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

لإعداد المشهد، يمكنك إرفاق موزع أمام الكاميرا وتوجيه الكاميرا إلى مصدر إضاءة يبلغ 2000 لكس تقريبًا. يجب أن تكون الصور التي يتم التقاطها لأجل scene5 مموّهة الإضاءة بدون أي تفاصيل واضحة. في ما يلي عيّنة صورة:

مثال على المشهد 5

الشكل 117: مثال على التقاط المشهد 5

test_lens_shading_and_color_uniformity

يختبر هذا الاختبار ما إذا كان يتم تطبيق تصحيح تظليل العدسة بشكل مناسب، وما إذا كان يتم توزيع لون المشهد الأحادي اللون بالتساوي. يُجري هذا الاختبار على لقطة YUV باستخدام ميزة "التثبيت التلقائي للصورة والصوت والتعرّف على الوجوه". يتم تقييم تظليل العدسة استنادًا إلى قناة y. تقيس هذه الطريقة متوسّط قيمة y لكلّ كتلة عيّنات محدّدة، وتحدّد النجاح أو الفشل من خلال المقارنة مع قيمة y في الوسط. يتم تقييم اختبار اتّساق اللون في مساحة اللون الأحمر والأخضر والأزرق والأخضر.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يجب أن يكون التباين بين قيمة اللونَين الأحمر والأخضر واللونَين الأزرق والأخضر أقل من% 20 في نصف القطر المحدّد للصورة لاجتياز الاختبار.

scene6

scene6 هي شبكة من علامات ArUco التي يمكن التعرّف عليها بشكل فريد. يمكن أن تكون الاختبارات في scene6 حسّاسة للتنسيق، لذا اعتبارًا من 15، يمكنك استخدام check_alignment.py في دليل tools لتفعيل التحقّق من DUT وتنسيق الرسم البياني.

scene6

الشكل 118: مثال على المشهد 6

test_in_sensor_zoom

يختبر هذا الاختبار سلوك ميزة التكبير/التصغير في الكاميرا، والتي تنتج صورًا أولية مُقتطعة.

عند ضبط حالة استخدام البث على CROPPED_RAW، يُجري الاختبار عمليتَي التقاط على نطاق التكبير/التصغير، وهما صورة أساسية كاملة لمجال الرؤية وصورة أساسية تم اقتصاصها. يحوّل الاختبار الصور إلى صفائف RGB ، ويقلّل حجم الصورة الخام المقتطعة بالحجم الكامل إلى الحجم الذي يُبلغ عنه SCALER_RAW_CROP_REGION، ويحسب الفرق في RMS ثلاثي الأبعاد بين الصورتَين.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون الفرق في متوسّط الانحراف المعياري الثلاثي الأبعاد بين الصورة الخام المُعدَّلة والمقصوصة والصورة الخام الكاملة لمجال الرؤية أقل من الحدّ المسموح به المحدّد في الاختبار.

test_zoom

يختبر سلوك تكبير/تصغير الكاميرا من العدسة لالتقاط صور موسّعة إلى العدسة لالتقاط صور عريضة. تلتقط الصور على نطاق التكبير وتتحقّق مما إذا كانت علامات ArUco تكبر مع تكبير الكاميرا. يتحقّق الاختبار أيضًا مما إذا كان موضع العلامة المركزية يتغيّر بشكل متوقّع خلال كل عملية تسجيل. يمكن أن تتغيّر المسافة من مركز العلامة المركزية إلى مركز الصورة إما بمعدّل ثابت بالنسبة إلى نسبة التكبير إلى أن يتم تبديل الكاميرا، أو يمكن أن تتغيّر بشكل منتظم نحو الموقع الجغرافي للعلامة نفسها بعد تبديل الكاميرا. يجب تثبيت تطبيق Jetpack Camera (JCA) على الجهاز قبل الاختبار.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يكون الحجم النسبي لعلامة ArUco التي تم التقاطها دقيقًا مقارنةً بنسبة التكبير/التصغير المطلوبة للتأكّد من أنّ الكاميرا تكبير/تصغير الصورة بشكل صحيح، وتتغيّر مسافة العلامة عن مركز الصورة وفقًا للمعايير المذكورة في وصف الاختبار.

test_zoom للعثور على محيط علامة ArUco الأقرب إلى المركز

الشكل 119: test_zoom للعثور على محيط علامة ArUco الأقرب إلى المركز

test_low_latency_zoom

يختبر سلوك التكبير/التصغير بوقت استجابة منخفض في الكاميرا. تلتقط الصور على نطاق التكبير باستخدام android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM)، وتتحقّق مما إذا كانت العلامات في صور الإخراج تتطابق مع نسب التكبير في البيانات الوصفية للمقطع الذي تم التقاطه. يتم استخدام جلسة الالتقاط نفسها للكاميرا لتوحيد 3A و التقاط الصور.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون الحجم النسبي للعلامة التي تم التقاطها دقيقًا مقارنةً بنِسب التكبير والتصغير والبيانات الوصفية للنتائج.

test_preview_video_zoom_match

اختبارات تُظهر أنّ معاينة الفيديو وإخراج الفيديو أثناء التسجيل والتكبير/التصغير يعرضان ويسجلان النتيجة نفسها تُحتسب هذه الدالة حجم العلامة الأقرب إلى المركز عند نسب تكبير مختلفة، وتتحقّق ممّا إذا كان حجم العلامة يزداد مع زيادة نسبة التكبير.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون الحجم النسبي للعلامة التي تم التقاطها دقيقًا مقارنةً بنسبة التكبير/التصغير المطلوبة في الفيديو والمعاينة.

HD_1280x720_key_frame.png

الشكل 120: HD_1280x720_key_frame.png (قبل التكبير)

preview_1280x720_key_frame.png

الشكل 121: preview_1280x720_key_frame.png (قبل التكبير)

HD_1280x720_key_frame_zoomed.png

الشكل 122: HD_1280x720_key_frame.png (بعد التكبير)

preview_1280x720_key_frame_zoomed.png

الشكل 123: preview_1280x720_key_frame.png (بعد التكبير)

test_preview_zoom

اختبارات للتأكّد من أنّ نسبة التكبير لكل إطار معاينة تتطابق مع البيانات الوصفية لالتقاط اللقطة من العدسة فائقة العرض إلى العدسة الواسعة يأخذ الاختبار لقطات معاينة على نطاق التكبير والعمّق ويبحث عن علامة ArUco الأقرب إلى المركز. بعد ذلك، يتحقّق الاختبار ممّا إذا كان موضع العلامة المركزية يتغيّر بشكل متوقّع خلال كل عملية تسجيل. يمكن أن تتغيّر المسافة من مركز العلامة المركزية إلى مركز الصورة إما بمعدّل ثابت بالنسبة إلى نسبة التكبير إلى أن يتم تبديل الكاميرا، أو يمكن أن تتغيّر بشكل منتظم نحو الموقع الجغرافي للعلامة نفسها بعد تبديل الكاميرا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون الحجم النسبي لعلامة ArUco المحدّدة دقيقًا بالنسبة إلى ratio التكبير المُبلّغ عنها لنتيجة الالتقاط المقابلة لجميع لقطات المعاينة. تكون المسافة النسبية للعلامة المحدّدة من مركز الصورة دقيقة بالنسبة إلى نسبة التكبير المسجّلة لنتيجة الالتقاط المقابلة لجميع لقطات المعاينة.

صور test_preview_zoom تعرض العلامة المحدّدة الأقرب إلى المركز

الشكل 124: صور test_preview_zoom تعرض العلامة المحدّدة الأقرب إلى المركز

test_session_characteristics_zoom

يختبر نطاق نسبة التكبير/التصغير لجميع إعدادات الجلسات المتوافقة المدرَجة في CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. بالنسبة إلى كلّ من هذه الإعدادات، إذا كانت دالة CameraDeviceSetup#isSessionConfigurationSupported تُعرِض القيمة true، يُحقِّق الاختبار من إمكانية الوصول إلى نطاق نسبة التكبير/التصغير الذي تم عرضه في دالة CameraDeviceSetup#getSessionCharacteristics.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: يمكن الوصول إلى الحد الأدنى والحد الأقصى لنسبة التكبير/التصغير لكل SessionConfiguration متوافقة مُدرَجة في CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION.

scene7

scene7 هو إطار مستطيل مقسَّم إلى أربعة أقسام متساوية، تم ملء كل منها بلون مختلف. في منتصف المستطيل، يظهر رسم بياني للجانب المائل لفحص الحدة. تتم محاذاة علامات ArUco الأربعة مع الزوايا الخارجية الأربعة للمستطيل للمساعدة في الحصول على إحداثيات دقيقة لإطار المستطيل الرئيسي بنسب تكبير/تصغير مختلفة.

scene7

الشكل 125: المشهد 7

test_multi_camera_switch

يتحقق هذا الاختبار من أنّه أثناء تسجيل المعاينة بنسب تكبير مختلفة، يؤدي التبديل بين عدسة العرض الفائق العرض (UW) والعدسة الواسعة (W) إلى قيم RGB مشابهة.

يستخدم الاختبار نسب تكبير مختلفة ضمن النطاق المحدَّد مسبقًا لإجراء تسجيل ملف معاينة ديناميكي وتحديد النقطة التي تتغيّر فيها الكاميرا المادية. تشير هذه النقطة إلى نقطة التداخل بين عدسة UW والعدسة W.

يتم تحليل اللقطات التي تم التقاطها عند نقطة التداخل وقبلها لتحديد مستوى الإضاءة التلقائي (AE) وموازنة اللون الأبيض التلقائية (AWB) والتركيز التلقائي (AF).

يتحقّق التحقّق من "التثبيت التلقائي للتعرّف على الوجه" من أنّ تغيير مستوى النصوع ضمن النطاق المتوقّع لكلٍّ من صور عدسة "العرض الفائق" و"العرض العادي". يتحقق التحقّق من توازن اللون الأبيض التلقائي من أنّ نِسب اللونَين الأحمر والأخضر والأزرق والأخضر ضمن القيم الحدّية لكلّ من صور عدسة UW وW. يُقيّم فحص ضبط التركيز التلقائي قيمة تقدير الحدة استنادًا إلى متوسط انحدار مقدار التدرج بين صور عدسة UW وW.

أثناء تنفيذ هذا الاختبار، إذا كان تأثير "موiré" يتداخل مع النتائج، استخدِم جهازًا لوحيًا بدرجة دقة أعلى من قائمة قائمة الأجهزة اللوحية المعتمَدة لاختبار ITS للكاميرا.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: لاجتياز الاختبار، يجب اجتياز عمليات التحقّق من AE وAWB. لا تُستخدَم نتائج التحقّق من AF إلا لأغراض التسجيل. في ما يلي معايير كل عملية تحقّق:

  • التحقّق من ميزة "التثبيت التلقائي للصورة": يجب أن يكون تغيُّر مستوى الإضاءة (قيمة Y) بين الصور الملتقطة بعدسة UW والعدسة الواسعة الزاوية أقل من% 4 لجميع البقع الملونة إذا كان الجهاز متوافقًا مع كل من ae_regions وawb_regions. إذا كان الخيار ae_regions فقط متاحًا، يجب أن تستوفي قيم رقعة اللون الرمادي فقط المعايير.
  • التحقّق من ميزة "توازن اللون الأبيض التلقائي": يجب أن يكون الفرق بين قيم الأحمر والأخضر والأزرق والأخضر لصور عدسة UW وW أقل من% 3 لبقعة اللون الرمادي، ويجب أن يكون أقل من% 10 لبقع الألوان الأخرى إذا كان الجهاز متوافقًا مع كل من ae_regions وawb_regions.
  • التحقّق من ضبط ميزة "ضبط التركيز التلقائي": يجب أن تكون حدة الصورة عند التقاطها باستخدام عدسة "العرض العادي" أعلى من الحدة عند التقاطها باستخدام عدسة "العرض الفائق العرض".

test_multi_camera_switch_gray_uw_y

الشكل 126: تم التقاط رقعة رمادية باستخدام عدسة لالتقاط صور موسّعة.

test_multi_camera_switch_gray_w_y

الشكل 127: تم التقاط رقعة رمادية باستخدام عدسة W.

scene8

scene8 هو إطار مستطيل مقسم إلى أربع مناطق متساوية، يحتوي كل منها على صورة عمودية تم التقاطها بدرجة تعريض مختلفة أو تم تطبيق ظل لون مختلف عليها (ظل أزرق، درجة تعريض أعلى، درجة تعريض أقل، ظل أصفر). تتم محاذاة أربعة علامات ArUco مع الزوايا الخارجية الأربعة للمستطيل للحصول على إحداثيات دقيقة لإطار المستطيل الرئيسي.

مثال على المشهد 8

الشكل 128: مثال على المشهد 8

test_ae_awb_regions

يختبر هذا الاختبار اختلاف قيم RGB ودرجة النصوع عند معاينة التسجيل في مناطق مختلفة لميزة "التثبيت التلقائي للصورة" وميزة "توازن اللون الأبيض التلقائي".

يسجِّل الاختبار معاينة مدتها 8 ثوانٍ، ويُجري قياسًا للتعرّف التلقائي على المشهد (AE) ودرجة حرارة اللون التلقائية (AWB) في كلّ من الأرباع لمدة ثانيتَين لكلّ منها. بعد ذلك، يستخرج الاختبار إطارًا من تسجيل المعاينة لكل منطقة، ويستخدم الإطارات المستخرَجة للقيام بالعمليات التالية للتحقّق من ضبط الإضاءة التلقائية (AE) وتوازن اللون الأبيض التلقائي (AWB):

  • التحقّق من ميزة "التثبيت التلقائي للصورة": للتحقّق من أنّ اللقطة التي تقيس الإضاءة في المنطقة التي تم فيها تقليل سطوع الصورة تحتوي على قيمة سطوع أعلى بنسبة تزيد عن% 1 مقارنةً باللقطة التي تقيس الإضاءة في المنطقة التي تم فيها زيادة سطوع الصورة. يضمن ذلك أنّه يتم تخفيف عتمة الصور عند قياس الإضاءة في منطقة مظلمة.
  • التحقّق من توازن اللون الأبيض التلقائي: للتحقّق من أنّ نسبة اللون الأحمر إلى اللون الأزرق (من متوسط قيم RGB للصورة) في اللقطة التي تحتوي على منطقة قياس اللون الأزرق أعلى من ‎2% مقارنةً باللقطة التي تحتوي على منطقة قياس اللون الأصفر. يتحقق هذا من أنّ الصور تحتوي على قيمة RGB متوازنة عند قياس منطقة صفراء (دافئة) أو زرقاء (باردة).

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: اجتياز عمليات التحقّق من "التثبيت التلقائي للصورة" و"توازن اللون الأبيض التلقائي"

test_ae_awb_regions_dark_region

الشكل 129: قياس اللقطة للمنطقة المظلمة مع زيادة التعرّض

test_ae_awb_regions_light_region

الشكل 130: قياس اللقطة لمنطقة أفتح مع انخفاض مستوى التعرّض

آليات حدوث الأعطال:

  • إنّ رصد جميع علامات ArUco الأربعة بدقة أمر ضروري لإجراء هذا الاختبار. إذا تعذّر التعرّف على الصورة في المحاولة الأولى، يحاول النظام إجراء محاولة ثانية باستخدام نسخة بالأبيض والأسود من الصورة. تمثّل الصورة التالية ذات التدرّج الرمادي خطوة المعالجة الثانوية:

    عدم محاذاة علامات ArUco

    الشكل 131: عدم محاذاة علامات ArUco

test_color_correction_mode_cct

اختبارات COLOR_CORRECTION_MODE على مستوى درجات حرارة الألوان ودرجات اللون المختلفة، للتحقّق من التغييرات في نِسب RGB مقارنةً بمشهد الالتقاط، المشهد 8

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تعرض نسب RGB الارتفاعات أو الانخفاضات المتوقّعة مقارنةً بدرجات حرارة الألوان ودرجات اللون المحدّدة.

اختبار معايير التخطّي

يتم تخطّي اختبار test_color_correction_mode_cct في حال استيفاء أي من الشارَتَين التاليتَين:

scene9

يتألف scene9 من آلاف الدوائر ذات الأحجام والألوان العشوائية لإنشاء مشهد بقابلية تكرار منخفضة جدًا لاختبار خوارزميات ضغط JPEG.

مثال على scene9

الشكل 132: مثال على تنسيق scene9

test_jpeg_high_entropy

اختبارات تُثبت أنّ ضغط JPEG في الكاميرا يعمل على scene9 مع محتوى عالي التشويش وعامل جودة JPEG مضبوطًا على ‎100% يتم زيادة عامل التكبير للتأكّد من أنّه المشهد المعروض على الجهاز اللوحي يملأ مجال رؤية الكاميرا.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: تم ضغط ملف JPEG بشكل صحيح وكتابته وقراءته من القرص.

test_jpeg_quality

لاختبار جودة ضغط JPEG في الكاميرا غيِّر جودة JPEG من خلال android.jpeg.quality وتأكَّد من أنّ جداول الترميز تتغيّر بشكلٍ صحيح.

واجهات برمجة التطبيقات التي تم اختبارها:

القبول: تنخفض مصفوفة الترميز مع زيادة الجودة. (تمثّل المصفوفة معامل القسمة).

متوسطات مصفوفة DQT للّون الأسود والأبيض واللون في الكاميرا الخلفية لهاتف Pixel 4 مقارنةً بجودة JPEG

الشكل 133: متوسطات مصفوفة DQT للّون الأسود والأبيض واللون في الكاميرا الخلفية لهاتف Pixel 4 مقارنةً بجودة JPEG

مثال على اختبار تعذّر اجتيازه في test_jpeg_quality

الشكل 134: مثال على اختبار تعذّر إكماله

scene_video

scene_video هو مشهد فيديو يتألف من أربع دوارن مختلفة الألوان تتحرّك ذهابًا وإيابًا بمعدّلات عرض مختلفة للإطارات على خلفية بيضاء.

الشكل 135: مثال على سمة scene_video

test_preview_frame_drop

يختبر هذا الاختبار الحفاظ على معدّل عرض اللقطات المطلوب في المعاينة مع مشهد ديناميكي. يتم إجراء هذا الاختبار على جميع الكاميرات التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون معدّل عرض اللقطات في المعاينة هو الحدّ الأقصى لنطاق معدّل عرض اللقطات المطلوب، ويكون متوسّط الاختلاف بين اللقطات المتتالية أقل من الحدّ القصوى المسموح به في الاختبار.

scene_extensions

اختبارات scene_extensions مخصّصة لإضافات الكاميرا ويجب استخدام Camera ITS-in-a-Box، لأنّها تتطلّب التحكّم الدقيق في بيئة الاختبار. بالإضافة إلى ذلك، يجب التحكّم في جميع عمليات تسرُّب الضوء. قد يتطلّب ذلك تغطية منصة الاختبار والجهاز الذي يتم اختباره والجهاز اللوحي بقطعة قماش، بالإضافة إلى إزالة تسرُّب الضوء من الشاشة الأمامية للجهاز الذي يتم اختباره.

scene_hdr

يتألّف مشهد scene_hdr من صورة عمودية على اليسار ورمز استجابة سريعة منخفض التباين على اليمين.

scene_hdr

الشكل 136: مثال على مَعلمة scene_hdr

test_hdr_extension

يختبر إضافات HDR. يتم التقاط الصور مع تفعيل الإضافة أو بدون تفعيلها، والتحقّق مما إذا كانت الإضافة تجعل رمز الاستجابة السريعة أكثر رصدًا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تعمل إضافة HDR على تقليل عدد تغييرات التباين اللازمة لرصد رمز الاستجابة السريعة أو تقليل التدرّج في رمز الاستجابة السريعة.

scene_low_light

يتألّف مشهد scene_low_light من شبكة من المربّعات بدرجات مختلفة من الرمادي على خلفية سوداء، وتكون شبكة المربّعات محاطة بخط محيطي أحمر. يتم ترتيب المربّعات في اتجاه منحنى هيلبرت.

مثال على scene_low_light

الشكل 137: مثال على scene_low_light

test_night_extension

يختبر إضافة "الليل". يتم إجراء عمليات الالتقاط مع تفعيل الإضافة، وتنفيذ ما يلي:

  • رصد وجود 20 مربّعًا
  • احتساب مستوى النصوع المحدود بكل مربّع
  • احتساب متوسط قيمة الإضاءة في أول 6 مربّعات وفقًا لاتجاه شبكة منحنى هيلبرت
  • تُحتسب هذه السمة الفرق في قيمة المقياس اللوني للّون الأبيض/الأسود للمربّعات المتتالية (على سبيل المثال، المربّع 2 - المربّع 1) حتى المربّعَين 5 و6 (المربّع 6 - المربّع 5)، وتجد متوسط الفروق الخمسة المحسوبة.

بالنسبة إلى الأجهزة التي تعمل بالإصدار Android 16 أو إصدار أحدث، يتضمّن طلب التقاط منطقة مُقيَّدة تتوافق مع المستطيل الذي يحدّد شبكة المربّعات. تؤدي هذه الإضافة إلى تغيير معايير اجتياز الحدّ الأدنى.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور:

  • بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 16 أو إصدار أحدث، يجب أن يكون متوسط قيمة درجة التباين في أول 6 مربّعات 80 على الأقل، ويجب أن يكون متوسط الفرق في قيمة درجة التباين للمربّعات المتتالية حتى المربّعَين 5 و 6 18.75 على الأقل.
  • بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 15 والإصدارات الأقدم، يجب أن يكون متوسط قيمة luminance للمربّعات الستة الأولى 85 على الأقل، ويجب أن يكون متوسط الفرق في قيمة luminance للمربّعات المتتالية حتى المربّعَين 5 و6 هو 17 على الأقل.

يوضّح الرسم البياني التالي للسطوع شكل نتيجة الاختبار التي تجتاز الفحص.

مثال على اجتياز اختبار المشهد الليلي في الإضاءة المنخفضة

الشكل 138: مثال على اجتياز اختبار المشهد الليلي في الإضاءة المنخفضة

test_low_light_boost_extension

اختبار وضع "تحسين الإضاءة المنخفضة" للتعرّف التلقائي على المشهد إذا كانت Camera2 تتيح وضع التعرّض التلقائي المحسَّن للضوء المنخفض، يتم إجراء هذا الاختبار لمحاولة تحسين أداء Camera2. إذا كانت إضافة "الوضع الليلي" متوافقة مع الكاميرا وكانت الإضافة تتوافق مع وضع التعرّض التلقائي "تحسين الإضاءة المنخفضة"، يتم أيضًا إجراء هذا الاختبار لإضافة "الوضع الليلي" في الكاميرا. يضبط هذا الاختبار وضع "التثبيت التلقائي للصورة" على ميزة "تحسين الإضاءة المنخفضة"، ويأخذ لقطة من المعاينة، وينفّذ ما يلي:

  • رصد وجود 20 مربّعًا
  • احتساب مستوى النصوع المحدود بكل مربّع
  • احتساب متوسط قيمة الإضاءة في أول 6 مربّعات وفقًا لاتجاه شبكة منحنى هيلبرت
  • تُحتسب هذه السمة الفرق في قيمة المقياس اللوني للّون الأبيض/الأسود للمربّعات المتتالية (على سبيل المثال، المربّع 2 - المربّع 1) حتى المربّعَين 5 و6 (المربّع 6 - المربّع 5)، وتجد متوسط الفروق الخمسة المحسوبة.

بالنسبة إلى الأجهزة التي تعمل بالإصدار Android 16 أو إصدار أحدث، يتضمّن طلب التقاط منطقة مُقيَّدة تتوافق مع المستطيل الذي يحدّد شبكة المربّعات. تؤدي هذه الإضافة إلى تغيير معايير اجتياز الحدّ الأدنى.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور:

  • بالنسبة إلى الأجهزة التي تعمل بالإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث، يجب أن يكون متوسط قيمة درجة التباين في أول 6 مربّعات 54 على الأقل، ويجب أن يكون متوسط الفرق في قيمة درجة التباين للمربّعات المتتالية حتى المربّعَين 5 و 6 17 على الأقل.

  • بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 15 والإصدارات الأقدم، يجب أن يكون متوسط قيمة luminance للمربّعات الستة الأولى 70 على الأقل، ويجب أن يكون متوسط الفرق في قيمة luminance للمربّعات المتتالية حتى المربّعَين 5 و6 هو 18 على الأقل.

scene_tele

من المتطلبات الرئيسية لاختبارات scene_tele أن تكون مسافة الرسم البياني مساوية على الأقل لأقل مسافة تركيز لعدسة المقرّبة. وبما أنّ الحد الأدنى لشدّة التركيز يمكن أن يختلف بين الأجهزة، عليك ضبط الإعدادات لتناسب الكاميرا المقرِّبة المحدّدة.

إعداد scene_tele استنادًا إلى مسافة التركيز للكاميرا ذات الزاوية الواسعة والكاميرا المقرِّبة

الشكل 139: إعداد scene_tele استنادًا إلى مسافة التركيز لكل من الكاميرا ذات الزاوية الواسعة والكاميرا المقرِّبة

لمزيد من المعلومات عن إعداد الأجهزة الاختبارية، يُرجى الاطّلاع على إعداد قاعدة تثبيت الكاميرا.

scene6_tele

يتألّف مشهد scene6_tele من شبكة من علامات ArUco على خلفية بيضاء.

إذا كانت لقطات scene6_tele تظهر وكأنها مُعرَّضة للضوء بشكل زائد في القاعدة المُدمجة، أزِل الصفيحة الأمامية للقاعدة المُدمجة.

افصل جهاز اختبار WFoV عن الإضافة وأزِل حامل الهاتف.

عليك فصل جهاز اختبار WFoV عن الإضافة وإزالة حامل الهاتف.

الشكل 140: افصل جهاز اختبار WFoV عن الإضافة وأزِل حامل الهاتف.

remove_front_plate

الشكل 141: أزِل اللوحة الأمامية.

test_zoom_tele

يختبر سلوك تكبير/تصغير الكاميرا من العدسة الواسعة إلى العدسة المقرِّبة. اختبار هو مطابق لاختبار test_zoom، ولكنه يختبر سلوك التكبير/التصغير في الكاميرا من العدسة العريضة إلى العدسة المقرِّبة.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون الحجم النسبي لعلامة ArUco التي تم التقاطها دقيقًا مقارنةً بنسبة التكبير/التصغير المطلوبة للتأكّد من أنّ الكاميرا تكبير الصورة بشكل صحيح، وتتغيّر مسافة العلامة عن مركز الصورة وفقًا للمعايير الواردة في test_zoom.

test_preview_zoom_tele

يختبر سلوك تكبير/تصغير الكاميرا لإطارات المعاينة من العدسة الواسعة إلى عدسة التصوير المقرّب. الاختبار مطابق لاختبار test_preview_zoom، ولكنه يختبر سلوك التكبير/التصغير في الكاميرا لإطارات المعاينة من العدسة الواسعة إلى العدسة المقرِّبة.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون الحجم النسبي لعلامة ArUco التي تم التقاطها دقيقًا مقارنةً بنِسب التكبير/التصغير المطلوبة للتأكّد من أنّ الكاميرا تكبير/تصغير الصورة بشكل صحيح، وتتغيّر مسافة العلامة عن مركز الصورة وفقًا للمعايير الواردة في test_preview_zoom.

scene7_tele

scene7_tele مطابقة لـ scene7، ولكن تم إعدادها لاختبار عدسة مقرِّبة. وهو عبارة عن إطار مستطيل مقسم إلى أربعة أقسام متساوية، تم ملء كل منها بلون مختلف. في منتصف المستطيل، يظهر رسم بياني للجانب المائل لفحص الحدة. تتم محاذاة علامات ArUco الأربعة مع الزوايا الخارجية الأربعة للمستطيل للمساعدة في الحصول على إحداثيات دقيقة لإطار المستطيل الرئيسي بنسب تكبير/تصغير مختلفة.

test_multi_camera_switch_tele

يتحقق هذا الاختبار من أنّه أثناء تسجيل المعاينة بمعدّلات تكبير مختلفة، يؤدي التبديل بين عدسةَي العرض الواسع (W) والتصوير عن بُعد (tele) إلى قيم مشابهة لإحداثيات RGB.

يستخدم الاختبار نسب تكبير مختلفة ضمن النطاق المحدَّد مسبقًا لإجراء تسجيل ملف معاينة ديناميكي وتحديد النقطة التي تتغيّر فيها الكاميرا تشير هذه النقطة إلى نقطة التداخل بين عدسة W والعدسة المقرِّبة.

يتم تحليل اللقطات التي تم التقاطها عند نقطة التداخل وقبلها لتحديد وظائف AE وAWB وAF.

يتحقق التحقّق من التعرّف التلقائي على المشهد من أنّ تغيير مستوى النصوع يقع ضمن النطاق المتوقّع لكلٍّ من صور عدسة العريضة الزاوية والعدسة المقرِّبة. يتحقق التحقّق من التوازن التلقائي للأبيض والأسود من أنّ نِسب اللونَين الأحمر والأخضر والأزرق والأخضر ضمن القيم الحدّية لكلّ من الصور الملتقطة بالعدسة العريضة والعدسة المقرِّبة. يُقيّم فحص ضبط التركيز التلقائي قيمة تقدير الحدة استنادًا إلى متوسط انحدار مقدار التدرج بين الصور الملتقطة بالعدسة الواسعة الزاوية والعدسة المقرِّبة.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: لاجتياز الاختبار، يجب اجتياز عمليات التحقّق من AE وAWB وAF. في ما يلي معايير كل عملية تحقّق:

  • التحقّق من التعريض التلقائي: يجب أن يكون تغيُّر مستوى النصوع بين الصور الملتقطة بالعدسة الواسعة الزاوية والعدسة المقرِّبة أقل من %4.
  • التحقّق من ميزة "التوازن التلقائي للأبيض والأسود": في مساحة ألوان LAB، لا يمكن أن تتجاوز قيمة دلتا C بين الأحمر والأخضر والأزرق والأخضر للكاميرا ذات الزاوية الواسعة والكاميرا المقرِّبة 10.
  • التحقّق من ضبط التركيز التلقائي: يجب أن تكون حدة الصورة في عدسة المقرّبة أعلى من عدسة W.

scene_flash

تتطلّب اختبارات scene_flash مشهدًا مظلمًا في مربّع دمج البيانات من المستشعرات.

test_auto_flash

يختبر هذا الاختبار تفعيل الفلاش التلقائي في بيئة مظلمة للكاميرات الخلفية والأمامية. بالنسبة إلى الكاميرات الأمامية، يستخدم الفلاش التلقائي الشاشة لمحاولة إضاءة المشهد، وليس وحدة فلاش خارجية. يتحقّق الاختبار من أنّه يتم تفعيل ميزة الوميض التلقائي من خلال التحقّق من أنّ مركز صورة المربّع يصبح أكثر إشراقًا عند تفعيل ميزة الوميض التلقائي. لتشغيل الفلاش التلقائي، يجب إطفاء المصابيح في منصة الاختبار. ويمكن إطفاء المصابيح تلقائيًا باستخدام وحدة تحكّم Arduino. يجب أن يكون المشهد مظلمًا تمامًا لكي يعمل الاختبار بشكلٍ صحيح. يجب تثبيت تطبيق Jetpack Camera (JCA) على الجهاز قبل الاختبار. يعتمد الفلاش التلقائي للكاميرات المُوجَّهة للخلف على حالة "ضبط الإضاءة التلقائي" (AE) لتفعيله، ولكن الفلاش التلقائي للكاميرات المُوجَّهة للخلف لا يعتمد على "ضبط الإضاءة التلقائي" ويتم تفعيله دائمًا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون مركز صورة المربّع الذي تم تفعيل الفلاش التلقائي فيه أكثر إشراقًا مقارنةً بصورة المشهد الأصلية في جميع الكاميرات.

test_flash_strength

يختبر هذا الاختبار ما إذا كان يتم تنفيذ التحكّم في قوة الفلاش في وضع SINGLE بشكل صحيح.

للتحقّق من أنّه إذا كان الجهاز يتيح التحكّم في قوة الفلاش أثناء استخدام الكاميرا في وضع SINGLE، تتغيّر قوة الفلاش مع مستويات القوة المطلوبة المختلفة التحقّق من أنّ عنصر التحكّم في قوة الفلاش يعمل مع AE_MODES مختلفة على سبيل المثال، إذا كان وضع التعريض التلقائي هو ON أو OFF، سيؤثّر مستوى شدة فلاش الكامير في السطوع، وإذا كان الوضع هو ON_AUTO_FLASH، لن يؤثّر مستوى شدة فلاش الكامير في السطوع.

لإجراء الاختبار، يجب إطفاء الأضواء في منصة الاختبار. يمكن إطفاء الأضواء تلقائيًا باستخدام وحدة التحكّم Arduino. يجب أن يكون المشهد مظلمًا تمامًا لكي يعمل الاختبار بشكل صحيح.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور:

عندما يكون وضع التعريض التلقائي هو ON أو OFF، يزداد سطوع قطعة الصورة مع زيادة مستوى قوة الفلاش من عدم استخدام الفلاش إلى FLASH_SINGLE_STRENGTH_MAX_LEVEL. عندما يكون وضع التعريض التلقائي هو ON_AUTO_FLASH، يكون الفرق في سطوع أجزاء الصورة ضمن الحدود المسموح بها مع زيادة مستوى قوة الفلاش من عدم استخدام الفلاش إلى FLASH_SINGLE_STRENGTH_MAX_LEVEL.

test_led_snapshot

اختبارات للتأكّد من أنّ لقطات الإضاءة المميّزة لا تُشبع الصورة أو تُضفي عليها لونًا

يضيف هذا الاختبار وحدة تحكّم في الإضاءة إلى "علبة دمج المستشعرات" للتحكّم في المصابيح. عندما تكون الأضواء مضاءة على OFF، يأخذ الاختبار لقطة باستخدام وضع AUTO_FLASH على ON. أثناء عملية الالتقاط هذه، يُجري الاختبار تسلسلاً للتقاط الصور قبل أن يتم ضبط عامل التفعيل aePrecapture على START، ويضبط نية الالتقاط على Preview لإجراء عملية الالتقاط باستخدام الفلاش.

بما أنّ اللقطة تحتوي على نقطة ساخنة مميزة بسبب الفلاش، يحسب الاختبار متوسط صورة الفلاش للّقطة بأكملها ويتحقّق مما إذا كانت القيمة ضمن النطاق (68، 102). للتحقّق مما إذا كانت الصورة متوازنة بشكل معقول باللون الأبيض، يحسب الاختبار نِسب اللونَين الأحمر والأخضر والأزرق والأخضر ويتحقق مما إذا كانت النِسب تتراوح بين 0.95 و1.05.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: تتراوح نسبة اللونَين الأحمر والأخضر والأزرق والأخضر بين 0.95 و1.05. يكون متوسّط سطوع الصورة ضمن النطاق (68، 102).

test_night_mode_indicator

يختبر هذا الاختبار وظيفة مؤشر الوضع الليلي، وهي ميزة تشير إلى ما إذا كانت الكاميرا تعمل في ظروف الإضاءة المنخفضة وستستفيد من التقاط محتوى ثابت باستخدام إضافة "الوضع الليلي". لا تتوفّر هذه الميزة إلا على الأجهزة التي تتيح استخدام إضافات ميزة "الوضع الليلي" في الكاميرا.

يتحقّق هذا الاختبار من أنّ مؤشر وضع الرؤية الليلية يعكس بشكل صحيح ظروف الإضاءة أثناء معاينة الكاميرا. ينفِّذ الاختبار الخطوات التالية:

  1. الإعداد: يُعدّ الاختبار ItsSession ويستردّ سمات الكاميرا. ويُنشئ أيضًا اتصالاً مع وحدة التحكّم في الإضاءة.
  2. شروط التخطّي: يتم تخطّي الاختبار إذا كان الجهاز لا يتيح استخدام المستوى المطلوب لواجهة برمجة التطبيقات أو ميزة مؤشر الوضع الليلي.
  3. جلسة Camera2:
    • يبدأ الاختبار جلسة لالتقاط معاينة باستخدام جلسة Camera2.
    • يتم تشغيل الضوء ويتم التقاط إطار معاينة.
    • يتحقق الاختبار من أنّ مؤشر الوضع الليلي في الحالة OFF.
    • يتم إطفاء الإضاءة ويتم التقاط إطار معاينة.
    • يتحقق الاختبار من أنّ مؤشر الوضع الليلي في الحالة ON.
  4. جلسة إضافة الكاميرا:
    • يكرّر الاختبار الإجراء نفسه المُتّبع في جلسة Camera2، ولكن باستخدام جلسة CameraExtension مع إضافة EXTENSION_NIGHT.
  5. التنظيف: يغلق الاختبار ItsSession ويُطلق وحدة التحكّم في الإضاءة.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور:

  • عندما يكون الضوء مُفعَّلاً، يجب أن يكون مؤشر الوضع الليلي في الحالة OFF.
  • عندما يكون الضوء مطفأً، يجب أن يكون مؤشر الوضع الليلي في الحالة ON.
  • ينطبق على جلسات Camera2 وCameraExtension.

test_preview_min_frame_rate

يختبر هذا الاختبار ما إذا كان عدد اللقطات في الثانية للمعاينة ينخفض بشكل صحيح في المشهد المظلم. لكي يعمل هذا الاختبار بشكل صحيح، يجب أن يوقِف مستخدم وحدة التحكّم المصابيح في منصة الاختبار أو أن يوقِفها مُشغّل الاختبار يدويًا.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون معدّل عرض اللقطات في المعاينة هو الحدّ الأدنى لنطاق معدّل عرض اللقطات المطلوب، ويكون التباين بين اللقطات أقلّ من الحدّ الأقصى المسموح به الذي تم ضبطه في الاختبار.

test_torch_strength

يختبر هذا الاختبار ما إذا كان يتم تنفيذ التحكّم في قوة الفلاش في وضع TORCH بشكل صحيح.

التحقّق من أنّه إذا كان الجهاز يتيح التحكّم في قوة الفلاش أثناء استخدام الكاميرا في وضع TORCH، تتغيّر قوة المصباح اليدوي مع مستويات القوة المطلوبة المختلفة التحقّق من أنّ عنصر التحكّم في قوة الفلاش يعمل مع AE_MODES مختلفة على سبيل المثال، إذا كان وضع التعريض التلقائي هو ON أو OFF، سيؤثّر مستوى شدة فلاش الكامير في السطوع، وإذا كان الوضع هو ON_AUTO_FLASH، لن يؤثّر مستوى شدة فلاش الكامير في السطوع. للتحقّق من أنّ قوة ضوء المصباح تظلّ كما هي طوال مدة استخدام وضع "التصوير المتسلسل"، ما يحاكي جلسة تصوير فيديو. لإجراء الاختبار، يجب إطفاء الأضواء في منصة الاختبار. ويمكن إطفاء الأضواء تلقائيًا باستخدام جهاز التحكّم Arduino. يجب أن يكون المشهد مظلمًا تمامًا لكي يعمل الاختبار بشكلٍ صحيح.

واجهات برمجة التطبيقات التي تم اختبارها:

المرور:

عندما يكون وضع التعريض التلقائي هو ON أو OFF، يزداد سطوع مجموعات ومضات الصورة مع زيادة مستوى قوة الفلاش من عدم استخدام الفلاش إلى FLASH_TORCH_STRENGTH_MAX_LEVEL. عندما يكون وضع التعريض التلقائي هو ON_AUTO_FLASH، يكون الفرق في سطوع أجزاء اللقطات المتسلسلة للصورة ضمن حدود القبول مع زيادة مستوى قوة الفلاش من عدم استخدام فلاش إلى FLASH_TORCH_STRENGTH_MAX_LEVEL.

sensor_fusion

تتطلّب اختبارات دمج البيانات من أجهزة الاستشعار تحريك الهاتف بطريقة معيّنة أمام نمط اشتهرت به لعبة الشطرنج وعلامات ArUco. للحصول على أفضل النتائج، تأكَّد من أنّ مخطّط الاختبار مُثبَّت بشكلٍ مستوٍ. تؤثر الرسوم البيانية غير المستوية في عمليات احتساب التدوير للعديد من الاختبارات. يجب أن يملأ الرسم البياني الجزء الخلفي من مربّع دمج البيانات من خلال الطباعة بمقاس 17×17 بوصة. (43×43 سم). يمكن إجراء اختبارات sensor_fusion بشكل آلي باستخدام Sensor Fusion Box.

الرسم البياني لدمج بيانات المستشعرات

الشكل 142: رسم بياني لدمج البيانات من المستشعرات

رسم بياني لدمج بيانات المستشعرات في "وحدة التحكّم"

الشكل 143: رسم بياني لدمج بيانات أجهزة الاستشعار يملأ الجزء الخلفي من مربّع دمج بيانات أجهزة الاستشعار

test_lens_intrinsic_calibration

اختبارات لمعرفة ما إذا كان المركز البصري للعدسة يتغيّر بشكل أساسي عند تحريك العدسة بسبب ميزة "التثبيت البصري للصور" (OIS) إذا كانت عيّنات العدسة الأساسية متوفرة، يتم اختبار ما إذا كان المركز البصري لعينات العدسة الأساسية يتغيّر عند تحرّك العدسة بسبب ميزة OIS.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يتغيّر المركز البصري للعدسة بشكل أساسي بمقدار بكسل واحد أو أكثر. إذا كانت عيّنات العدسة الأساسية متاحة، يتغيّر مركزا العدسة البصريان بمقدار بكسل واحد أو أكثر.

الشكل التالي هو مثال على test_lens_intrinsic_calibration الرسم البياني الذي يعرض تغييرات النقاط الرئيسية بالبكسل لكل إطار:

test_lens_intrinsic_calibration_example.png

الشكل 144: مثال على الرسم البياني test_lens_intrinsic_calibration الذي يعرض تغييرات النقاط الرئيسية بالبكسل لكل إطار

test_multi_camera_frame_sync

اختبارات تُثبت أنّ الطوابع الزمنية لإطارات الكاميرا المنطقية تقع ضمن 10 مللي ثانية من خلال محاسبة زوايا المربّعات ضمن لوحة الشطرنج لتحديد الطابع الزمني

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: لا تتغيّر الزاوية بين الصور من كل كاميرا بشكل ملحوظ أثناء تدوير الهاتف.

test_preview_distortion

يختبر هذا الاختبار تصحيح التشوه في كل إطار معاينة يتم التقاطه عند مستويات تكبير مختلفة. بالنسبة إلى كل إطار معاينة، يحسب الاختبار النقاط المثالية استنادًا إلى العوامل الداخلية والخارجية للكاميرا.

في مثال الصورة، تظهر النقاط المثالية باللون الأخضر، والنقاط الفعلية باللون الأحمر. يتم احتساب خطأ التشويه استنادًا إلى متوسط مربعات مسافة البكسل بين النقاط الفعلية والنقاط المثالية. تُستخدَم الإضاءات الخضراء والحمراء على الصورة لرصد منطقة الخطأ الناتج عن التشوه بصريًا.

test_preview_distortion_example.jpg

الشكل 145: صورة لوحة شطرنج تظهر فيها النقاط المثالية باللون الأخضر والنقاط الفعلية باللون الأحمر

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: يكون خطأ التشويه المعدَّل لكل إطار معاينة أقل من الحدّ الأدنى الذي تم ضبطه في الاختبار.

test_preview_stabilization

اختبارات تُظهر أنّ الفيديو الذي تم تثبيته في المعاينة يدور بدرجة أقل من الدوران في أداة الاستشعار الدوراني

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: الحد الأقصى لدوران الزاوية على اللقطات أقل من% 70 من دوران المقلوب.

في ما يلي أمثلة على فيديوهات تم تثبيتها وأخرى لم يتم تثبيتها:

الشكل 146: نموذج فيديو تم تثبيته

الشكل 147: نموذج فيديو بدون تثبيت الصورة

test_sensor_fusion

يختبر هذا الاختبار الفرق في الطابع الزمني بين الكاميرا وجهاز الاستشعار الدوراني لتطبيقات الواقع المعزّز والواقع الافتراضي. يتم تدوير الهاتف 90 درجة 10 مرات أمام نمط لوحة الشطرنج. تستغرق الحركة ذهاباً وإيابًا حوالي ثانيتين. يتم تخطّي هذا الاختبار في حال عدم تضمين أداة جيروسكوب أو إذا لم تكن مَعلمة مصدر الطابع الزمني REALTIME مفعّلة.

يُنشئ اختبار test_sensor_fusion عددًا من المخططات. إليك أهم رسومَين بيانيَّتَين لتحديد الأخطاء وإصلاحها:

  • test_sensor_fusion_gyro_events: تعرِض هذه البطاقة أحداث الجيروسكوب للهاتف أثناء الاختبار. تشير الحركة في الاتجاهَين x وy إلى أنّ الهاتف ليس مثبّتًا بإحكام على لوحة التثبيت، ما يقلل من احتمال اجتياز الاختبار. يعتمد عدد الدورات في الرسم البياني على سرعة الكتابة لحفظ اللقطات.

    مثال على أحداث الجيروسكوب في test_sensor_fusion

    الشكل 148: مثال على أحداث أداة اختبار_دمج_الاستشعارات لقياس التسارع

  • test_sensor_fusion_plot_rotations: تعرِض هذه البطاقة محاذاة الجيروسكوب وأحداث الكاميرا. يجب أن يعرض هذا المخطط حركة متطابقة بين الكاميرا و الجيروسكوب بدقة تصل إلى ±1 ملي ثانية.

    مثال على عمليات تدوير الرسم البياني في test_sensor_fusion

    الشكل 149: مثال على عمليات تدوير الرسم البياني في test_sensor_fusion

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: إذا كان الفارق الزمني بين الطوابع الزمنية للكاميرا والجيروسكوب أقل من 1 ملي ثانية وفقًا لفقرة 7.3.9 أجهزة الاستشعار العالية الدقة في مستند CDD

آليات حدوث الأعطال:

  • خطأ في الانحراف: لم يتم ضبط الانحراف في أداة التحكّم في الكاميرا بشكل صحيح ليكون ضمن +/-1 ملي ثانية.
  • انخفاض عدد اللقطات: لا تكون عملية النقل سريعة بما يكفي لالتقاط 200 لقطة بشكل متتالٍ.
  • أخطاء في المقبس: لا يمكن لجهاز adb الاتصال بجهاز DUT بشكل موثوق لفترة كافية ل ejecutant الاختبار.
  • الرسم البياني غير مثبّت بشكلٍ مستوٍ. يحتوي الرسم البياني test_sensor_fusion_plot_rotations على لقطات يختلف فيها دوران الجيروسكوب والكاميرا بشكل كبير أثناء دوران الكاميرا في أجزاء الرسم البياني غير المستوية.
  • الكاميرا غير مثبَّتة بشكل مستوٍ. يعرض الرسم البياني test_sensor_fusion_gyro_events الحركة في مستوىَي X وY. يُرجى العِلم أنّ هذا العُطل أكثر شيوعًا في الكاميرات الأمامية لأنّ الكاميرا الخلفية غالبًا ما يكون لها نتوء بارز عن باقي أجزاء جسم الهاتف، ما يؤدي إلى حدوث إمالة عند تركيب الجزء الخلفي من الهاتف على لوحة التثبيت.

test_video_stabilization

اختبارات تُظهر أنّ الفيديو الذي تم تثبيته يدور بدرجة أقل من الدوران الناتج عن أداة التسوية التلقائية

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: الحد الأقصى لدوران الزاوية على مدار اللقطات أقل من% 60 من دوران المقلوب.

في ما يلي أمثلة على فيديوهات تم تحسينها باستخدام ميزة "التثبيت" وأخرى لم يتم تحسينها.

الشكل 150: نموذج فيديو تم تثبيته

الشكل 151: نموذج فيديو بدون تثبيت الصورة

test_video_stabilization_jca

الاختبارات التي أظهرت أنّ الفيديو الذي تم تثبيته باستخدام JCA يدور بدرجة أقل من الدوران الذي يرصده أداة الاستشعار الدوراني يجب تثبيت JCA على الجهاز قبل الاختبار.

واجهات برمجة التطبيقات التي تم اختبارها:

مقبول: الحد الأقصى لتدوير الزاوية على اللقطات المستخرَجة من الفيديو الذي تم التقاطه باستخدام JCA أقل من% 70 من دوران أداة الاستشعار الدوراني.

feature_combination

تتحقّق اختبارات feature_combination من عمل الميزات بشكل صحيح عند تفعيل ميزات متعددة للكاميرا في الوقت نفسه. تستخدِم هذه الاختبارات ملف صورة لوحة الشطرنج نفسه المستخدَم في مشهد دمج بيانات المستشعرات.

test_feature_combination

اختبار جميع تركيبات البث المختلفة ووضع تثبيت الفيديو ونطاق عدد اللقطات المستهدَف في الثانية وفيديو 10 بت بنطاق عالي الديناميكية وUltra HDR التي يتوافق معها جهاز الكاميرا

بالنسبة إلى Android 16 والإصدارات الأحدث، يُجري الاختبار جميع مجموعات الميزات المتوافقة، ويُسجّل النتائج في ملف proto. لا يتم استدعاء التأكيدات على حالات الفشل إلا لمجموعات الميزات التي يعرض فيها isSessionConfigurationSupported القيمة True.

واجهات برمجة التطبيقات التي تم اختبارها:

اجتياز: لكل مجموعة من الميزات المتوافقة:

  • يتم تحسين جودة معاينة البث إذا كانت ميزة "تحسين جودة المعاينة" مفعّلة.
  • يتراوح معدل عرض اللقطات في المعاينة ضمن AE_TARGET_FPS_RANGE الذي تم ضبطه.
  • تطابق مساحة اللون في بث المعاينة المسجّل المساحة التي تم ضبطها.
  • تحتوي عملية الالتقاط بدقة HDR فائقة على خريطة مكاسب صالحة.

scene_ip

في الإصدار 16 من نظام التشغيل Android والإصدارات الأحدث، يتيح المشهد scene_ip عمليات التحقّق من التطابق بين الصور في تطبيق الكاميرا التلقائي وتطبيق كاميرا Jetpack (JCA) بهدف تحديد الاختلافات الرئيسية بين الصور التي تم التقاطها. يُنشئ JCA نُسخًا من عمليات التقاط تطبيق وسائل التواصل الاجتماعي ويقدّم صورة أساسية تعالج تطبيقات وسائل التواصل الاجتماعي هذه الصورة وتُحسّنها.

متطلبات إعداد الأجهزة

يجب إعداد الأجهزة التالية لإجراء اختبارات scene_ip:

  • يتم تنفيذ الاختبارات في كاميرا الجيل الثاني ITS-in-a-box.
  • يتم استخدام أدوات التحكّم في الإضاءة والسيرفو التي تشكّل جزءًا من منصة الجيل الثاني للتحكّم في بيئة الاختبار.
  • يتم وضع رسم بياني لميزة الاختبار داخل منصة Gen2.

test_chart_gen2

الشكل 152: مثال على Gen2chart_sample

معايير اختبار التخطّي

يتم تخطّي اختبارات scene_ip في حال استيفاء أيّ من المعايير التالية:

  • إذا كان الجهاز يحتوي على المستوى الأول من واجهة برمجة التطبيقات (first_api_level) 35 أو أقل
  • الجهاز ليس هاتفًا مزوّدًا بكاميرا أساسية أمامية وخلفية (مثل جهاز لوحي أو تلفزيون).

test_default_jca_ip

التقاط لقطات من الرسم البياني للميزة الاختبارية في ظروف إضاءة خاضعة للتحكّم باستخدام تطبيق الكاميرا التلقائي وJCA وإجراء عمليات التحقّق التالية:

  • مجال الرؤية: للتحقّق من أنّ تطبيق الكاميرا التلقائي وعمليات التقاط JCA تتضمّن مجال الرؤية نفسه يستخدم هذا التحقّق ميزة رمز الاستجابة السريعة في المنتصف المستخرَج من صور الالتقاط الرسوم البيانية.

  • السطوع: للتحقّق من أنّ الفرق في السطوع الذي تم قياسه بين تطبيق الكاميرا التلقائي وJCA لا يتجاوز 10 يستخدم هذا الفحص تصحيح النطاق الديناميكي لقياس السطوع.

  • توازن اللون الأبيض: للتأكّد من أنّ الفرق في توازن اللون الأبيض بين تطبيق الكاميرا التلقائي وJCA لا يتجاوز 4 يستخدم هذا الفحص تصحيح النطاق الديناميكي لقياس السطوع.

اجتياز القسم الأساسي: يجتاز الاختبار عمليات التحقّق من مجال الرؤية والسطوع وموازنة اللون الأبيض. في الإصدار 16 من Android، لا يكون هذا الاختبار إلزاميًا (NOT_YET_MANDATED).