Informacje o wersji Androida 12 Camera Image Test Suite

W wersji Androida 12 uwzględniono wiele zmian w ITS aparatu. Na tej stronie znajduje się podsumowanie zmian, które dzielą się na 4 ogólne kategorie:

• Refaktoryzacja na Python 3
• Wdrożenie frameworku testów Mobly
• Testowanie zmian
• Nowe testy

Przerzuć na Pythona 3

W związku z wycofaniem języka Python 2.7 w styczniu 2020 r. cały kod źródłowy ITS aparatu został przekształcony na język Python 3. W Androidzie 12 wymagane są te wersje i biblioteki Pythona:

• 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
• Poduszka 8.1.0
• PyYAML 5.3.1

Główny program testowy, tools/run_all_tests.py, pozostaje taki sam jak w wersjach Androida 11 i starszych. Został on przebudowany na potrzeby Pythona 3.

Wszystkie pojedyncze testy są refaktoryzowane i używają nowej klasy konfiguracji testu zdefiniowanej w zasadzie tests/its_base_test.py. Większość nazw i funkcji testów pozostaje bez zmian. W Androidzie 12 wszystkie pojedyncze testy wczytują swoje sceny. Ładowanie sceny dla każdego testu zwiększa ogólny czas testowania, ale umożliwia debugowanie poszczególnych testów.

Więcej informacji o poszczególnych zmianach testów znajdziesz w artykule Zmiany testów.

Te moduły Pythona zostały poddane refaktoryzacji 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

Wdrażanie testowego frameworka Mobly

Mobly to platforma testowa o zasadzie działania opartym na Pythonie, która obsługuje przypadki testowe wymagające wielu urządzeń z niestandardową konfiguracją sprzętową. Camera ITS korzysta z infrastruktury testowej Mobly, aby umożliwić lepszą kontrolę i rejestrowanie testów.

Camera ITS korzysta z infrastruktury testowej Mobly, aby umożliwić lepsze kontrolowanie testów i rejestrowanie ich przebiegu. Mobly to platforma testowa oparta na Pythonie, która obsługuje przypadki testowe wymagające wielu urządzeń z niestandardową konfiguracją sprzętową. Więcej informacji o Mobly znajdziesz na google/mobly.

Pliki config.yml

Korzystając z ramy Mobly, możesz skonfigurować urządzenie testowe (DUT) i tablet z wykresami w klasie its_base_test. Do utworzenia środowiska testowego Mobly służy plik config.yml (YAML). W tym pliku konfiguracyjnym można skonfigurować wiele platform testowych, np. tablet i platformę testową fuzji czujników. W sekcji kontrolera w każdej platformie testowej możesz określić wartość device_ids, aby wskazać odpowiednie urządzenia z Androidem dla narzędzia do uruchamiania testów. Oprócz identyfikatorów urządzenia do klasy testu przekazywane są inne parametry, takie jak tablet brightness, chart_distance, debug_mode, camera_id i scene_id. Typowe wartości parametrów testowych:

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 słowo kluczowe TABLET musi znajdować się w nazwie pokoju testowego. Podczas inicjalizacji sterownik testów Mobly inicjalizuje TestParamsi przekazuje je do poszczególnych testów.

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

Moduł testowy można wywołać za pomocą funkcji tools/run_all_tests.py. Jeśli nie ma wartości wiersza poleceń, testy są wykonywane z wartościami z pliku config.yml. Dodatkowo możesz zastąpić wartości w pliku konfiguracji camera i scene w wierszu poleceń, używając poleceń podobnych do tych w Androidzie 11 lub niższym.

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 danych z czujników

W przypadku testowania fuzji czujników nazwa testu musi zawierać słowo kluczowe SENSOR_FUSION. Odpowiednie środowisko testowe zależy od testowanych scen. Android 12 obsługuje zarówno Arduino, jak i kontrolery Canakit do fuzji danych z czujników.

Poniżej znajduje się przykładowy plik config.yml dotyczący uruchomień czujnika Fusion.

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 sensorów za pomocą urządzenia do testowania fuzji sensorów, użyj:

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

Wiele łóżek testowych

W pliku konfiguracji można uwzględnić wiele platform testowych. Najpowszechniejszą kombinacją jest badanie zarówno na tablecie, jak i w połączeniu z czujnikiem fuzji.

Poniżej znajduje się przykładowy plik config.yml z testami na platformach testowych z wykorzystaniem tabletów i fuzji danych z 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

Testowanie ręczne jest nadal obsługiwane w Androidzie 12. Testy muszą jednak być oznaczone w nazwach testbedów za pomocą słowa kluczowego MANUAL. Ponadto testbed nie może zawierać identyfikatora tabletu.

Poniżej znajduje się 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

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

Uruchamianie poszczególnych testów

Poszczególne testy można uruchamiać tylko w celu debugowania, ponieważ ich wyniki nie są zgłaszane do weryfikatora CTS. Ponieważ plików config.yml nie można nadpisać w wierszu poleceń w przypadku camera i scene, te parametry muszą być poprawne w pliku config.yml w przypadku konkretnego testu. Jeśli w pliku konfiguracyjnym znajduje się więcej niż 1 platforma testowa, musisz ją określić za pomocą parametru --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 testów dla ITS aparatu są przechowywane podobnie jak w Androidzie 11 lub starszym, ale z tymi zmianami:

• Katalog artefaktu testowego /tmp ma na początku 8-znakowy losowy ciąg znaków CameraITS_, aby zwiększyć przejrzystość.
• 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.
• Logcaty DUT i tabletu z każdego testu są przechowywane w katalogu /tmp/CameraITS_########, co upraszcza debugowanie, ponieważ wszystkie informacje potrzebne do debugowania problemów z 3A są rejestrowane.

Testowanie zmian

W Androidzie 12 sceny na tablety są plikami PNG, a nie PDF. Korzystanie z 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 Androidzie 12 funkcja test_black_white łączy w sobie funkcjonalność funkcji test_black_white i test_channel_saturation.

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

W tabeli poniżej znajdziesz opis testu scalonego, scen1_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.

scen1_2/test_tonemap_sequence.py

Test test_tonemap_sequence jest wykonywany 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 działa na LIMITED aparatach na Androidzie 12.

scene3/test_flip_mirror.py

Test test_flip_mirror jest wykonywany na ograniczonej liczbie aparatów w Androidzie 12.

scene4/test_aspect_ratio_and_crop.py

Kręgi wyników w aplikacji scene4/test_aspect_ratio_and_crop.py zostały refaktoryzowane w Androidzie 12.

We wcześniejszych wersjach Androida używano metody polegającej na znajdowaniu konturu podrzędnego (kółka) wewnątrz konturu nadrzędnego (kwadratu) za pomocą filtrów rozmiaru i koloru. Android 12 używa metody, która polega na znalezieniu wszystkich kontur, a następnie na filtrowaniu ich w celu znalezienia cech najbardziej zbliżonych do okręgu. Aby wyeliminować fałszywe kręgi na wyświetlaczu, wymagany jest minimalny obszar konturu, a kontur koła musi być czarny.

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

Rysunek 1. Rysunek koncepcyjny przedstawiający krzywe i kryteria wyboru

Metoda Androida 12 jest prostsza i rozwiązuje problem z przycinaniem ramki na niektórych tabletach z ekranem dotykowym. Wszystkie propozycje z kręgu są logowane na potrzeby debugowania.

W Androidzie 12 test przycinania jest uruchamiany na urządzeniach FULL i LEVEL3. Android 11 lub starszy pomija stwierdzenia testu przycinania na urządzeniach FULL.

Tabela poniżej zawiera twierdzenia dotyczące 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() do przechwytywania YUV w scene4/test_multi_camera_alignment.py została przekształcona, aby uwzględniać bardziej dokładne przycinanie na czujnikach, które nie pasują do formatu obrazu.

Kod 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 Python 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 do testu fuzji czujników dodano metodę wykrywania cech na zdjęciach.

W wersjach starszych niż Android 12 do znajdowania najlepszych 240 cech obrazu używane jest całe zdjęcie, a te cechy są następnie maskowane do 20% środkowej części, aby uniknąć efektu migawki. Minimalna liczba cech to 30.

Jeśli funkcje znalezione za pomocą tej metody są niewystarczające, Android 12 najpierw ogranicza obszar wykrywania funkcji do 20%, a potem ogranicza maksymalne funkcje do podwojenia minimalnych wymagań funkcji.

Na ilustracji poniżej widać różnicę między wykrywaniem funkcji w Androidzie 11 a Androidzie 12. Podniesienie minimalnego progu wymagań dotyczących cech skutkuje wykrywaniem cech o niskiej jakości i negatywnie wpływa na pomiary.

Rysunek 2. Różnica w wykrywania funkcji w Androidzie 11 i Androidzie 12

Nowe testy

scene0/test_solid_color_test_pattern.py

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

Aby korzystać z trybu prywatności aparatu, należy włączyć testowe wzory jednokolorowych. Test test_solid_color_test_pattern potwierdza wynik obrazu wyjściowego obrazu YUV w kolorze jednolitym o kolorze zdefiniowanym przez wybrany wzór, a kolory obrazu zmieniają się 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żywane są: SOLID_COLOR.
• android.sensor.testPatternData: ustawia wartości wzorca testowego R, Gr, Gb, G w trybie wzorców testowych.

Opis jednolitego koloru w wzorze testowym znajdziesz w artykule SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Metoda

Ramki YUV są rejestrowane zgodnie z ustawionymi parametrami, a treści obrazu są weryfikowane. Wzór testowy jest generowany bezpośrednio z czujnika obrazu, więc nie jest wymagana żadna szczególna scena. Jeśli PER_FRAME_CONTROL jest obsługiwane, dla każdego testowanego ustawienia jest rejestrowana pojedyncza ramka YUV. Jeśli parametr PER_FRAME_CONTROL nie jest obsługiwany, rejestrowane są 4 klatki z analizowaną tylko ostatnią klatką, aby zmaksymalizować zasięg testu w LIMITED kamerach.

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

Tabela stwierdzeń

Tabela poniżej opisuje stwierdzenia testowe dotyczące test_solid_color_test_pattern.py.

Testy klasy wydajności

scene2_c/test_camera_launch_perf_class.py

Sprawdza, czy uruchamianie aparatu zajmuje mniej niż 500 ms w przypadku zarówno przedniego, jak i tylnego głównego aparatu w scenie twarzy scene2_c.

scene2_c/test_jpeg_capture_perf_class.py

Weryfikacja, czy opóźnienie podczas rejestrowania zdjęć JPEG w rozdzielczości 1080p jest krótsze niż 1 sekunda w przypadku przedniej i tylnej kamery głównej w scenie z twarzą scene2_c.