اعتبارًا من عام 2026، ولضمان اتّساق نموذج التطوير الثابت الأساسي واستقرار المنصة في النظام المتكامل، سننشر رمز المصدر في مشروع Android مفتوح المصدر (AOSP) في الربعَين الثاني والرابع. لبناء مشروع Android مفتوح المصدر والمساهمة فيه، استخدِم android-latest-release. سيشير فرع بيان android-latest-release دائمًا إلى أحدث إصدار تم نشره في مشروع Android مفتوح المصدر. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في مشروع Android مفتوح المصدر.

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

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

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

يتم تحديث اختبارات ITS أو إضافتها مع كل إصدار من Android كما هو موضّح في ملاحظات إصدار Camera ITS لإصدار Android المعنيّ. يتم إجراء التحديثات بناءً على الأخطاء التي يبلغ عنها المستخدمون أو المطوّرون. تتم الإضافات من خلال الأخطاء التي أبلغ عنها المستخدمون أو المطوّرون والتحقّق من السلوك الصحيح لميزات إطار عمل الكاميرا الجديدة.

في الإصدار 17 من Android والإصدارات الأحدث، يتم تقسيم اختبارات Camera ITS إلى نشاطَين في CTS Verifier للسماح بالتنفيذ المتوازي وتقليل وقت الاختبار: نشاط واحد لاختبارات feature_combination وsensor_fusion، وآخر لجميع الاختبارات الأخرى. لمزيد من المعلومات، يُرجى الاطّلاع على تقليل وقت الاختبار.

تتحكّم مجموعة اختبارات Camera 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: نسبة العرض إلى الارتفاع والاقتصاص ومجال الرؤية
scene6: Zoom
scene7: التبديل بين الكاميرات المتعددة
scene8: قياس منطقة التعرض التلقائي للضوء (AE) وتوازن اللون الأبيض التلقائي (AWB)
scene9: ضغط JPEG
scene_extensions: إضافات الكاميرا
scene_tele: التبديل إلى العدسة المقرِّبة
scene_video: عدد اللقطات التي تم إسقاطها

مشاهد اختبارية مستندة إلى Gen2 rig / sensor_fusion

feature_combination: مجموعات الميزات
‫scene_flash: الفلاش التلقائي والحدّ الأدنى لعدد اللقطات في الثانية
scene_gen2_chart: اختبارات باستخدام مخطط Gen2 الورقي
scene_ip: تكافؤ الصور بين تطبيق الكاميرا التلقائي و"تطبيق كاميرا Jetpack"‏ (JCA)
‫sensor_fusion: إزاحة توقيت الكاميرا والجيروسكوب

مشهد اختبار مستند إلى الناشر

scene5: تظليل العدسة

مشهد اختبار يستند إلى جهاز لوحي ذي نطاق واسع

scene_wide_gamut: ملف تعريف ونطاق ألوان واسع

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

مَشاهد اختبارية على الأجهزة اللوحية

scene0

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

test_jitter

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

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

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

في الشكل التالي، لاحظ نطاق المحور الصغير. الارتعاش صغير في الواقع في هذا المخطط.

test_jitter plot

الشكل 1: رسم بياني لـ test_jitter

test_metadata

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

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

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

test_request_capture_match

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

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

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

test_sensor_events

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

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

ناجح: يتم تلقّي الأحداث لكل أداة استشعار.

test_solid_color_test_pattern

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

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

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

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

test_test_pattern

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

يلتقط صورًا لجميع أنماط الاختبار المتوافقة.
يتم إجراء فحص للتأكّد من صحة نمط اختبار اللون الثابت وأشرطة الألوان.

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

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

مثال على test_test_patterns

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

test_tonemap_curve

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

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

ناجح: تبدو صورتا YUV وRAW متشابهتَين.

مثال على test_tonemap_curve raw

الشكل 3: مثال على test_tonemap_curve raw

مثال على test_tonemap_curve YUV

الشكل 4: مثال على اختبار test_tonemap_curve YUV

test_unified_timestamp

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

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

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

test_vibration_restriction

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

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

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

scene1_1

‫scene1 هو رسم بياني رمادي. يجب أن يغطي المخطط الرمادي نسبة% 30 من مركز مجال رؤية الكاميرا. من المتوقّع أن يمثّل المخطط الرمادي تحديًا متوسطًا لـ 3A (التعرّض التلقائي وتوازن اللون الأبيض التلقائي والتركيز التلقائي) لأنّ المنطقة المركزية لا تتضمّن أي ميزات. ومع ذلك، يحدّد طلب الالتقاط المشهد بأكمله الذي يتضمّن ميزات كافية لتقارب 3A.

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

مثال على scene1

الشكل 5: مخطط scene1 بالحجم الكامل (يسار)، مخطط مصغر بمقدار 2/3 (يمين).

test_ae_precapture_trigger

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

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

النجاح: يتقارب AE.

test_auto_vs_manual

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

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

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

test_auto_vs_manual auto example

الشكل 6: مثال على test_auto_vs_manual auto

مثال على توازن اللون الأبيض في 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, black example

الشكل 9: test_black_white، مثال على اللون الأسود

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

الشكل 10: مثال على test_black_white، أبيض

مثال على متوسط مخطط test_black_white

الشكل 11: مثال على test_black_white وplot means.

test_burst_capture

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

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

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_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 crop example

الشكل 14: مثال على اقتصاص أولي من خلال test_crop_region_raw comp.

test_crop_region_raw comp raw full example

الشكل 15: مثال كامل على test_crop_region_raw comp raw

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

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

test_crop_region_raw_yuv_full example

الشكل 17: مثال كامل على test_crop_region_raw YUV

test_crop_regions

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

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

ناجح: تتطابق صورة المنطقة التي تم اقتصاصها مع الجزء الذي يتوافق مع صورة الاقتصاص.

test_ev_compensation

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

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

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

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

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

test_ev_compensation_basic

الشكل 18: test_ev_compensation_basic

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

test_ev_compensation_advanced_plot_means

الشكل 19: test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

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

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

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

آلية الفشل: في الشكل التالي، مع زيادة قيم مضاعِف الكسب (المحور س)، تبدأ القيم المتوسطة لمستوى النموذج اللوني (RGB) التي تمت تسويتها (المحور ص) في الانحراف عن قيم مضاعِف الكسب المنخفضة.

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. يتم التقاط سلسلة من اللقطات باستخدام طلبات متتالية، مع تغيير مَعلمات طلب الالتقاط بين اللقطات. يتحقّق من أنّ الصور تحتوي على الخصائص المتوقّعة.

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

android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL

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

test_latching plot means example

الشكل 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 بشكل خطي مع زيادة الحساسية.

مثال على متوسطات مخطط test_linearity

الشكل 37: مثال على متوسط مخطط test_linearity.

test_locked_burst

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

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

ناجح: تبدو الصور متّسقة.

test_locked_burst frame0 example

الشكل 38: مثال على الإطار 0 في test_locked_burst

test_locked_burst frame1 example

الشكل 39: مثال على الإطار الأول في 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.* عند ضبطها. Takes shots with different transform and gain values, and tests that they look correspondingly different. يتم اختيار التحويل والمكاسب لجعل الناتج أحمر أو أزرق بشكل متزايد. يستخدم خريطة تدرج خطية.

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

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

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

test_param_color_correction plot means example

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

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

test_param_color_correction req=0 unity example

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

test_param_color_correctness req=1 red boost example

الشكل 43: مثال على تعزيز اللون الأحمر في req=1 لـ test_param_color_correctness

مثال على تعزيز اللون الأزرق في test_param_color_correction req=2

الشكل 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

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

مثال على test_param_flash_mode_2

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

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

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

test_param_noise_reduction

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

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

android.hardware.camera2.CaptureRequest#NOISE_REDUCTION_MODE

ناجح: تختلف نسبة الإشارة إلى الضوضاء باختلاف أوضاع تقليل الضوضاء وتعمل بشكل مشابه للرسم البياني التالي:

مثال على نسب الإشارة إلى الضوضاء في مخطط test_param_noise_reduction

الشكل 49: مثال على نِسب الإشارة إلى الضوضاء في مخطط test_param_noise_reduction

0: OFF, 1: FAST, 2: HQ, 3: MIN , 4: ZSL

test_param_noise_reduction high gain nr=0 example

الشكل 50: مثال على test_param_noise_reduction high gain nr=0

test_param_noise_reduction high gain nr=1 example

الشكل 51: مثال على test_param_noise_reduction high gain nr=1

test_param_noise_reduction high gain nr=2 example

الشكل 52: مثال على test_param_noise_reduction high gain nr=2

test_param_noise_reduction high gain nr=3 example

الشكل 53: مثال على test_param_noise_reduction high gain 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 lens shading map, mode 1 loop 0

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

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

الشكل 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 بحساسية مختلفة، وتنشر مجموعة تعزيز الحساسية الأولية، وتتحقّق مما إذا كان متوسط بكسل الناتج يتطابق مع إعدادات الطلب.

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

ناجح: تصبح صور RAW داكنة أكثر مع زيادة التعزيز، بينما يظل سطوع صور 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 example

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

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

الشكل 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 example

الشكل 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.

test_post_raw_sensitivity_boost raw plot means example

الشكل 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 example

الشكل 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 example

الشكل 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 example

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

مثال على test_raw_exposure ISO=286

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

test_raw_exposure ISO=363 example

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

test_raw_exposure_s=440

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

test_reprocess_noise_reduction

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

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

android.hardware.camera2.CaptureResult#NOISE_REDUCTION_MODE

النجاح: FAST >= OFF وHQ >= FAST وHQ >> OFF.

مخطّط نموذجي لنسبة الإشارة إلى الضوضاء (SNR) مقابل وضع تقليل الضوضاء (NR)

الشكل 79: مثال على رسم بياني نموذجي لنسبة الإشارة إلى الضوضاء مقابل وضع 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

يختبر هذا الاختبار ما إذا كانت الأحجام والتنسيقات المبلَّغ عنها لالتقاط الصور تعمل بشكل صحيح.

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

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

ناجح: يكتمل الاختبار ويعرض الصور المطلوبة.

مثال على 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 الأوّلي. يوضّح الرسم البياني التباين الذي تم قياسه في الجزء الأوسط من البطاقة الرمادية في اللقطات الأولية التي تم التقاطها على نطاق من الحساسيات، ويقارن هذه القيم بالتباين المتوقّع عند كل حساسية من خلال نموذج التشويش 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، ويتحقق من أنها تتطابق.

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

android.graphics.ImageFormat#JPEG

ناجح: متوسط الفرق في 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 متشابهة، والفرق بينهما أقل من% 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. السجلّاتandroid.shading.mode.

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

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

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 في حال استيفاء أي من المعايير التالية:

أن يكون مستوى واجهة برمجة التطبيقات (first_api_level) الأول في الجهاز هو 35 أو أقل
لا يعرض الجهاز الإعلانات CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY في CONTROL_AE_AVAILABLE_PRIORITY_MODES.

test_exposure_time_priority

يتم اختبار CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY عبر أوقات تعرّض مختلفة، مع التحقّق من ثبات السطوع في النطاق الذي يمكن أن يعوّضه ISO.

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

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

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

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

أن يكون مستوى واجهة برمجة التطبيقات (first_api_level) الأول في الجهاز هو 35 أو أقل
لا يعرض الجهاز الإعلانات CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY في CONTROL_AE_AVAILABLE_PRIORITY_MODES.

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: مثال على وضع التعرّف على الوجوه test_num_faces 1

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

يظهر "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 لا يتجاوز دقة 1920x1440. يتم ضبط jpeg.quality على 100 والتقاط طلب مزدوج من مساحة العرض. يتم تحويل الصورتَين إلى مصفوفات RGB ويتم احتساب الفرق بينهما من خلال الجذر التربيعي لمتوسط المربعات (RMS) الثلاثي الأبعاد.

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

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

ناجح: صور YUV وJPEG لحالة الاستخدام STILL_CAPTURE بها أقل من 3% من فرق RMS (قيمة جذر متوسط المربع للإشارة)، وصور YUV لجميع حالات الاستخدام المتوافقة بها أقل من 4% من فرق CIELAB عن صور 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).

النجاح: يجب أن يكون وقت استجابة التقاط صور JPEG في Camera2 أقل من 1000 ملي ثانية بدقة 1080p، كما تم قياسه من خلال اختبار PerformanceTest لكاميرا CTS في ظروف الإضاءة ITS ‏ (3000 كلفن) لكلتا الكاميرتين الأساسيتين.

test_camera_launch_perf_class

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

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

test_default_camera_hdr

يختبر هذا الاختبار ما إذا كان التقاط الكاميرا التلقائي هو Ultra HDR لفئة الأداء 15 كما هو محدّد في القسم 2.2.7.2 الكاميرا من مستند تعريف التوافق (CDD).

ناجح: يجب أن يكون التقاط حزمة الكاميرا التلقائية بدقة HDR الفائقة لجهاز من فئة الأداء 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 example

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

test_preview_num_faces

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

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

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

test_num_faces_fd_mode_1

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

scene2_g

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

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

test_preview_num_faces

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

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

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

test_preview_num_faces

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

scene3

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

scene3_aruco_chart

الشكل 108: رسم بياني للمشهد 3

test_edge_enhancement

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

ناجح: وضع HQ (2) أكثر وضوحًا من وضع OFF (0). وضع "FAST" (1) أكثر وضوحًا من وضع "OFF". يجب أن يكون وضع "HQ" أكثر وضوحًا من وضع "FAST" أو مساويًا له.

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

android.hardware.camera2.CaptureRequest#EDGE_MODE

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

EDGE_MODE

test_edge_enhancement_edge=0

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

test_edge_enhancement edge=1 example

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

test_edge_enhancement edge=2 example

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

test_flip_mirror

يختبر هذا الاختبار ما إذا كانت الصورة موجّهة بشكل صحيح وفقًا للقسم 7.5.2 الكاميرا الأمامية في مستند تعريف التوافق (CDD). في الإصدار 17 من نظام التشغيل Android والإصدارات الأحدث، يتم استخدام علامات ArUco للتحقّق من وجود المخطّط واتجاهه. يمكن تحديد الصور المعكوسة أو المقلوبة أو المُدارة من خلال ميزة المعين بالقرب من المركز.

ناجح: تم رصد جميع العلامات ومحاذاتها بشكل صحيح. يجب ألا تكون الصورة مقلوبة أو معكوسة أو تم تدويرها.

مثال على رقعة مشهد test_flip_mirror

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

test_imu_drift

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

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

البطاقة:

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

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

الشكل 113: مثال على انحراف الجيروسكوب في اختبار test_imu_drift

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

الشكل 114: مثال على انحراف متّجه الدوران في اختبار test_imu_drift

test_landscape_to_portrait

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

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

ناجح: يحدّد الاختبار موقع مخطط بالتدوير المتوقّع (0 درجة عند إيقاف إلغاء الوضع الأفقي إلى الوضع العمودي، و90 درجة عند التفعيل).

مثال على test_landscape_to_portrait

الشكل 115: مثال على test_landscape_to_portrait

test_lens_movement_reporting

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

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

في الإصدار 17 من نظام التشغيل Android والإصدارات الأحدث، يستخدم هذا الاختبار علامات ArUco لتحديد منطقة المخطّط التي تحتوي على الحواف الحادة اللازمة. توفّر هذه الطريقة رصدًا ثابتًا للكاميرات، بدءًا من الكاميرات ذات العدسة الواسعة جدًا (UW) ووصولاً إلى الكاميرات المقرِّبة.

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

ناجح: تكون علامة حركة العدسة 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

الشكل 116: مثال على رسم بياني لـ test_reprocess_edge_enhancement

scene4

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

يمكن أن تكون الاختبارات في scene4 حساسة للمحاذاة، لذا بدءًا من الإصدار 15 من نظام التشغيل Android، يمكنك استخدام check_alignment.py في دليل الأدوات لتفعيل التحقّق من محاذاة الجهاز قيد الاختبار والمخطط.

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

الشكل 117: مثال على scene4

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. لمزيد من المعلومات، يُرجى الاطّلاع على السؤال الأول في الأسئلة الشائعة حول Camera ITS-in-a-box.

test_preview_aspect_ratio_and_crop

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

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

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

test_preview_stabilization_fov

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

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

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

test_video_aspect_ratio_and_crop

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

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

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

scene6

‫scene6 هي شبكة من علامات ArUco التي يمكن التعرّف عليها بدقة. قد تكون الاختبارات في scene6 حساسة للمحاذاة، لذا بدءًا من الإصدار 15، يمكنك استخدام check_alignment.py في دليل الأدوات لتفعيل التحقّق من محاذاة الجهاز قيد الاختبار والمخطط.

scene6

الشكل 118: مثال على scene6

test_in_sensor_zoom

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

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

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

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

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

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

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

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

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

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

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

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

test_preview_zoom

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

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

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

test_preview_zoom images showing selected marker closest to the center

الشكل 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: scene7.

test_multi_camera_switch

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

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

يتم تحليل اللقطات التي تم التقاطها عند نقطة التقاطع وقبلها من أجل التعرّض التلقائي (AE) وتوازن اللون الأبيض التلقائي (AWB) والتركيز التلقائي (AF).

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

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

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

الاجتياز: لاجتياز الاختبار، يجب اجتياز عمليات التحقّق من التعريض التلقائي وتوازن اللون الأبيض التلقائي. تُستخدم نتائج فحص التركيز التلقائي لأغراض التسجيل فقط. فيما يلي معايير كل فحص:

التحقّق من التعرّض التلقائي: يجب أن يكون التغيير في الإضاءة (قيمة Y) بين صور العدسة الواسعة والعدسة الواسعة جدًا أقل من% 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: رقعة رمادية تم التقاطها باستخدام عدسة واسعة الزاوية

scene8

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

مثال على scene8

الشكل 128: مثال على scene8

test_ae_awb_regions

يختبر هذا الاختبار ما إذا كانت قيم RGB وLuma تختلف عند تسجيل المعاينة في مناطق مختلفة من التعرض التلقائي (AE) وتوازن اللون الأبيض التلقائي (AWB).

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

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

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

اجتياز: اجتياز عمليتَي التحقّق من AE وAWB.

test_ae_awb_regions_dark_region

الشكل 129: يتم قياس الإضاءة في المنطقة المظلمة من الإطار مع زيادة التعرض للضوء.

test_ae_awb_regions_light_region

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

آليات الإخفاق:

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

الشكل 131: علامات ArUco غير محاذية.

test_color_correction_mode_cct

يختبر COLOR_CORRECTION_MODE درجات حرارة الألوان وتدرّجاتها المختلفة، ويتحقّق من التغييرات في نِسب النموذج اللوني أحمر أخضر أزرق (RGB) مقارنةً بالمشهد الذي تم التقاطه، scene8.

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

ناجح: تُظهر نِسب RGB الزيادات أو الانخفاضات المتوقعة بالنسبة إلى درجات حرارة الألوان ودرجات الألوان المحدّدة.

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

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

أن يكون مستوى واجهة برمجة التطبيقات (first_api_level) الأول في الجهاز هو 35 أو أقل
لا يعرض الجهاز الإعلانات COLOR_CORRECTION_MODE_CCT في COLOR_CORRECTION_AVAILABLE_ABERRATION_MODES.

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_extensions

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

scene_hdr

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

scene_hdr

الشكل 135: مثال على scene_hdr

test_hdr_extension

يختبر إضافة HDR. Takes captures with and without the extension enabled, and checks if the extension makes the QR code more detectable.

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

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

scene_low_light

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

مثال على scene_low_light

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

test_night_extension

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

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

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

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

البطاقة:

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

يعرض مخطط الإضاءة التالي شكل نتيجة الاختبار الناجحة.

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

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

test_low_light_boost_extension

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

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

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

البطاقة:

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

scene_tele

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

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

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

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

scene6_tele

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

إذا كانت لقطات "scene6_tele" تبدو ساطعة أكثر من اللازم في الجهاز المعياري، عليك إزالة اللوحة الأمامية للجهاز المعياري.

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

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

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

remove_front_plate

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

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 متشابهة.

يتم تحليل اللقطات التي تم التقاطها عند نقطة الانتقال وقبلها من أجل التعرّض التلقائي للضوء وتوازن اللون الأبيض التلقائي والتركيز التلقائي.

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

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

الاجتياز: لاجتياز الاختبار، يجب اجتياز عمليات التحقّق من التعريض الضوئي التلقائي وتوازن اللون الأبيض التلقائي والتركيز التلقائي. في ما يلي معايير كل عملية تحقّق:

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

scene_video

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

الشكل 141: مثال على scene_video

test_preview_frame_drop

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

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

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

مشاهد اختبار مستندة إلى Gen2 rig / sensor_fusion

feature_combination

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

test_feature_combination

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

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

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

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

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

scene_flash

تتطلّب اختبارات scene_flash مشهدًا مظلمًا في صندوق دمج أدوات الاستشعار. في الإصدار 17 من Android والإصدارات الأحدث، يمكن إجراء اختبار scene_flash باستخدام جهاز Gen2.

test_auto_flash

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

في Android 17 والإصدارات الأحدث، يتم اختبار مستويات التكبير غير 1x للتحقّق من عملها بشكل صحيح في جميع نطاقات التكبير المتوافقة.

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

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

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

يختبر هذا الإجراء ما إذا كانت لقطات LED تشبّع الصورة أو تلوّنها.

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

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

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

ناجح: تتراوح نِسب الأحمر إلى الأخضر والأزرق إلى الأخضر بين 0.95 و1.05. متوسط صورة الفلاش ضمن النطاق (68, 102).

test_night_mode_indicator

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

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

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

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

android.extension.nightModeIndicator

البطاقة:

عندما يكون الضوء مضاءً، يجب أن يكون مؤشر الوضع الليلي في الحالة 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.

scene_gen2_chart

في الإصدار 17 من Android والإصدارات الأحدث، يستخدم تطبيق "scene_gen2_chart" مخطط Gen2 الورقي.

يتكوّن مخطط الاختبار هذا من عينات للوجه ورمز استجابة سريعة ورقع تدرج الرمادي ونجمة سيمنز ومخطط ألوان ومربعات مائلة.

test_chart_gen2

الشكل 142: مثال على نموذج رسم بياني من الجيل الثاني

test_tonemap_sequence

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

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

اختبار رسم تسلسل خريطة الألوان

الشكل 143: اختبار رسم تسلسل خريطة الألوان

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

ناجح: يكون الفرق في السطوع بين المنحنيَين التلقائي والخطي أكثر من %15، بينما يكون الفرق بين المنحنيَين الأسيَّين أقل من %8.

test_multi_camera_switch

يتحقّق هذا الاختبار من اتساق الألوان والتعرّض للضوء أثناء الانتقال بين مستويات التكبير/التصغير الديناميكي. يتحقّق هذا الاختبار من أنّ التبديل بين العدسة الواسعة جدًا (UW) والعدسة الواسعة (W) أثناء تسجيل المعاينة يحافظ على قيم CIELAB متطابقة تقريبًا، ما يمنع حدوث تغييرات مرئية في تجربة المستخدم.

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

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

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

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

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

uw_dynamic_range_patch_cell_8

الشكل 144: رقعة رمادية تم التقاطها باستخدام عدسة واسعة الزاوية

w_dynamic_range_patch_cell_7

الشكل 145: رقعة رمادية تم التقاطها باستخدام عدسة واسعة الزاوية

scene_ip

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

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

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

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

test_chart_gen2

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

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

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

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

test_default_jca_ip

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

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

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

test_jca_jpegr_ip

يتحقّق هذا الاختبار من أنّ الفرق في توازن اللون الأبيض بين لقطة المعاينة بتنسيق JPEG_R JCA والصور التي تم التقاطها لا يتجاوز 4.

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

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

sensor_fusion

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

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

الشكل 147: مخطط دمج أجهزة الاستشعار

الرسم البياني لدمج بيانات أدوات الاستشعار في Rig

الشكل 148: مخطّط دمج أجهزة الاستشعار الذي يملأ الجزء الخلفي من صندوق دمج أجهزة الاستشعار

test_lens_intrinsic_calibration

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

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

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

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

الشكل 149: مثال على رسم بياني لـ test_lens_intrinsic_calibration يعرض التغييرات في النقاط الرئيسية بالبكسل لكل لقطة

test_multi_camera_frame_sync

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

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

ناجح: لا تتغيّر الزاوية بين الصور من كل كاميرا بشكل ملحوظ عند تدوير الهاتف.

test_preview_distortion

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

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

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

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

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

test_preview_stabilization

يتم اختبار ما إذا كان فيديو المعاينة الثابت يدور أقل من الجيروسكوب.

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

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

في ما يلي نماذج لفيديوهات تم تثبيتها وأخرى لم يتم تثبيتها:

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

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

test_sensor_fusion

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

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

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

الشكل 153: مثال على أحداث جيروسكوب test_sensor_fusion
‫test_sensor_fusion_plot_rotations: يعرض محاذاة أحداث الجيروسكوب والكاميرا. يجب أن يعرض هذا المخطط حركة مطابقة بين الكاميرا والجيروسكوب بمقدار +/-1 ملي ثانية.

الشكل 154: مثال على دوران مخطط test_sensor_fusion

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

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

آليات الإخفاق:

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

test_video_stabilization

متوقّف نهائيًا: تم إيقاف هذا الاختبار نهائيًا من Android 17. في الإصدار Android 17 والإصدارات الأحدث، يتم استبدال هذا الاختبار بـ test_video_stabilization_jca.

يختبر هذا الإعداد ما إذا كان الفيديو المثبَّت يدور أقل من الجيروسكوب.

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

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

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

الشكل 155: فيديو نموذجي مع ميزة التثبيت

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

test_video_stabilization_jca

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

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

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

مشهد اختبار يستند إلى الناشر

scene5

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

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

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

الشكل 157: مثال على التقاط scene5

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

test_lens_shading_and_color_uniformity

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

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

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

آليات الإخفاق:

تظليل مفرط في الصور
ظهور حواف سوداء في الصور

test_lens_shading_and_color_uniformity_y_plane

الشكل 158: test_lens_shading_and_color_uniformity_y_plane.

test_lens_shading_and_color_uniformity_color_uniformity_result

الشكل 159: test_lens_shading_and_color_uniformity_color_uniformity.

test_lens_shading_and_color_uniformity_lens_shading_result

الشكل 160: test_lens_shading_and_color_uniformity_lens_shading_result

مشهد اختبار يستند إلى جهاز لوحي ذي نطاق واسع

scene_wide_gamut

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

تتحقّق هذه الاختبارات من أنّ الصورة التي تم التقاطها تلتزم بالملف الشخصي الصحيح للألوان ونطاق الألوان.

test_display_p3

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

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

ناجح: يحتوي ملف JPEG على ملف تعريف ICC لمساحة العرض P3 وأكثر من %1 من الألوان خارج نطاق sRGB.

مثال على test_display_p3

الشكل 161: مثال على test_display_p3

اختبارات ITS للكاميرا تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

مَشاهد اختبارية على الأجهزة اللوحية

scene0

test_jitter

test_metadata

test_request_capture_match

test_sensor_events

test_solid_color_test_pattern

test_test_pattern

test_tonemap_curve

test_unified_timestamp

test_vibration_restriction

scene1_1

test_ae_precapture_trigger

test_auto_vs_manual

test_black_white

test_burst_capture

test_burst_sameness_manual

test_crop_region_raw

test_crop_regions

test_ev_compensation

test_exposure_x_iso

test_latching

test_linearity

test_locked_burst

scene1_2

test_param_color_correction

test_param_flash_mode

test_param_noise_reduction

test_param_shading_mode

test_param_tonemap_mode

test_post_raw_sensitivity_boost

test_raw_exposure

test_reprocess_noise_reduction

test_tonemap_sequence

test_yuv_jpeg_all

test_yuv_plus_dng

scene1_3

test_capture_result

test_dng_noise_model

test_jpeg

test_raw_burst_sensitivity

test_raw_sensitivity

test_yuv_plus_jpeg

test_yuv_plus_raw

test_sensitivity_priority

test_exposure_time_priority

scene2_a

test_autoframing

test_display_p3

test_effects

test_exposure_keys_consistent

test_format_combos

test_num_faces

test_reprocess_uv_swap

scene2_b

test_preview_num_faces

test_yuv_jpeg_capture_sameness

scene2_c

test_num_faces

test_jpeg_capture_perf_class

test_camera_launch_perf_class

test_default_camera_hdr

scene2_d

test_preview_num_faces

scene2_e

test_continuous_picture

test_num_faces

scene2_f

test_preview_num_faces

scene2_g

test_preview_num_faces

scene3

test_edge_enhancement

test_flip_mirror

test_imu_drift

test_landscape_to_portrait

test_lens_movement_reporting

test_reprocess_edge_enhancement

scene4

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