Informacje o wersji Androida 12 Camera Image Test Suite

W Androidzie 12 wprowadzono szereg zmian w Camera ITS. Na tej stronie znajdziesz podsumowanie zmian, które dzielą się na 4 szerokie kategorie:

Refaktoryzacja do Pythona 3

W styczniu 2020 r. język Python 2.7 został wycofany, dlatego cały kod Camera ITS został przekształcony na język Python 3. W Androidzie 12 wymagane są te wersje Pythona i biblioteki:

Główny program uruchamiający testy, tools/run_all_tests.py, pozostaje taki sam jak w przypadku Androida 11 i starszych wersji. Został on przekształcony w Pythona 3.

Wszystkie testy indywidualne zostały zmodyfikowane i korzystają z nowej klasy konfiguracji testu zdefiniowanej w tests/its_base_test.py. Większość nazw testów i funkcji pozostanie bez zmian. W Androidzie 12 wszystkie poszczególne testy wczytują teraz swoje sceny. Wczytywanie sceny w przypadku każdego testu wydłuża ogólny czas testu, ale umożliwia debugowanie poszczególnych testów.

Więcej informacji o poszczególnych zmianach w testach znajdziesz w sekcji Zmiany w testach.

Te moduły Pythona zostały zmodyfikowane 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 platformy testowej Mobly

Mobly to platforma testowa oparta na Pythonie, która obsługuje przypadki testowe wymagające wielu urządzeń z niestandardowymi konfiguracjami sprzętowymi. Camera ITS korzysta z infrastruktury testowej Mobly, aby zapewnić lepszą kontrolę i rejestrowanie testów.

Camera ITS korzysta z infrastruktury testowej Mobly, aby zapewnić lepszą kontrolę i rejestrowanie testów. Mobly to platforma testowa oparta na Pythonie, która obsługuje przypadki testowe wymagające wielu urządzeń z niestandardowymi konfiguracjami sprzętowymi. Więcej informacji o Mobly znajdziesz na stronie google/mobly.

pliki config.yml,

Za pomocą platformy Mobly możesz skonfigurować testowane urządzenie (DUT) i tablet z wykresem w klasie its_base_test. Do utworzenia platformy testowej Mobly służy plik config.yml (YAML). W tym pliku konfiguracyjnym można skonfigurować wiele platform testowych, np. platformę testową tabletu i platformę testową fuzji czujników. W sekcji kontrolera każdego środowiska testowego możesz określić device_ids, aby wskazać odpowiednie urządzenia z Androidem dla narzędzia do uruchamiania testów. Oprócz identyfikatorów urządzeń w klasie testowej przekazywane są inne parametry, takie jak tablet brightness, chart_distance, debug_mode, camera_id i scene_id. Typowe wartości parametru testowego 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 tabletach

W przypadku testów na tabletach w nazwie platformy testowej musi występować słowo kluczowe TABLET. Podczas inicjowania program uruchamiający testy Mobly inicjuje TestParams i przekazuje je do poszczególnych testów.

Poniżej znajdziesz przykładowy plik config.yml dla testów na tabletach.

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

Środowisko testowe można wywołać za pomocą polecenia tools/run_all_tests.py. Jeśli nie ma wartości wiersza poleceń, testy są przeprowadzane z wartościami z pliku config.yml. Dodatkowo możesz zastąpić wartości plików konfiguracyjnych camera i scene w wierszu poleceń za pomocą poleceń podobnych do tych z Androida 11 lub starszego.

Na 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 czujników

W przypadku testowania fuzji czujników nazwa stanowiska testowego musi zawierać słowo kluczowe SENSOR_FUSION. Odpowiednie środowisko testowe jest określane na podstawie testowanych scen. Android 12 obsługuje zarówno kontrolery Arduino, jak i Canakitdo fuzji czujników.

Poniżej znajdziesz przykładowy plik config.yml dla testów fuzji 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 uruchomić testy fuzji czujników za pomocą platformy testowej fuzji czujników, użyj tego polecenia:

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

Wiele platform testowych

Plik konfiguracji może zawierać wiele platform testowych. Najczęstszym rozwiązaniem jest posiadanie zarówno platformy testowej tabletu, jak i platformy testowej fuzji czujników.

Poniżej znajdziesz przykładowy plik config.yml z platformami testowymi zarówno na tablety, jak i na czujniki.

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. Platforma testowa musi jednak oznaczać testowanie za pomocą słowa kluczowego MANUAL w nazwie. Dodatkowo platforma testowa nie może zawierać identyfikatora tabletu.

Poniżej znajdziesz 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ą TEST_BED_TABLET_SCENES, tablet musi być podłączony, a jego numer seryjny musi być prawidłowy, nawet jeśli tablet nie jest używany, ponieważ konfiguracja klasy testowej przypisuje wartość numeru seryjnego do tabletu.

Przeprowadzanie pojedynczych testów

Poszczególne testy można uruchamiać tylko w celach debugowania, ponieważ ich wyniki nie są zgłaszane do CTS Verifier. Ponieważ plików config.yml nie można zastąpić w wierszu poleceń w przypadku camera i scene, te parametry muszą być prawidłowe w pliku config.yml w przypadku danego testu. Jeśli w pliku konfiguracyjnym jest więcej niż 1 platforma testowa, musisz określić platformę testową za pomocą flagi --test_bed. Na 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 testowe ITS aparatu są przechowywane podobnie jak w Androidzie 11 lub starszym, ale z tymi zmianami:

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

Testowanie zmian

W Androidzie 12 sceny na tablety są plikami PNG, a nie PDF. Używanie 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 przypadku Androida 12 symbol test_black_white ma funkcje symboli test_black_white i test_channel_saturation.

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

Nazwa testu Pierwszy poziom interfejsu API Asercje
scene1_1/test_black_white.py WSZYSTKO Krótka ekspozycja, niskie wzmocnienie, wartości RGB ~[0, 0, 0]
Długa ekspozycja, wysokie wzmocnienie, wartości RGB ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Zmniejszona tolerancja różnic w przypadku wartości [255, 255, 255], aby wyeliminować zabarwienie kolorów na białych obrazach.

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

Nazwa testu Pierwszy poziom interfejsu API Asercje
scene1_1/test_black_white.py WSZYSTKO Krótki czas ekspozycji, niskie wzmocnienie, wartości RGB ~[0, 0, 0]
Długi czas ekspozycji, wysokie wzmocnienie, wartości RGB ~[255, 255, 255] i zmniejszona tolerancja między wartościami, aby wyeliminować odcień koloru na białych obrazach.

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 przeprowadzany 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 przeprowadzany na OGRANICZONEJ liczbie aparatów w Androidzie 12.

scene3/test_flip_mirror.py

Test test_flip_mirror jest przeprowadzany na OGRANICZONEJ liczbie aparatów w Androidzie 12.

scene4/test_aspect_ratio_and_crop.py

W Androidzie 12 zmieniono sposób wyszukiwania okręgów w scene4/test_aspect_ratio_and_crop.py.

W starszych wersjach Androida stosowano metodę polegającą na znajdowaniu konturu podrzędnego (koła) wewnątrz konturu nadrzędnego (kwadratu) za pomocą filtrów rozmiaru i koloru. Android 12 korzysta z metody, która polega na znajdowaniu wszystkich konturów, a następnie filtrowaniu ich na podstawie cech, które są najbardziej okrągłe. Aby odfiltrować fałszywe okręgi na wyświetlaczu, wymagany jest minimalny obszar konturu, a kontur okręgu musi być czarny.

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

Rysunek koncepcyjny konturów i kryteriów wyboru

Rysunek 1. Rysunek koncepcyjny konturów i kryteriów wyboru

Metoda z Androida 12 jest prostsza i pomaga rozwiązać problem z przycinaniem ramki ograniczającej na niektórych tabletach. Wszystkie kandydatury do okręgu są rejestrowane na potrzeby debugowania.

W Androidzie 12 test przycinania jest przeprowadzany na urządzeniach FULL i LEVEL3. W przypadku urządzeń FULL Android w wersji 11 lub starszej pomija testy przycinania.

W tabeli poniżej znajdziesz asercje dla test_aspect_ratio_and_crop.py, które odpowiadają danemu poziomowi urządzenia i pierwszemu poziomowi interfejsu API.

Poziom urządzenia Pierwszy poziom interfejsu API Asercje
LIMITED WSZYSTKO Współczynnik proporcji
Pole widzenia w przypadku formatów 4:3, 16:9 i 2:1
PEŁNY ODCINEK < 31 Współczynnik proporcji
Pole widzenia w przypadku formatów 4:3, 16:9 i 2:1
PEŁNY ODCINEK ≥ 31 Kadrowanie
Format obrazu
Pole widzenia dla formatów 4:3, 16:9 i 2:1
POZIOM 3 WSZYSTKO Kadrowanie
Format obrazu
Pole widzenia dla formatów 4:3, 16:9 i 2:1

scene4/test_multi_camera_alignment.py

Metoda undo_zoom() w przypadku rejestrowania obrazu w formacie YUV w scene4/test_multi_camera_alignment.py została zmodyfikowana, aby dokładniej uwzględniać przycinanie na sensorach, których proporcje obrazu nie są zgodne z proporcjami rejestrowanego 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 w Pythonie 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 dodano metodę wykrywania cech na obrazach na potrzeby testu fuzji czujników.

W wersjach starszych niż Android 12 do znalezienia 240 najlepszych cech, które są następnie maskowane do 20% środkowej części, aby uniknąć efektu migawki rolowanej, używany jest cały obraz. Minimalna liczba cech to 30.

Jeśli funkcje znalezione tą metodą są niewystarczające, Android 12 najpierw maskuje obszar wykrywania funkcji do 20% środka i ogranicza maksymalną liczbę funkcji do dwukrotności minimalnego wymagania dotyczącego funkcji.

Obraz poniżej pokazuje różnicę między wykrywaniem funkcji w Androidzie 11 a Androidzie 12. Podniesienie minimalnego progu wymagań dotyczących funkcji powoduje wykrywanie funkcji o niskiej jakości i negatywnie wpływa na pomiary.

różnica w wykrywaniu funkcji między Androidem 11 a Androidem 12 wykrywanie funkcji fuzji czujników

Rysunek 2. Różnice w wykrywaniu funkcji między Androidem 11 a Androidem 12

Nowe testy

scene0/test_solid_color_test_pattern.py

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

Scena Nazwa testu Pierwszy poziom interfejsu API Opis
0 test_solid_color_test_pattern 31 Potwierdza wyjście obrazu w jednolitym kolorze i możliwość programowania koloru obrazu.

Aby obsługiwać tryb prywatności kamery, musisz włączyć jednolite wzorce testowe kolorów. Test test_solid_color_test_pattern potwierdza wyjście obrazu YUV w jednolitym kolorze z kolorem zdefiniowanym przez wybrany wzór oraz zmiany koloru obrazu zgodnie ze specyfikacją.

Parametry

  • cameraPrivacyModeSupport: określa, czy kamera obsługuje tryb prywatności.
  • android.sensor.testPatternMode: ustawia tryb wzorca testowego. Ten test korzysta z SOLID_COLOR.
  • android.sensor.testPatternData: Ustawia wartości wzorca testowego R, Gr, Gb, G dla trybu wzorca testowego.

Opis jednolitego wzorca testowego znajdziesz w SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Metoda

Klatki YUV są przechwytywane dla ustawionych parametrów, a treść obrazu jest weryfikowana. Wzorzec testowy jest generowany bezpośrednio z czujnika obrazu, więc nie jest wymagana żadna konkretna scena. Jeśli PER_FRAME_CONTROL jest obsługiwane, dla każdego testowanego ustawienia rejestrowana jest pojedyncza ramka YUV. Jeśli format PER_FRAME_CONTROL nie jest obsługiwany, rejestrowane są 4 klatki, a analizowana jest tylko ostatnia z nich, aby zmaksymalizować pokrycie testu w przypadku kamer LIMITED.

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

Kolor testPatternData (RGGB)
CZARNE (0, 0, 0, 0)
BIAŁE (1, 1, 1, 1)
dyrektywa w sprawie urządzeń radiowych (1, 0, 0, 0)
ZIELONY (0, 1, 1, 0)
NIEBIESKI (0, 0, 0, 1)

Tabela asercji

W tabeli poniżej znajdziesz asercje testowe dla elementu test_solid_color_test_pattern.py.

Aparat
Pierwszy poziom interfejsu API		 Typ kamery Kolory
31 Bayer CZARNY, BIAŁY, CZERWONY, ZIELONY, NIEBIESKI
31 MONO CZARNY, BIAŁY
< 31 Bayer/MONO CZARNE

Testy klasy wydajności

scene2_c/test_camera_launch_perf_class.py

Sprawdza, czy uruchomienie aparatu trwa mniej niż 500 ms w przypadku przedniego i tylnego aparatu głównego w scenie2_c z twarzą.

scene2_c/test_jpeg_capture_perf_class.py

Sprawdza, czy opóźnienie rejestrowania zdjęć JPEG w rozdzielczości 1080p jest mniejsze niż 1 sekunda w przypadku przedniego i tylnego aparatu głównego w scenie z twarzą scene2_c.