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

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

• Изменения оборудования
• Первые ОБЯЗАТЕЛЬНЫЕ тесты уровня API
• Тестовое освещение проверено
• Изменения названий сцен
• Тестовые изменения и дополнения
• Расширенное ОГРАНИЧЕННОЕ тестирование камеры

Изменения оборудования

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

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

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

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

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

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

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

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

Для загрузки последних описаний и механических чертежей см. RFoV box (rev1a) и WFoV box (rev2.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 (rev1a) и блоке WFoV (rev2.9) .

Новый контроллер слияния датчиков

Аппаратная часть контроллера Sensor 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 на две сцены: scene1_1 и scene1_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-файла определяются двухбайтовыми маркерами. Подробнее см. в разделе JPEG .

Тест извлекает матрицы квантования из JPEG-снимка. Маркером для матриц квантования в JPEG-снимке служит последовательность [255, 219]. После обнаружения маркера следующие два элемента списка указывают размер. Маркер размера DQT для JPEG обычно равен [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, снимающей сцену scene2_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_continuous_picture

Метод

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

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

Утверждает

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

изменение_сцены/тестовое_изменение_сцены

Метод

Добавлен новый тест для проверки наличия флага 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 с шести попыток, время изменено на основе предыдущих результатов.

scene6/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).

Утверждает

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

Расширенное ОГРАНИЧЕННОЕ тестирование камеры

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

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

• 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