Informacje o wersji pakietu Camera Image Test Suite dla systemu Android 12

W wersji Androida 12 uwzględniono szereg zmian w systemie Camera ITS . Na tej stronie podsumowano zmiany, które można podzielić na cztery szerokie kategorie:

Refaktoryzuj do Pythona 3

Ze względu na wycofanie języka Python 2.7 w styczniu 2020 r. cała baza kodu Camera ITS została przebudowana na język Python 3. W systemie Android 12 wymagane są następujące wersje i biblioteki języka Python:

Główny program uruchamiający testy, tools/run_all_tests.py , pozostaje taki sam jak wersje Androida 11 lub starsze i został przebudowany na Python 3.

Wszystkie indywidualne testy są refaktoryzowane i korzystają z nowej klasy konfiguracji testów zdefiniowanej w tests/its_base_test.py . Większość nazw testów i funkcjonalności pozostaje taka sama. W Androidzie 12 wszystkie indywidualne testy ładują teraz swoje sceny. Chociaż ładowanie sceny dla każdego testu zwiększa całkowity czas testu, umożliwia debugowanie poszczególnych testów.

Aby uzyskać więcej informacji na temat poszczególnych zmian w testach, zobacz Zmiany w testach .

Następujące moduły Pythona są refaktoryzowane ze zmianą nazwy:

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

Przyjęcie platformy testowej Mobly

Mobly to platforma testowa oparta na języku Python obsługująca przypadki testowe wymagające wielu urządzeń z niestandardową konfiguracją sprzętową. Camera ITS wykorzystuje infrastrukturę testową Mobly, aby umożliwić lepszą kontrolę i rejestrowanie testów.

Camera ITS wykorzystuje infrastrukturę testową Mobly, aby umożliwić lepszą kontrolę i rejestrowanie testów. Mobly to platforma testowa oparta na języku Python obsługująca przypadki testowe wymagające wielu urządzeń z niestandardową konfiguracją sprzętową. Więcej informacji na temat Mobly można znaleźć na stronie google/mobly .

pliki config.yml

Dzięki frameworkowi Mobly możesz skonfigurować testowane urządzenie (DUT) i tablet z wykresami w its_base_test . Do utworzenia środowiska testowego Mobly używany jest plik config.yml (YAML). W tym pliku konfiguracyjnym można skonfigurować wiele stanowisk testowych, na przykład tablet i stanowisko testowe do fuzji czujników. W sekcji kontrolera każdego środowiska testowego możesz określić device_ids , aby zidentyfikować odpowiednie urządzenia z systemem Android dla osoby przeprowadzającej test. Oprócz identyfikatorów urządzeń w klasie testowej przekazywane są inne parametry, takie jak brightness tabletu, chart_distance , debug_mode , camera_id i scene_id . Typowe wartości parametrów testowych 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 tabletach w nazwie stanowiska testowego musi znajdować się słowo kluczowe TABLET . Podczas inicjalizacji uruchamiający test Mobly inicjuje TestParams i przekazuje je do poszczególnych testów.

Poniżej znajduje się przykładowy plik config.yml dla komputerów stacjonarnych.

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ą tools/run_all_tests.py . Jeśli nie ma żadnych wartości wiersza poleceń, testy są uruchamiane z wartościami pliku config.yml . Dodatkowo możesz zastąpić wartości plików konfiguracyjnych camera i scene w wierszu poleceń, używając poleceń podobnych do 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 czujnika

W przypadku testów fuzji czujników nazwa stanowiska testowego musi zawierać słowo kluczowe SENSOR_FUSION . Prawidłowe stanowisko testowe zależy od testowanych scen. Android 12 obsługuje kontrolery Arduino i Canakit do łączenia czujników .

Poniżej znajduje się przykładowy plik config.yml dla przebiegó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 przeprowadzić testy zgrzewania czujnika za pomocą stanowiska do badania zgrzewania czujnika , użyj:

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

Wiele stanowisk testowych

W pliku konfiguracyjnym można uwzględnić wiele stanowisk testowych. Najczęstszą kombinacją jest posiadanie zarówno stanowiska testowego tabletu, jak i stanowiska testowego fuzji czujników.

Poniżej znajduje się przykładowy plik config.yml ze stanowiskami testowymi dla tabletów i 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

Testowanie ręczne

Testowanie ręczne jest nadal obsługiwane w systemie Android 12. Jednakże stanowisko testowe musi identyfikować testowanie jako takie za pomocą słowa kluczowego MANUAL w nazwie stanowiska testowego. Ponadto środowisko testowe nie może zawierać identyfikatora tabletu.

Poniżej znajduje się 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 wykonać za pomocą TEST_BED_TABLET_SCENES lub TEST_BED_MANUAL . Jeśli jednak testowanie zostanie przeprowadzone za pomocą TEST_BED_TABLET_SCENES , tablet musi być podłączony, a identyfikator seryjny tabletu musi być ważny, nawet jeśli tablet nie jest używany, ponieważ konfiguracja klasy testowej przypisuje wartość identyfikatora seryjnego tabletowi.

Przeprowadź indywidualne testy

Poszczególne testy można uruchamiać wyłącznie w celach debugowania, ponieważ ich wyniki nie są raportowane do CTS Verifier . Ponieważ plików config.yml nie można zastąpić w wierszu poleceń dla camera i scene , parametry te muszą być poprawne w pliku config.yml dla danego testu. Dodatkowo, jeśli w pliku konfiguracyjnym znajduje się więcej niż jedno stanowisko testowe, należy określić stanowisko testowe 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 systemie Android 12 artefakty testowe dla ITS aparatu są przechowywane podobnie jak w systemie Android 11 lub starszym, ale z następującymi zmianami:

  • Dla przejrzystości w katalogu artefaktu testowego /tmp CameraITS_ jest dodany do 8-znakowego losowego ciągu.
  • Dane wyjściowe testu i błędy są zapisywane w test_log.DEBUG dla każdego testu zamiast w test_name_stdout.txt i test_name_stderr.txt .
  • Logcats DUT i tabletu z każdego pojedynczego testu są przechowywane w katalogu /tmp/CameraITS_######## co upraszcza debugowanie, ponieważ rejestrowane są wszystkie informacje wymagane do debugowania problemów 3A.

Zmiany testowe

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

scene0/test_jitter.py

Test test_jitter działa na fizycznych ukrytych kamerach w systemie Android 12.

scena1_1/test_black_white.py

W systemie Android 12 test_black_white ma funkcjonalność zarówno test_black_white , jak i test_channel_saturation .

Poniższa tabela opisuje dwa indywidualne testy w systemie Android 11.

Nazwa testu Pierwszy poziom API Twierdzenia
scena1_1/test_black_white.py WSZYSTKO Krótka ekspozycja, niskie wartości RGB ~[0, 0, 0]
Długi czas ekspozycji, duże wzmocnienie Wartości RGB ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Zmniejszona tolerancja dla różnic [255, 255, 255] w celu wyeliminowania zabarwienia kolorów na białych obrazach.

W poniższej tabeli opisano połączony test scene1_1/test_black_white.py w systemie Android 12.

Nazwa testu Pierwszy poziom API Twierdzenia
scena1_1/test_black_white.py WSZYSTKO Krótka ekspozycja, niskie wartości RGB ~[0, 0, 0]
Długi czas naświetlania, wysokie wartości wzmocnienia RGB ~[255, 255, 255] i zmniejszona tolerancja między wartościami w celu wyeliminowania zabarwienia kolorów na białych obrazach.

scene1_1/test_burst_sameness_manual.py

Test test_burst_sameness_manual działa na fizycznych ukrytych kamerach w systemie Android 12.

scene1_2/test_tonemap_sequence.py

Test test_tonemap_sequence działa na OGRANICZONYCH kamerach w systemie Android 12.

scene1_2/test_yuv_plus_raw.py

Test test_yuv_plus_raw działa na fizycznych ukrytych kamerach w systemie Android 12.

scene2_a/test_format_combos.py

Test test_format_combos działa na aparatach LIMITED w systemie Android 12.

scene3/test_flip_mirror.py

Test test_flip_mirror działa na LIMITED aparatach w systemie Android 12.

scene4/test_aspect_ratio_and_crop.py

Znajdowanie kręgów w scene4/test_aspect_ratio_and_crop.py zostało przebudowane w Androidzie 12.

We wcześniejszych wersjach Androida zastosowano metodę polegającą na znajdowaniu konturu podrzędnego (okręgu) wewnątrz konturu nadrzędnego (kwadratu) za pomocą filtrów rozmiaru i koloru. Android 12 wykorzystuje metodę polegającą na znajdowaniu wszystkich konturów, a następnie filtrowaniu w poszukiwaniu cech, które są najbardziej okrągłe . Aby odsiać fałszywe okręgi na wyświetlaczu, wymagany jest minimalny obszar konturu, a kontur okręgu musi być czarny.

Kontury i kryteria ich wyboru pokazano na poniższym obrazku.

Rysunek koncepcyjny konturów i kryteria wyboru

Rysunek 1. Rysunek koncepcyjny konturów i kryteria wyboru

Metoda Androida 12 jest prostsza i rozwiązuje problem przycinania obwiedni na niektórych tabletach z wyświetlaczem. Wszyscy kandydaci z kręgu są rejestrowani w celu debugowania.

W systemie Android 12 test przycinania jest uruchamiany dla urządzeń FULL i LEVEL3 . Wersje Androida 11 lub starsze pomijają potwierdzenia testu przycinania dla urządzeń FULL .

W poniższej tabeli wymieniono twierdzenia dla test_aspect_ratio_and_crop.py , które odpowiadają danemu poziomowi urządzenia i pierwszemu poziomowi API.

Poziom urządzenia Pierwszy poziom API Twierdzenia
OGRANICZONY WSZYSTKO Proporcje
FoV dla formatów 4:3, 16:9, 2:1
PEŁNY < 31 Proporcje
FoV dla formatów 4:3, 16:9, 2:1
PEŁNY ≥ 31 Przyciąć
Proporcje
FoV dla formatów 4:3, 16:9, 2:1
POZIOM 3 WSZYSTKO Przyciąć
Proporcje
FoV dla formatów 4:3, 16:9, 2:1

scene4/test_multi_camera_alignment.py

Metoda undo_zoom() dla przechwytywania YUV w scene4/test_multi_camera_alignment.py została przebudowana, aby dokładniej uwzględnić kadrowanie na czujnikach, które nie pasują do proporcji przechwytywania.

Kod Androida 11 w Pythonie 2

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 Androida 12 w Pythonie 3

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 systemie Android 12 dodano metodę wykrywania cech na obrazach na potrzeby testu fuzji czujnika.

W wersjach starszych niż Android 12 cały obraz jest używany do znalezienia 240 najlepszych funkcji, które są następnie maskowane do 20% pośrodku, aby uniknąć efektu ruchomej migawki, przy czym minimalne wymagania dotyczące funkcji wynoszą 30 funkcji.

Jeśli funkcje znalezione tą metodą okażą się niewystarczające, Android 12 maskuje najpierw obszar wykrywania funkcji do środka o 20% i ogranicza maksymalną liczbę funkcji do dwukrotności minimalnych wymagań.

Poniższy obraz pokazuje różnicę między wykrywaniem funkcji w Androidzie 11 i Androidzie 12. Podniesienie minimalnego progu wymagań dotyczących cech powoduje wykrycie cech o niskiej jakości i negatywnie wpływa na pomiary.

różnica w wykrywaniu funkcji między Androidem 11 i Androidem 12 wykrywanie funkcji sensor_fusion

Rysunek 2. Różnica w wykrywaniu funkcji pomiędzy Androidem 11 i Androidem 12

Nowe testy

scene0/test_solid_color_test_pattern.py

Nowy test, test_solid_color_test_pattern , został włączony dla Androida 12. Ten test jest włączony dla wszystkich kamer i jest opisany w poniższej tabeli.

Scena Nazwa testu Pierwszy poziom API Opis
0 test_solid_color_test_pattern 31 Potwierdza wydruk obrazu w jednolitych kolorach i możliwość programowania kolorów obrazu.

Aby móc korzystać z trybu prywatności kamery, należy włączyć wzorce testowe w jednolitym kolorze. Test test_solid_color_test_pattern potwierdza wydruk obrazu YUV w jednolitym kolorze z kolorem zdefiniowanym przez wybrany wzór oraz zmiany kolorów obrazu zgodnie ze specyfikacją.

Parametry

  • cameraPrivacyModeSupport : Określa, czy kamera obsługuje tryb prywatności.
  • android.sensor.testPatternMode : Ustawia tryb wzorca testowego. W tym teście używany jest SOLID_COLOR .
  • android.sensor.testPatternData : Ustawia wartości wzorca testowego R, Gr, Gb, G dla trybu wzorca testowego.

Aby zapoznać się z opisem wzoru testowego jednolitego koloru, zobacz SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .

metoda

Ramki YUV są przechwytywane pod kątem ustawionych parametrów, a zawartość obrazu jest sprawdzana. Wzór testowy jest wysyłany bezpośrednio z czujnika obrazu, więc nie jest wymagana żadna konkretna scena. Jeśli obsługiwane jest PER_FRAME_CONTROL , dla każdego testowanego ustawienia przechwytywana jest pojedyncza ramka YUV. Jeśli PER_FRAME_CONTROL nie jest obsługiwany, przechwytywane są cztery klatki, a analizowana jest tylko ostatnia klatka, aby zmaksymalizować zasięg testu w LIMITED kamerach.

Przechwytywanie YUV jest ustawione na w pełni nasycone wzorce testowe BLACK , WHITE , RED , GREEN i BLUE . Ponieważ definicja wzoru testowego jest zgodna ze wzorem Bayera czujnika, kanały kolorów należy ustawić dla każdego koloru, jak pokazano w poniższej tabeli.

Kolor Dane wzorca testowego (RGGB)
CZARNY (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 twierdzeń

W poniższej tabeli opisano potwierdzenia testowe dla test_solid_color_test_pattern.py .

Kamera
Pierwszy poziom API
Typ aparatu Kolory potwierdzone
31 Bayera CZARNY, BIAŁY, CZERWONY, ZIELONY, NIEBIESKI
31 MONONUKLEOZA CZARNY BIAŁY
< 31 Bayera/MONO CZARNY

Testy klasy wydajności

scene2_c/test_camera_launch_perf_class.py

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

scene2_c/test_jpeg_capture_perf_class.py

Sprawdza, czy opóźnienie przechwytywania plików JPEG w rozdzielczości 1080p jest mniejsze niż 1 sekunda w przypadku przedniego i tylnego aparatu głównego ze sceną twarzy scene2_c.