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

Na tej stronie podsumowano zmiany w pakiecie Camera Image Test Suite (ITS) w systemie Android 11. Zmiany można podzielić na następujące kategorie:

Zmiany sprzętowe

Android 11 wprowadza kilka zmian sprzętowych, aby obniżyć koszty i zwiększyć dostępność. Zmiany te można podzielić na następujące kategorie:

Dodatkowy producent

Rahi Systems posiada kwalifikacje do produkcji obudów testowych ITS, oprócz naszego istniejącego dostawcy, firmy MYWAY design. Informacje o firmie dla kwalifikujących się dostawców są następujące:

Ujednolicone metody produkcji

Obudowa testowa ITS o regularnym polu widzenia (RFoV) w wersji 1 w wersji 1 została przeprojektowana w celu wykorzystania metod produkcyjnych stosowanych w obudowach testowych o szerokim polu widzenia (WFoV) i skrzynkach do syntezy czujników . Funkcjonalność jest identyczna i dla uproszczenia projekt jest określany jako rev1a . Przeprojektowanie umożliwia producentom magazynowanie jednego rodzaju tworzywa sztucznego do produkcji wszystkich obudów testowych. Dodatkowo przeprojektowano uchwyt do tabletu i uchwyty na lampki, aby obsługiwały większą różnorodność tabletów i listew świetlnych LED.

Aby pobrać najnowsze opisy i rysunki mechaniczne, zobacz skrzynkę RFoV (rev1a) i skrzynkę WFoV (rev2.9) .

Większe możliwości tabletu

Do listy polecanych tabletów dodano tablety, w tym Samsung Galaxy Tab A 10.1 i Chuwi Hi9 Air 10.1. Ważne jest, aby tablet nie posiadał modulacji szerokości impulsu (PWM) umożliwiającej dostosowanie jasności ekranu w celu wyeliminowania pasków na przechwyconych obrazach.

Aby uzyskać najnowsze informacje na temat zalecanych tabletów, zobacz Wymagania dotyczące tabletów .

Zmniejszone otwieranie tabletu

Aby umożliwić korzystanie z Galaxy Tab A 10.1, wysokość otworu tabletu została nieco zmniejszona zarówno w przypadku obudów testowych RFoV (rev1a), jak i WFoV (rev2). Wersje odzwierciedlające te zmiany to rev1a.1 i rev2.9. Aby zapoznać się z tymi rysunkami, zobacz ramkę RFoV (wersja 1a) i ramkę WFoV (wersja 2.9) .

Nowy kontroler fuzji czujników

Sprzęt kontrolera zespalania czujników został przeprojektowany w celu poprawy możliwości produkcyjnych. Nowy kontroler jest oparty na Arduino i ma niestandardową osłonę płytki routingu, którą montuje się na górze Arduino. Rysunek 1 przedstawia osłonę, a rysunek 2 przedstawia rysunek mechaniczny obudowy. Nowy sterownik zasilany jest pojedynczym zasilaczem 5 V, który bezpośrednio zasila silnik. Sterowanie elektroniką odbywa się całkowicie poprzez złącze USB. Oddzielne zasilanie pozwala na całkowitą izolację pomiędzy elektroniką sterującą a serwomotorem. Dodatkowo pojedynczy sterownik może sterować maksymalnie sześcioma serwomotorami.

Widok z góry Arduino

Rysunek 1. Widok z góry nakładki Arduino

Projekt obudowy

Rysunek 2. Projekt obudowy

Android 11 jest wstecznie kompatybilny z istniejącymi kontrolerami. Aby wywołać testowanie za pomocą kontrolera opartego na Arduino, użyj:

python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion

Pierwszy poziom API

W systemie Android 10 testy ITS są oznaczone jako MANDATED i NOT_YET_MANDATED . Aby można było uruchomić aplikację na urządzeniu z systemem Android 10, należy przejść wszystkie MANDATED testy. Testy NOT_YET_MANDATED mogą zakończyć się niepowodzeniem, ale w raportach weryfikatora CTS są zapisywane jako PASS . Wymóg testów MANDATED dotyczy również zmodernizowanych urządzeń. Ten wymóg, aby zmodernizowane urządzenia przeszły wszystkie testy MANDATED , spowodował, że testy stały się testami MANDATED z opóźnieniem, ponieważ starsze urządzenia również musiały przejść te testy.

W systemie Android 11 testy MANDATED są bramkowane przez flagę pierwszego poziomu API z właściwości telefonu. W przypadku urządzeń aktualizowanych do systemu Android 11 testy są uruchamiane jako testy NOT_YET_MANDATED , co oznacza, że ​​test może zakończyć się niepowodzeniem, ale zostanie zaliczony jako PASS w CtsVerifier.apk .

Na przykład:

  • W systemie Android 11 test test_channel_saturation jest MANDATED dla urządzeń z pierwszym poziomem API większym niż 29.
  • W systemie Android 10 test test_channel_saturation jest MANDATED dla wszystkich urządzeń.

Sprawdzanie oświetlenia sceny

W systemie Android 11 oświetlenie sceny jest weryfikowane poprzez analizę jasności w rogach sceny. Wszystkie sceny ręczne są sprawdzane pod kątem oświetlenia, a sceny na tabletach są sprawdzane pod kątem kamer RFoV na stanowisku testowym RFoV i kamer WFoV na stanowisku testowym WFoV. Jeśli poziom oświetlenia jest niewystarczający, zgłaszany jest błąd i test kończy się niepowodzeniem.

Zmiana nazwy sceny

W Androidzie 10 scena 1 obejmuje większość testów i duży procent całkowitego czasu testów. Jeśli jakikolwiek test w ramach sceny 1 zakończy się niepowodzeniem, należy powtórzyć całą scenę. Z założenia ponowne uruchomienie całej sceny zmniejsza liczbę testów marginalnych. W systemie Android 11 czas ponownego uruchomienia jest skrócony poprzez podzielenie sceny 1 na dwie sceny, scenę 1_1 i scenę 1_2.

W poniższej tabeli przedstawiono czasy testów tylnego aparatu Pixel 4 dla różnych scen. Liczbę testów dzieli się w celu wyrównania czasu testów, a nie w celu wyrównania liczby testów.

Dodatkowo istnieje możliwość oczyszczenia nazw. Scena 2 jest podzielona literami, a scena 1 jest podzielona cyframi. Nazewnictwo różnych rozszerzeń jest następujące:

  • Sceny z tym samym wykresem, ale różnymi testami: *_1,2,3
  • Sceny z różnymi wykresami, ale tymi samymi testami: *_a,b,c
Scena Liczba testów Czas działania Pixela 4 (min:sek)
0 11 1:12
1_1 22 5:12
1_2 13 5:20
2_a 5 3:22
2_b 1 0:24
2_c 1 0:24
3 6 2:04
4 2 2:46

Zmiany testowe

Testy zaktualizowano tak, aby korzystały z pierwszego poziomu API

W systemie Android 11 testy w poniższej tabeli zostały zaktualizowane w celu użycia flagi pierwszego poziomu interfejsu API. Wszystkie te testy wykorzystują pierwszy poziom API 29, z wyjątkiem testu test_tonemap_curve , który wykorzystuje pierwszy poziom API 30.

Scena Nazwa testu Pierwszy poziom API Opis
0 test_tonemap_curve 30 Upewnij się, że potok ma odpowiednie kolory wyjściowe z liniową mapą tonów i idealnym obrazem wejściowym (polega na test_test_patterns ).
1 test_ae_precapture_trigger 29 Przetestuj maszynę stanu AE podczas korzystania z wyzwalacza wstępnego przechwytywania. Upewnij się, że przy wyłączonej AE wyzwalacz wstępnego przechwytywania nie działa.
test_channel_saturation 29 Upewnij się, że kanały RGB są nasycone do podobnych wartości, aby wyeliminować zabarwienie w nasyconych obszarach.
2_a/b/c test_num_faces 29 Zwiększ różnorodność wiekową scen twarzy.

Testy ze zmianami

Testy z poniższej tabeli zostały zaktualizowane w systemie Android 11. Zmiany opisano w kolumnie Opis zmian .

Scena Nazwa testu Pierwszy poziom API Opis zmian
1 test_burst_sameness_manual 30 Zmniejsz tolerancję do 2%.
4 test_aspect_ratio_and_crop 30 Zmień, aby działać na OGRANICZONYCH urządzeniach.
test_multi_camera_alignment 30 Jeśli przechwytywanie z wielu kamer nie jest obsługiwane, przeglądaj kamery indywidualnie. Przerób logikę wyboru kamer, aby uwzględnić systemy z trzema i czterema kamerami, i pomiń kamery monofoniczne, kamery głębinowe i kamery na podczerwień.

Nowe testy

Testy przedstawione w poniższej tabeli są włączone w systemie Android 11. Podsumowanie testów znajduje się w tabeli, a szczegółowe opisy znajdują się w kolejnych sekcjach.

Scena Nazwa testu Pierwszy poziom API Opis
0 test_vibration_restrictions 30 Upewnij się, że alerty i wibracje nie są aktywowane podczas przechwytywania obrazu.
2_a test_jpeg_quality 30 Sprawdź, czy tabele kwantyzacji zmniejszają kompresję w celu zwiększenia jakości JPEG.
2_d/2_e test_num_faces 30 Zwiększ różnorodność wieku twarzy.
2_e test_continuous_picture 30 Upewnij się, że 3A jest ustawione w android.control.afAvailableModes = CONTINUOUS_PICTURE.
zmiana test_scene_change 31 android.control.afSceneChange aktywowany po zmianie sceny.
6 test_zoom 30 Przetestuj android.control.zoomRatioRange .

scena0/test_wibracji_ograniczenie

Test ten nie wymaga konkretnej sceny, ale testowane urządzenie (DUT) musi zostać umieszczone lub zamontowane na twardej powierzchni. Obejmuje to montaż w obudowach testowych ITS-in-a-box.

Twierdzi

  • Brak wibracji podczas użytkowania aparatu

scena2_a/test_jpeg_jakość

metoda

Różne części pliku JPEG są definiowane za pomocą 2-bajtowych znaczników. Aby uzyskać więcej informacji, zobacz JPEG .

Test wyodrębnia macierze kwantyzacji z przechwyconego pliku JPEG. Znakiem macierzy kwantyzacji w przechwytywaniu JPEG jest sekwencja [255, 219]. Po znalezieniu znacznika kolejne dwa elementy listy to rozmiar. Znacznik rozmiaru JPEG DQT to zwykle [0, 132] = 256*0+132 = 132, co odpowiada rozmiarowi danych DQT w przechwytywaniu JPEG. Osadzone dane mają postać: [255, 219, 0, 132, 0 (znacznik luma), matryca 8x8 luma, 1 (znacznik chrominancji), matryca chrominancji 8x8].

Wartości 0 dla znacznika matrycy luminalnej i 1 dla znacznika chrominancji wydają się spójne dla wielu urządzeń, w tym telefonów, które oddzielają dwie matryce w oddzielnych sekcjach DQT w pliku JPEG. Matryce Luma mają zwykle większą różnorodność wartości w porównaniu z matrycami chrominancji, ponieważ ludzkie oko jest bardziej wrażliwe na lumę niż obrazy chrominancji, a obrazy JPEG to uwzględniają.

Poniżej pokazano próbki wyodrębnionych matryc luma i chroma dla współczynników jakości 85 i 25 dla tylnej kamery Pixel 4 rejestrującej scenę 2_a za pomocą zestawu testowego ITS. Wartości matrycy znacznie wzrastają (co oznacza zwiększoną kompresję) przy niższym ustawieniu jakości. Te macierze są drukowane ze skryptem tylko wtedy, gdy zastosowana jest flaga debug=True . Zwróć uwagę na większe zróżnicowanie wpisów w matrycach luminancji w porównaniu z matrycami chromatycznymi.

    luma matrix (quality = 85)    chroma matrix (quality = 85)

    [[ 5  3  4  4  4  3  5  4]    [[ 5  5  5  7  6  7 14  8]
     [ 4  4  5  5  5  6  7 12]     [ 8 14 30 20 17 20 30 30]
     [ 8  7  7  7  7 15 11 11]     [30 30 30 30 30 30 30 30]
     [ 9 12 17 15 18 18 17 15]     [30 30 30 30 30 30 30 30]
     [17 17 19 22 28 23 19 20]     [30 30 30 30 30 30 30 30]
     [26 21 17 17 24 33 24 26]     [30 30 30 30 30 30 30 30]
     [29 29 31 31 31 19 23 34]     [30 30 30 30 30 30 30 30]
     [36 34 30 36 28 30 31 30]]     [30 30 30 30 30 30 30 30]]

    luma matrix (quality = 25)            chroma matrix (quality = 25)

    [[ 32  22  24  28  24  20  32  28]    [[ 34  36  36  48  42  48  94  52]
     [ 26  28  36  34  32  38  48  80]     [ 52  94 198 132 112 132 198 198]
     [ 52  48  44  44  48  98  70  74]     [198 198 198 198 198 198 198 198]
     [ 58  80 116 102 122 120 114 102]     [198 198 198 198 198 198 198 198]
     [112 110 128 144 184 156 128 136]     [198 198 198 198 198 198 198 198]
     [174 138 110 112 160 218 162 174]     [198 198 198 198 198 198 198 198]
     [190 196 206 208 206 124 154 226]     [198 198 198 198 198 198 198 198]
     [242 224 200 240 184 202 206 198]]     [198 198 198 198 198 198 198 198]]

Rysunek 3 przedstawia średnie wartości matrycy dla tylnego aparatu Pixel 4 w porównaniu z jakością JPEG. Wraz ze wzrostem jakości JPEG zmniejsza się poziom kompresji (średnia jasność/chroma matrycy DQT).

Średnie wartości matrycy Pixela 4

Rysunek 3. Średnie wartości jasności/chromatyczności matrycy DQT tylnego aparatu Pixel 4 w porównaniu z jakością JPEG

Twierdzi

  • Dla [25, 45, 65, 86], jakość +20 oznacza średnią matrycy kwantyzacji redukcji o 20%.
  • Ładunki macierzy DQT są liczbami kwadratowymi.

Rysunek 4 przedstawia przykład telefonu, który nie przeszedł testu. Należy zauważyć, że w przypadku obrazów o bardzo niskiej jakości ( jpeg.quality < 50 ) nie następuje wzrost kompresji w matrycy kwantyzacji.

Nieudany przykład testu

Rysunek 4. Przykład nieudanego testu

scene2_d/e test_num_faces

Dodano dwie nowe sceny wykrywania twarzy, aby zwiększyć różnorodność kontroli algorytmu wykrywania twarzy. Po wielokrotnych testach wielu kamer oczekuje się, że najtrudniejszą twarzą będzie twarz znajdująca się najbardziej na lewo w scenie 2_d. W szczególności modelka ma zarówno kapelusz, jak i brodę, co jest nowością w scenach twarzy. Nowe sceny pokazano na rysunkach 5 i 6.

scena2_d

Rysunek 5. scena2_d

scena2_e

Rysunek 6. scena2_e

Twierdzi

  • num_faces == 3

scene2_e/test_continuous_picture

metoda

Test test_continuous_picture wykorzystuje scene2_e, ale można go włączyć w dowolnej scenie twarzy. W tym teście przechwytywanych jest 50 klatek w rozdzielczości VGA przy pierwszym ustawieniu żądania przechwytywania android.control.afMode = 4 (CONTINUOUS_PICTURE) .

Oczekuje się, że system 3A ustabilizuje się pod koniec przechwytywania 50 klatek.

Twierdzi

  • 3A jest w stanie zbieżnym pod koniec przechwytywania.

zmiana_sceny/testowa_zmiana_sceny

metoda

Włączono nowy test w celu sprawdzenia, czy flaga android.control.afSceneChange została potwierdzona przy zmianie sceny. Zmiana sceny polega na wyświetlaniu na tablecie sceny twarzy, a następnie włączaniu i wyłączaniu tabletu w celu zmiany sceny. Scena ponownie wykorzystuje scenę 2_e, ale znajduje się w osobnej scenie ze względu na wymaganą kontrolę tabletu.

Dodatkowo, w przypadku testów ręcznych, zmianę sceny można przeprowadzić machając ręką przed kamerą.

Rysunek 7 przedstawia diagram czasowy testu. Czas między wyłączeniem ekranu a przechwyceniem jest dostosowywany na podstawie wyników zdarzeń z poprzednich przechwytów.

Diagram czasowy dla test_scene_change

Rysunek 7. Diagram czasowy dla test_scene_change

Warunki zmiany:

  • Jeśli nastąpi zmiana sceny i afSceneChange == 1 , test zwraca PASS .
  • Jeśli nastąpi zmiana sceny i afSceneChange == 0 , zmiana sceny zostanie przesunięta o 5 klatek wcześniej, aby dać więcej czasu na potwierdzenie afSceneChange .
  • Jeśli nie ma zmiany sceny i afSceneChange == 1 , test zwraca FAIL .
  • Jeśli nie ma zmiany sceny i afSceneChange == 0 , zmiana sceny przesuwa się o 30 klatek wcześniej, aby uzyskać zmianę sceny w przechwytywaniu.

Twierdzi

  • Przełącza ekran (scenę).
  • Flaga afSceneChange znajduje się w [0, 1].
  • Jeśli żadna scena się nie zmieni, 3A zbiega się (funkcjonalnie identyczny z test_continuous_picture ).
  • Jeśli afSceneChange == 1 , jasność sceny musi się zmienić.
  • PASS w ciągu sześciu prób z czasem zmienionym w oparciu o poprzednie wyniki.

scena6/test_zoom

metoda

Do przetestowania android.control.zoomRatioRange wymagana jest nowa scena, ponieważ ustalone sceny albo nie mają elementu wystarczająco małego, aby można go było powiększyć (sceny [1, 2, 4]), albo scena zawiera wiele obiektów, których nie można łatwo zidentyfikować , co komplikuje ekstrakcję cech (scena 3).

Rysunek 8 przedstawia nową scenę z regularnym układem okręgów. Tablica okręgów rozluźnia wymagania dotyczące centrowania DUT/mapy i pozwala na umieszczenie okręgu zawsze w pobliżu środka przechwyconego obrazu. W tej scenie tablica składa się z okręgów 9x5 z czarną obwódką. Jedno kółko zostaje zastąpione kwadratem w prawym górnym rogu, aby pokazać orientację. Rozmiary okręgów mają cechę o powierzchni około 7500 pikseli ( radius=50pixels ) dla czujnika 4000x3000 rejestrowanego przy polu widzenia (FoV) około 80 stopni.

scena test_zoom

Rysunek 8. Scena test_zoom

Pixel 4 znalazł okrąg

Rysunek 9. Pixel 4 cam[0] zoom = [1, 3,33, 5,67, 8] obrazy ze znalezionym okręgiem

Rysunek 9 przedstawia obrazy zrobione tylnym aparatem Pixela 4, gdy zoom zwiększa się od 1 do 8x w czterech krokach. Ten zestaw zdjęć wykonano bez szczególnej staranności przy centrowaniu, z wyjątkiem użycia przysłony testowej telefonu z dwoma otworami, aby umożliwić testowanie zarówno przedniego, jak i tylnego aparatu. Oczekuje się przesunięcia od środka i jest ono obserwowane, gdy tabletka wykresu jest nieco na lewo od środka. Dodatkowo wykres wydaje się wystarczający do przetestowania przy współczynnikach powiększenia większych niż 8x.

Znajdowanie kręgów

Test obejmuje metodę find_circle() wykorzystującą metodę findContours , która wyszukuje wszystkie kontury i zawęża wyszukiwanie konturów do żądanych okręgów, testując następujące elementy:

  • Kontury muszą mieć obszar większy niż 10 pikseli.
  • Kontury muszą mieć NUM_PTS >= 15 .
  • Kontury muszą mieć czarne środki.
  • Kontury muszą przypominać okrąg, czyli ich powierzchnia jest zbliżona do obszaru pi*r2 konturu.

Zakres testowy

android.control.zoomRatioRange jest podzielony na 10 kroków.

  • [1, 7] testy [1, 1,67, 2,33, 3, 3,67, 4,33, 5, 5,67, 6,33, 7]

Powiększanie zostaje zatrzymane, jeśli znaleziony okrąg dotknie granic obrazu. W teście sprawdzane jest, czy osiągnięto wystarczający poziom powiększenia (10x).

Twierdzi

  • Przy każdym ustawieniu powiększenia znaleziono co najmniej jedno kółko.
  • Testowane jest 10-krotne lub maksymalnie android.control.zoomRatioRange .
  • Promień okręgu skaluje się z powiększeniem (RTOL 10% od oczekiwanego).
  • Przesunięcie środka okręgu od skali środkowej przy powiększeniu (RTOL 10% od oczekiwanego).
  • Osiągnięto wystarczający poziom powiększenia (2x).

Zwiększone OGRANICZONE testy kamer

W systemie Android 11 testy przedstawione w poniższej tabeli testują kamery LIMITED . Oprócz nowych testów , zaktualizowano test scene4/test_aspect_ratio_and_crop aby umożliwić testowanie urządzeń LIMITED z pierwszym poziomem API 30 lub wyższym.

Scena Nazwa testu
0 test_vibration_restrictions
2_a test_jpeg_quality
2_d/2_e test_num_faces
4 test_aspect_ratio_and_crop
6 test_zoom

Rysunek 10 przedstawia pierścień tajnego dekodera ITS systemu Android 11. Tajny pierścień dekodera pokazuje, jakimi ustawieniami testu bramkowane są poszczególne testy. Bramka jest oznaczona kolorami, aby ułatwić przeglądanie. Główne elementy bramkowania to:

  • MANUAL_SENSOR
  • READ_3A *wymaga MANUAL SENSOR
  • COMPUTE_TARGET_EXPOSURES *wymaga MANUAL SENSOR
  • PER_FRAME_CONTROL
  • RAW
  • SENSORS * REALTIME
  • MULTI_CAMERA

MANUAL SENSOR , READ_3A , COMPUTE_TARGET_EXPOSURES i PER_FRAME_CONTROL bramkują większość testów. Dodatkowo testy włączone dla LIMITED urządzeń są podświetlone na jasnozielonym kolorze.

tajny pierścień dekodera

Rysunek 10. Pierścień tajnego dekodera Androida 11