ИТС тесты камеры

На этой странице представлен полный список тестов Camera Image Test Suite (ITS), который является частью Android Compatibility Test Suite (CTS) Verifier. Тесты ITS являются функциональными тестами, то есть они не измеряют качество изображения, а все заявленные функции камеры работают так, как и ожидалось. Этот документ позволяет разработчикам и тестировщикам понять, что делают отдельные тесты и как устранять сбои в тестах.

ITS камеры пропускает тесты по требуемым свойствам камеры, уровню 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

Тесты не требуют конкретной информации о сцене. Однако для гироскопа и вибрационного тестирования телефон должен быть неподвижен.

тест_джиттер

Измеряет дрожание временных меток камеры.

Протестированные API:

Пройдено: разница между кадрами составляет не менее 30 мс.

На следующем рисунке обратите внимание на небольшой диапазон оси Y. На этом графике джиттер на самом деле небольшой.

график test_jitter

Рисунок 1. График test_jitter.

тестовые_метаданные

Проверяет валидность записей метаданных, просматривая результаты захвата и объекты характеристик камеры. Этот тест использует значения экспозиции и усиления auto_capture_request , поскольку содержимое изображения не важно.

Протестированные API:

Пройдено: уровень оборудования, rollingShutterSkew , теги frameDuration , timestampSource , croppingType , blackLevelPattern , pixel_pitch , поле зрения (FoV) и гиперфокальное расстояние присутствуют и имеют допустимые значения.

test_request_capture_match

Проверяет, что устройство записывает правильные значения экспозиции и усиления, считывая метаданные захвата.

Протестированные API:

Пройдено: значения метаданных запроса и захвата совпадают для всех снимков.

тестовые_события_датчика

Для устройств, которые заявляют о поддержке слияния датчиков, этот тест проверяет, запрашивает ли устройство и выводит ли оно события датчиков. Ожидаемые датчики — акселерометр, гироскоп и магнитометр. Этот тест работает только при включенном экране, то есть устройство не находится в режиме ожидания.

Протестированные API:

Пройдено: получены события для каждого датчика.

тестовый_сплошной_цвет_тестовый_шаблон

Тесты, что тестовые шаблоны сплошного цвета генерируются правильно для отключения камеры. Если отключение камеры поддерживается, тестовые шаблоны сплошного цвета должны поддерживаться. Если отключение камеры не поддерживается, тестовые шаблоны сплошного цвета проверяются только в том случае, если эта возможность объявлена.

Если поддерживаются необработанные изображения, также проверяется назначение цвета. Проверяются следующие цвета: черный, белый, красный, синий и зеленый. Для камер, которые не поддерживают необработанные изображения, проверяется только черный.

Протестированные API:

Пройдено: Поддерживаемые сплошные тестовые шаблоны имеют правильный цвет, а дисперсия в изображении низкая.

тестовый_тестовый_шаблон

Тестирует параметр android.sensor.testPatternMode для захвата кадров для каждого допустимого тестового шаблона и проверяет, что кадры генерируются правильно для сплошных цветов и цветных полос. Этот тест включает следующие шаги:

  1. Захватывает изображения для всех поддерживаемых тестовых шаблонов.
  2. Выполняет проверку правильности тестового шаблона сплошного цвета и цветных полос.

Протестированные API:

Пройдено: Поддерживаемые тестовые шаблоны генерируются правильно.

пример test_test_patterns

Рисунок 2. Пример test_test_patterns.

test_tonemap_curve

Тестирует преобразование тестового шаблона из raw в 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:

Пройдено: временные метки движения находятся между двумя временными метками изображения.

ограничение_вибрации_теста

Проверяет, функционирует ли вибрация устройства должным образом.

Протестированные API:

Пройдено: устройство не вибрирует при отключении звука с помощью API ограничения звука камеры.

сцена1_1

scene1 — это серая карта. Серая карта должна покрывать центральные 30% поля зрения камеры. Ожидается, что серая карта будет умеренно бросать вызов 3A (AE, AWB и AF), поскольку центральная область не имеет особенностей. Однако запрос на захват указывает всю сцену, которая включает достаточно особенностей для сходимости 3A.

Камеры RFoV можно тестировать в WFoV или испытательном стенде RFoV. Если камера RFoV тестируется в испытательном стенде WFoV, диаграмма масштабируется на 2/3, чтобы указать некоторые границы для серой диаграммы в FoV, чтобы помочь 3A сблизиться. Более подробное описание испытательных стендов камер см. в разделе Camera ITS-in-a-box .

пример сцены1

Рисунок 5. Полноразмерная диаграмма сцены1 (слева), диаграмма в масштабе 2/3 (справа).

test_ae_precapture_trigger

Тестирует конечный автомат AE при использовании триггера предварительного захвата. Захватывает пять ручных запросов с отключенным AE. Последний запрос имеет триггер предварительного захвата AE, который следует игнорировать, поскольку AE отключен.

Протестированные API:

Пройдено: AE сходится.

тест_авто_против_ручного

Тесты, в которых были сделаны снимки в автоматическом и ручном режимах, выглядят одинаково.

Протестированные API:

Пройдено: ручное усиление баланса белого и преобразование, указанные в каждом результате съемки, соответствуют estimate автоматического баланса белого, выполненной с помощью алгоритма 3A камеры.

пример test_auto_vs_manual auto

Рисунок 6. Пример test_auto_vs_manual auto.

пример баланса белого test_auto_vs_manual

Рисунок 7. Пример баланса белого test_auto_vs_manual.

test_auto_vs_manual пример ручного преобразования баланса белого

Рисунок 8. Пример ручного преобразования баланса белого test_auto_vs_manual.

тест_черный_белый

Тестирует, что устройство производит полностью черно-белые изображения. Делает два снимка, первый с крайне низким усилением и короткой выдержкой, что приводит к черному фото, а второй с крайне высоким усилением и длинной выдержкой, что приводит к белому фото.

Протестированные API:

Пройдено: создает черно-белые изображения. Насыщенные каналы белых изображений имеют значения 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

Проверяет, что весь конвейер захвата может справиться со скоростью полноразмерного захвата и временем ЦП.

Протестированные API:

Пройдено: делает серию полноразмерных снимков, проверяет наличие пропусков кадров и яркость изображения.

test_burst_sameness_manual

Делает 5 серий из 50 изображений с ручной настройкой захвата и проверяет, что все они идентичны. Используйте этот тест, чтобы определить, есть ли спорадические кадры, которые обрабатываются по-разному или имеют артефакты.

Протестированные API:

Пройдено: Изображения идентичны визуально и по значениям 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 не подлежат кадрированию.

Протестированные API:

Пройдено: изображения YUV обрезаются по центру, но не изображения RAW.

test_crop_region_raw comp пример необработанного урожая

Рисунок 14. Пример необработанной обрезки test_crop_region_raw comp.

test_crop_region_raw comp raw полный пример

Рисунок 15. Пример полного исходного кода test_crop_region_raw comp.

test_crop_region_raw comp пример кадрирования YUV

Рисунок 16. Пример кадрирования YUV-изображения test_crop_region_raw comp.

пример test_crop_region_raw_yuv_full

Рисунок 17. Полный пример test_crop_region_raw YUV.

тестовые_регионы_урожая

Тесты, которые показывают, что области обрезки работают. Берет полное изображение и создает участки пяти различных областей (углы и центр). Берет изображения с установленным кадрированием для пяти областей. Сравнивает значения участка и изображения обрезки.

Протестированные API:

Пройдено: Изображение обрезанной области совпадает с участком, соответствующим обрезанному изображению.

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 (что сделало бы их похожими на плоские линии). Тест также можно запустить с изображениями RAW, установив флаг debug в файле конфигурации.

Протестированные API:

Пройдено: изображения имеют одинаковую яркость, но становятся шумнее при более высоком значении ISO. Плоскости RGB плоские, когда значение ISO*экспозиция постоянно в пределах тестируемого пространства усиления.

Механизм отказа: на следующем рисунке по мере увеличения значений множителя усиления (ось 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 график означает пример

Рисунок 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 lock и YUV burst (с использованием автоматической настройки). Этот тест разработан для прохождения даже на ограниченных устройствах, которые не имеют 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 unity.

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:

Пройдено: в центре изображения плитки имеется большой градиент, что означает, что сработала вспышка.

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_шум_снижения

Проверяет, что параметр android.noiseReduction.mode применяется правильно, если установлен. Захватывает изображения при тусклом освещении камеры. Использует высокое аналоговое усиление, чтобы гарантировать, что захваченное изображение будет шумным. Захватывает три изображения: для NR off, быстро и высокого качества. Также захватывает изображение с низким усилением и NR off и использует его дисперсию в качестве базовой линии. Чем выше отношение сигнал/шум (SNR), тем лучше качество изображения.

Протестированные API:

Пройдено: SNR меняется в зависимости от режима шумоподавления и ведет себя аналогично следующему графику:

test_param_noise_reduction plot Пример SNR

Рисунок 49. Пример графика SNR для test_param_noise_reduction.

0: ВЫКЛ, 1: БЫСТРО, 2: HQ, 3: МИН, 4: ZSL

test_param_noise_reduction высокий коэффициент усиления nr=0 пример

Рисунок 50. Пример высокого усиления test_param_noise_reduction nr=0.

test_param_noise_reduction высокий коэффициент усиления nr=1 пример

Рисунок 51. Пример высокого усиления test_param_noise_reduction nr=1.

test_param_noise_reduction высокий коэффициент усиления nr=2 пример

Рисунок 52. Пример высокого усиления test_param_noise_reduction nr=2.

test_param_noise_reduction высокий коэффициент усиления nr=3 пример

Рисунок 53. Пример высокого усиления test_param_noise_reduction nr=3.

пример низкого усиления test_param_noise_reduction

Рисунок 54. Пример низкого усиления test_param_noise_reduction.

режим_затенения_тестовых_параметров

Проверяет, применяется ли параметр android.shading.mode .

Протестированные API:

Пройдено: режимы затенения переключаются, и карты затенения линз изменяются, как и ожидалось.

test_param_shading_mode карта затенения линз, режим 0, цикл 0, пример

Рисунок 55. Карта затенения линз test_param_shading_mode, пример режима 0, цикла 0.

test_param_shading_mode карта затенения линз, пример цикла 0 режима 1

Рисунок 56. Карта затенения линз test_param_shading_mode, пример режима 1, цикла 0.

test_param_shading_mode карта затенения линз, пример цикла 0 режима 2

Рисунок 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

Проверяет повышение чувствительности после обработки. Захватывает набор изображений в формате RAW и YUV с разной чувствительностью, публикует комбинацию повышения чувствительности после обработки и проверяет, соответствует ли среднее значение выходного пикселя запрошенным настройкам.

Протестированные API:

Пройдено: Необработанные изображения становятся темнее по мере увеличения усиления, в то время как яркость изображений YUV остается постоянной.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 пример

Рисунок 60. test_post_raw_sensitivity_boost raw s=3583 boost=0100 пример.

test_post_raw_sensitivity_boost raw s=1792 boost=0200 пример

Рисунок 61. test_post_raw_sensitivity_boost raw s=1792 boost=0200 пример.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 пример

Рисунок 62. test_post_raw_sensitivity_boost raw s=0896 boost=0400 пример.

test_post_raw_sensitivity_boost raw s=0448 boost=0800 пример

Рисунок 63. test_post_raw_sensitivity_boost raw s=0448 boost=0800 пример.

test_post_raw_sensitivity_boost raw s=0224 boost=1600 пример

Рисунок 64. test_post_raw_sensitivity_boost raw s=0224 boost=1600 пример.

test_post_raw_sensitivity_boost raw s=0112 boost=3199 пример

Рисунок 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:

Проход: Увеличение ISO (усиление) делает пиксели более чувствительными к свету, поэтому график смещается влево.

test_raw_exposure пример ISO=55

Рисунок 73. Пример test_raw_exposure ISO=55.

10⁰ равно 1 мс, 10¹ равно 10 мс, а 10⁻¹ равно 0,1 мс.

test_raw_exposure пример ISO=132

Рисунок 74. Пример test_raw_exposure ISO=132.

пример test_raw_exposure ISO=209

Рисунок 75. Пример test_raw_exposure ISO=209.

test_raw_exposure пример ISO=286

Рисунок 76. Пример test_raw_exposure ISOs=286.

test_raw_exposure пример ISO=363

Рисунок 77. Пример test_raw_exposure ISO=363.

test_raw_exposure_s=440

Рисунок 78. Пример test_raw_exposure ISO=440.

test_reprocess_шум_снижения

Проверяет, применяется ли android.noiseReduction.mode для запросов на повторную обработку. Захватывает повторно обработанные изображения при тусклом освещении камеры. Использует высокое аналоговое усиление для проверки того, что захваченное изображение является шумным. Захватывает три повторно обработанных изображения для NR off, fast и high quality. Захватывает повторно обработанное изображение с низким усилением и NR off и использует его дисперсию в качестве базовой линии.

Протестированные 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.

тест_yuv_plus_dng

Проверяет работоспособность указанных размеров и форматов захвата изображений.

Протестированные API:

Пройдено: Тест завершен и возвращает запрошенные изображения.

пример test_yuv_plus_dng

Рисунок 87. Пример test_yuv_plus_dng.

сцена1_3

scene 1_3 является функционально идентичной копией scene 1_1 , реализующей структуру подсцены для облегчения длительности scene 1 .

test_capture_result

Тесты, которые показывают, что допустимые данные возвращаются в объектах CaptureResult . Тест состоит из автоматического захвата, ручного захвата и второго автоматического захвата.

Протестированные API:

Pass: Метаданные действительны для всех снимков, и ручные настройки не просачиваются во второй автоматический снимок. Выстраивает коррекцию затенения объектива для снимков.

test_capture_result_plot_lsc_auto_ch0

Рисунок 88. test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

Проверяет правильность параметров модели DNG raw. График отображает измеренную дисперсию центрального участка серой карты в необработанных снимках, снятых в диапазоне чувствительности, и сравнивает эти значения с дисперсией, ожидаемой при каждой чувствительности моделью шума DNG в HAL камеры (на основе параметров O,S, возвращаемых в объектах результата захвата). Для получения более подробной информации о модели шума DNG загрузите следующий документ о модели шума DNG .

Протестированные API:

Pass: параметры модели DNG raw верны. Ожидаемые значения RGB соответствуют фактическим измеренным значениям RGB.

test_dng_noise_model_plog

Рисунок 89. test_dng_noise_model_plog.

тест_jpeg

Тесты, которые конвертировали изображения YUV и изображения JPEG устройства, выглядят одинаково. Тест берет центральные 10% изображения и вычисляет значение RGB, а также проверяет, что они совпадают.

Протестированные API:

Пройдено: средняя разница 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:

Пас: Разница увеличивается с каждым броском.

тест_сырой_чувствительности_дисперсия

Рисунок 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

Тестирует захват одного кадра как в формате RAW (10- и 12-битного RAW), так и в формате YUV, если поддерживается. Использует ручной запрос с линейной тональной картой, поэтому RAW и YUV должны быть одинаковыми. Сравнивает центральные 10% значения RGB преобразованных изображений RGB. Регистрирует android.shading.mode .

Протестированные API:

Пройдено: изображения YUV и RAW схожи и имеют разницу менее 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:

Пройдено: более высокое значение ISO приводит к повышению уровня шума.

Критерии пропуска теста

Тест test_sensitivity_priority.py пропускается, если выполняется любой из следующих критериев:

приоритет_времени_экспозиции_теста

Тестирует CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY при различных значениях времени экспозиции, проверяя стабильную яркость в диапазоне, в котором ISO может компенсировать ее.

Протестированные API:

Пройдено: яркость стабильна (в пределах допуска) на протяжении всего времени экспозиции, если ISO находится в пределах диапазона компенсации.

Критерии пропуска теста

Тест test_exposure_time_priority пропускается, если выполняется любой из следующих критериев:

сцена2_а

scene2_a имеет три лица с серым фоном и нейтральной одеждой. Лица выбираются с широким диапазоном оттенков кожи. Для оптимальной работы функции распознавания лиц диаграмма должна иметь правильную ориентацию.

пример сцены2_a

Рисунок 98. Пример scene2_a.

test_autoframeing

Тестирует поведение автокадрирования устройства камеры. Выполняет большое масштабирование, так что ни одно из лиц в сцене не видно, включает режим автокадрирования, устанавливая AUTOFRAMING в CaptureRequest в True , и проверяет, могут ли быть обнаружены все лица в исходной сцене, когда состояние сходится (то есть когда AUTOFRAMING_STATE в CaptureResult установлено в AUTOFRAMING_STATE_CONVERGED ).

Протестированные API:

Пройдено: все три лица обнаружены.

тест_дисплей_p3

Тесты Отображение захвата P3 в JPEG с использованием API ColorSpaceProfiles . Тесты того, что захваченный JPEG имеет соответствующий профиль ICC в своем заголовке, и что изображение содержит цвета за пределами гаммы sRGB.

Протестированные API:

Пройдено: JPEG содержит профиль Display P3 ICC и цвета за пределами гаммы sRGB.

тестовые_эффекты

Захватывает кадр для поддерживаемых эффектов камеры и проверяет, правильно ли они сгенерированы. Тест проверяет только эффекты OFF и MONO , но сохраняет изображения для всех поддерживаемых эффектов.

Протестированные API:

Проход: захватывает изображение сцены с OFF эффектами и монохромное изображение с эффектами, установленными на MONO .

тестовые_эффекты_МОНО

Рисунок 99. test_effects_MONO.

test_exposure_keys_consistent

В этом тесте сравнивается средняя яркость захвата с включенной АЭ и захвата с выключенной АЭ, в котором вручную применяются параметры экспозиции (чувствительность, время экспозиции, длительность кадра, повышение чувствительности после обработки), полученные в CaptureResult захвата с включенной АЭ.

Протестированные 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:

Пройдено: находит три лица с ориентирами в ограничивающих их рамках.

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:

PASS: изображения YUV и JPEG для варианта использования STILL_CAPTURE имеют менее чем 3% среднеквадратичных средств (значение квадратного квадрата корневого квадрата сигнала); Изображения YUV для всех поддерживаемых вариантов использования имеют разницу менее чем на 10% среднеквадратичных разниц от изображений YUV с вариантом использования STILL_CAPTURE .

Scene2_c

test_num_faces

Тесты обнаружения лица с повышенным разнообразием тона кожи в сценах лица.

Протестировано API:

Проход: находит три лица.

test_num_faces_fd_mode_1

Рисунок 103. Пример режима обнаружения лиц TEST_NUM_FACES.

test_jpeg_capture_perf_class

Тестирует задержку захвата JPEG для класса производительности S, как указано в разделе 2.2.7.2 камеры в CDD.

Проход: должен иметь задержку схватки Camera2 JPEG <1000 мс для разрешения 1080p, измеренная камерой CTS, работающей в условиях освещения (3000K) для обеих первичных камер.

test_camera_launch_perf_class

Тестирует задержку запуска камеры для класса производительности S в качестве указанного раздела 2.2.7.2 камера в CDD.

Пропуск: Должен иметь задержку запуска Camera2 (открывая камеру для первого предварительного просмотра рамки) <600 мс, измеренная камерой CTS PerformanceTest в условиях его освещения (3000K) для обеих первичных камер.

test_default_camera_hdr

Тесты, которые захват камеры по умолчанию, представляют собой Ultra HDR для класса 15, как указано в разделе 2.2.7.2 камеры CDD.

Пропустите: по умолчанию пакет камеры должен быть Ultra HDR для устройства Performance Class 15.

Scene2_d

test_preview_num_faces

Тесты обнаружения лица в предварительном просмотре с увеличением разнообразия тонов кожи в сценах лица.

Протестировано API:

Пропуск: находит три лица с достопримечательностями лица на лице.

Scene2_e

test_continoury_picture

50 кадров разрешения VGA захватываются с помощью запроса захвата, сначала настройка android.control.afMode = 4 (CONTINUOUS_PICTURE).

Протестировано API:

Пропуск: 3A Система оседает к концу захвата из 50 кадров.

test_num_faces

Тесты обнаружения лица с повышенным разнообразием тона кожи в сценах лица.

Протестировано API:

Проход: находит 3 лица.

Scene2_f

scene2_f имеет три лица с белым фоном и белой одеждой. Лицы имеют широкий спектр оттенков кожи и высокий контраст с фоном.

пример сцены2_f

Рисунок 104. Пример сцены2_f.

test_preview_num_faces

Тесты обнаружения лица с повышенным разнообразием тона кожи в сценах лица.

Протестировано API:

Пропуск: находит три лица с достопримечательностями лица на лице.

test_num_faces_fd_mode_1

Рисунок 105. Пример TEST_NUM_FACES_FD_MODE_1.

Scene2_g

scene2_g имеет три лица профиля с белым фоном и белой одеждой. Лицы имеют широкий спектр оттенков кожи и высокий контраст с фоном.

Scene2_g.png

Рисунок 106. Сцена2_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 Mode Sharper или равен FAST режиму.

Протестировано API:

Поврежденные параметры камеры:

  • EDGE_MODE

test_edge_enhancement_edge = 0

Рисунок 108. test_edge_enhancement Edge = 0 Пример.

test_edge_enhancement edge = 1 пример

Рисунок 109. Пример TEST_EDGE_ENHANCEMENT = 1 (FAST MODE).

TEST_EDGE_ENHANCENT EDGE = 2 Пример

Рисунок 110. Пример TEST_EDGE_ENHANCENT EDGE = 2 (режим высокого качества).

test_flip_mirror

Тесты, если изображение правильно ориентировано в соответствии с 7.5.2 Фронтальной камеры в CDD.

Зеркальные, перевернутые или повернутые изображения могут быть идентифицированы с помощью алмазной функции вблизи центра.

Проход: изображение не перевернуто, зеркало и не вращается.

Пример патча сцены test_flip_mirror

Рисунок 111. Пример патча сцены Test_flip_mirror.

test_imu_drift

Тесты, если блок инерционного измерения (IMU) имеет стабильный выход в течение 30 секунд, в то время как устройство является стационарным и фиксирует предварительный просмотр высокого определения.

Протестировано API:

Проходить:

  • Дрейф гироскопа составляет менее 0,01 рад во время испытания.
  • Дисперсия показания гироскопа составляет менее 1E-7 рад 2 /с 2 /Гц за время испытания.
  • Дрейф вектора вращения составляет менее 0,01 рад во время испытания.
  • (Еще не обязательно) дрейф гироскопа составляет менее 1 градуса в секунду.

пример дрейфа тестирования

Рисунок 112. Пример дрейфа тестирования

Пример дрейфа VECTOR TEST_IMU_DRIFT VECTOR

Рисунок 113. Пример дрейфа test_imu_drift Vector.

test_landscape_to_portrait

Проверки, если правильный переопределение ландшафта в Portrait правильно функционирует для ландшафтных датчиков.

Протестировано API:

Проход: тест обнаруживает диаграмму с ожидаемым вращением (0 градусов, когда переопределение ландшафта в пор-

test_landscape_to_portrait Пример

Рисунок 114. Пример test_landscape_to_portrait.

test_lens_movement_reporting

Испытания, если флаг движения объектива правильно сообщается. Занимает всплеск из 24 изображений с первыми 12 кадрами на оптимальном расстоянии фокусировки (как найдено 3А) и последние 12 кадров на минимальном расстоянии фокуса. Вокруг кадра 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_REPOCESS_EDGE_ENHANCEMENT ПРИМЕР

Рисунок 115. Пример сюжета test_repocess_edge_enhancement.

Сцена4

scene4 состоит из черного круга на белом фоне внутри квадрата.

Тесты в сцене4 могут быть чувствительны к выравниванию, поэтому, начиная с 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 кадров в секунду не более 7,5%

Механизмы провал:

  • Круг из видео 30 кадров в секунду значительно отличается по размеру от 60 -кадтного видео.
  • Круг в захваченном изображении искажен в процессе обработки.
  • Круг в захваченном изображении обрезан из -за чрезвычайного запроса по захвату соотношения сторон, снижающего высоту или ширину изображения.
  • Круг на захваченном изображении имеет отражение в центре и не выглядит полностью заполненным.

test_aspect_ratio_and_crop

Тесты, если изображения искажены или неожиданно обрезаются в трубопроводе изображения. Фотографирует круг по всем форматам. Проверяет круг не искажен, круг не движется от центра изображения, и круг не изменяется неправильно с различными соотношениями сторон или разрешениями.

Протестировано API:

Пропуск: изображения не растянуты, центр изображений не отличается более чем на 3%, и максимально возможный FOV сохраняется.

Механизмы провал:

  • Камера не выровнена с кругом, отображаемым на планшете в центре захваченной сцены.
  • Круг в захваченном изображении искажен в процессе обработки.
  • Изображение нижнего разрешения с двойным обрезанным в конвейере изображения, создавая различные FOV между изображениями с высоким и низким разрешением.
  • Круг в захваченном изображении обрезан из -за чрезвычайного запроса по захвату соотношения сторон, снижающего высоту или ширину изображения.
  • Круг на захваченном изображении имеет отражение в центре и не выглядит полностью заполненным.

test_multi_camera_alenment

Проверяет параметры калибровки камеры, связанные с позиционированием камеры для систем нескольких камеры. Используя многокамерные физические подкамеры, сфотографируется с одной из физических камер. Находит центр круга. Проецирует Circle Center к миру координаты для каждой камеры. Сравнивает разницу между центрами круга камер в мировых координатах. Воспроизведения мировой координации координат пикселя и сравнение с оригиналами как проверка достоверности. Сравнивает размеры круга, проверяя, различаются ли фокусные расстояния камер.

Протестировано API:

Проход: Центры кружков и размеры, как и ожидалось, на прогнозируемых изображениях по сравнению с захваченными изображениями, использующими данные калибровки камеры и фокусные расстояния.

Механизмы провал:

  • LENS_INTRINSIC_CALIBRATION , LENS_POSE_TRANSLATION и LENS_POSE_ROTATION являются проектными значениями, а не фактическими данными калибровки.
  • Система камеры не подходит для тестовой настройки, например, тестирования широкой и сверхуровневой системы камеры с помощью испытательной установки RFOV. Для получения дополнительной информации см. Camera ITS IT-в-короб, FAQ 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:

Pass: видео кадры не растянуты, центр кадров не отличается более чем на 3%, и максимально возможный FOV сохраняется.

Сцена5

scene5 требует равномерно освещенной серой сцены. Это достигается диффузором, помещенным над объективом камеры. Мы рекомендуем следующий диффузор: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168 .

Чтобы подготовить сцену, прикрепите диффузор перед камерой и укажите камеру на источник освещения около 2000 года. Изображения, снятые для scene5 , требуют диффузного освещения без очевидных функций. Ниже приведен пример изображения:

Сцена5 Пример

Рисунок 117. Сцена5 пример захвата.

test_lens_shading_and_color_uniformity

Испытания о том, что коррекция затенения объектива применяется соответствующим образом, и цвет монохромной единой сцены, равномерно распределяется. Выполняет этот тест на кадре YUV с Auto 3A. Затенение линз оценивается на основе канала Y. Измеряют среднее значение y для каждого указанного блока выборки и определяет проход или сбой, сравнивая с центром y. Тест на однородность цвета оценивается в красно-зеленом и сине-зеленом пространстве.

Протестировано API:

Проход: при указанном радиусе изображения дисперсия красного зеленого и синего зеленого значения должна составлять менее 20% для прохождения теста.

Сцена6

scene6 - это сетка уникальных идентифицируемых маркеров ARUCO. Тесты в scene6 могут быть чувствительны к выравниванию, поэтому, начиная с 15, вы можете использовать check_alignment.py в каталоге инструментов, чтобы обеспечить проверку выравнивания DUT и диаграммы.

Сцена6

Рисунок 118. Сцена6 Пример.

test_in_sensor_zoom

Проверяет поведение функции Zoom Zoom in-Camer, которая создает обрезанные необработанные изображения.

С вариантом использования потока, установленным в CROPPED_RAW , тест берет два захвата над диапазоном Zoom, полное изображение FOV и обрезанное сырое изображение. Тест преобразует изображения в массивы RGB, снижает полноразмерное обрезанное сырое изображение в размер, сообщаемый SCALER_RAW_CROP_REGION , и вычисляет разницу в 3D-среднеквадратичных средах между двумя изображениями.

Протестировано API:

Пропуск: Разница в 3D RMS между обрезанным сырым изображением с ножом и полным изображением FOV меньше, чем пороговое значение, установленное в тесте.

test_zoom

Проверяет поведение камеры от ультравидного объектива до широкого объектива. Принимает захваты через диапазон увеличения и проверяет, становятся ли маркеры ARUCO больше по мере увеличения камеры. Тест также проверяет, изменяется ли положение центрального маркера предсказуемо за каждый захват. Расстояние от центра центрального маркера до центра изображений может либо меняться с постоянной скоростью по отношению к соотношению Zoom до физического переключателя камеры, либо он может монотонно меняться в направлении места одного и того же маркера после физического переключателя камеры. Приложение JetPack Camera ( JCA ) должно быть установлено на устройстве перед тестированием.

Протестировано API:

Пропуск: Относительный размер захваченного маркера ARUCO является точным по сравнению с запрошенным соотношением масштабирования, чтобы убедиться, что камера правильно увеличивается, и расстояние маркера до центра изображения изменяется в соответствии с критериями, указанными в описании теста.

test_zoom, чтобы найти контур маркера ARUCO, ближайший к центру

Рисунок 119. test_zoom, чтобы найти контур маркера ARUCO, ближайший к центру.

test_low_latency_zoom

Проверяет камеру низкого уровня задержки. Принимает захваты через диапазон Zoom с android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) и проверяет, соответствуют ли маркеры в выходных изображениях соотношениях Zoom в метаданных захвата. Тот же сеанс захвата камеры используется для сходимости 3A и захвата.

Протестировано API:

Пропуск: Относительный размер захваченного маркера является точным по сравнению с метаданными результатами увеличения.

test_preview_video_zoom_match

Проверяет это при записи и масштабировании, предварительный просмотр видео и вывод видео и записывает один и тот же вывод. Рассчитывает размер маркера, ближайший к центру при различных коэффициентах масштабирования, и проверяет, увеличивается ли размер маркера с увеличением коэффициента масштабирования.

Протестировано API:

Пропуск: относительный размер захваченного маркера является точным против запрошенного соотношения масштабирования в видео и предварительном просмотре.

HD_1280x720_key_frame.png

Рисунок 120. HD_1280x720_key_frame.png (до Zoom).

preview_1280x720_key_frame.png

Рисунок 121. Preview_1280x720_key_frame.png (до Zoom).

Hd_1280x720_key_frame_zoomed.png

Рисунок 122. HD_1280x720_key_frame.png (после Zoom).

preview_1280x720_key_frame_zoomed.png

Рисунок 123. Preview_1280x720_key_frame.png (после Zoom).

test_preview_zoom

Тесты, что соотношение масштабирования каждой рамки предварительного просмотра соответствует соответствующим метаданным захвату от ультравидного объектива к широкому объективу. Тест берет предварительные кадры над диапазоном масштабирования и находит маркер ARUCO, наиболее близкий к центру. Затем тест проверяет, если позиция центрального маркера предсказуемо изменяется над каждым захватом. Расстояние от центра центрального маркера до центра изображений может либо меняться с постоянной скоростью по отношению к соотношению Zoom до физического переключателя камеры, либо он может монотонно меняться в направлении места одного и того же маркера после физического переключателя камеры.

Протестировано API:

Пропуск: относительный размер выбранного маркера ARUCO является точным для сообщаемого соотношения Zoom соответствующего результата захвата для всех кадров предварительного просмотра. Относительное расстояние выбранного маркера от центра изображения является точным для сообщаемого соотношения зумного уровня соответствующего результата захвата всех кадров предварительного просмотра.

test_preview_zoom Изображения, показывающие выбранный маркер, ближайший к центру

Рис.

test_session_characteristics_zoom

Проверяет диапазон соотношения Zoom для всех поддерживаемых конфигураций сеанса, перечисленных в CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION . Для каждой из этих конфигураций, если CameraDeviceSetup#isSessionConfigurationSupported включает возврат true , тест подтверждает, что диапазон соотношений Zoom возвращается в 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 Lens. Проверка AWB проверяет, что соотношения красно-зеленых и сине-зеленых находятся в пределах пороговых значений как для изображений UW, так и для W Lens. Проверка AF оценивает значение оценки резкости на основе средней величины градиента между изображениями UW и W Lens.

При проведении этого теста, если эффект муара мешает результатам, используйте планшет с более высоким разрешением из списка камеры его утвержденный список планшетов .

Протестировано API:

Пропустите: чтобы пройти тест, проверки AE и AWB должны пройти. Результаты проверки AF используются только в целях ведения журнала. Ниже приведены критерии для каждой проверки:

  • Проверка AE: изменение LUMA (значение y) между изображениями UW и W Lens должно составлять менее 4% для всех цветовых патчей, если устройство поддерживает как ae_regions , так и awb_regions . Если поддерживается только ae_regions , то только серо -цветовые значения должны соответствовать критериям.
  • Проверка AWB: разница между красно-зелеными и сине-зелеными значениями для изображений UW и W Lens должна составлять менее 3% для патча серого цвета и должно составлять менее 10% для других цветовых патчей, если устройство поддерживает как ae_regions так и awb_regions .
  • Проверка AF: резкость изображения для захвата линзы должна быть выше резкости с захватом UW.

test_multi_camera_switch_gray_uw_y

Рисунок 126. Серые пятно, взятые с объективом UW.

test_multi_camera_switch_gray_w_y

Рисунок 127. Серые пятно, взятые с W Lens.

Сцена8

scene8 - это прямоугольная рама, разделенная на четыре равных областях, каждый из которых содержит портрет, снятый с различным воздействием или наложенный с различным цветовым оттенком (синий оттенок, повышенное воздействие, уменьшение воздействия, желтый оттенок). Четыре маркера ARUCO выровнены с четырьмя наружными углами прямоугольника, чтобы получить точные координаты основной рамы прямоугольника.

Сцена8 пример

Рисунок 128. Сцена8 Пример.

test_ae_awb_regions

Проверки, что значения RGB и LUMA различаются, когда просмотр записи в разных областях AE и AWB.

Тест записывает 8 -секундную запись предварительного просмотра, выполняя измерение AE и AWB на каждом квадранте по 2 секунды каждый. Затем тест извлекает кадр из записи предварительного просмотра каждого региона и использует извлеченные кадры для выполнения следующих проверок AE и AWB:

  • Проверка AE: проверяет, что измерение рамки в области с уменьшенным воздействием имеет повышенное значение LUMA более чем на 1%, чем измерение рамки с увеличением воздействия. Это проверяет, что изображения осветляются при измерении темной области.
  • Проверка AWB: проверяет, что отношение от красного к синим (средних значений RGB изображения) в раме с областью синего измерения более чем на 2% выше, чем кадр с помощью области желтого измерения. Это проверяет, что изображения имеют сбалансированное значение RGB при измерении желтой (теплой) или синей (прохладной) области.

Протестировано API:

Проход: 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 .

Протестировано API:

Проход: отношения RGB демонстрируют ожидаемое увеличение или уменьшение по сравнению с выбранными температурами и оттенками.

Тестовые критерии пропуска

Тест test_color_correction_mode_cct пропускается, если выполняется какой -либо из следующих критериев:

Сцена9

scene9 состоит из тысяч случайных и цветных кругов, чтобы создать сцену с очень низкой повторяемостью для стресса алгоритмов сжатия JPEG.

Сцена9 пример

Рисунок 132. Сцена9 Пример.

test_jpeg_high_entropy

Тестирует, что сжатие камеры JPEG работает на scene9 с высокой энтропией, а коэффициент качества JPEG составляет 100%. Коэффициент масштабирования увеличивается, чтобы убедиться, что сцена, отображаемая на планшете, заполняет камеру FOV.

Протестировано API:

Pass: файл JPEG сжимается правильно, написан и читайте обратно с диска.

test_jpeg_quality

Тестирует качество сжатия камеры JPEG. Шаг JPEG качества через android.jpeg.quality и проверяет, что таблицы квантования изменяются правильно.

Протестировано API:

Проход: Матрица квантования уменьшается с увеличением качества. (Матрица представляет фактор деления.)

Pixel 4 Задняя камера Luma и Chroma DQT Матрица Средние по сравнению с качеством JPEG

Рисунок 133. Средние матрицы Pixel 4 Luma и Chroma DQT по сравнению с качеством JPEG.

TEST_JPEG_QUALIATIO

Рисунок 134. Неудачный тестовый пример.

Scene_video

scene_video - это видео -сцена, состоящая из четырех разных цветных кругов, движущихся взад и вперед с разными частотами кадров на белом фоне.

Рисунок 135. Пример сцены_video.

test_preview_frame_drop

Испытания, которые поддерживается запрошенной частотой кадров предварительного просмотра с динамической сценой. Этот тест работает на всех камерах, которые подвергаются воздействию сторонних приложений.

Протестировано API:

Пропуск: частота кадров предварительного просмотра находится на максимуме запрашиваемого диапазона частоты кадров, а среднее изменение между последовательными кадрами меньше, чем относительная допуск, установленная в тесте.

Scene_extensions

Тесты scene_extensions предназначены для расширений камеры и должны использовать камеру ITS в коробке , поскольку они требуют точного управления средой тестирования. Кроме того, вся утечка света должна контролироваться. Это может потребовать покрытия испытательной установки, DUT и планшета капельной тканью, а также устранение утечки света с переднего экрана DUT.

Scene_hdr

Сцена scene_hdr состоит из портрета слева и низкоконтрастного QR-кода справа.

Scene_hdr

Рисунок 136. Пример сцены_HDR.

test_hdr_extension

Проверка расширения HDR . Принимает захваты с включенным расширением и без него, и проверяет, делает ли расширение QR -код более обнаруживаемым.

Протестировано API:

Пропуск: расширение HDR уменьшает количество изменений контрастности, необходимых для обнаружения QR -кода или уменьшения градиента по QR -коду.

Scene_low_light

Сцена scene_low_light состоит из сетки квадратов с различными оттенками серого на черном фоне, а сетка квадратов связана красным контуром. Квадраты расположены в ориентации кривой Гильберта.

Scene_low_light Пример

Рисунок 137. Пример сцены_лоу.

test_night_extension

Проверка ночи расширения . Принимает захваты с включенным расширением и выполняет следующее:

  • Обнаруживает наличие 20 квадратов
  • Вычисляет люму, ограниченную каждым квадратом
  • Вычисляет среднее значение LUMA первых 6 квадратов в соответствии с ориентацией сетки Hilbert Curve
  • Вычисляет разницу в значении LUMA последовательных квадратов (например, Square2 - Square1) до квадратов 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

Тестирует режим повышения Low Light AE . Если Camera2 поддерживает режим Low Light Boost AE, то этот тест выполняется для Camera2. Если поддерживается расширение камеры ночного режима, а расширение поддерживает режим Low Light Boost AE, то этот тест также выполняется для расширения камеры ночного режима. Этот тест устанавливает режим AE на повышение слабых освещений, берет раму из предварительного просмотра и выполняет следующее:

  • Обнаруживает наличие 20 коробок
  • Вычисляет Luma, ограниченную каждой коробкой
  • Вычисляет среднее значение LUMA первых 6 квадратов в соответствии с ориентацией сетки Hilbert Curve
  • Вычисляет разницу в значении LUMA последовательных квадратов (например, Square2 - Square1) до квадратов 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

Ключевым требованием для тестов scene_tele является то, что расстояние диаграммы должно быть как минимум минимальным расстоянием фокусировки телеобъектива. Поскольку это минимальное расстояние фокуса может отличаться между устройствами, вы должны настроить свою настройку в соответствии с конкретной телеобъективной камерой.

Установка Scene_tele на основе расстояния фокусировки широкой и телевизионной камеры

Рисунок 139. Установка SCHEEE_TELE на основе расстояния фокусировки широкой и телевизионной камеры.

Для получения дополнительной информации о настройке тестового оборудования см. Настройку расширения Tele .

Scene6_Tele

Сцена scene6_tele состоит из сетки маркеров Aruco на белом фоне.

Если scene6_tele захватывают, что смотрится, переэкспонированное в модульной буровой установке , снимите переднюю пластину модульной установки .

Отключите испытательную установку WFOV от расширения и снимите крепление телефона.

Отключите испытательную установку WFOV от расширения и снимите крепление телефона

Рисунок 140. Отсоедините испытательную установку WFOV от расширения и снимите крепление телефона.

remove_front_plate

Рисунок 141. Снимите переднюю пластину.

test_zoom_tele

Проверяет поведение камеры от широкого объектива до телеобъектива. Тест идентичен test_zoom , но проверяет поведение камеры от широкого объектива до телеобъектива.

Протестировано API:

Пропуск: Относительный размер захваченного маркера ARUCO является точным по сравнению с запрошенным соотношением Zoom, чтобы убедиться, что камера правильно увеличивается, и маркер расстояние до центра изображений изменяется в соответствии с критериями, перечисленными в 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 ).