تست دوربین ITS

این صفحه فهرست جامعی از تست‌های مجموعه تست تصویر دوربین (ITS) را ارائه می‌کند که بخشی از تأییدکننده مجموعه تست سازگاری Android (CTS) است. تست‌های ITS تست‌های عملکردی هستند، به این معنی که کیفیت تصویر را اندازه‌گیری نمی‌کنند، اما همه عملکردهای دوربین تبلیغاتی همانطور که انتظار می‌رود کار می‌کنند. این سند به توسعه‌دهندگان و آزمایش‌کنندگان اجازه می‌دهد بفهمند که آزمایش‌های فردی چه می‌کنند و چگونه خطاهای آزمایش را اشکال‌زدایی کنند.

دوربین ITS gates را بر اساس ویژگی های دوربین مورد نیاز، سطح API و سطح کلاس عملکرد رسانه (MPC) آزمایش می کند. برای سطح API، ITS از ro.product.first_api_level برای دروازه‌سازی تست‌های اضافه شده در سطح API خاص استفاده می‌کند که تجربیات منفی کاربر را برای عملکرد در سطوح پایین‌تر API آزمایش می‌کند. ITS از ro.vendor.api_level برای تست گیت برای ویژگی‌های اضافه شده در سطح API خاص استفاده می‌کند که به قابلیت سخت‌افزاری جدید نیاز دارد. اگر 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 (JCA)

برای توضیح هر صحنه به بخش های جداگانه مراجعه کنید.

صحنه 0

آزمایش ها به اطلاعات صحنه خاصی نیاز ندارند. اما برای تست ژیروسکوپ و لرزش گوشی باید ثابت باشد.

test_jitter

لرزش را در مهرهای زمانی دوربین اندازه گیری می کند.

API های آزمایش شده:

پاس: حداقل 30 میلی‌ثانیه دلتا بین فریم‌ها وجود دارد.

در شکل زیر به محدوده کوچک محور y توجه کنید. جیتر در واقع در این طرح کوچک است.

طرح test_jitter

شکل 1. نمودار test_jitter.

test_metadata

اعتبار ورودی‌های فراداده را آزمایش می‌کند، به نتایج عکس‌برداری و ویژگی‌های دوربین نگاه می‌کند. این آزمایش از نوردهی و دریافت مقادیر auto_capture_request استفاده می کند زیرا محتوای تصویر مهم نیست.

API های آزمایش شده:

Pass: سطح سخت‌افزار، rollingShutterSkew ، برچسب‌های frameDuration ، timestampSource ، croppingType ، blackLevelPattern ، pixel_pitch ، میدان دید (FoV) و فاصله هایپرکانونی موجود هستند و مقادیر معتبری دارند.

test_request_capture_match

آزمایش می کند که دستگاه با بازخوانی فراداده ضبط، مقادیر نوردهی و افزایش صحیح را می نویسد.

API های آزمایش شده:

پاس: درخواست و گرفتن مقادیر فراداده در تمام عکس‌ها مطابقت دارد.

test_sensor_events

برای دستگاه‌هایی که پشتیبانی از همجوشی حسگر را تبلیغ می‌کنند، این آزمایش بررسی می‌کند که آیا دستگاه رویدادهای حسگر را جستجو و چاپ می‌کند یا خیر. سنسورهای مورد انتظار شتاب سنج، ژیروسکوپ و مغناطیس سنج هستند. این تست فقط در صورتی کار می کند که صفحه نمایش روشن باشد، یعنی دستگاه در حالت آماده به کار نیست.

API های آزمایش شده:

پاس: رویدادها برای هر سنسور دریافت می شود.

test_solid_color_test_pattern

آزمایش‌هایی که الگوهای تست رنگ ثابت به درستی برای بی‌صدا کردن دوربین ایجاد می‌شوند. اگر قطع دوربین پشتیبانی می شود، الگوهای تست رنگ ثابت باید پشتیبانی شوند. اگر بی‌صدا کردن دوربین پشتیبانی نمی‌شود، الگوهای تست رنگ ثابت فقط در صورتی آزمایش می‌شوند که قابلیت تبلیغ شده باشد.

اگر تصاویر خام پشتیبانی می شوند، تخصیص رنگ نیز آزمایش می شود. رنگ های تست شده مشکی، سفید، قرمز، آبی و سبز هستند. برای دوربین هایی که از تصاویر خام پشتیبانی نمی کنند، فقط مشکی تست شده است.

API های آزمایش شده:

پاس: الگوهای تست جامد پشتیبانی شده رنگ صحیح هستند و واریانس کمی در تصویر وجود دارد.

test_test_pattern

پارامتر android.sensor.testPatternMode را برای گرفتن فریم‌ها برای هر الگوی آزمایشی معتبر آزمایش می‌کند و بررسی می‌کند که فریم‌ها برای رنگ‌های ثابت و نوارهای رنگی درست تولید شده‌اند. این آزمون شامل مراحل زیر است:

  1. تصاویر را برای همه الگوهای تست پشتیبانی شده می گیرد.
  2. بررسی صحت الگوی تست رنگ ثابت و نوارهای رنگی را انجام می دهد.

API های آزمایش شده:

پاس: الگوهای تست پشتیبانی شده به درستی تولید می شوند.

نمونه test_test_patterns

شکل 2. نمونه test_test_patterns.

test_tonemap_curve

تبدیل الگوی آزمایشی از خام به YUV را با نقشه خطی آزمایش می کند. این آزمایش به android.sensor.testPatternMode = 2 ( COLOR_BARS ) نیاز دارد تا یک الگوی تصویر عالی برای تبدیل نقشه تن ایجاد کند. تأیید می کند که خط لوله دارای خروجی های رنگی مناسب با نقشه خطی و ورودی تصویر ایده آل است (متکی به test_test_patterns ).

API های آزمایش شده:

پاس: YUV و RAW شبیه یکدیگر هستند.

test_tonemap_curve مثال خام

شکل 3. test_tonemap_curve مثال خام.

test_tonemap_curve مثال YUV

شکل 4. test_tonemap_curve مثال YUV.

test_unified_timestamp

آزمایش می کند که آیا رویدادهای حسگر تصویر و حرکت در یک حوزه زمانی هستند یا خیر.

API های آزمایش شده:

پاس: مهرهای زمانی حرکت بین دو مهر زمانی تصویر هستند.

test_vibration_restriction

آزمایش می کند که آیا لرزش دستگاه مطابق انتظار عمل می کند یا خیر.

API های آزمایش شده:

پاس: هنگامی که توسط API محدودیت صوتی دوربین بی‌صدا می‌شود، دستگاه نمی‌لرزد.

صحنه 1_1

scene1 یک نمودار خاکستری است. نمودار خاکستری باید 30 درصد از دوربین FoV مرکز را پوشش دهد. انتظار می رود نمودار خاکستری 3A (AE، AWB و AF) را به طور متوسط ​​​​به چالش بکشد زیرا منطقه مرکزی هیچ ویژگی ندارد. با این حال، درخواست عکسبرداری کل صحنه را مشخص می کند که شامل ویژگی های کافی برای همگرایی 3A است.

دوربین های RFoV را می توان در دستگاه تست WFoV یا RFoV آزمایش کرد. اگر یک دوربین RFoV در دستگاه تست WFoV آزمایش شود، نمودار با 2/3 مقیاس می شود تا برخی از مرزها برای نمودار خاکستری در FoV مشخص شود تا به همگرایی 3A کمک کند. برای توضیحات دقیق تر از دستگاه های تست دوربین، دوربین ITS-in-a-a-box را ببینید.

صحنه 1 نمونه

شکل 5. نمودار صحنه1 در اندازه کامل (چپ)، نمودار مقیاس شده 2/3 (راست).

test_ae_precapture_trigger

هنگام استفاده از ماشه پیش گرفتن، دستگاه حالت AE را آزمایش می کند. پنج درخواست دستی را با AE غیرفعال می گیرد. آخرین درخواست دارای یک ماشه Precapture AE است که باید نادیده گرفته شود زیرا AE غیرفعال است.

API های آزمایش شده:

پاس: AE همگرا می شود.

test_auto_vs_manual

تست‌هایی که عکس‌های خودکار و دستی گرفته‌اند یکسان هستند.

API های آزمایش شده:

پاس: افزایش و تبدیل دستی تراز سفیدی گزارش شده در هر نتیجه عکسبرداری با estimate تعادل رنگ سفید خودکار از الگوریتم 3A دوربین مطابقت دارد.

نمونه خودکار test_auto_vs_manual

شکل 6. نمونه خودکار test_auto_vs_manual.

نمونه test_auto_vs_manual white balance

شکل 7. مثال test_auto_vs_manual white balance.

test_auto_vs_manual دستی مثال تبدیل تعادل رنگ سفید

شکل 8. مثال تبدیل تعادل رنگ سفید دستی test_auto_vs_manual.

تست_سیاه_سفید

تست هایی که دستگاه تصاویر سیاه و سفید کامل تولید می کند. دو عکس می گیرد، اولی با بهره بسیار کم و نوردهی کوتاه که منجر به یک عکس سیاه می شود و دومی با بهره بسیار زیاد و نوردهی طولانی که منجر به یک عکس سفید می شود.

API های آزمایش شده:

Pass: تصاویر سیاه و سفید تولید می کند. کانال های اشباع شده تصاویر سفید دارای مقادیر RGB [255، 255، 255] با حاشیه خطای کمتر از 1٪ اختلاف هستند.

test_black_white، نمونه سیاه

شکل 9. test_black_white، مثال سیاه.

test_auto_vs_manual دستی مثال تبدیل تعادل رنگ سفید

شکل 10. test_black_white، نمونه سفید.

طرح test_black_white به معنای مثال است

شکل 11. test_black_white، نمودار به معنای مثال است.

test_burst_capture

تأیید می کند که کل خط لوله ضبط می تواند با سرعت ضبط در اندازه کامل و زمان CPU مطابقت داشته باشد.

API های آزمایش شده:

Pass: مجموعه‌ای از تصاویر در اندازه کامل را می‌گیرد، افت فریم و روشنایی تصویر را بررسی می‌کند.

test_burst_sameness_manual

5 بار پشت سر هم از 50 عکس با تنظیمات ضبط دستی می گیرد و بررسی می کند که همه آنها یکسان هستند. از این تست برای شناسایی فریم های پراکنده ای استفاده کنید که متفاوت پردازش شده اند یا مصنوعاتی دارند.

API های آزمایش شده:

پاس: تصاویر از نظر بصری و در مقادیر RGB یکسان هستند.

Fail: یک افزایش یا کاهش نمودار میانگین RGB را در ابتدای هر انفجار نشان می دهد

  • تحمل برای first_API_level <30 3٪ است
  • تحمل برای first_API_level >= 30 2٪ است

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 قابل برش نیستند.

API های آزمایش شده:

پاس: تصاویر YUV در مرکز برش داده می شوند اما تصاویر خام نه.

نمونه برش خام test_crop_region_raw comp

شکل 14. test_crop_region_raw comp raw نمونه محصول.

test_crop_region_raw comp raw مثال کامل

شکل 15. test_crop_region_raw comp raw مثال کامل.

نمونه برش test_crop_region_raw comp YUV

شکل 16. نمونه برش test_crop_region_raw comp YUV.

test_crop_region_raw_yuv_full مثال

شکل 17. نمونه کامل test_crop_region_raw YUV.

test_crop_regions

آزمایش هایی که مناطق کشت کار می کنند. یک تصویر کامل می گیرد و وصله هایی از پنج ناحیه مختلف (گوشه ها و مرکز) ایجاد می کند. با مجموعه برش برای پنج منطقه عکس می گیرد. مقادیر پچ و برش تصویر را با هم مقایسه می کند.

API های آزمایش شده:

Pass: تصویر ناحیه برش خورده با وصله مربوط به تصویر برش مطابقت دارد.

test_ev_compensation

آزمایش هایی که نشان می دهد جبران ارزش نوردهی (EV) اعمال می شود. این آزمون شامل یک بخش مقدماتی و یک بخش پیشرفته است.

بخش اصلی آزمایش می کند که جبران EV با استفاده از محدوده ایجاد شده با CONTROL_AE_COMPENSATION_STEP اعمال می شود. در هر مقدار جبرانی هشت فریم گرفته می شود.

بخش پیشرفته نوردهی را در هشت مرحله افزایش می دهد و روشنایی اندازه گیری شده را در مقابل روشنایی مورد انتظار بررسی می کند. مقادیر مورد انتظار از روشنایی تصویر بدون اعمال جبران EV محاسبه می شود و اگر مقادیر محاسبه شده از محدوده مقدار واقعی تصویر بیشتر شود، مقدار مورد انتظار اشباع می شود. اگر مقادیر مورد انتظار و مقادیر اندازه‌گیری شده مطابقت نداشته باشند یا اگر تصاویر در عرض پنج مرحله بیش از حد نوردهی کنند، آزمایش با شکست مواجه می‌شود.

API های آزمایش شده:

پاس بخش اصلی: تصاویر افزایش نوردهی را بدون نوردهی بیش از حد در پنج مرحله نشان می‌دهند.

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 چسبانده نشده اند (که باعث می شود آنها مانند خطوط صاف به نظر برسند). با تنظیم پرچم debug در فایل پیکربندی، آزمایش را می توان با تصاویر RAW نیز اجرا کرد.

API های آزمایش شده:

پاس: تصاویر دارای روشنایی یکسان هستند، اما با ISO بالاتر نویزتر می شوند. صفحات RGB زمانی که مقدار ISO*exposure در فضای بهره آزمایش شده ثابت باشد صاف هستند.

مکانیسم شکست: در شکل زیر، با افزایش مقادیر ضریب بهره (محور 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 می چسبند. یک سری عکس با استفاده از درخواست های پشت سر هم می گیرد و پارامترهای درخواست عکس برداری را بین عکس ها تغییر می دهد. بررسی می کند که تصاویر دارای ویژگی های مورد انتظار هستند.

API های آزمایش شده:

پاس: تصاویر [2، 3، 6، 8، 10، 12، 13] ISO یا نوردهی را افزایش داده اند و با میانگین RGB بالاتر در نمودار زیر نشان داده می شوند.

test_latching plot به معنی مثال است

شکل 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.

تست_خطی

آزمایش می کند که پردازش دستگاه را می توان به پیکسل های خطی معکوس کرد. دنباله ای از عکس ها را با دستگاه به سمت یک هدف یکنواخت می گیرد.

API های آزمایش شده:

پاس: مقادیر R، G، B باید به صورت خطی با افزایش حساسیت افزایش یابد.

نمودار test_linearity به معنای مثال است

شکل 37. نمودار test_linearity به معنای مثال است.

test_locked_burst

تست قفل 3A و انفجار YUV (با استفاده از تنظیم خودکار). این آزمون برای قبولی در دستگاه‌های محدودی طراحی شده است که MANUAL_SENSOR یا PER_FRAME_CONTROLS ندارند. تست سازگاری تصویر YUV را بررسی می کند در حالی که بررسی نرخ فریم در CTS است.

API های آزمایش شده:

پاس: عکس‌ها یکدست به نظر می‌رسند.

نمونه test_locked_burst frame0

شکل 38. test_locked_burst frame0 مثال.

نمونه test_locked_burst frame1

شکل 39. test_locked_burst frame1 مثال.

test_locked_burst_frame2

شکل 40. نمونه test_locked_burst frame2.

صحنه 1_2

scene 1_2 از لحاظ عملکردی یک کپی یکسان از scene 1_1 است که ساختار زیرصحنه ای را برای کاهش مدت زمان طولانی scene 1 اجرا می کند.

test_param_color_correction

آزمایش می کند که پارامترهای android.colorCorrection.* هنگام تنظیم اعمال می شوند. عکس هایی با مقادیر تبدیل و افزایش متفاوت می گیرد، و آزمایش می کند که به نسبت متفاوت به نظر می رسند. تبدیل و سود به گونه ای انتخاب می شوند که خروجی به طور فزاینده ای قرمز یا آبی شود. از نقشه خطی استفاده می کند.

نگاشت تن تکنیکی است که در پردازش تصویر برای نگاشت یک مجموعه از رنگ ها به مجموعه ای دیگر به منظور تقریب ظاهر تصاویر با دامنه دینامیکی بالا در محیطی که محدوده دینامیکی محدودتری دارد استفاده می شود.

API های آزمایش شده:

پاس: مقادیر R و B با توجه به تبدیل افزایش می یابد.

test_param_color_correction نمودار به معنای مثال است

شکل 41. نمودار test_param_color_correction به معنای مثال است.

در شکل‌های زیر، محور x درخواست‌های گرفتن است: 0 = وحدت، 1 = تقویت قرمز، و 2 = تقویت آبی.

test_param_color_correction req=0 مثال واحد

شکل 42. test_param_color_correction req=0 مثال واحد.

test_param_color_correctness req=1 مثال تقویت قرمز

شکل 43. test_param_color_correctness req=1 مثال تقویت قرمز.

test_param_color_correction req=2 مثال تقویت آبی

شکل 44. test_param_color_correction req=2 مثال تقویت آبی.

test_param_flash_mode

آزمایش می کند که پارامتر android.flash.mode اعمال می شود. به صورت دستی نوردهی را در سمت تاریک قرار می دهد، به طوری که مشخص است که فلاش روشن شده است یا نه، و از یک نقشه خطی استفاده می کند. مرکز را با تصویر کاشی بررسی می کند تا ببیند آیا یک گرادیان بزرگ ایجاد شده است تا بررسی کند که فلاش روشن شده است یا خیر.

API های آزمایش شده:

Pass: مرکز تصویر کاشی دارای یک گرادیان بزرگ است، به این معنی که فلاش شلیک می شود.

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 مثال.

نمونه کاشی test_param_flash_mode 2

شکل 48. نمونه دو کاشی test_param_flash_mode.

test_param_noise_reduction

آزمایش می کند که هنگام تنظیم پارامتر android.noiseReduction.mode به درستی اعمال شود. با دوربین کم نور عکس می گیرد. از یک بهره آنالوگ بالا برای کمک به اطمینان از نویز بودن تصویر گرفته شده استفاده می کند. سه عکس برای NR خاموش، سریع و با کیفیت بالا می گیرد. همچنین تصویری با بهره کم و NR خاموش می گیرد و از واریانس آن به عنوان خط پایه استفاده می کند. هر چه نسبت سیگنال به نویز (SNR) بیشتر باشد، کیفیت تصویر بهتر است.

API های آزمایش شده:

Pass: SNR با حالت های مختلف کاهش نویز متفاوت است و مانند نمودار زیر رفتار می کند:

test_param_noise_reduction نمودار SNRs مثال

شکل 49. نمونه SNRs نمودار test_param_noise_reduction.

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

test_param_noise_reduction بهره بالا nr=0 مثال

شکل 50. test_param_noise_reduction high gain nr=0 مثال.

test_param_noise_reduction بهره بالا nr=1 مثال

شکل 51. test_param_noise_reduction high gain nr=1 مثال.

test_param_noise_reduction بهره بالا nr=2 مثال

شکل 52. test_param_noise_reduction high gain nr=2 مثال.

test_param_noise_reduction بهره بالا nr=3 مثال

شکل 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 اعمال می شود.

API های آزمایش شده:

پاس: حالت‌های سایه‌زنی تغییر می‌کنند و نقشه‌های سایه‌زنی لنز مطابق انتظار اصلاح می‌شوند.

نقشه سایه زنی لنز 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 تشکیل شده است.

API های آزمایش شده:

پاس:

  • test1 : هر دو تصویر دارای نقشه خطی هستند، اما n=1 دارای شیب تندتری است. کانال G (سبز) برای تصویر n=1 روشن تر است.
  • test2 : نقشه رنگی یکسان، اما طول متفاوت. تصاویر هم همینطور.

test_param_tonemap_mode با n=0

شکل 58. test_param_tonemap_mode با n=0.

test_param_tonemap_mode با n=1

شکل 59. test_param_tonemap_mode با n=1.

test_post_raw_sensitivity_boost

افزایش حساسیت خام را بررسی می کند. مجموعه ای از تصاویر خام و YUV را با حساسیت های مختلف می گیرد، ترکیب تقویت حساسیت خام را پست می کند، و بررسی می کند که آیا میانگین پیکسل خروجی با تنظیمات درخواست مطابقت دارد یا خیر.

API های آزمایش شده:

پاس: با افزایش بوست، تصاویر خام تیره تر می شوند در حالی که روشنایی تصاویر YUV ثابت می ماند.

test_post_raw_sensitivity_boost خام s=3583 boost=0100 مثال

شکل 60. test_post_raw_sensitivity_boost raw s=3583 boost=0100 مثال.

test_post_raw_sensitivity_boost خام s=1792 boost=0200 مثال

شکل 61. test_post_raw_sensitivity_boost raw s=1792 boost=0200 مثال.

test_post_raw_sensitivity_boost خام s=0896 boost=0400 مثال

شکل 62. test_post_raw_sensitivity_boost raw s=0896 boost=0400 مثال.

test_post_raw_sensitivity_boost خام s=0448 boost=0800 مثال

شکل 63. test_post_raw_sensitivity_boost raw s=0448 boost=0800 مثال.

test_post_raw_sensitivity_boost خام s=0224 boost=1600 مثال

شکل 64. test_post_raw_sensitivity_boost raw s=0224 boost=1600 مثال.

test_post_raw_sensitivity_boost خام s=0112 boost=3199 مثال

شکل 65. test_post_raw_sensitivity_boost raw s=0112 boost=3199 مثال.

test_post_raw_sensitivity_boost نمودار خام یعنی مثال

شکل 66. test_post_raw_sensitivity_boost نمودار خام به معنای مثال است.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 مثال

شکل 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 مثال

شکل 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

مجموعه ای از تصاویر خام را با افزایش زمان نوردهی می گیرد و مقادیر پیکسل را اندازه گیری می کند.

API های آزمایش شده:

Pass: افزایش ISO (بهره) پیکسل ها را نسبت به نور حساس تر می کند، بنابراین نمودار به سمت چپ حرکت می کند.

test_raw_exposure ISO=55 مثال

شکل 73. test_raw_exposure ISO=55 مثال.

10⁰ 1 ms، 101 10 ms و 10-1 0.1 ms است.

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 برای پردازش مجدد درخواست ها اعمال می شود. تصاویر پردازش شده را با دوربین کم نور می گیرد. از یک بهره آنالوگ بالا برای تأیید نویز بودن تصویر ضبط شده استفاده می کند. سه تصویر پردازش شده برای NR خاموش، سریع و با کیفیت بالا می گیرد. یک تصویر پردازش مجدد با بهره کم و NR خاموش می گیرد و از واریانس آن به عنوان خط پایه استفاده می کند.

API های آزمایش شده:

پاس: FAST >= OFF، HQ >= FAST، و HQ >> OFF.

نمودار SNR معمولی در مقابل حالت NR

شکل 79. نمونه نمودار SNR معمولی در مقابل حالت NR.

test_tonemap_sequence

دنباله‌ای از عکس‌ها را با منحنی‌های نقشه رنگی مختلف آزمایش می‌کند. 3 عکس دستی با نقشه رنگی خطی می گیرد. 3 عکس دستی با نقشه آهنگ پیش فرض می گیرد. دلتا را بین هر جفت فریم متوالی محاسبه می کند.

API های آزمایش شده:

پاس: سه فریم یکسان و به دنبال آن یک مجموعه متفاوت از سه فریم یکسان وجود دارد.

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 ذخیره شوند.

API های آزمایش شده:

پاس: همه مراکز تصویر دارای حداکثر اختلاف ریشه میانگین مربع (RMS) (مقدار سیگنال) در تصاویر تبدیل شده RGB با 3٪ بالاترین وضوح تصویر YUV هستند.

نمونه test_yuv_jpeg_all

شکل 86. نمونه test_yuv_jpeg_all.

test_yuv_plus_dng

تست هایی که اندازه ها و فرمت های گزارش شده برای ثبت تصویر کار می کنند.

API های آزمایش شده:

Pass: تست تصاویر درخواستی را تکمیل و برمی گرداند.

نمونه test_yuv_plus_dng

شکل 87. نمونه test_yuv_plus_dng.

صحنه 1_3

scene 1_3 از لحاظ عملکردی یک کپی یکسان از scene 1_1 است که ساختار زیرصحنه ای را برای کاهش مدت زمان طولانی scene 1 پیاده سازی می کند.

test_capture_result

آزمایش می کند که داده های معتبر در اشیاء CaptureResult برمی گردند. این تست شامل یک عکسبرداری خودکار، یک عکسبرداری دستی و یک عکسبرداری خودکار دوم است.

API های آزمایش شده:

پاس: ابرداده برای همه عکس‌برداری‌ها معتبر است و تنظیمات دستی در ضبط خودکار دوم به بیرون درز نمی‌کنند. تصحیح سایه لنز را برای عکسبرداری ترسیم می کند.

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 دانلود کنید.

API های آزمایش شده:

پاس: پارامترهای مدل خام DNG صحیح است. مقادیر RGB مورد انتظار با مقادیر واقعی RGB اندازه گیری شده مطابقت دارد.

test_dng_noise_model_plog

شکل 89. test_dng_noise_model_plog.

test_jpeg

آزمایش‌هایی که تصاویر YUV و تصاویر JPEG دستگاه را تبدیل کرده‌اند یکسان به نظر می‌رسند. تست مرکز 10% تصویر را می گیرد و مقدار RGB را محاسبه می کند و مطابقت آنها را تأیید می کند.

API های آزمایش شده:

Pass: میانگین تفاوت 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

مجموعه ای از تصاویر خام را با افزایش افزایش می دهد و نویز را اندازه گیری می کند. فقط به صورت خام و به صورت رگباری عکس می گیرد.

API های آزمایش شده:

پاس: هر شات نویزتر از شلیک قبلی است، زیرا بهره در حال افزایش است.

از واریانس سلول شبکه آمار مرکز استفاده می کند.

test_raw_burst_sensitivity_variance

شکل 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

مجموعه ای از تصاویر خام را با افزایش حساسیت می گیرد و نویز (واریانس) در مرکز 10% تصویر را اندازه گیری می کند. آزمایش هایی که نشان می دهد هر شات نویزتر از عکس قبلی است.

API های آزمایش شده:

پاس: با هر ضربه واریانس افزایش می یابد.

test_raw_sensitivity_variance

شکل 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

گرفتن یک فریم را به عنوان خروجی YUV و JPEG آزمایش می کند. از یک درخواست دستی با یک نقشه خطی استفاده می کند تا YUV و JPEG هنگام تبدیل توسط ماژول image_processing_utils یکسان به نظر برسند.

API های آزمایش شده:

پاس: تصاویر YUV و JPEG مشابه هستند و کمتر از 1٪ RMS (مقدار سیگنال) تفاوت دارند.

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 آزمایش می کند. از یک درخواست دستی با نقشه خطی استفاده می کند، بنابراین انتظار می رود خام و YUV یکسان باشند. مقادیر RGB 10% مرکز تصاویر تبدیل شده را با هم مقایسه می کند. گزارشات android.shading.mode .

API های آزمایش شده:

پاس: تصاویر 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.

آزمون_حساسیت_اولویت

CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY را در تنظیمات ISO مختلف آزمایش می کند تا ارتباط بین ISO بالاتر و سطوح نویز افزایش یافته را تأیید کند.

API های آزمایش شده:

Pass: ISO بالاتر منجر به افزایش سطح نویز می شود.

معیارهای رد شدن از آزمون

در صورت رعایت هر یک از معیارهای زیر، از آزمون test_sensitivity_priority.py صرفنظر می شود:

test_exposure_time_priority

CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY را در زمان‌های مختلف نوردهی آزمایش می‌کند و روشنایی پایدار را در محدوده‌ای که ISO می‌تواند جبران کند، بررسی می‌کند.

API های آزمایش شده:

پاس: روشنایی (در محدوده تحمل) در طول زمان نوردهی ثابت است اگر ISO در محدوده جبران آن باشد.

معیارهای رد شدن از آزمون

در صورت رعایت هر یک از معیارهای زیر، آزمون test_exposure_time_priority نادیده گرفته می‌شود:

صحنه2_a

scene2_a دارای سه چهره با زمینه خاکستری و لباس خنثی است. چهره ها به گونه ای انتخاب می شوند که طیف وسیعی از رنگ پوست داشته باشند. نمودار باید جهت گیری درستی داشته باشد تا تشخیص چهره به طور بهینه کار کند.

صحنه2_یک مثال

شکل 98. صحنه2_یک مثال.

test_autoframing

رفتار قاب خودکار دستگاه دوربین را آزمایش می کند. بزرگنمایی زیادی انجام می دهد به طوری که هیچ یک از چهره های صحنه قابل مشاهده نباشد، با تنظیم AUTOFRAMING در CaptureRequest روی True ، حالت قاب خودکار را فعال می کند، و بررسی می کند که آیا تمام چهره های صحنه اصلی در هنگام همگرا شدن وضعیت قابل AUTOFRAMING_STATE_CONVERGED هستند (یعنی زمانی که AUTOFRAMING_STATE در CaptureResult تنظیم شده است.

API های آزمایش شده:

پاس: هر سه چهره شناسایی می شوند.

test_display_p3

آزمایش‌ها، ضبط P3 را در JPEG با استفاده از ColorSpaceProfiles API نمایش می‌دهد. آزمایش می کند که JPEG گرفته شده دارای یک نمایه ICC مناسب در هدر خود باشد و اینکه تصویر حاوی رنگ هایی خارج از محدوده sRGB باشد.

API های آزمایش شده:

پاس: JPEG حاوی نمایه نمایشگر P3 ICC و رنگ‌هایی خارج از محدوده sRGB است.

test_effects

قاب را برای جلوه های دوربین پشتیبانی شده می گیرد و بررسی می کند که آیا آنها به درستی تولید شده اند یا خیر. این آزمایش فقط جلوه‌های OFF و MONO را بررسی می‌کند، اما تصاویر را برای همه جلوه‌های پشتیبانی شده ذخیره می‌کند.

API های آزمایش شده:

Pass: تصویر صحنه را با جلوه‌های OFF و یک تصویر تک رنگ با جلوه‌ها روی MONO می‌گیرد.

test_effects_MONO

شکل 99. test_effects_MONO.

test_exposure_keys_consistent

این تست میانگین لومای یک عکسبرداری با قابلیت AE را با یک عکس برداری غیرفعال شده با AE مقایسه می کند که به صورت دستی پارامترهای نوردهی (حساسیت، زمان نوردهی، مدت زمان فریم، افزایش حساسیت پس از خام) دریافت شده در CaptureResult از عکسبرداری با قابلیت AE را اعمال می کند.

API های آزمایش شده:

پاس: اختلاف نسبی لوما بین دو ضبط کمتر از 4 درصد است.

test_format_combos

ترکیب های مختلف فرمت های خروجی را آزمایش می کند.

API های آزمایش شده:

پاس: همه ترکیب ها با موفقیت ضبط می شوند.

test_num_faces

تشخیص چهره را آزمایش می کند.

API های آزمایش شده:

پاس: سه چهره را پیدا می کند.

test_num_faces حالت تشخیص چهره 1 مثال

شکل 100. حالت تشخیص چهره test_num_faces 1 مثال.

test_reprocess_uv_swap

آزمایش‌هایی که نشان می‌دهد پردازش مجدد YUV هواپیماهای U و V را تعویض نمی‌کند. این با محاسبه مجموع تفاوت‌های مطلق (SAD) بین تصویر پردازش‌شده مجدد و عکس‌برداری غیر پردازش‌شده شناسایی می‌شود. اگر مبادله صفحات خروجی U و V ضبط مجدد منجر به افزایش SAD شود، در این صورت خروجی دارای صفحات U و V صحیح فرض می شود.

API های آزمایش شده:

پاس: هواپیماهای U و V تعویض نمی شوند.

test_reprocess_uv_swap

شکل 101. نمونه test_reprocess_uv_swap.

صحنه2_ب

test_preview_num_faces

تشخیص چهره را در پیش نمایش با افزایش تنوع رنگ پوست در صحنه های صورت آزمایش می کند.

API های آزمایش شده:

Pass: سه چهره با نشانه‌های چهره را در جعبه‌های محدودکننده چهره پیدا می‌کند.

test_num_faces_fd_mode_1

شکل 102. حالت تشخیص چهره test_num_faces 1 مثال.

test_yuv_jpeg_capture_sameness

دو تصویر را با استفاده از بزرگترین فرمت‌های رایج YUV و JPEG با نسبت ابعادی مشابه با بزرگ‌ترین فرمت JPEG با وضوح تصویر 1920x1440 می‌گیرد. jpeg.quality را روی 100 تنظیم می کند و درخواست دو سطحی را می گیرد. هر دو تصویر را به آرایه‌های RGB تبدیل می‌کند و اختلاف ریشه سه‌بعدی میانگین مربع (RMS) بین دو تصویر را محاسبه می‌کند.

به‌علاوه، این آزمایش تأیید می‌کند که خروجی‌های YUV برای همه موارد استفاده از جریان پشتیبانی‌شده تا حد معقولی شبیه به YUV با حالت استفاده STILL_CAPTURE هستند.

API های آزمایش شده:

پاس: تصاویر YUV و JPEG برای مورد استفاده STILL_CAPTURE کمتر از 3٪ RMS (مقدار ریشه میانگین مربع سیگنال) تفاوت دارند. تصاویر YUV برای کلیه موارد استفاده پشتیبانی شده کمتر از 10 ٪ RMS تفاوت از تصاویر YUV با مورد استفاده STILL_CAPTURE دارند.

صحنه 2_C

test_num_faces

آزمایشات با افزایش تنوع تن پوست در صحنه های صورت ، آزمایشات صورت را تشخیص می دهد.

API آزمایش کرد:

پاس: سه چهره پیدا می کند.

test_num_faces_fd_mode_1

شکل 103. TEST_NUM_FACES مثال حالت تشخیص چهره.

test_jpeg_capture_perf_class

تست JPEG CACTURE LATENCY برای کلاس عملکرد S همانطور که در بخش 2.2.7.2 در CDD مشخص شده است.

PASS: باید دارای Camera2 JPEG Capture Latency <1000 ms برای وضوح 1080p باشد که توسط CTS Camera Performancetest در شرایط روشنایی آن (3000K) برای هر دو دوربین اصلی اندازه گیری می شود.

test_camera_launch_perf_class

آزمایشگاه راه اندازی دوربین را برای کلاس عملکرد S به عنوان بخش مشخص شده 2.2.7.2 دوربین در CDD آزمایش می کند.

PASS: باید دارای تاخیر راه اندازی Camera2 (دوربین باز برای اولین قاب پیش نمایش) <600ms باشد که توسط دوربین CTS Termancetest در شرایط روشنایی آن (3000K) برای هر دو دوربین اصلی اندازه گیری می شود.

test_default_camera_hdr

تست هایی که ضبط دوربین پیش فرض فوق العاده HDR برای کلاس 15 عملکرد است همانطور که در بخش 2.2.7.2 دوربین CDD مشخص شده است.

پاس: ضبط پیش فرض دوربین باید برای یک دستگاه کلاس 15 عملکرد فوق العاده HDR باشد.

صحنه 2_D

test_preview_num_faces

آزمایشات تشخیص چهره در پیش نمایش با افزایش تنوع تن پوست در صحنه های صورت.

API آزمایش کرد:

پاس: سه چهره با نقاط دیدنی در جعبه های محدود شده صورت پیدا می کند.

Scene2_e

test_continuous_picture

50 فریم وضوح VGA با درخواست Capture First Setting android.control.afMode = 4 (CONTINUOUS_PICTURE).

API آزمایش کرد:

گذر: سیستم 3A تا پایان یک ضبط 50 فریم تسویه می شود.

test_num_faces

آزمایشات با افزایش تنوع تن پوست در صحنه های صورت ، آزمایشات صورت را تشخیص می دهد.

API آزمایش کرد:

پاس: 3 چهره پیدا می کند.

صحنه 2_f

scene2_f دارای سه صورت با پس زمینه سفید و لباس سفید است. چهره ها دارای طیف گسترده ای از تن پوست و کنتراست زیاد با پس زمینه هستند.

Scene2_f مثال

شکل 104. Scene2_F مثال.

test_preview_num_faces

آزمایشات با افزایش تنوع تن پوست در صحنه های صورت ، آزمایشات صورت را تشخیص می دهد.

API آزمایش کرد:

پاس: سه چهره با نقاط دیدنی در جعبه های محدود شده صورت پیدا می کند.

test_num_faces_fd_mode_1

شکل 105. test_num_faces_fd_mode_1 مثال.

strenge2_g

scene2_g دارای سه چهره پروفایل با پس زمینه سفید و لباس سفید است. چهره ها دارای طیف گسترده ای از تن پوست و کنتراست زیاد با پس زمینه هستند.

Scene2_g.png

شکل 106. Sente2_g مثال.

test_preview_num_faces

آزمایشات با افزایش تنوع تن پوست در صحنه های صورت ، آزمایشات صورت را تشخیص می دهد.

API آزمایش کرد:

پاس: سه چهره با نقاط دیدنی در جعبه های محدود شده صورت پیدا می کند.

test_preview_num_faces

شکل 107. مثال test_preview_num_faces.

صحنه 3

scene3 از نمودار ISO12233 استفاده می کند و بیشتر آزمایشات از یک روش استخراج نمودار برای یافتن نمودار در صحنه استفاده می کنند. به همین دلیل ، بیشتر تصاویر ذخیره شده مرزهایی مانند تصاویر برای صحنه های 1 ، 2 یا 4 ندارند ، اما فقط نمودار هستند. نمودار باید در جهت گیری صحیح باشد تا یاب نمودار بهینه کار کند.

test_edge_enhancement

آزمایشاتی که پارامتر android.edge.mode به درستی اعمال می شود. تصاویر غیر پردازش را برای هر حالت لبه ضبط می کند و وضوح تصویر خروجی و ابرداده نتیجه ضبط را برمی گرداند. یک درخواست ضبط را با یک حالت لبه معین ، حساسیت ، زمان قرار گرفتن در معرض ، فاصله تمرکز و پارامتر سطح خروجی پردازش می کند.

عبور: حالت HQ (2) واضح تر از حالت OFF (0). حالت FAST (1) واضح تر از حالت OFF . حالت HQ واضح تر یا برابر با حالت FAST .

API آزمایش کرد:

پارامترهای دوربین تأثیرگذار:

  • EDGE_MODE

test_edge_enhancement_edge = 0

شکل 108. test_edge_enhancement Edge = 0 مثال.

TEST_EDGE_ENHANCEMENT EDGE = 1 مثال

شکل 109. test_edge_enhancement Edge = 1 (حالت سریع).

Edge test_edge_enhancement = 2 مثال

شکل 110. test_edge_enhancement Edge = 2 (حالت با کیفیت بالا).

test_flip_mirror

اگر تصویر مطابق با 7.5.2 دوربین جلوی جلوی CDD باشد ، آزمایش می کند.

تصاویر آینه ای ، تلنگر یا چرخان شده را می توان با ویژگی الماس در نزدیکی مرکز مشخص کرد.

PASS: تصویر تلنگر ، آینه یا چرخانده نمی شود.

TEST_FLIP_MIRROR PATCH PATCH مثال

شکل 111. مثال پچ صحنه TEST_FLIP_MIRROR.

test_imu_drift

آزمایش اگر واحد اندازه گیری اینرسی (IMU) در حالی که دستگاه ثابت است و یک پیش نمایش با کیفیت بالا را ضبط می کند ، به مدت 30 ثانیه از خروجی پایدار برخوردار است.

API آزمایش کرد:

پاس:

  • رانش ژیروسکوپ در زمان آزمایش کمتر از 0.01 RAD است.
  • واریانس خواندن ژیروسکوپ کمتر از 1E-7 RAD 2 /S 2 /هرتز در طول زمان است.
  • رانش بردار چرخش در زمان آزمایش کمتر از 0.01 RAD است.
  • (هنوز اجباری نشده است) رانش ژیروسکوپ کمتر از 1 درجه در ثانیه است.

test_imu_drift ژیروسکوپ رانش مثال

شکل 112. مثال Drift ژیروسکوپ TEST_IMU_DRIFT.

TEST_IMU_DRIFT VECTOR VECTOR DRIFT مثال

شکل 113. مثال وکتور چرخش TEST_IMU_DRIFT.

test_landscape_to_portrait

آزمایش اگر چشم انداز به پرتره به درستی برای سنسورهای منظره محور عمل کند.

API آزمایش کرد:

PASS: این آزمون نمودار را با چرخش مورد انتظار قرار می دهد (0 درجه در هنگام غیرفعال کردن چشم انداز به پرتره ، 90 درجه در هنگام فعال کردن).

test_landscape_to_portrait

شکل 114. test_landscape_to_portrait.

test_lens_movement_reporting

در صورت گزارش صحیح پرچم حرکت لنز ، آزمایشات انجام می شود. با 12 فریم اول در فاصله بهینه فوکوس (همانطور که توسط 3A یافت می شود) و 12 فریم آخر در حداقل فاصله فوکوس ، 24 تصویر را ضبط می کند. در اطراف قاب 12 ، لنزها حرکت می کنند و باعث کاهش وضوح می شوند. با حرکت لنز به موقعیت نهایی ، وضوح در نهایت تثبیت می شود.

پرچم حرکت لنز باید در تمام قاب هایی که در آن وضوح در وضوح در چند فریم اول با لنز ثابت در فاصله کانونی بهینه قرار دارد ، و چند فریم پایانی که لنز در حداقل فاصله کانونی ثابت است ، ادعا شود. قاب دقیقی که لنز حرکت می کند مهم نیست: آنچه مهم است این است که هنگام حرکت لنز ، پرچم حرکت ادعا می شود.

API آزمایش کرد:

پاس: پرچم حرکت لنز در قاب با تغییر وضوح 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

آزمایشات اگر روشهای پردازش مجدد برای تقویت لبه به درستی کار می کنند. یک درخواست ضبط را با یک حالت لبه پردازش مجدد پردازش می کند و حالت های مختلف را برای ضبط با حالت های لبه پردازشگر غیرفعال مقایسه می کند.

API آزمایش کرد:

پاس: وضوح برای حالتهای مختلف لبه صحیح است. HQ (حالت 2) واضح تر از OFF است (حالت 0) ، و بهبود بین حالت های مختلف مشابه است.

test_reprocess_edge_enhancement مثال طرح

شکل 115. test_reprocess_edge_enhancement مثال طرح.

صحنه 4

scene4 از یک دایره سیاه روی یک پس زمینه سفید در داخل یک مربع تشکیل شده است.

آزمایشات در Scene4 می تواند به تراز حساس باشد ، بنابراین با شروع در Android 15 ، می توانید از check_alignment.py در فهرست ابزارها استفاده کنید تا بررسی تراز DUT و نمودار را انجام دهید.

Scene4 مثال

شکل 116. صحنه 4.

test_30_60fps_preview_fov_match

آزمایشاتی که 30 فریم در ثانیه و 60 فریم در ثانیه فیلم های پیش نمایش دارای همان FOV هستند. این تست دو فیلم را ضبط می کند ، یکی با 30 فریم در ثانیه و دیگری با 60 فریم در ثانیه. یک قاب نماینده از هر ویدیو انتخاب شده و مورد تجزیه و تحلیل قرار می گیرد تا تأیید کند که تغییرات FOV در دو فیلم در مشخصات قرار دارد. آزمایشاتی که نسبت ابعاد دایره ثابت باقی می ماند ، مرکز دایره پایدار است و شعاع دایره ثابت است.

API آزمایش کرد:

پاس: تصاویر کشیده نشده ، مرکز تصاویر بیش از 3 ٪ متفاوت نیست و حداکثر نسبت ابعاد بین 30 فریم بر ثانیه و 60 فیلم تغییر می کند

مکانیسم های شکست:

  • دایره از فیلم 30 فریم در ثانیه از نظر اندازه با ویدیوی 60 فریم در ثانیه متفاوت است.
  • دایره موجود در تصویر ضبط شده توسط خط لوله پردازش تحریف شده است.
  • دایره موجود در تصویر ضبط شده به دلیل درخواست ضبط نسبت ابعاد شدید ، باعث کاهش ارتفاع یا عرض تصویر می شود.
  • دایره موجود در تصویر ضبط شده بازتاب در مرکز دارد و کاملاً پر نمی شود.

test_aspect_ratio_and_crop

آزمایش اگر تصاویر در خط لوله تصویر تحریف شده یا به طور غیر منتظره ای بریده شده اند. از یک دایره از همه قالب ها عکس می گیرد. تأیید می کند که دایره تحریف نشده است ، دایره از مرکز تصویر حرکت نمی کند ، و دایره با نسبت یا وضوح ابعاد مختلف اندازه را نادرست تغییر نمی دهد.

API آزمایش کرد:

پاس: تصاویر کشیده نشده اند ، مرکز تصاویر بیش از 3 ٪ متفاوت نیست و حداکثر FOV ممکن حفظ می شود.

مکانیسم های شکست:

  • این دوربین با دایره نمایش داده شده روی رایانه لوحی در مرکز صحنه ضبط شده تراز نشده است.
  • دایره موجود در تصویر ضبط شده توسط خط لوله پردازش تحریف شده است.
  • تصویر با وضوح پایین در خط لوله تصویر دو برابر شده است و باعث ایجاد FOV مختلف بین تصاویر با وضوح بالا و پایین می شود.
  • دایره موجود در تصویر ضبط شده به دلیل درخواست ضبط نسبت ابعاد شدید ، باعث کاهش ارتفاع یا عرض تصویر می شود.
  • دایره موجود در تصویر ضبط شده بازتاب در مرکز دارد و کاملاً پر نمی شود.

test_multi_camera_alignment

پارامترهای کالیبراسیون دوربین مربوط به موقعیت یابی دوربین را برای سیستم های چند دوربین آزمایش می کند. با استفاده از زیرگوشهای فیزیکی چند دوربین ، با یکی از دوربین های فیزیکی عکس می گیرد. مرکز دایره را پیدا می کند. مرکز دایره را به مختصات جهان برای هر دوربین می پردازد. تفاوت بین مراکز دایره دوربین ها در مختصات جهان را مقایسه می کند. مختصات جهان را به مختصات پیکسل بازگرداند و در برابر اصل به عنوان یک بررسی اعتبار مقایسه می شود. اندازه های دایره را بررسی می کند که آیا فاصله کانونی دوربین ها متفاوت است یا خیر.

API آزمایش کرد:

پاس: مراکز و اندازه های دایره همانطور که در تصاویر پیش بینی شده در مقایسه با تصاویر ضبط شده با استفاده از داده های کالیبراسیون دوربین و طول کانونی انتظار می رود.

مکانیسم های شکست:

  • LENS_INTRINSIC_CALIBRATION ، LENS_POSE_TRANSLATION و LENS_POSE_ROTATION مقادیر طراحی هستند و داده های کالیبراسیون واقعی نیستند.
  • سیستم دوربین برای تنظیم تست مناسب نیست ، به عنوان مثال ، آزمایش یک سیستم دوربین گسترده و فوق العاده گسترده با دکل تست RFOV. برای اطلاعات بیشتر ، به دوربین آن در جعبه Q1 مراجعه کنید.

test_preview_aspect_ratio_and_crop

مشابه تست test_aspect_ratio_and_crop برای ضبط هنوز ، قالب های پیش نمایش پشتیبانی شده را بررسی می کند تا تأیید کند که قاب های پیش نمایش کشیده نشده و یا به طور نامناسب خرد نمی شوند. تأیید می کند که نسبت ابعاد دایره تغییر نمی کند ، تصاویر خرد شده دایره را در مرکز قاب نگه می دارند و اندازه دایره برای یک قالب ثابت یا با وضوح مختلف (بررسی FOV) تغییر نمی کند.

API آزمایش کرد:

پاس: تصاویر کشیده نشده اند ، مرکز تصاویر بیش از 3 ٪ متفاوت نیست و حداکثر FOV ممکن حفظ می شود.

test_preview_stabilization_fov

اندازه های پیش نمایش پشتیبانی شده را بررسی می کند تا اطمینان حاصل شود که FOV به طور مناسب از آن استفاده می شود. این تست دو فیلم را ضبط می کند ، یکی با ON پیش نمایش و دیگری با OFF پیش نمایش. یک قاب نماینده از هر ویدیو انتخاب شده و برای تأیید اینکه تغییرات FOV در دو فیلم در مشخصات است ، تجزیه و تحلیل می شود.

API آزمایش کرد:

پاس: نسبت ابعاد دایره در مورد ثابت باقی مانده است ، محل مرکزی دایره پایدار است و اندازه دایره بیش از 20 ٪ تغییر نمی کند.

test_video_aspect_ratio_and_crop

فیلم هایی از یک دایره را در داخل یک مربع در تمام قالب های ویدیویی می گیرد. فریم های کلیدی را استخراج می کند و نسبت ابعاد دایره تغییر نمی کند ، تصاویر خرد شده دایره را در مرکز نگه می دارند و اندازه دایره برای یک قالب ثابت یا با وضوح مختلف (بررسی FOV) تغییر نمی کند.

API آزمایش کرد:

پاس: قاب های ویدئویی کشیده نشده اند ، مرکز قاب ها بیش از 3 ٪ تفاوت ندارند و حداکثر FOV ممکن حفظ می شود.

صحنه 5

scene5 به یک صحنه خاکستری یکنواخت روشن نیاز دارد. این کار توسط یک دیفیوزر قرار داده شده بر روی لنز دوربین انجام می شود. ما دیفیوزر زیر را توصیه می کنیم: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168 .

برای تهیه صحنه ، یک دیفیوزر را در مقابل دوربین وصل کنید و دوربین را به منبع روشنایی در حدود 2000 لوکس نشان دهید. تصاویر ضبط شده برای scene5 نیاز به نورپردازی پراکنده و بدون هیچ ویژگی مشهود دارند. موارد زیر یک تصویر نمونه است:

SCENE5 مثال

شکل 117. Scene5 مثال ضبط.

test_lens_shading_and_color_uniformity

آزمایشاتی که اصلاح سایه لنز به طور مناسب اعمال می شود ، و رنگ یک صحنه یکنواخت تک رنگ به طور مساوی توزیع می شود. این تست را روی یک قاب YUV با Auto 3A انجام می دهد. سایه لنز بر اساس کانال Y ارزیابی می شود. مقدار متوسط ​​Y را برای هر بلوک نمونه مشخص شده اندازه گیری می کند و با مقایسه با مقدار مرکز Y ، پاس یا شکست را تعیین می کند. تست یکنواختی رنگ در فضای سبز سبز و آبی-سبز ارزیابی می شود.

API آزمایش کرد:

پاس: در شعاع مشخص شده تصویر ، واریانس مقدار سبز سبز و آبی-سبز باید برای گذراندن آزمون کمتر از 20 ٪ باشد.

صحنه 6

scene6 شبکه ای از نشانگرهای Aruco منحصر به فرد قابل شناسایی است. آزمایشات در scene6 می تواند به تراز حساس باشد ، بنابراین با شروع از 15 ، می توانید از check_alignment.py در فهرست ابزارها استفاده کنید تا بررسی تراز DUT و نمودار را فعال کنید.

صحنه 6

شکل 118. Scene6 مثال.

test_in_sensor_zoom

آزمایش عملکرد بزرگنمایی دوربین در سنسور ، که تصاویر خام خرد شده را تولید می کند.

با استفاده از جریان استفاده از جریان به CROPPED_RAW ، این آزمایش دو ضبط از محدوده بزرگنمایی ، یک تصویر خام FOV و یک تصویر خام خرد شده می گیرد. این تست تصاویر را به آرایه های RGB تبدیل می کند ، تصویر خام خرد شده با اندازه کامل را به اندازه گزارش شده توسط SCALER_RAW_CROP_REGION تبدیل می کند و تفاوت RMS سه بعدی را بین دو تصویر محاسبه می کند.

API آزمایش کرد:

PASS: تفاوت RMS سه بعدی بین تصویر خام خرد شده با پایین و تصویر کامل FOV RAW کمتر از آستانه تعیین شده در آزمون است.

test_zoom

رفتار بزرگنمایی دوربین را از لنز Ultrawide به لنزهای گسترده آزمایش می کند. ضبط را از محدوده زوم می گیرد و بررسی می کند که آیا نشانگرهای Aruco با بزرگنمایی دوربین بزرگتر می شوند. این آزمایش همچنین بررسی می کند که آیا موقعیت نشانگر مرکز به طور قابل پیش بینی بر روی هر ضبط تغییر می کند. فاصله از مرکز نشانگر مرکز تا مرکز تصویر می تواند با توجه به نسبت بزرگنمایی با سرعت ثابت تغییر کند تا سوئیچ دوربین فیزیکی ، یا می تواند بعد از سوئیچ دوربین فیزیکی به صورت یکنواخت به سمت همان نشانگر تغییر کند. برنامه دوربین JetPack ( JCA ) باید قبل از آزمایش روی دستگاه نصب شود.

API آزمایش کرد:

PASS: اندازه نسبی نشانگر Aruco ضبط شده در برابر نسبت بزرگنمایی درخواست شده برای تأیید اینکه دوربین به درستی زوم شده است ، دقیق است و فاصله نشانگر تا مرکز تصویر با توجه به معیارهای بیان شده در توضیحات آزمون تغییر می کند.

test_zoom برای یافتن کانتور نشانگر آروکو که نزدیک به مرکز است

شکل 119. test_zoom برای یافتن کانتور نشانگر آروکو که نزدیک به مرکز است.

test_low_latency_zoom

رفتار بزرگنمایی دوربین را آزمایش می کند. ضبط از محدوده زوم با android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) می گیرد و بررسی می کند که آیا نشانگرهای موجود در تصاویر خروجی با نسبت های بزرگنمایی در ابرداده ضبط مطابقت دارند یا خیر. از همان جلسه ضبط دوربین برای همگرایی 3A و گرفتن ضبط استفاده می شود.

API آزمایش کرد:

پاس: اندازه نسبی نشانگر ضبط شده در برابر ابرداده نتیجه نسبت بزرگنمایی دقیق است.

test_preview_video_zoom_match

تست هایی که هنگام ضبط و بزرگنمایی ، پیش نمایش ویدیو و خروجی ویدیو را نمایش داده و همان خروجی را ضبط می کنید. اندازه نشانگر نزدیک به مرکز را با نسبت های مختلف بزرگنمایی محاسبه می کند و بررسی می کند که آیا با افزایش نسبت بزرگنمایی ، اندازه نشانگر افزایش می یابد یا خیر.

API آزمایش کرد:

پاس: اندازه نسبی نشانگر ضبط شده در برابر نسبت بزرگنمایی درخواست شده در فیلم و پیش نمایش دقیق است.

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

آزمایشاتی که نسبت بزرگنمایی هر قاب پیش نمایش با ابرداده ضبط مربوطه از لنز Ultrawide به لنزهای گسترده مطابقت دارد. این آزمایش فریم های پیش نمایش را از محدوده زوم می گیرد و نشانگر آروکو را نزدیک به مرکز می یابد. آزمون سپس بررسی می کند که آیا موقعیت نشانگر مرکز به طور قابل پیش بینی در هر ضبط تغییر می کند. فاصله از مرکز نشانگر مرکز تا مرکز تصویر می تواند با توجه به نسبت بزرگنمایی با سرعت ثابت تغییر کند تا سوئیچ دوربین فیزیکی ، یا می تواند بعد از سوئیچ دوربین فیزیکی به صورت یکنواخت به سمت همان نشانگر تغییر کند.

API آزمایش کرد:

پاس: اندازه نسبی نشانگر آروکو انتخاب شده برای نسبت بزرگنمایی گزارش شده از نتیجه ضبط مربوطه برای همه فریم های پیش نمایش دقیق است. فاصله نسبی نشانگر انتخاب شده از مرکز تصویر برای نسبت بزرگنمایی گزارش شده از نتیجه ضبط مربوطه از تمام فریم های پیش نمایش دقیق است.

تصاویر test_preview_zoom که نشانگر منتخب را نزدیک به مرکز نشان می دهد

شکل 124 تصاویر test_preview_zoom که نشانگر انتخاب شده نزدیک به مرکز را نشان می دهد

test_session_characteristics_zoom

محدوده نسبت بزرگنمایی را برای کلیه تنظیمات جلسه پشتیبانی شده ذکر شده در CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION آزمایش می کند. برای هر یک از این تنظیمات ، اگر CameraDeviceSetup#isSessionConfigurationSupported true بازگردد ، این آزمایش تأیید می کند که دامنه نسبت بزرگنمایی که در CameraDeviceSetup#getSessionCharacteristics وجود دارد ، می توان به دست آورد.

API آزمایش کرد:

پاس: هر دو نسبت حداقل و حداکثر بزرگنمایی را می توان برای هر SessionConfiguration پشتیبانی شده پشتیبانی شده ذکر شده در CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION دریافت کرد.

صحنه 7

scene7 یک قاب مستطیل شکل است که به چهار ربع مساوی تقسیم می شود که هر کدام با رنگ دیگری پر شده اند. در مرکز مستطیل یک نمودار لبه شیب دار برای بررسی وضوح قرار دارد. چهار نشانگر Aruco با چهار گوشه بیرونی مستطیل تراز شده است تا در به دست آوردن مختصات دقیق قاب مستطیل اصلی در نسبت های مختلف بزرگنمایی کمک کند.

صحنه 7

شکل 125. صحنه 7.

test_multi_camera_switch

این آزمایش تأیید می کند که در طول ضبط پیش نمایش در نسبت های مختلف بزرگنمایی ، سوئیچ بین لنزهای Ultrawide (UW) و گسترده (W) منجر به مقادیر RGB مشابه می شود.

در این آزمون از نسبت های بزرگنمایی مختلف در محدوده از پیش تعریف شده استفاده می کند تا یک ضبط پیش نمایش پویا را انجام دهد و نقطه ای را که دوربین فیزیکی در آن تغییر می کند ، شناسایی کند. این نقطه کراس اوور را از UW به لنز W نشان می دهد.

قاب های ضبط شده در و قبل از نقطه متقاطع برای قرار گرفتن در معرض خودکار (AE) ، تعادل سفید خودکار (AWB) و فوکوس خودکار (AF) تجزیه و تحلیل می شوند.

چک AE تأیید می کند که تغییر LUMA برای هر دو تصویر لنز UW و W در محدوده مورد انتظار است. بررسی AWB تأیید می کند که نسبت های سبز سبز و آبی-سبز در مقادیر آستانه برای هر دو لنز UW و W قرار دارند. بررسی AF مقدار تخمین وضوح را بر اساس میانگین بزرگی شیب بین تصاویر لنز UW و W ارزیابی می کند.

در حین اجرای این آزمایش اگر اثر Moire با نتایج تداخل دارد ، از لیست دوربین با وضوح بالاتر از لیست دوربین مصوب تبلت های خود استفاده کنید.

API آزمایش کرد:

پاس: برای گذراندن آزمون ، چک های AE و AWB باید عبور کنند. نتایج بررسی AF فقط برای اهداف ورود به سیستم استفاده می شود. موارد زیر معیارهای هر چک است:

  • بررسی AE: تغییر LUMA (مقدار Y) بین تصاویر لنز UW و W باید برای همه لکه های رنگی کمتر از 4 ٪ باشد اگر دستگاه از ae_regions و awb_regions پشتیبانی کند. اگر فقط ae_regions پشتیبانی شود ، فقط مقادیر پچ رنگ خاکستری باید معیارها را رعایت کنند.
  • بررسی AWB: تفاوت بین مقادیر سبز سبز و آبی-سبز برای تصاویر لنز UW و W باید برای لکه های رنگ خاکستری کمتر از 3 ٪ باشد و اگر دستگاه از ae_regions و awb_regions پشتیبانی کند ، باید برای سایر لکه های رنگی کمتر از 10 ٪ باشد.
  • بررسی AF: وضوح تصویر برای ضبط لنز W باید بالاتر از وضوح با ضبط UW باشد.

test_multi_camera_switch_gray_uw_y

شکل 126. وصله خاکستری گرفته شده با لنز UW.

test_multi_camera_switch_gray_w_y

شکل 127. وصله خاکستری گرفته شده با لنز W.

scene8

scene8 یک قاب مستطیل شکل است که به چهار منطقه مساوی تقسیم می شود ، هر کدام حاوی یک پرتره با قرار گرفتن در معرض متفاوت یا پوششی با سایه رنگی متفاوت (سایه آبی ، افزایش قرار گرفتن در معرض ، کاهش قرار گرفتن در معرض ، سایه زرد). چهار نشانگر Aruco با چهار گوشه بیرونی مستطیل تراز شده است تا مختصات دقیق قاب مستطیل اصلی بدست آید.

Scene8 مثال

شکل 128. Sente8 مثال.

test_ae_awb_regions

آزمایشاتی که مقادیر RGB و LUMA هنگام ضبط پیش نمایش در مناطق مختلف AE و AWB متفاوت است.

این تست یک ضبط پیش نمایش 8 ثانیه ای را ضبط می کند ، و اندازه گیری AE و AWB را در هر ربع به مدت 2 ثانیه انجام می دهد. سپس این آزمایش یک قاب را از ضبط پیش نمایش هر منطقه استخراج می کند و از قاب های استخراج شده برای انجام چک های زیر AE و AWB استفاده می کند:

  • Check AE: تأیید می کند که اندازه گیری قاب منطقه با کاهش قرار گرفتن در معرض ، مقدار لوما را بیش از 1 ٪ افزایش می دهد تا قاب که منطقه را با افزایش قرار گرفتن در معرض اندازه گیری می کند. این تأیید می کند که تصاویر هنگام اندازه گیری یک منطقه تاریک روشن می شوند.
  • بررسی AWB: تأیید می کند که نسبت قرمز به آبی (از میانگین مقادیر RGB تصویر) در قاب با منطقه اندازه گیری آبی بیش از 2 ٪ بیشتر از قاب با ناحیه اندازه گیری زرد است. این تأیید می کند که تصاویر هنگام اندازه گیری یک منطقه زرد (گرم) یا آبی (خنک) دارای مقدار RGB متعادل هستند.

API آزمایش کرد:

PASS: AE و AWB هر دو پاس را بررسی می کنند.

test_ae_awb_regions_dark_region

شکل 129. اندازه گیری قاب منطقه تاریک با افزایش قرار گرفتن در معرض.

test_ae_awb_regions_light_region

شکل 130. منطقه سبک تر اندازه گیری قاب با کاهش قرار گرفتن در معرض.

مکانیسم های شکست:

  • تشخیص دقیق هر چهار نشانگر آروکو برای این آزمایش ضروری است. اگر تشخیص اولیه از بین برود ، سیستم با استفاده از نسخه سیاه و سفید تصویر ، سعی می کند تشخیص دوم را انجام دهد. تصویر مقیاس خاکستری زیر مرحله پردازش ثانویه را نشان می دهد:

    نشانگرهای آروکو نادرست

    شکل 131. نشانگرهای آروکو.

test_color_correction_mode_cct

تست های COLOR_CORRECTION_MODE در دمای مختلف رنگ و رنگ ها ، تأیید تغییرات در نسبت RGB در برابر صحنه ضبط ، Scene8 .

API آزمایش کرد:

PASS: نسبت RGB نسبت به دمای رنگ انتخاب شده و رنگ های انتخاب شده ، افزایش یا کاهش پیش بینی شده را نشان می دهد.

معیارهای پرش تست

در صورت رعایت هر یک از معیارهای زیر ، تست test_color_correction_mode_cct از بین می رود:

صحنه 9

scene9 از هزاران محافل به اندازه تصادفی و رنگی تشکیل شده است تا صحنه ای با تکرارپذیری بسیار کم برای استرس الگوریتم های فشرده سازی JPEG ایجاد شود.

SCENE9 مثال

شکل 132. Sente9 مثال.

test_jpeg_high_entropy

تست هایی که فشرده سازی دوربین JPEG در scene9 با آنتروپی بالا و فاکتور کیفیت JPEG به 100 ٪ کار می کند. فاکتور بزرگنمایی برای تأیید اینکه صحنه نمایش داده شده در رایانه لوحی FOV دوربین را پر می کند ، افزایش می یابد.

API آزمایش کرد:

پاس: پرونده JPEG به درستی فشرده می شود ، نوشته شده و از دیسک خوانده می شود.

test_jpeg_quality

کیفیت فشرده سازی دوربین JPEG را آزمایش می کند. ویژگی های مرحله JPEG از طریق android.jpeg.quality و تأیید می کند که جداول کمیت به درستی تغییر می کند.

API آزمایش کرد:

پاس: ماتریس کمیت با افزایش کیفیت کاهش می یابد. (ماتریس عامل تقسیم را نشان می دهد.)

Pixel 4 دوربین عقب لوما و ماتریس Chroma DQT در مقابل کیفیت JPEG

شکل 133. Pixel 4 دوربین عقب لوما و ماتریس Chroma DQT در مقابل کیفیت JPEG.

test_jpeg_quality مثال آزمایش ناموفق

شکل 134 مثال آزمایش ناموفق.

Scene_video

scene_video یک صحنه ویدیویی است که از چهار دایره رنگی مختلف تشکیل شده است و با نرخ قاب های مختلف در برابر یک پس زمینه سفید به جلو و عقب حرکت می کند.

شکل 135. مثال Scene_Video.

test_preview_frame_drop

آزمایشاتی که نرخ فریم پیش نمایش درخواست شده با صحنه پویا حفظ می شود. این آزمایش بر روی تمام دوربین هایی که در معرض برنامه های شخص ثالث قرار دارند اجرا می شود.

API آزمایش کرد:

پاس: نرخ فریم پیش نمایش در حداکثر محدوده نرخ فریم درخواست شده است و میانگین تغییر بین قاب های متوالی کمتر از تحمل نسبی است که در آزمون تعیین شده است.

endextensions

تست های scene_extensions برای پسوندهای دوربین است و باید از دوربین آن در یک جعبه استفاده کند ، زیرا به کنترل دقیق محیط آزمایش نیاز دارند. علاوه بر این ، تمام نشت نور باید کنترل شود. این ممکن است نیاز به پوشش دکل آزمایشی ، DUT و قرص با پارچه قطره ای و همچنین از بین بردن نشت نور از صفحه جلوی DUT داشته باشد.

strenge_hdr

صحنه scene_hdr از یک پرتره در سمت چپ و کد QR کم کنتراست در سمت راست تشکیل شده است.

strenge_hdr

شکل 136. Scene_HDR مثال.

test_hdr_extension

پسوند HDR را آزمایش می کند. ضبط ها را با و بدون فعال شدن پسوند انجام می دهد ، و بررسی می کند که آیا پسوند باعث می شود کد QR قابل تشخیص تر باشد.

API آزمایش کرد:

پاس: پسوند HDR تعداد تغییرات کنتراست مورد نیاز برای تشخیص کد QR را کاهش می دهد یا شیب را در کد QR کاهش می دهد.

Scene_low_light

صحنه scene_low_light از شبکه ای از مربع های مختلف سایه های خاکستری در برابر پس زمینه سیاه تشکیل شده است و شبکه مربع ها با یک طرح قرمز محدود می شوند. مربع ها در جهت گیری منحنی هیلبرت مرتب شده اند.

مثال scene_low_light

شکل 137. Sende_Low_light مثال.

test_night_extension

آزمایش شبانه . ضبط را با برنامه افزودنی فعال می کند و موارد زیر را انجام می دهد:

  • حضور 20 مربع را تشخیص می دهد
  • لوما محدود شده توسط هر مربع را محاسبه می کند
  • مقدار لوما متوسط ​​6 مربع اول را با توجه به جهت گیری شبکه منحنی هیلبرت محاسبه می کند
  • تفاوت در مقدار LUMA مربع های متوالی (به عنوان مثال ، Square2 - Square) تا مربع های 5 و 6 (Square6 - Square5) را محاسبه می کند و میانگین پنج تفاوت محاسبه شده را می یابد.

برای دستگاه هایی که Android 16 یا بالاتر را اجرا می کنند ، درخواست ضبط شامل یک منطقه اندازه گیری شده مربوط به مستطیل است که شبکه مربع ها را محدود می کند. این افزودنی معیارهای عبور آستانه را تغییر می دهد.

API آزمایش کرد:

پاس:

  • برای دستگاه هایی که Android 16 یا بالاتر را اجرا می کنند ، میانگین مقدار LUMA 6 مربع اول باید حداقل 80 باشد و میانگین تفاوت در مقدار LUMA مربع های متوالی تا مربع های 5 و 6 باید حداقل 18.75 باشد.
  • برای دستگاه هایی که Android 15 و پایین تر دارند ، میانگین مقدار LUMA 6 مربع اول باید حداقل 85 باشد و میانگین تفاوت در مقدار LUMA مربع های متوالی تا مربع های 5 و 6 باید حداقل 17 باشد.

طرح درخشش زیر نشان می دهد که نتیجه تست عبور چگونه به نظر می رسد.

نمونه تست صحنه شب کم نور

شکل 138. نمونه تست صحنه شب کم نور.

test_low_light_boost_extension

حالت AE Low Light Boost را آزمایش می کند. اگر Camera2 از حالت AE Low Light Boost پشتیبانی می کند ، این تست برای Camera2 انجام می شود. اگر پسوند دوربین حالت شب پشتیبانی شود و پسوند از حالت کم نور AE پشتیبانی کند ، این تست نیز برای پسوند دوربین حالت شب انجام می شود. این تست حالت AE را به سمت کم نور تنظیم می کند ، یک قاب از پیش نمایش می گیرد و موارد زیر را انجام می دهد:

  • حضور 20 جعبه را تشخیص می دهد
  • لوما محدود شده توسط هر جعبه را محاسبه می کند
  • مقدار لوما متوسط ​​6 مربع اول را با توجه به جهت گیری شبکه منحنی هیلبرت محاسبه می کند
  • تفاوت در مقدار LUMA مربع های متوالی (به عنوان مثال ، Square2 - Square) تا مربع های 5 و 6 (Square6 - Square5) را محاسبه می کند و میانگین پنج تفاوت محاسبه شده را می یابد.

برای دستگاه هایی که Android 16 یا بالاتر را اجرا می کنند ، درخواست ضبط شامل یک منطقه اندازه گیری شده مربوط به مستطیل است که شبکه مربع ها را محدود می کند. این افزودنی معیارهای عبور آستانه را تغییر می دهد.

API آزمایش کرد:

پاس:

  • برای دستگاه هایی که Android 16 یا بالاتر را اجرا می کنند ، میانگین مقدار LUMA 6 مربع اول باید حداقل 54 باشد و میانگین تفاوت در مقدار LUMA مربع های متوالی تا مربع های 5 و 6 باید حداقل 17 باشد.

  • برای دستگاه هایی که Android 15 و پایین تر دارند ، میانگین مقدار LUMA 6 مربع اول باید حداقل 70 باشد و میانگین تفاوت در مقدار LUMA مربع های متوالی تا مربع های 5 و 6 باید حداقل 18 باشد.

صحنه_

یک نیاز اصلی برای تست های scene_tele این است که فاصله نمودار باید حداقل حداقل فاصله فوکوس لنز تله فوتو باشد. از آنجا که این حداقل فاصله فوکوس می تواند بین دستگاه ها متفاوت باشد ، شما باید تنظیمات خود را متناسب با دوربین تله فوتو خاص پیکربندی کنید.

Sende_tele Setup بر اساس فاصله تمرکز دوربین گسترده و Tele

شکل 139. Scene_Tele Setup بر اساس فاصله تمرکز دوربین گسترده و Tele.

برای کسب اطلاعات بیشتر در مورد تنظیمات سخت افزار تست ، به تنظیم تنظیم Tele Extension Rig مراجعه کنید.

صحنه 6_tele

صحنه scene6_tele از شبکه ای از نشانگرهای آروکو در پس زمینه سفید تشکیل شده است.

اگر ضبط های scene6_tele در دکل مدولار به نظر می رسد ، صفحه جلوی دکل مدولار را بردارید.

دکل تست WFOV را از پسوند جدا کرده و سوار تلفن را بردارید.

دکل تست WFOV را از پسوند جدا کرده و نصب تلفن را بردارید

شکل 140. دکل تست WFOV را از پسوند جدا کرده و نصب تلفن را بردارید.

remove_front_plate

شکل 141 صفحه جلوی را بردارید.

test_zoom_tele

رفتار بزرگنمایی دوربین را از لنزهای وسیع به لنز تله فوتو آزمایش می کند. این آزمایش با test_zoom یکسان است ، اما رفتار بزرگنمایی دوربین را از لنزهای گسترده به لنز تله تست می کند.

API آزمایش کرد:

پاس: اندازه نسبی نشانگر Aruco ضبط شده در برابر نسبت بزرگنمایی درخواست شده برای تأیید اینکه دوربین به درستی زوم شده است ، دقیق است و فاصله نشانگر تا مرکز تصویر با توجه به معیارهای ذکر شده در test_zoom تغییر می کند.

test_preview_zoom_tele

رفتار بزرگنمایی دوربین را برای فریم های پیش نمایش از لنزهای گسترده به لنز تله فوتو آزمایش می کند. این آزمایش با test_preview_zoom یکسان است ، اما رفتار بزرگنمایی دوربین را برای فریم های پیش نمایش از لنزهای گسترده به لنزهای تله فوتو آزمایش می کند.

API آزمایش کرد:

پاس: اندازه نسبی نشانگر Aruco ضبط شده در برابر نسبت بزرگنمایی درخواست شده برای تأیید اینکه دوربین به درستی زوم شده است ، دقیق است و فاصله نشانگر تا مرکز تصویر با توجه به معیارهای ذکر شده در TEST_PREVIEW_ZOOM تغییر می کند.

Scene7_tele

scene7_tele با scene7 یکسان است ، اما برای آزمایش لنزهای تله فوتو تنظیم شده است. این یک قاب مستطیل شکل است که به چهار ربع مساوی تقسیم می شود که هر کدام با رنگ دیگری پر شده اند. در مرکز مستطیل یک نمودار لبه شیب دار برای بررسی وضوح قرار دارد. چهار نشانگر Aruco با چهار گوشه بیرونی مستطیل تراز شده است تا در به دست آوردن مختصات دقیق قاب مستطیل اصلی در نسبت های مختلف بزرگنمایی کمک کند.

test_multi_camera_switch_tele

This test verifies that during preview recording at varying zoom ratios, the switch between the wide (W) and telephoto (tele) lenses results in similar RGB values.

The test uses different zoom ratios within the predefined range to perform a dynamic preview recording and identify the point at which the physical camera changes. This point marks the crossover from the W to the tele lens.

The frames captured at and before the crossover point are analyzed for AE, AWB, and AF.

The AE check verifies that the luma change is within the expected range for both W and tele lens images. The AWB check verifies that the ratios of red-green and blue-green are within threshold values for both W and tele lens images. The AF check evaluates the sharpness estimation value based on the average gradient magnitude between W and tele lens images.

APIs tested:

Pass: For the test to pass, the AE, AWB, and AF checks must all pass. The following are the criteria for each check:

  • AE check: The luma change between the W and tele lens images must be less than 4%.
  • AWB check: In the LAB color space, the delta C between red-green and blue-green for wide and telephoto cannot exceed 10.
  • AF check: The image sharpness of the tele lens must be higher than the W lens.

scene_flash

The scene_flash tests require a dark scene in the sensor fusion box.

test_auto_flash

Tests that auto-flash is triggered in a dark scene for rear-facing and front-facing cameras. For front-facing cameras, auto-flash uses the screen to illuminate the scene, not a physical flash unit. The test verifies that auto-flash is fired by checking that the center of the tile image is brighter with auto-flash enabled. To trigger auto-flash, the lights in the test rig must be turned off. The lights can be turned off automatically with the Arduino controller. The scene must be completely dark for the test to work correctly. The Jetpack Camera App ( JCA ) must be installed on the device before testing. Auto-flash for rear-facing cameras relies on the AE state to be triggered, but auto-flash for front-facing cameras doesn't rely on AE and is always triggered.

APIs tested:

Pass: The center of the tile image with auto-flash enabled is brighter than the original scene image for all cameras.

test_flash_strength

Tests that flash strength control in SINGLE mode is implemented correctly.

Verifies that if the device supports flash strength control during camera use in SINGLE mode, the flash strength changes with different requested strength levels. Verifies that flash strength control works with different AE_MODES . For example, if the auto-exposure mode is ON or OFF , the flash strength level has an effect on brightness, and if the mode is ON_AUTO_FLASH , the flash strength level has no effect on brightness.

To conduct the test, lights in the test rig must be turned off. The lights can be turned off automatically with the Arduino controller. The scene must be completely dark for the test to work correctly.

APIs tested:

پاس:

When the auto-exposure mode is ON or OFF , the brightness of the image patches increases as the flash strength level increases from no flash to FLASH_SINGLE_STRENGTH_MAX_LEVEL . When the auto-exposure mode is ON_AUTO_FLASH , the difference in brightness of the image patches is within tolerance as the flash strength level increases from no flash to FLASH_SINGLE_STRENGTH_MAX_LEVEL .

test_led_snapshot

Tests that the LED snapshots don't saturate or tint the image.

This test adds a lighting controller to the Sensor Fusion Box to control the lights. With the lights set to OFF , the test takes a capture with the AUTO_FLASH mode set to ON . During this capture, the test runs a precapture sequence with the aePrecapture trigger set to START , and sets the capture intent to Preview to take the capture with flash.

Because the capture has a distinctive hotspot due to flash, the test computes the flash image mean of the entire capture and verifies whether the value is within the (68, 102) range. To check if the image is reasonably white balanced, the test calculates the red-green and blue-green ratios and verifies whether the ratios are within 0.95 and 1.05.

APIs tested:

Pass: The red-green and blue-green ratios are within 0.95 and 1.05. The flash image mean is within the (68, 102) range.

test_night_mode_indicator

Tests the functionality of the night mode indicator, a feature that indicates whether the camera is operating in low light conditions and will benefit from a Night Mode Camera extension still capture. This feature is available only on devices that support Night Mode Camera extensions.

This test checks that the night mode indicator correctly reflects the lighting conditions during camera preview. The test performs the following steps:

  1. Initialization: The test initializes an ItsSession and retrieves camera properties. It also establishes a connection with the lighting controller.
  2. Skip Conditions: The test is skipped if the device doesn't support the required API level or the night mode indicator feature.
  3. Camera2 Session:
    • The test starts a preview capture session using a Camera2 session.
    • The light is turned on and a preview frame is captured.
    • The test verifies that the night mode indicator is in the OFF state.
    • The light is turned off and a preview frame is captured.
    • The test verifies that the night mode indicator is in the ON state.
  4. Camera extension session:
    • The test repeats the same procedure as for the Camera2 session, but using a CameraExtension session with the EXTENSION_NIGHT extension.
  5. Cleanup: The test closes ItsSession and releases the lighting controller.

APIs tested:

پاس:

  • When the light is on, the night mode indicator should be in the OFF state.
  • When the light is off, the night mode indicator should be in the ON state.
  • Applies to both Camera2 and CameraExtension sessions.

test_preview_min_frame_rate

Tests that the preview frame rate decreases correctly in a dark scene. For this test to work correctly, the lights in the test rig must be turned off by the controller or manually by the test operator.

APIs tested:

Pass: The preview frame rate is at the minimum of the requested frame rate range, and the variation between frames is less than the absolute tolerance set in the test.

test_torch_strength

Tests that flash strength control in TORCH mode is implemented correctly.

Verifies that if the device supports flash strength control during camera use in TORCH mode, the torch strength changes with different requested strength levels. Verifies that flash strength control works with different AE_MODES . For example, if the auto-exposure mode is ON or OFF , the flash strength level has an effect on brightness, and if the mode is ON_AUTO_FLASH , the flash strength level has no effect on brightness. Verifies that the torch strength stays the same throughout the duration of a burst, simulating a video capture session. To conduct the test, lights in the test rig must be turned off. The lights can be turned off automatically with the Arduino controller. The scene must be completely dark for the test to work correctly.

APIs tested:

پاس:

When the auto-exposure mode is ON or OFF , the brightness of the image burst patches increases as the flash strength level increases from no flash to FLASH_TORCH_STRENGTH_MAX_LEVEL . When the auto-exposure mode is ON_AUTO_FLASH , the difference in brightness of the image burst patches are within tolerance as the flash strength level increases from no flash to FLASH_TORCH_STRENGTH_MAX_LEVEL .

sensor_fusion

Sensor fusion tests require specific phone movement in front of a checkerboard pattern and ArUco markers. For optimum results, verify that the test chart is mounted flat. Charts that aren't flat affect the rotation calculations for many of the tests. The chart must fill the back of the sensor fusion box by printing at 17x17 in. (43x43 cm). The sensor_fusion tests can be automated with the Sensor Fusion Box .

Sensor fusion chart

Figure 142. Sensor fusion chart.

Sensor fusion chart in Rig

Figure 143. Sensor fusion chart that fills the back of the sensor fusion box.

test_lens_intrinsic_calibration

Tests that the optical center of the lens intrinsic changes when the lens moves due to optical image stabilization (OIS). If lens intrinsic samples are supported, tests that the optical center of the lens intrinsic samples changes when the lens moves due to OIS.

APIs tested:

Pass: The optical center of the lens intrinsic changes by 1 pixel or more. If lens intrinsic samples are supported, the optical centers of the lens intrinsic samples change by 1 pixel or more.

The following figure is an example test_lens_intrinsic_calibration plot showing changes of principal points in pixels for each frame:

test_lens_intrinsic_calibration_example.png

Figure 144. Example of test_lens_intrinsic_calibration plot showing changes of principal points in pixels for each frame.

test_multi_camera_frame_sync

Tests that frame timestamps captured by logical camera are within 10 ms by computing angles of squares within the checkerboard to determine the timestamp.

APIs tested:

Pass: The angle between images from each camera doesn't change appreciably as the phone is rotated.

test_preview_distortion

Tests that distortion is corrected throughout each preview frame taken at various zoom levels. For each preview frame, the test calculates ideal points based on camera intrinsics and extrinsics.

In the example image, ideal points are shown in green; actual points are shown in red. The distortion error is calculated based on the RMS pixel distance between the actual points and ideal points. The green and red highlights on the image are used to visually detect the area of distortion error.

test_preview_distortion_example.jpg

Figure 145. Image of checkerboard with ideal points as green and actual points as red.

APIs tested:

Pass: The normalized distortion error of each preview frame is less than the threshold set in the test.

test_preview_stabilization

Tests that stabilized preview video rotates less than gyroscope.

APIs tested:

Pass: Maximum angle rotation over frames is less than 70% of gyroscope rotation.

The following are sample videos with and without stabilization:

Figure 146. Sample video with stabilization.

Figure 147. Sample video without stabilization.

test_sensor_fusion

Tests the timestamp difference between the camera and the gyroscope for AR and VR applications. The phone is rotated 90 degrees 10 times in front of the checkerboard pattern. Motion is about 2 s round trip. This test is skipped if no gyroscope is included or if the timestamp source REALTIME parameter isn't enabled.

The test_sensor_fusion test generates a number of plots. The two most important plots for debugging are:

  • test_sensor_fusion_gyro_events : Shows the gyroscope events for the phone during the test. Movement in the x and y direction implies the phone isn't securely mounted on the mounting plate, reducing the probability of the test passing. The number of cycles in the plot depends on the write speed for saving frames.

    test_sensor_fusion gyroscope events example

    Figure 148. test_sensor_fusion gyroscope events example.

  • test_sensor_fusion_plot_rotations : Shows the alignment of the gyroscope and camera events. This plot must show matching movement between camera and gyroscope to +/-1 ms.

    test_sensor_fusion plot rotations example

    Figure 149. test_sensor_fusion plot rotations example.

APIs tested:

Pass: Camera and gyroscope timestamps' offset is less than 1 ms as per 7.3.9 High Fidelity Sensors in the CDD.

Fail mechanisms:

  • Offset error: The camera-gyroscope offset isn't correctly calibrated to within +/-1 ms.
  • Frame drops: The pipeline isn't fast enough to capture 200 frames consecutively.
  • Socket errors: adb can't reliably connect to the DUT long enough to execute the test.
  • The chart isn't mounted flat. The plot test_sensor_fusion_plot_rotations has frames where the gyroscope and camera rotation vary considerably as the camera rotates through the parts of the chart that aren't flat.
  • The camera isn't mounted flat. The plot test_sensor_fusion_gyro_events shows movement in the X and Y planes. This failure is more common in front-facing cameras as the rear camera often has a raised bump to the rest of the phone body, creating a tilt when mounting the rear of the phone to the mounting plate.

test_video_stabilization

Tests that stabilized video rotates less than gyroscope.

APIs tested:

Pass: Maximum angle rotation over frames is less than 60% of gyroscope rotation.

The following are sample videos with and without stabilization.

Figure 150. Sample video with stabilization.

Figure 151. Sample video without stabilization.

test_video_stabilization_jca

Tests that stabilized video captured using the JCA rotates less than the gyroscope. The JCA must be installed on the device before testing.

APIs tested:

Pass: The maximum angle rotation over frames extracted from video captured using the JCA is less than 70% of gyroscope rotation.

feature_combination

The feature_combination tests verify that features work correctly when multiple camera features are enabled at the same time. These tests use the same checkerboard image that is used in the sensor fusion scene .

test_feature_combination

Tests all combinations of different stream combinations, video stabilization mode, target FPS range, 10-bit HDR video, and Ultra HDR that are supported by the camera device.

For Android 16 and higher, the test runs all combinations of supported features, and logs the results into a proto file. Failure assertions are called only for combinations of features for which isSessionConfigurationSupported returns True .

APIs tested:

Pass: For each supported feature combination:

  • The preview stream is stabilized if preview stabilization is on.
  • The preview frame rate falls within the configured AE_TARGET_FPS_RANGE .
  • The recorded preview stream's color space matches what's set.
  • The Ultra HDR capture has a valid gain map.

scene_ip

In Android 16 and higher, scene scene_ip enables image parity checks between the default camera app and the Jetpack camera app (JCA) to identify major differences between captured images. The JCA replicates social media app captures and provides a baseline image that that social media apps then process and refine.

Hardware setup requirements

The following hardware setup is required for scene_ip tests:

  • Tests are executed in the Gen2 camera ITS-in-a-box .
  • The lighting and servo controllers that are part of the Gen2 rig are used to control the test environment
  • A test feature chart is placed inside the Gen2 rig.

test_chart_gen2

Figure 152. Gen2chart_sample example.

Test skip criteria

The scene_ip tests are skipped if any of the following criteria are met:

  • The device has a first API level ( first_api_level ) of 35 or lower.
  • The device isn't a phone device with front and rear primary camera devices (for example, a tablet or TV).

test_default_jca_ip

Takes captures of the test feature chart under controlled lighting conditions using the default camera app and the JCA and performs the following checks:

  • FoV: Checks that the default camera app and JCA captures have the same FoV. This check uses the center QR Code feature extracted from the captures chart image.

  • Brightness: Checks that the brightness difference measured between the default camera app and JCA doesn't exceed 10. This check uses the dynamic range patch for brightness measurement.

  • White balance: Checks that the white balance difference between the default camera app and JCA doesn't exceed 4. This check uses the dynamic range patch for brightness measurement.

Basic section pass: Test passes the FoV, brightness, and white balance checks. In Android 16, this test isn't mandated ( NOT_YET_MANDATED ).