Примечания к выпуску пакета тестирования изображения камеры Android 11

На этой странице представлены изменения в Camera Image Test Suite (ITS) в Android 11. Изменения делятся на следующие категории:

• Аппаратные изменения
• ОБЯЗАТЕЛЬНЫЕ тесты первого уровня API
• Тестовое освещение подтверждено
• Изменение названия сцены
• Тестовые изменения и дополнения
• Увеличенное тестирование камер LIMITED

Аппаратные изменения

В Android 11 представлено несколько аппаратных изменений, направленных на снижение затрат и повышение доступности. Эти изменения делятся на следующие категории:

• Дополнительный производитель
• Унифицированные методы производства
• Расширенные возможности планшета
• Уменьшено открытие планшета.
• Новый сенсорный контроллер Fusion

Дополнительный производитель

Rahi Systems имеет право производить испытательные корпуса ITS в дополнение к нашему существующему поставщику, компании MYWAY design. Информация о компании для квалифицированных поставщиков следующая:

• Рахи Системс Инк.
  48303 Fremont Blvd, Фремонт, Калифорния 94538, США
  rahisystems.com/products/android-device-testing-equipment/
  androidpartner@rahisystems.com
  +1-510-319-3802

• МАЙВЕЙ дизайн
  4F., № 163, улица Фу-Ин, район Синьчжуан, город Нью-Тайбэй, Тайвань
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Унифицированные методы производства

Испытательный корпус ITS-в-коробке со стандартным полем обзора (RFoV) версии 1 переработан с учетом методов производства, используемых в испытательных корпусах с широким полем обзора (WFoV) и коробкой для слияния датчиков . Функциональность идентична, и для простоты дизайн называется rev1a . Модернизация позволяет производителям иметь на складе один тип пластика для изготовления всех испытательных корпусов. Кроме того, конструкция крепления планшета и держателей светильников была изменена, чтобы обеспечить большее разнообразие планшетов и светодиодных панелей.

Чтобы загрузить новейшие описания и механические чертежи, см. раздел RFoV (версия 1a) и WFoV (версия 2.9) .

Расширенные возможности планшета

В список рекомендуемых планшетов добавлены планшеты, в том числе Samsung Galaxy Tab A 10.1 и Chuwi Hi9 Air 10.1. Важно, чтобы планшет не имел широтно-импульсной модуляции (ШИМ) для регулировки яркости экрана и устранения полос на захваченных изображениях.

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

Уменьшено открытие планшета.

Чтобы можно было использовать Galaxy Tab A 10.1, отверстие планшета немного уменьшено по высоте как для тестовых корпусов RFoV (rev1a), так и для WFoV (rev2). Версии, отражающие эти изменения, — rev1a.1 и rev2.9. Эти рисунки см. в блоке RFoV (ред. 1a) и блоке WFoV (ред. 2.9) .

Новый сенсорный контроллер Fusion

Аппаратное обеспечение сенсорного контроллера Fusion было переработано для повышения технологичности. Новый контроллер основан на Arduino , со специальной защитой платы маршрутизации, которая крепится поверх Arduino. На рисунке 1 показан экран, а на рисунке 2 показан механический чертеж корпуса. Новый контроллер питается от одного источника питания 5 В, который напрямую питает двигатель. Электроника полностью управляется через разъем USB. Отдельный источник питания обеспечивает полную изоляцию между управляющей электроникой и серводвигателем. Кроме того, один контроллер может управлять до шести серводвигателями.

Рисунок 1. Вид сверху на шилд Arduino

Рисунок 2. Конструкция корпуса

Android 11 обратно совместим с существующими контроллерами. Чтобы запустить тестирование с помощью контроллера на базе Arduino, используйте:

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

Первый уровень API

В Android 10 тесты ITS обозначаются как MANDATED и NOT_YET_MANDATED . Для запуска устройства под управлением Android 10 необходимо пройти все MANDATED тесты. Тесты NOT_YET_MANDATED могут завершиться неудачно, но для отчетов верификатора CTS они занесены в таблицу как PASS . Требование MANDATED испытаний также применяется к модернизированным устройствам. Это требование к обновленным устройствам пройти все MANDATED тесты привело к тому, что тесты стали MANDATED тестами с задержкой, поскольку старые устройства также должны пройти тесты.

В Android 11 MANDATED тесты контролируются первым флагом уровня API в свойствах телефона. Для устройств, обновляющихся до Android 11, тесты выполняются как тесты NOT_YET_MANDATED . Это означает, что тест может завершиться неудачей, но будет занесен в таблицу как PASS в CtsVerifier.apk .

Например:

• В Android 11 тест test_channel_saturation MANDATED для устройств с первым уровнем API выше 29.
• В Android 10 тест test_channel_saturation является MANDATED для всех устройств.

Проверка освещения сцены

В Android 11 освещение сцены проверяется путем анализа яркости в углах сцены. Все сцены, созданные вручную, проверяются на предмет освещения, а сцены на планшете проверяются для камер RFoV на испытательном стенде RFoV и камер WFoV на испытательном стенде WFoV. Если уровни освещения недостаточны, выдается сообщение об ошибке и тестирование не удается.

Изменение названия сцены

В Android 10 на сцену 1 приходится большая часть тестов и большой процент от общего времени тестирования. Если какой-либо тест в сцене 1 не пройден, всю сцену необходимо запустить заново. По задумке, повторный запуск всей сцены сокращает прохождение предельных тестов. В Android 11 время повтора сокращается за счет разделения сцены 1 на две сцены: сцена 1_1 и сцена 1_2.

В следующей таблице показано время тестирования задней камеры Pixel 4 для различных сцен. Количество тестов разделено для выравнивания времени тестирования, а не для выравнивания количества тестов.

Дополнительно есть очистка имен. Сцена 2 разделена буквами, а сцена 1 — цифрами. Номенклатура различных расширений следующая:

• Сцены с одной и той же диаграммой, но разными тестами: *_1,2,3
• Сцены с разными графиками, но одинаковыми тестами: *_a,b,c

Тестовые изменения

Тесты обновлены для использования первого уровня API.

В Android 11 тесты в следующей таблице обновлены для использования первого флага уровня API. Во всех этих тестах используется первый уровень API 29, за исключением теста test_tonemap_curve , который использует первый уровень API 30.

Тесты с изменениями

Тесты в следующей таблице обновлены в Android 11. Изменения описаны в столбце «Описание изменений» .

Новые тесты

Тесты, представленные в следующей таблице, включены в Android 11. Тесты обобщены в таблице, а подробные описания представлены в следующих разделах.

Scene0/test_vibration_restriction

Этот тест не требует какой-либо конкретной сцены, но тестируемое устройство (DUT) должно быть размещено или установлено на твердой поверхности. Сюда входит монтаж на испытательных шкафах ITS-in-a-box.

Утверждает

• Отсутствие вибраций при использовании камеры.

Scene2_a/test_jpeg_quality

Метод

Различные части файла JPEG определяются 2-байтовыми маркерами. Для получения дополнительной информации см. JPEG .

Тест извлекает матрицы квантования из файла JPEG. Маркером для матриц квантования при захвате JPEG является последовательность [255, 219]. Когда маркер найден, следующие два элемента списка — это размер. Маркер размера JPEG DQT обычно равен [0, 132] = 256*0+132 = 132, что определяет размер данных DQT при захвате JPEG. Встроенные данные имеют вид: [255, 219, 0, 132, 0 (маркер яркости), матрица яркости 8x8, 1 (маркер цветности), матрица цветности 8x8].

0 для маркера матрицы яркости и 1 для маркера цветности кажутся одинаковыми для ряда устройств, включая телефоны, которые разделяют две матрицы на отдельные разделы DQT в файле JPEG. Матрицы яркости, как правило, имеют более широкий диапазон значений по сравнению с матрицами цветности, поскольку человеческий глаз более чувствителен к яркости, чем к цветности, и изображения JPEG учитывают это.

Ниже показаны образцы извлеченных матриц яркости и цветности для коэффициентов качества 85 и 25 для задней камеры Pixel 4, записывающей сцену 2_a на испытательном стенде ITS. Значения матрицы существенно увеличиваются (обозначая повышенное сжатие) при настройке более низкого качества. Эти матрицы печатаются сценарием только в том случае, если установлен флаг debug=True . Обратите внимание на большее изменение записей в матрицах яркости по сравнению с матрицами цветности.

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

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

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

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

На рисунке 3 показаны средние значения матрицы задней камеры Pixel 4 в зависимости от качества JPEG. По мере повышения качества JPEG уровень сжатия (среднее значение яркости/цветности матрицы DQT) снижается.

Рис. 3. Средние значения яркости/цветности матрицы DQT задней камеры Pixel 4 в сравнении с качеством JPEG

Утверждает

• Для [25, 45, 65, 86] качество +20 приводит к уменьшению средних значений матрицы квантования на 20%.
• Полезные данные матрицы DQT представляют собой квадратные числа.

На рис. 4 показан пример телефона, который не прошел тест. Обратите внимание, что для изображений очень низкого качества ( jpeg.quality < 50 ) сжатие в матрице квантования не увеличивается.

Рисунок 4. Пример неудачного теста

Scene2_d/e test_num_faces

Добавлены две новые сцены обнаружения лиц, чтобы увеличить разнообразие лиц при проверках алгоритма обнаружения лиц. При повторном тестировании нескольких камер ожидается, что самым сложным лицом будет самое левое лицо в сцене 2_d. В частности, на модели есть и шляпа, и борода, что-то новое в сценах с лицом. Новые сцены показаны на рисунках 5 и 6.

Рисунок 5. Scene2_d

Рисунок 6. Scene2_e

Утверждает

• num_faces == 3

Scene2_e/test_continious_picture

Метод

Тест test_continuous_picture использует Scene2_e, но его можно включить в любой сцене с лицами. В этом тесте 50 кадров с разрешением VGA захватываются с первой установкой запроса захвата android.control.afMode = 4 (CONTINUOUS_PICTURE) .

Ожидается, что система 3A стабилизируется в конце захвата 50 кадров.

Утверждает

• 3А находится в сведенном состоянии в конце захвата.

Scene_change/test_scene_change

Метод

Новый тест позволяет проверить, устанавливается ли флаг android.control.afSceneChange при смене сцены. При смене сцены планшет отображает сцену с лицом, а затем включает и выключает планшет для изменения сцены. Сцена повторно использует сцену Scene2_e, но находится в отдельной сцене из-за необходимости управления планшетом.

Кроме того, при ручном тестировании смену сцены можно выполнить, помахав рукой перед камерой.

На рисунке 7 представлена ​​временная диаграмма теста. Время между выключением экрана и захватом регулируется на основе результатов событий предыдущих снимков.

Рисунок 7. Временная диаграмма test_scene_change

Условия смены:

• Если происходит смена сцены и afSceneChange == 1 , тест возвращает PASS .
• Если происходит смена сцены и afSceneChange == 0 , смена сцены сдвигается на 5 кадров раньше, чтобы дать больше времени для подтверждения afSceneChange .
• Если смены сцены нет и afSceneChange == 1 , тест возвращает FAIL .
• Если смены сцены нет и afSceneChange == 0 , смена сцены сдвигается на 30 кадров раньше, чтобы обеспечить смену сцены при захвате.

Утверждает

• Экран (сцена) переключается.
• Флаг afSceneChange находится в [0, 1].
• Если сцена не меняется, 3A сходится (функционально идентично test_continuous_picture ).
• Если afSceneChange == 1 , яркость должна измениться в сцене.
• PASS за шесть попыток, время изменено в зависимости от предыдущих результатов.

сцена6/test_zoom

Метод

Для тестирования android.control.zoomRatioRange необходима новая сцена, поскольку в установленных сценах либо нет достаточно маленького объекта, чтобы его можно было увеличить (сцены [1, 2, 4]), либо в сцене много объектов, которые нелегко идентифицировать. , что усложняет извлечение признаков (сцена 3).

На рис. 8 показана новая сцена с регулярным массивом кругов. Массив кругов ослабляет требования к центрированию тестируемого устройства/диаграммы и позволяет всегда иметь круг рядом с центром захваченного изображения. В этой сцене массив кругов 9x5 с черной рамкой покрывает весь планшет. Один круг заменяется квадратом в правом верхнем углу, чтобы показать ориентацию. Размеры кругов имеют площадь около 7500 пикселей ( radius=50pixels ) для датчика 4000x3000, снятого с полем зрения (FoV) около 80 градусов.

Рисунок 8. Сцена test_zoom

Рис. 9. Изображения Pixel 4 cam[0] Zoom = [1, 3,33, 5,67, 8] с найденным кругом.

На рис. 9 показаны изображения, снятые задней камерой Pixel 4 при увеличении масштаба от 1 до 8x за четыре шага. Этот набор изображений снят без особого внимания к центрированию, за исключением использования диафрагмы для тестирования телефона с двумя отверстиями, позволяющими протестировать как переднюю, так и заднюю камеры. Ожидается смещение от центра, которое наблюдается, когда картографический планшет находится немного левее центра. Кроме того, диаграммы кажется достаточной для тестирования с коэффициентом масштабирования более 8x.

Поиск кругов

Тест включает метод find_circle() с использованием findContours , который находит все контуры и сужает поиск контуров до нужных кругов, проверяя следующее:

• Контуры должны иметь площадь более 10 пикселей.
• Контуры должны иметь NUM_PTS >= 15 .
• Контуры должны иметь черные центры.
• Контуры должны напоминать круг, то есть их площадь близка к площади pi*r2 контура.

Тестовый полигон

android.control.zoomRatioRange разделен на 10 шагов.

• [1, 7] тесты [1, 1.67, 2.33, 3, 3.67, 4.33, 5, 5.67, 6.33, 7]

Масштабирование останавливается, если найденный круг касается границ изображения. Существует проверка, позволяющая убедиться, что в тесте достигнут достаточный уровень масштабирования (10x).

Утверждает

• При каждой настройке масштабирования обнаруживается хотя бы один кружок.
• Протестировано 10-кратное или максимальное значение android.control.zoomRatioRange .
• Радиус круга масштабируется с увеличением (RTOL 10 % от ожидаемого).
• Смещение центра круга от центра шкалы с масштабированием (RTOL 10 % от ожидаемого).
• Достигнут достаточный уровень масштабирования (2x).

Увеличенное тестирование камер LIMITED

В Android 11 тесты, приведенные в следующей таблице, проверяют камеры LIMITED . В дополнение к новым тестам обновлен тест scene4/test_aspect_ratio_and_crop , позволяющий тестировать устройства LIMITED с первым уровнем API 30 или выше.

На рисунке 10 показано кольцо секретного декодера Android 11 ITS. Кольцо секретного декодера показывает, какими настройками тестов ограничиваются отдельные тесты. Ворота имеют цветовую маркировку для удобства просмотра. Основными элементами ворот являются:

• MANUAL_SENSOR
• READ_3A *требуется MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *требуется MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS * REALTIME
• MULTI_CAMERA

MANUAL SENSOR , READ_3A , COMPUTE_TARGET_EXPOSURES и PER_FRAME_CONTROL контролируют большинство тестов. Кроме того, тесты, включенные для устройств LIMITED , выделяются светло-зеленым цветом.

Рис. 10. Кольцо секретного декодера Android 11.