Informacje o wersji pakietu Android 12 Camera Image Test Suite

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W wersji Androida 12 uwzględniono wiele zmian dotyczących aparatu ITS . Ta strona podsumowuje zmiany, które dzielą się na cztery szerokie kategorie:

Refaktoryzacja do Pythona 3

Ze względu na wycofanie Pythona 2.7 w styczniu 2020 r., cała baza kodu Camera ITS została zrefaktoryzowana do Pythona 3. Następujące wersje i biblioteki Pythona są wymagane w systemie Android 12:

Główny program uruchamiający testy, tools/run_all_tests.py , pozostaje taki sam jak w wersjach Androida 11 lub niższych i został zrefaktoryzowany do Pythona 3.

Wszystkie indywidualne testy są refaktoryzowane i korzystają z nowej klasy konfiguracji testów zdefiniowanej w tests/its_base_test.py . Większość nazw i funkcji testów pozostaje taka sama. W Androidzie 12 wszystkie poszczególne testy ładują teraz swoje sceny. Ładowanie scen dla każdego testu wydłuża ogólny czas testu, ale umożliwia debugowanie poszczególnych testów.

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

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 frameworka do testów mobilnych

Mobly to oparta na Pythonie platforma testowa obsługująca przypadki testowe, które wymagają wielu urządzeń z niestandardową konfiguracją sprzętu. 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 oparta na Pythonie platforma testowa obsługująca przypadki testowe, które wymagają wielu urządzeń z niestandardową konfiguracją sprzętu. Więcej informacji o Mobly znajdziesz na google/mobly .

config.yml pliki

Dzięki frameworkowi Mobly możesz skonfigurować testowane urządzenie (DUT) i tablet z wykresami w klasie its_base_test . Plik config.yml (YAML) służy do tworzenia środowiska testowego Mobly. W tym pliku konfiguracyjnym można skonfigurować wiele stanowisk testowych, na przykład tablet i stanowisko testowe łączenia czujników. W sekcji kontrolera każdego stanowiska testowego można określić device_ids urządzeń, aby zidentyfikować odpowiednie urządzenia z systemem Android dla programu uruchamiającego testy. Oprócz identyfikatorów urządzeń w klasie testowej są przekazywane 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 tabletach

W przypadku testowania na tablecie słowo kluczowe TABLET musi znajdować się w nazwie stanowiska testowego. Podczas inicjalizacji program uruchamiający testy Mobly inicjuje TestParams i przekazuje je do poszczególnych testów.

Poniżej znajduje się przykładowy plik config.yml do uruchamiania 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 żadnych wartości wiersza poleceń, testy są uruchamiane z wartościami pliku config.yml . Dodatkowo możesz nadpisać wartości pliku konfiguracyjnego camera i scene w wierszu poleceń za pomocą poleceń podobnych do systemu Android 11 lub niższego.

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 połączenia czujników nazwa stanowiska testowego musi zawierać słowo kluczowe SENSOR_FUSION . Prawidłowe stanowisko testowe zależy od przetestowanych scen. Android 12 obsługuje zarówno kontrolery Arduino, jak i Canakit do fuzji czujników .

Poniżej znajduje się przykładowy plik config.yml dla przebiegów łączenia 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 łączenia czujników za pomocą stanowiska testowego do łączenia 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 stanowisk testowych

W pliku konfiguracyjnym można umieścić wiele środowisk testowych. Najczęstszą kombinacją jest posiadanie zarówno stanowiska do testowania tabletów, jak i stanowiska do testowania fuzji czujników.

Poniżej znajduje się przykładowy plik config.yml zawierający stanowiska testowe do łączenia 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 stanowisko testowe musi identyfikować testowanie jako takie za pomocą słowa kluczowego MANUAL w nazwie stanowiska testowego. Ponadto platforma testowa nie może zawierać identyfikatora tabletu.

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

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 wykonać za pomocą TEST_BED_TABLET_SCENES lub TEST_BED_MANUAL . Jeśli jednak testowanie jest wykonywane z TEST_BED_TABLET_SCENES , tablet musi być podłączony, a identyfikator seryjny tabletu musi być prawidłowy, nawet jeśli tablet nie jest używany, ponieważ konfiguracja klasy testowej przypisuje wartość identyfikatora szeregowego tabletu.

Przeprowadzanie testów indywidualnych

Poszczególne testy można uruchamiać tylko do celów debugowania, ponieważ ich wyniki nie są zgłaszane do weryfikatora CTS . Ponieważ plików config.yml nie można nadpisać w wierszu poleceń 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 z flagą --test_bed . Na przykład:

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

Testuj artefakty

W systemie Android 12 artefakty testowe dla Camera ITS są przechowywane podobnie do systemu Android 11 lub starszego, ale z następującymi zmianami:

  • W katalogu artefaktu testowego /tmp przed 8-znakowym ciągiem losowym jest poprzedzony CameraITS_ , aby zapewnić przejrzystość.
  • Wyniki testów i błędy są przechowywane w test_log.DEBUG dla każdego testu zamiast test_name_stdout.txt i test_name_stderr.txt .
  • Logcats DUT i tabletu z każdego indywidualnego testu są przechowywane w katalogu /tmp/CameraITS_######## , co upraszcza debugowanie, ponieważ wszystkie informacje wymagane do debugowania problemów 3A są rejestrowane.

Testuj zmiany

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

scene0/test_jitter.py

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

scene1_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 Asercje
scene1_1/test_black_white.py WSZYSTKO Krótka ekspozycja, niskie wzmocnienie wartości RGB ~[0, 0, 0]
Długa ekspozycja, wysokie wartości RGB ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Zmniejszona tolerancja dla różnic [255, 255, 255] w celu wyeliminowania odcieni kolorów na białych obrazach.

Poniższa tabela opisuje scalony test scene1_1/test_black_white.py w systemie Android 12.

Nazwa testu Pierwszy poziom API Asercje
scene1_1/test_black_white.py WSZYSTKO Krótka ekspozycja, niskie wzmocnienie wartości RGB ~[0, 0, 0]
Długa ekspozycja, wysokie wartości RGB o wysokim wzmocnieniu ~[255, 255, 255] i zmniejszona tolerancja między wartościami w celu wyeliminowania odcieni koloru 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 LIMITOWANYCH 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 LIMITOWANYCH kamerach w systemie Android 12.

scena3/test_flip_mirror.py

Test test_flip_mirror działa na LIMITOWANYCH kamerach 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 zrefaktoryzowane w Androidzie 12.

Wcześniejsze wersje Androida wykorzystywały metodę, która polegała na znalezieniu konturu podrzędnego (koła) wewnątrz konturu nadrzędnego (kwadracie) z filtrami rozmiaru i koloru. Android 12 korzysta z metody, która polega na znalezieniu wszystkich konturów, a następnie filtrowaniu według najbardziej kolistych funkcji . W celu odseparowania fałszywych okręgów na wyświetlaczu wymagana jest minimalna powierzchnia konturu, a kontur okręgu musi być czarny.

Kontury i kryteria ich wyboru są pokazane na poniższym obrazku.

Koncepcyjny rysunek konturów i kryteriów wyboru

Rysunek 1. Koncepcyjny rysunek konturów i kryteria wyboru

Metoda Androida 12 jest prostsza i działa w celu rozwiązania problemu z obcinaniem pola ograniczającego w niektórych tabletach z wyświetlaczem. Wszyscy kandydaci do kręgów są rejestrowani w celach debugowania.

W systemie Android 12 test upraw jest uruchamiany dla urządzeń FULL i LEVEL3 . Wersje Androida 11 lub starsze pomijają asercje testów upraw dla FULL urządzeń.

W poniższej tabeli wymieniono 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 API Asercje
OGRANICZONY WSZYSTKO Współczynnik proporcji
FoV dla formatów 4:3, 16:9, 2:1
PEŁNY < 31 Współczynnik proporcji
FoV dla formatów 4:3, 16:9, 2:1
PEŁNY ≥ 31 Przyciąć
Współczynnik proporcji
FoV dla formatów 4:3, 16:9, 2:1
POZIOM 3 WSZYSTKO Przyciąć
Współczynnik proporcji
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 zrefaktoryzowana, aby dokładniej uwzględnić kadrowanie na czujnikach, które nie pasują do współczynnika proporcji przechwytywania.

Kod Androida 11 Python 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 Python 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 do testu fuzji czujników dodano metodę wykrywania funkcji w obrazach.

W wersjach niższych niż Android 12 cały obraz jest używany do znalezienia najlepszych 240 funkcji, które są następnie maskowane do środka 20%, aby uniknąć efektów „rolling shutter”, przy czym minimalnym wymaganiem funkcji jest 30 funkcji.

Jeśli funkcje znalezione tą metodą są niewystarczające, system Android 12 najpierw maskuje obszar wykrywania funkcji do centrum 20% i ogranicza maksymalne funkcje do dwukrotności minimalnego wymagania funkcji.

Poniższy obraz przedstawia różnicę między wykrywaniem funkcji systemu Android 11 i Android 12. Podniesienie minimalnego progu wymagań dotyczących cech skutkuje wykryciem 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 między Androidem 11 a Androidem 12

Nowe testy

scene0/test_solid_color_test_pattern.py

Nowy test, test_solid_color_test_pattern , jest włączony dla systemu Android 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 wyjście obrazu w jednolitym kolorze i programowalność koloru obrazu.

Aby obsługiwać tryb prywatności kamery, należy włączyć jednolite wzory testowe. Test test_solid_color_test_pattern potwierdza jednolity kolor obrazu YUV w kolorze zdefiniowanym 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 wzorca testowego. Ten test używa SOLID_COLOR .
  • android.sensor.testPatternData : Ustawia wartości wzorca testowego R, Gr, Gb, G dla trybu wzorca testowego.

Aby uzyskać opis wzoru testowego jednolitego koloru, zobacz SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .

metoda

Ramki YUV są przechwytywane dla ustawionych parametrów, a zawartość obrazu jest weryfikowana. Wzór testowy jest wyprowadzany bezpośrednio z przetwornika obrazu, więc nie jest wymagana żadna konkretna scena. Jeśli PER_FRAME_CONTROL jest obsługiwane, pojedyncza ramka YUV jest przechwytywana dla każdego testowanego ustawienia. Jeśli PER_FRAME_CONTROL nie jest obsługiwana, przechwytywane są cztery klatki, przy czym analizowana jest tylko ostatnia klatka, aby zmaksymalizować pokrycie testowe w kamerach LIMITED .

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 czujnika Bayer, kanały kolorów muszą być ustawione dla każdego koloru, jak pokazano w poniższej tabeli.

Kolor testPatternData (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 asercji

W poniższej tabeli opisano potwierdzenia testów dla test_solid_color_test_pattern.py .

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

Testy klasy wydajności

scene2_c/test_camera_launch_perf_class.py

Sprawdza, czy uruchomienie kamery trwa krócej niż 500 ms zarówno w przypadku przedniej, jak 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 mniejsze niż 1 sekunda zarówno dla przedniej, jak i tylnej kamery głównej ze sceną twarzy scene2_c.