Informacje o wersji Androida 12 Camera Image Test Suite

W wersji Androida 12 uwzględniono wiele zmian dotyczących ITS aparatu. Na tej stronie omówiono zmiany, które można podzielić na 4 duże kategorie:

• Refaktoryzacja do Pythona 3
• Wdrożenie frameworku testów Mobly
• Testowanie zmian
• Nowe testy

Przerzuć na Pythona 3

W związku z wycofaniem języka Python 2.7 w styczniu 2020 r. cały kod źródłowy ITS aparatu został przekształcony na język Python 3. W Androidzie 12 wymagane są te wersje i biblioteki Pythona:

• Python 3.7.9 lub Python 3.7.10
• OpenCV 3.4.2
• Numpy 1.19.2
• Matplotlib 3.3.2
• Scipy 1.5.2
• pySerial 3.5
• Pillow 8.1.0
• PyYAML 5.3.1

Główny program testowy, tools/run_all_tests.py, pozostaje taki sam jak w wersjach Androida 11 i starszych, ale został przebudowany na potrzeby Pythona 3.

Wszystkie pojedyncze testy zostały przebudowane i korzystają z nowej klasy konfiguracji testu zdefiniowanej w tests/its_base_test.py. Większość nazw i funkcji testów pozostaje bez zmian. W Androidzie 12 wszystkie pojedyncze testy wczytują swoje sceny. Ładowanie sceny dla każdego testu zwiększa ogólny czas testu, ale umożliwia debugowanie poszczególnych testów.

Więcej informacji o poszczególnych zmianach testów znajdziesz w artykule Zmiany testów.

Te moduły Pythona zostały przerobione i zmieniono ich nazwy:

• pymodules/its/caps.py → utils/camera_properties_utils.py
• pymodules/its/cv2image.py → utils/opencv_processing_utils.py
• pymodules/its/device.py → utils/its_session_utils.py
• pymodules/its/error.py → utils/error_util.py
• pymodules/its/image.py → utils/image_processing_utils.py
• pymodules/its/objects.py → utils/capture_request_utils.py
• pymodules/its/target.py → utils/target_exposure_utils.py
• tools/hw.py → utils/sensor_fusion_utils.py

Wdrożenie testowego frameworka Mobly

Mobly to platforma testowa o zasadzie działania opartym na Pythonie, która obsługuje przypadki testowe wymagające wielu urządzeń z niestandardową konfiguracją sprzętową. Camera ITS korzysta z infrastruktury testowej Mobly, aby umożliwić lepsze kontrolowanie testów i rejestrowanie ich wyników.

Camera ITS korzysta z infrastruktury testowej Mobly, aby umożliwić lepsze kontrolowanie testów i rejestrowanie ich przebiegu. Mobly to platforma testowa oparta na Pythonie, która obsługuje przypadki testowe wymagające wielu urządzeń z niestandardową konfiguracją sprzętową. Więcej informacji o Mobly znajdziesz na stronie google/mobly.

pliki config.yml,

Korzystając z ramy Mobly, możesz skonfigurować urządzenie testowe (DUT) i tablet z wykresami w klasie its_base_test. Do utworzenia środowiska testowego Mobly służy plik config.yml (YAML). W tym pliku konfiguracji można skonfigurować wiele platform testowych, na przykład tablet i platformę testową fuzji czujników. W sekcji kontrolera każdego środowiska testowego możesz określić wartość device_ids, aby zidentyfikować odpowiednie urządzenia z Androidem dla narzędzia do uruchamiania testów. Oprócz identyfikatorów urządzenia do klasy testu przekazywane są inne parametry, takie jak tablet brightness, chart_distance, debug_mode, camera_id i scene_id. Typowe wartości parametru test to:

brightness: 192  (all tablets except Pixel C)
chart_distance: 31.0  (rev1/rev1a box for FoV < 90° cameras)
chart_distance: 22.0 (rev2 test rig for FoV > 90° cameras)

Testowanie na tablecie

W przypadku testów na tablecie w nazwach testów musi występować słowo kluczowe TABLET. Podczas inicjowania sterownik testów Mobly inicjalizuje TestParamsi przekazuje je do poszczególnych testów.

Poniżej znajdziesz przykładowy plik config.yml do testów na tablecie.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

Platformę testową można wywołać za pomocą tools/run_all_tests.py. Jeśli nie ma wartości wiersza poleceń, testy są wykonywane z wartościami z pliku config.yml. Dodatkowo możesz zastąpić wartości w pliku konfiguracji camera i scene w wierszu poleceń, używając poleceń podobnych do tych w Androidzie 11 lub niższym.

Przykład:

python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=1 scenes=2,1,0

Testowanie fuzji danych z czujników

W przypadku testowania fuzji czujników nazwa testu musi zawierać słowo kluczowe SENSOR_FUSION. Odpowiednią platformę testową określają testowane sceny. Android 12 obsługuje zarówno Arduino, jak i kontrolery Canakit do fuzji danych z czujników.

Poniżej znajdziesz przykładowy plik config.yml do wykonywania zadań dotyczących fuzji danych z czujników.

Testbeds
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Aby przeprowadzić testy fuzji sensorów za pomocą urządzenia do testowania fuzji sensorów, użyj:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0

Wiele testbedów

W pliku konfiguracji można uwzględnić wiele testbedów. Najczęstszą kombinacją jest testowanie na platformie testowej tabletów i platformie testowej fuzji danych z czujników.

Poniżej znajduje się przykładowy plik config.yml z testami na platformach testowych z wykorzystaniem tabletów i zderzenia z czujnikiem.

Testbeds
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Testy ręczne

Testowanie ręczne jest nadal obsługiwane w Androidzie 12. Testbed musi jednak wskazywać, że jest to test, za pomocą słowa kluczowego MANUAL w nazwie. Ponadto testbed nie może zawierać identyfikatora tabletu.

Poniżej znajduje się przykładowy plik config.yml do testowania ręcznego.

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      chart_distance: 31.0
      camera: 0
      scene: scene1

Testowanie scen bez tabletów

Testowanie sceny 0 i sceny 5 można przeprowadzić za pomocą TEST_BED_TABLET_SCENES lub TEST_BED_MANUAL. Jeśli jednak testowanie odbywa się za pomocą funkcji TEST_BED_TABLET_SCENES, tablet musi być podłączony, a jego identyfikator seryjny musi być prawidłowy, nawet jeśli tablet nie jest używany, ponieważ konfiguracja klasy testowej przypisuje wartość identyfikatora seryjnego tabletu.

Uruchamianie poszczególnych testów

Poszczególne testy można uruchamiać tylko w celu debugowania, ponieważ ich wyniki nie są zgłaszane do weryfikatora CTS. Ponieważ plików config.yml nie można nadpisać w wierszu poleceń w przypadku camera i scene, te parametry muszą być poprawne w pliku config.yml dla danego testu. Jeśli w pliku konfiguracyjnym jest więcej niż 1 platforma testowa, musisz ją określić za pomocą parametru --test_bed. Przykład:

python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES

Artefakty testowe

W Androidzie 12 artefakty testów dla ITS aparatu są przechowywane podobnie jak w Androidzie 11 lub starszym, ale z tymi zmianami:

• Aby ułatwić identyfikację, do 8-znakowego losowego ciągu znaków w katalogu artefaktu testowego /tmp dodano prefiks CameraITS_.
• Dane wyjściowe i błędy testu są przechowywane w pliku test_log.DEBUG dla każdego testu zamiast w plikach test_name_stdout.txt i test_name_stderr.txt.
• Logcaty DUT i tabletu z każdego testu są przechowywane w katalogu /tmp/CameraITS_########, co upraszcza debugowanie, ponieważ wszystkie informacje wymagane do debugowania problemów z 3A są rejestrowane.

Testowanie zmian

W Androidzie 12 sceny na tablecie są plikami PNG, a nie PDF. Korzystanie z plików PNG umożliwia prawidłowe wyświetlanie scen na większej liczbie modeli tabletów.

scene0/test_jitter.py

Test test_jitter jest przeprowadzany na fizycznych ukrytych kamerach w Androidzie 12.

scene1_1/test_black_white.py

W Androidzie 12 test_black_white ma funkcje zarówno test_black_white, jak i test_channel_saturation.

W tabeli poniżej opisano 2 testy w Androidzie 11.

W tabeli poniżej opisano scalony test scene1_1/test_black_white.py w Androidzie 12.

scene1_1/test_burst_sameness_manual.py

Test test_burst_sameness_manual jest przeprowadzany na fizycznych ukrytych kamerach w Androidzie 12.

scene1_2/test_tonemap_sequence.py

Test test_tonemap_sequence jest wykonywany na ograniczonej liczbie aparatów w Androidzie 12.

scene1_2/test_yuv_plus_raw.py

Test test_yuv_plus_raw jest przeprowadzany na fizycznych ukrytych kamerach w Androidzie 12.

scene2_a/test_format_combos.py

Test test_format_combos jest wykonywany na ograniczonej liczbie aparatów w Androidzie 12.

scene3/test_flip_mirror.py

Test test_flip_mirror jest wykonywany na ograniczonej liczbie aparatów w Androidzie 12.

scene4/test_aspect_ratio_and_crop.py

W Androidzie 12 została zmieniona metoda znajdowania kręgów w scene4/test_aspect_ratio_and_crop.py.

W wcześniejszych wersjach Androida używano metody, która polegała na znalezieniu konturu podrzędnego (kółka) wewnątrz konturu nadrzędnego (kwadratu) za pomocą filtrów rozmiaru i koloru. Android 12 używa metody, która polega na znalezieniu wszystkich kontur, a następnie na filtrowaniu ich w celu znalezienia cech najbardziej zbliżonych do okręgu. Aby wyeliminować fałszywe koła na wyświetlaczu, wymagana jest minimalna powierzchnia konturu, a kontur koła musi być czarny.

Wyrażenia i ich kryteria wyboru są widoczne na ilustracji poniżej.

Rysunek 1. Rysunek koncepcyjny kontur i kryteriów wyboru

Metoda Androida 12 jest prostsza i rozwiązuje problem z przycinaniem ramki na niektórych tabletach z ekranem dotykowym. Wszystkie kręgi kandydujące są rejestrowane na potrzeby debugowania.

W Androidzie 12 test przycinania jest przeprowadzany na urządzeniach FULL i LEVEL3. W przypadku urządzeń FULL z Androidem 11 lub starszym pomiń stwierdzenia testu przycinania.

Tabela poniżej zawiera stwierdzenia dotyczące test_aspect_ratio_and_crop.py, które odpowiadają danemu poziomowi urządzenia i pierwszemu poziomowi interfejsu API.

scene4/test_multi_camera_alignment.py

Metoda undo_zoom() w przypadku rejestracji YUV w funkcji scene4/test_multi_camera_alignment.py została przebudowana, aby uwzględniać bardziej dokładne kadrowanie na czujnikach, które nie pasują do formatu obrazu.

Kod w języku Python 2 na Androida 11

zoom_ratio = min(1.0 * yuv_w / cr_w, 1.0 * yuv_h / cr_h)
circle[i]['x'] = cr['left'] + circle[i]['x'] / zoom_ratio
circle[i]['y'] = cr['top'] + circle[i]['y'] / zoom_ratio
circle[i]['r'] = circle[i]['r'] / zoom_ratio

Kod Python 3 na Androida 12

yuv_aspect = yuv_w / yuv_h
relative_aspect = yuv_aspect / (cr_w/cr_h)
if relative_aspect > 1:
  zoom_ratio = yuv_w / cr_w
  yuv_x = 0
  yuv_y = (cr_h - cr_w / yuv_aspect) / 2
else:
  zoom_ratio = yuv_h / cr_h
  yuv_x = (cr_w - cr_h * yuv_aspect) / 2
  yuv_y = 0
circle['x'] = cr['left'] + yuv_x + circle['x'] / zoom_ratio
circle['y'] = cr['top'] + yuv_y + circle['y'] / zoom_ratio
circle['r'] = circle['r'] / zoom_ratio

sensor_fusion/test_sensor_fusion.py

W Androidzie 12 do testu fuzji czujników dodano metodę wykrywania cech na zdjęciach.

W wersjach starszych niż Android 12 do znajdowania najlepszych 240 cech obrazu używany jest cały obraz, a następnie maskowane są 20% cech w środku, aby uniknąć efektu migawki. Minimalna liczba cech to 30.

Jeśli funkcje znalezione za pomocą tej metody są niewystarczające, Android 12 najpierw maskuje obszar wykrywania funkcji do 20%, a potem ogranicza maksymalne funkcje do podwojenia minimalnych wymagań funkcji.

Na ilustracji poniżej widać różnicę między wykrywaniem funkcji w Androidzie 11 a Androidzie 12. Podniesienie minimalnego progu wymagań funkcji powoduje wykrywanie funkcji o niskiej jakości i niekorzystnie wpływa na pomiary.

Rysunek 2. Różnica w wykrywania funkcji w Androidzie 11 i Androidzie 12

Nowe testy

scene0/test_solid_color_test_pattern.py

W przypadku Androida 12 włączono nowy test test_solid_color_test_pattern. Ten test jest włączony w przypadku wszystkich kamer i jest opisany w tabeli poniżej.

Aby obsługiwać tryb prywatności aparatu, musisz włączyć testowe wzory jednokolorowych. Test test_solid_color_test_pattern potwierdza, że wyjściowy obraz YUV ma jednolity kolor określony przez wybrany wzór, a kolor obrazu zmienia się zgodnie ze specyfikacją.

Parametry

• cameraPrivacyModeSupport: określa, czy kamera obsługuje tryb prywatności.
• android.sensor.testPatternMode: ustawia tryb wzoru testowego. W tym teście używany jest SOLID_COLOR.
• android.sensor.testPatternData: ustawia wartości wzorca testowego R, Gr, Gb, G w trybie wzorców testowych.

Opis jednolitego koloru w wzorze testowym znajdziesz w artykule SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Metoda

Ramki YUV są rejestrowane zgodnie z ustawionymi parametrami, a treści obrazu są weryfikowane. Wzór testowy jest generowany bezpośrednio z czujnika obrazu, więc nie jest wymagana żadna szczególna scena. Jeśli obsługiwana jest opcja PER_FRAME_CONTROL, dla każdego testowanego ustawienia jest rejestrowana pojedyncza ramka YUV. Jeśli PER_FRAME_CONTROL nie jest obsługiwana, rejestrowane są 4 ramki, z których analizowana jest tylko ostatnia, aby zmaksymalizować zasięg testu w przypadku kamer LIMITED.

Dane YUV są ustawione na w pełni nasycone wzorce testowe BLACK, WHITE, RED, GREEN i BLUE. Definicja testowego wzoru jest zgodna ze wzorem Bayera dla czujnika, więc kanały kolorów muszą być ustawione dla każdego koloru, jak pokazano w tabeli poniżej.

Tabela stwierdzeń

Tabela poniżej opisuje stwierdzenia testowe dotyczące test_solid_color_test_pattern.py.

Testy klasy wydajności

scene2_c/test_camera_launch_perf_class.py

Sprawdzanie, czy uruchamianie aparatu zajmuje mniej niż 500 ms w przypadku zarówno przedniego, jak i tylnego głównego aparatu w scenie twarzy scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Sprawdzanie, czy opóźnienie podczas rejestrowania zdjęć JPEG w rozdzielczości 1080p jest krótsze niż 1 sekunda w przypadku przedniej i tylnej kamery głównej w scenie z twarzą scene2_c.