Informacje o wersji Androida 12 Camera Image Test Suite

W wersji Androida 12 wprowadzono szereg zmian w Camera ITS. Ta strona zawiera podsumowanie zmian, które można podzielić na 4 główne kategorie:

Refaktoryzacja do Pythona 3

W styczniu 2020 r. język Python 2.7 został wycofany, dlatego cała baza kodu Camera ITS została refaktoryzowana do Pythona 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 Androidzie 11 lub starszym i został refaktoryzowany do Pythona 3.

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

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

Te moduły Pythona zostały refaktoryzowane ze zmianą 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

W platformie Mobly możesz skonfigurować testowane urządzenie (DUT) i tablet z wykresami w klasie its_base_test. Do utworzenia testbedu Mobly służy plik config.yml (YAML). W tym pliku konfiguracyjnym można skonfigurować wiele testbedów, np. tablet i testbed do testowania fuzji czujników. W sekcji kontrolera każdego testbedu możesz określić device_ids, aby zidentyfikować odpowiednie urządzenia z Androidem dla programu uruchamiającego testy. Oprócz identyfikatorów urządzeń w klasie testu przekazywane są inne parametry, takie jak brightness tabletu, chart_distance, debug_mode, camera_id i scene_id. Typowe wartości parametrów testu 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 testowania na tablecie w nazwie testbedu 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 do uruchamiania 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

Testbed można wywołać za pomocą tools/run_all_tests.py. Jeśli nie ma wartości w wierszu poleceń, testy są uruchamiane z wartościami z pliku config.yml. Dodatkowo możesz zastąpić wartości camera i scene w pliku konfiguracyjnym w wierszu poleceń za pomocą poleceń podobnych do tych w Androidzie 11 lub starszym.

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 testbedu musi zawierać słowo kluczowe SENSOR_FUSION. Prawidłowy testbed jest określany na podstawie testowanych scen. Android 12 obsługuje kontrolery Arduino i Canakit do fuzji czujników.

Poniżej znajdziesz przykładowy plik config.yml do uruchamiania 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:

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 konfiguracyjnym można uwzględnić wiele testbedów. Najczęstszym połączeniem jest używanie zarówno testbedu tabletu, jak i testbedu fuzji czujników.

Poniżej znajdziesz przykładowy plik config.yml z testbedami tabletu i fuzji czujników.

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

Testy ręczne są nadal obsługiwane w Androidzie 12. Testbed musi jednak identyfikować testy jako takie za pomocą słowa kluczowego MANUAL w nazwie testbedu. Testbed nie może też zawierać identyfikatora tabletu.

Poniżej znajdziesz przykładowy plik config.yml do testów ręcznych.

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

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

Sceny testowe 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 testu przypisuje wartość numeru seryjnego tabletu.

Uruchamianie poszczególnych testów

Poszczególne testy można uruchamiać tylko na potrzeby 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 dla danego testu. Jeśli w pliku konfiguracyjnym jest więcej niż 1 testbed, musisz też określić testbed za pomocą flagi --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 testowe Camera ITS są przechowywane podobnie jak w Androidzie 11 lub starszym, ale z tymi zmianami:

  • Dla przejrzystości do losowego ciągu 8 znaków w katalogu artefaktów testowych /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.
  • Logi DUT i tabletu z każdego testu są przechowywane w katalogu /tmp/CameraITS_########, co upraszcza debugowanie, ponieważ rejestrowane są wszystkie informacje potrzebne do debugowania problemów z 3A.

Zmiany w testach

W Androidzie 12 sceny tabletu 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 uruchamiany w Androidzie 12 na fizycznych ukrytych kamerach.

scene1_1/test_black_white.py

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

W tabeli poniżej opisano 2 poszczególne 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 [255, 255, 255], aby wyeliminować odcień koloru 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ótka ekspozycja, niskie wzmocnienie, wartości RGB ~[0, 0, 0]
Długa ekspozycja, 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 uruchamiany w Androidzie 12 na fizycznych ukrytych kamerach.

scene1_2/test_tonemap_sequence.py

Test test_tonemap_sequence jest uruchamiany w Androidzie 12 na kamerach z ograniczonymi funkcjami.

scene1_2/test_yuv_plus_raw.py

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

scene2_a/test_format_combos.py

Test test_format_combos jest uruchamiany w Androidzie 12 na kamerach z ograniczonymi funkcjami.

scene3/test_flip_mirror.py

Test test_flip_mirror jest uruchamiany w Androidzie 12 na kamerach z ograniczonymi funkcjami.

scene4/test_aspect_ratio_and_crop.py

W Androidzie 12 refaktoryzowano wyszukiwanie okręgów w scene4/test_aspect_ratio_and_crop.py.

W starszych wersjach Androida używano metody, która polegała na znajdowaniu konturu podrzędnego (okręgu) w konturze nadrzędnym (kwadracie) za pomocą filtrów rozmiaru i koloru. Android 12 używa metody, która polega na znajdowaniu wszystkich konturów, a następnie filtrowaniu ich przez wyszukiwanie cech, które są najbardziej okrągłe. Aby wyeliminować fałszywe okręgi na wyświetlaczu, wymagana jest minimalna powierzchnia konturu, a kontur okręgu musi być czarny.

Kontury i ich kryteria 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 Androida 12 jest prostsza i rozwiązuje problem z przycinaniem ramki ograniczającej na niektórych tabletach z wyświetlaczem. Wszystkie kandydaty na okręgi są rejestrowane na potrzeby debugowania.

W Androidzie 12 test przycinania jest uruchamiany na urządzeniach z poziomem FULL i LEVEL3. W Androidzie 11 lub starszym asercje testu przycinania są pomijane w przypadku urządzeń z poziomem FULL.

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 Format obrazu
Pole widzenia w formatach 4:3, 16:9, 2:1
FULL < 31 Format obrazu
Pole widzenia w formatach 4:3, 16:9, 2:1
FULL ≥ 31 Przycinanie
Format obrazu
Pole widzenia w formatach 4:3, 16:9, 2:1
LEVEL3 WSZYSTKO Przycinanie
Format obrazu
Pole widzenia w formatach 4:3, 16:9, 2:1

scene4/test_multi_camera_alignment.py

Metoda undo_zoom() do przechwytywania YUV w scene4/test_multi_camera_alignment.py została refaktoryzowana, aby dokładniej uwzględniać przycinanie na czujnikach, które nie pasują do formatu obrazu przechwytywania.

Kod Pythona 2 w Androidzie 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 Pythona 3 w Androidzie 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 obrazach.

W wersjach starszych niż Android 12 do znalezienia najlepszych 240 cech używany jest cały obraz, który jest następnie maskowany do środkowych 20%, aby uniknąć efektów migawki szczelinowej. Minimalna liczba cech to 30.

Jeśli cechy znalezione tą metodą są niewystarczające, Android 12 maskuje obszar wykrywania cech do środkowych 20% i ogranicza maksymalną liczbę cech do dwukrotności minimalnej liczby cech.

Ilustracja poniżej przedstawia różnicę między wykrywaniem cech w Androidzie 11 a Androidzie 12. Zwiększenie progu minimalnej liczby cech powoduje wykrywanie cech 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óżnica w wykrywaniu cech między Androidem 11 a Androidem 12

Nowe testy

scene0/test_solid_color_test_pattern.py

W Androidzie 12 włączono nowy test, test_solid_color_test_pattern. Ten test jest włączony dla wszystkich kamer i został 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 programowalność koloru obrazu.

Aby obsługiwać tryb prywatności kamery, należy włączyć wzorce testowe w jednolitym kolorze. Test test_solid_color_test_pattern potwierdza wyjście obrazu YUV w jednolitym kolorze z kolorem zdefiniowanym przez wybrany wzorzec 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 używa SOLID_COLOR.
  • android.sensor.testPatternData: ustawia wartości wzorca testowego R, Gr, Gb, G dla trybu wzorca testowego.

Opis wzorca testowego w jednolitym kolorze znajdziesz w sekcji SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Metoda

Przechwytywane są klatki YUV dla ustawionych parametrów i sprawdzana jest zawartość obrazu. Wzorzec testowy jest generowany bezpośrednio z czujnika obrazu, więc nie jest wymagana żadna konkretna scena. Jeśli obsługiwana jest funkcja PER_FRAME_CONTROL, dla każdego testowanego ustawienia przechwytywana jest pojedyncza klatka YUV. Jeśli PER_FRAME_CONTROL nie jest obsługiwana, przechwytywane są 4 klatki, a analizowana jest tylko ostatnia klatka, aby zmaksymalizować pokrycie testu w LIMITED kamerach.

Przechwytywanie YUV jest ustawione na w pełni nasycone wzorce testowe BLACK, WHITE, RED, GREEN i BLUE. Ponieważ definicja wzorca testowego jest zgodna ze wzorcem Bayera czujnika, kanały kolorów muszą być ustawione dla każdego koloru zgodnie z tabelą poniżej.

Kolor testPatternData (RGGB)
CZARNE (0, 0, 0, 0)
BIAŁY (1, 1, 1, 1)
CZERWONY (1, 0, 0, 0)
ZIELONY (0, 1, 1, 0)
NIEBIESKI (0, 0, 0, 1)

Tabela asercji

W tabeli poniżej opisano asercje testu test_solid_color_test_pattern.py.

Kamera
Pierwszy poziom interfejsu API		 Typ kamery Asercje kolorów
31 Bayer CZARNY, BIAŁY, CZERWONY, ZIELONY, NIEBIESKI
31 MONOCHROMATYCZNY CZARNY, BIAŁY
< 31 Bayer/MONOCHROMATYCZNY CZARNY

Testy klasy wydajności

scene2_c/test_camera_launch_perf_class.py

Sprawdza, czy czas uruchamiania kamery jest krótszy niż 500 ms w przypadku przedniej i tylnej kamery głównej ze sceną twarzy scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Sprawdza, czy opóźnienie przechwytywania JPEG w rozdzielczości 1080p jest krótsze niż 1 sekunda w przypadku przedniej i tylnej kamery głównej ze sceną twarzy scene2_c.