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 należą do tych ogólnych kategorii:

• Refaktoryzacja do Pythona 3
• Wdrożenie platformy testowej Mobly
• Testowanie zmian
• Nowe testy

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:

• 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 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 testy wczytują swoje sceny. Chociaż wczytywanie sceny w przypadku każdego testu wydłuża ogólny czas testowania, umożliwia debugowanie poszczególnych testów.

Więcej informacji o poszczególnych zmianach w testach znajdziesz w artykule 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. ITS aparatu korzysta z infrastruktury testowej Mobly, aby umożliwić 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 ramach 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 testu 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

Platformę testową można wywołać za pomocą polecenia tools/run_all_tests.py. Jeśli nie ma wartości w wierszu 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.

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 platformy testowej 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ć testy za pomocą słowa kluczowego MANUAL w nazwie platformy. Platforma testowa nie może też 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 poszczególnych 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. 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_, w celu uniknięcia wątpliwości.
• 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.

Sprawdź zmiany

W Androidzie 12 sceny na tablety są plikami PNG, a nie 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 jest przeprowadzany na fizycznych ukrytych kamerach w Androidzie 12.

scene1_1/test_black_white.py

W przypadku Androida 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 przeprowadzany na OGRANICZONYCH aparatach 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 OGRANICZONYCH aparatach w Androidzie 12.

scene3/test_flip_mirror.py

Test test_flip_mirror jest przeprowadzany na OGRANICZONYCH aparatach w Androidzie 12.

scene4/test_aspect_ratio_and_crop.py

W Androidzie 12 zmieniono sposób znajdowania 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) w konturze nadrzędnym (kwadracie) 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 wyeliminować fałszywe okręgi na wyświetlaczu, wymagana jest minimalna powierzchnia konturu, a kontur okręgu musi być czarny.

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

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 w przypadku niektórych tabletów. 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.

scene4/test_multi_camera_alignment.py

Metoda undo_zoom() w przypadku przechwytywania YUV w scene4/test_multi_camera_alignment.py została zmodyfikowana, aby dokładniej uwzględniać przycinanie na czujnikach, których format obrazu nie odpowiada formatowi obrazu przechwytywania.

Kod w Pythonie 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 Androidzie 11 i starszych wersjach do znalezienia 240 najlepszych cech używany jest cały obraz, który jest następnie maskowany do środkowych 20% – ma to zapobiegać efektowi migawki rolowanej. Minimalna liczba cech to 30.

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

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

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

Nowe testy

scene0/test_solid_color_test_pattern.py

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

Aby obsługiwać tryb prywatności kamery, musisz 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 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. W tym teście używany jest format SOLID_COLOR.
• android.sensor.testPatternData: Ustawia wartości wzorca testowego R, Gr, Gb, G w trybie wzorca testowego.

Opis jednolitego wzorca kolorów 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 przez czujnik 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 zgodnie z tabelą poniżej.

Tabela asercji

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

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 scenie z twarzą scene2_c.

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.