Informacje o wersji Androida 11 Camera Image Test Suite

Ta strona zawiera podsumowanie zmian w pakiecie testów obrazu z aparatu (ITS) w Androidzie 11. Zmiany dotyczą tych kategorii:

Zmiany dotyczące sprzętu

Android 11 wprowadza kilka zmian sprzętowych, które mają na celu obniżenie kosztów i zwiększenie dostępności. Te zmiany dotyczą tych kategorii:

Dodatkowy producent

Firma Rahi Systems jest wykwalifikowana do produkcji obudów testowych ITS, a dodatkowo jest naszym dotychczasowym dostawcą, firma MYWAY design. Oto informacje o firmie dla kwalifikowanych dostawców:

Ujednolicone metody produkcji

Obudowa testowa ITS-in-a-box z regularnym polem widzenia (RFoV) w wersji 1 została przeprojektowana w celu zastosowania metod produkcyjnych używanych w przypadku obudówek testowych z szerokim polem widzenia (WFoV) i obudówek z połączeniem czujników. Działanie tych funkcji jest identyczne, a dla uproszczenia interfejs jest nazywany rev1a. Nowy projekt pozwala producentom na zaopatrzenie się w jeden rodzaj tworzywa sztucznego na potrzeby wszystkich obudówek testowych. Dodatkowo uchwyt na tablet i uchwyty na światła zostały przeprojektowane, aby obsługiwać więcej modeli tabletów i barwowych pasków LED.

Najnowsze opisy i rysunki mechaniczne znajdziesz w artykułach na temat pudełka RFoV (rev1a) i pudełka WFoV (wersja 2.9).

Więcej opcji tabletów

Na liście rekomendowanych tabletów znalazły się urządzenia takie jak Samsung Galaxy Tab A 10.1 i Chuwi Hi9 Air 10.1. Ważne jest, aby tablet nie stosował modulacji szerokości impulsu (PWM) w celu regulacji jasności ekranu, ponieważ eliminuje to paskowanie na zarejestrowanych obrazach.

Najbardziej aktualne informacje o zalecanych tabletach znajdziesz w artykule Wymagania dotyczące tabletów.

Rzadsze otwieranie tabletów

Aby umożliwić korzystanie z tabletu Galaxy Tab A 10.1, zmniejszono nieco wysokość otworu na tablet w przypadku obudowy testowej RFoV (wersja 1a) i WFoV (wersja 2). Wersje, które uwzględniają te zmiany, to rev1a.1 i rev2.9. Rysunki te znajdziesz w dokumentach RFoV box (rev1a) i WFoV box (rev2.9).

Nowy kontroler czujnika fusion

Sprzęt kontrolera fuzji czujników został przeprojektowany w celu ułatwienia jego produkcji. Nowy kontroler oparty jest na Arduino i ma niestandardową tarczę montowaną na platformie Arduino. Rysunek 1 przedstawia osłonę, a rysunek 2 – rysunek techniczny obudowy. Nowy kontroler jest zasilany z pojedynczego źródła 5 V, które zasila silnik bezpośrednio. Urządzenia elektroniczne są całkowicie kontrolowane przez złącze USB. Oddzielne zasilanie umożliwia całkowitą izolację elektroniki sterującej od serwomechanizmu. Dodatkowo jeden kontroler może sterować maksymalnie 6 silnikami serw.

Widok z góry na Arduino

Rysunek 1. Widok z góry na płytkę Arduino

Projekt obudowy

Rysunek 2. Projekt obudowy

Android 11 jest zgodny wstecz z dotychczasowymi kontrolerami. Aby wywołać testowanie za pomocą kontrolera Arduino:

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

Pierwszy poziom interfejsu API

W Androidzie 10 testy ITS są oznaczone jako MANDATED i NOT_YET_MANDATED. Aby uruchomić aplikację na urządzeniu z Androidem 10, wszystkie testy MANDATED muszą zakończyć się pomyślnie. Testy NOT_YET_MANDATED mogą się nie udać, ale w raportach weryfikatora CTS są traktowane jako PASS. Wymagania dotyczące testów MANDATED obowiązują również w przypadku urządzeń z uaktualnioną wersją. Wymóg przejścia wszystkich testów MANDATED na uaktualnionych urządzeniach sprawia, że testy zostają przekształcone w testy MANDATED, ponieważ starsze urządzenia również muszą je przejść.

W Androidzie 11 testy MANDATED są ograniczone przez pierwszą flagę poziomu interfejsu API z właściwości telefonu. Na urządzeniach uaktualniających się do Androida 11 testy przebiegają jako testy NOT_YET_MANDATED, co oznacza, że test może się nie powieść, ale w CtsVerifier.apk będzie to oznaczone jako PASS.

Na przykład:

  • W Androidzie 11 test test_channel_saturation jest MANDATED na urządzeniach z pierwszym poziomem interfejsu API wyższym niż 29.
  • W Androidzie 10 test test_channel_saturation jest MANDATED na wszystkich urządzeniach.

Sprawdzanie oświetlenia sceny

W Androidzie 11 oświetlenie sceny jest weryfikowane przez analizowanie jasności w rogu sceny. Wszystkie sceny ręczne są sprawdzane pod kątem oświetlenia, a sceny na tablecie są sprawdzane pod kątem kamer RFoV w ramach testu RFoV i kamer WFoV w ramach testu WFoV. Jeśli poziomy oświetlenia są niewystarczające, zgłaszany jest błąd i testowanie się nie powiedzie.

Zmiana nazwy sceny

W Androidzie 10 scena 1 odpowiada za większość testów i duży odsetek łącznego czasu testowania. Jeśli jakikolwiek test w scenie 1 nie powiedzie się, należy ponownie przeprowadzić całą scenę. Ponowne uruchomienie całej sceny skraca testy krańcowe. W Androidzie 11 czasy ponownego uruchamiania są krótsze, ponieważ scena 1 została podzielona na dwie sceny: scene1_1 i scene1_2.

W tabeli poniżej znajdziesz czasy testów dla tylnego aparatu Pixela 4 w różnych scenach. Liczba testów jest dzielona, aby wyrównać czas trwania testu, a nie wyrównać ich liczbę.

Dodatkowo przeprowadzamy też czyszczenie nazw. Scena 2 jest podzielona za pomocą liter, a scena 1 za pomocą cyfr. Nazewnictwo różnych rozszerzeń:

  • Sceny z tym samym wykresem, ale z różnymi testami: *_1,2,3
  • Sceny z różnymi wykresami, ale z tymi samymi testami: *_a,b,c
Oświetlenie Liczba testów Czas pracy telefonu Pixel 4 (min:s)
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

Testowanie zmian

Testy zostały zaktualizowane, aby używać pierwszego poziomu interfejsu API.

W Androidzie 11 testy w tabeli poniżej zostały zaktualizowane, aby używały flagi pierwszego poziomu interfejsu API. Wszystkie te testy używają pierwszego poziomu interfejsu API 29, z wyjątkiem testu test_tonemap_curve, który używa pierwszego poziomu interfejsu API 30.

Oświetlenie Nazwa testu Pierwszy poziom interfejsu API Opis
0 test_tonemap_curve 30 Upewnij się, że pipeline ma prawidłowe wartości kolorów z mapą tonalną liniową i idealnym wejściem obrazu (zależy od test_test_patterns).
1 test_ae_precapture_trigger 29 Testowanie maszyny stanów AE przy użyciu wyzwalacza przed przechwyceniem. Upewnij się, że wyłączenie aktywatora wstępnego przechwytywania nie ma żadnego efektu.
test_channel_saturation 29 Upewnij się, że kanały RGB mają podobne wartości nasycenia, aby wyeliminować zabarwienie w nasyconych obszarach.
2_a/b/c test_num_faces 29 Zwiększ różnorodność wiekową w scenach z twarzy.

Testy z zmianami

Testy podane w tabeli poniżej są aktualizowane na urządzeniach z Androidem 11. Zmiany są opisane w kolumnie Opis zmian.

Oświetlenie Nazwa testu Pierwszy poziom interfejsu API Opis zmian
1 test_burst_sameness_manual 30 Zmniejsz tolerancję do 2%.
4 test_aspect_ratio_and_crop 30 Zmień ustawienie na „Ograniczone urządzenia”.
test_multi_camera_alignment 30 Jeśli robienie kilku kamer nie jest obsługiwane, musisz wykonać kolejne kroki z kamer. Zmodyfikuj logikę wyboru kamery, aby uwzględnić systemy z 3 i 4 kamerami oraz pominąć kamery mono, kamery IR i kamery z wyłącznie czujnikiem głębi.

Nowe testy

Testy w tabeli poniżej są włączone w Androidzie 11. Testy są opisane w tabeli, a ich szczegółowe opisy znajdziesz w następnych sekcjach.

Oświetlenie Nazwa testu Pierwszy poziom interfejsu API Opis
0 test_vibration_restrictions 30 Sprawdź, czy alerty i wibracje nie są włączone podczas robienia zdjęć.
2_a test_jpeg_quality 30 Sprawdź, czy tabele kwantowania zmniejszają kompresję, aby zwiększyć jakość JPEG.
2_d/2_e test_num_faces 30 Zwiększ różnorodność wiekową twarzy.
2_e test_continuous_picture 30 Upewnij się, że 3A jest rozliczane w android.control.afAvailableModes = CONTINUOUS_PICTURE.
zmień test_scene_change 31 android.control.afSceneChange asserted upon scene change.
6 test_zoom 30 Przetestuj android.control.zoomRatioRange.

scena0/ograniczenie_wibracji_testowej

Ten test nie wymaga konkretnej sceny, ale testowane urządzenie musi być umieszczone na twardej powierzchni lub zamontowane na niej. Obejmuje to montowanie obudów testowych w obudowie testowej ITS.

Twierdzenia

  • Brak wibracji podczas korzystania z aparatu

scene2_a/test_jpeg_quality

Metoda

Różne części pliku JPEG są definiowane za pomocą dwubajtowych znaczników. Więcej informacji znajdziesz w artykule JPEG.

Test wyodrębnia z obrazu JPEG macierz kwantyzacji. Marker dla macierzy kwantyzacji w zapisie JPEG to sekwencja [255, 219]. Gdy zostanie znaleziony znacznik, 2 kolejne elementy listy to rozmiar. Oznaczenie rozmiaru JPEG DQT to zwykle [0, 132] = 256*0+132 = 132, co odpowiada rozmiarowi danych DQT w przechwyceniu JPEG. Umieszczone dane mają postać: [255, 219, 0, 132, 0 (luma marker), 8x8 luma matrix, 1 (chroma marker), 8x8 chroma matrix].

Wartości 0 dla znacznika macierzy luminancji i 1 dla znacznika chromatyczności są spójne na wielu urządzeniach, w tym na telefonach, które rozdzielają te dwie macierze na osobne sekcje DQT w pliku JPEG. Matrycy luminancji zwykle mają większą różnorodność wartości w porównaniu do matryc chromatycznych, ponieważ ludzkie oko jest bardziej wrażliwe na luminancję niż chroma, a obrazy JPEG biorą to pod uwagę.

Poniżej pokazano wyodrębnione macierze luma i chroma dla współczynników jakości 85 i 25 dla tylnego aparatu Pixela 4, który rejestruje scenę 2_a za pomocą ITS. Wartości macierzy rosną (co oznacza zwiększoną kompresję) znacznie w przypadku ustawienia niższej jakości. Te macierze są drukowane tylko ze skryptem, jeśli zastosowano flagę debug=True. Zwróć uwagę na większą zmienność wpisów w macierzach luminancji w porównaniu z macierzami 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 macierzy dla tylnego aparatu Pixela 4 w porównaniu z jakością JPEG. Wraz ze wzrostem jakości JPEG zmniejsza się poziom kompresji (średnia matrycy DQT luma/chroma).

Średnie wartości macierzy Pixela 4

Rysunek 3. Średnie wartości matrycy DQT (luminancji/chromatyczności) tylnego aparatu Pixela 4 w porównaniu z jakością JPEG

Zgłoszenia

  • W przypadku [25, 45, 65, 86] wartość +20 w sekcji „Quality” oznacza 20% zmniejszenie średniej wartości kwantyzacji w macierzy.
  • Ładunki macierzy DQT to liczby kwadratowe.

Rysunek 4 przedstawia przykład telefonu, który nie spełnia wymagań. Pamiętaj, że w przypadku obrazów o bardzo niskiej jakości (jpeg.quality < 50) matryca kwantyzacji nie zwiększa kompresji.

Przykład nieudanego testu

Rysunek 4. Przykład testu zakończonego niepowodzeniem

scene2_d/e test_num_faces

Dodaliśmy 2 nowe sceny wykrywania twarzy, aby zwiększyć różnorodność testów stosowanych przez algorytm wykrywania twarzy. Po wielokrotnym przetestowaniu kilku kamer okazało się, że najtrudniejsza do rozpoznania twarz znajduje się po lewej stronie w scenie2_d. Model ma na sobie kapelusz i brodę, co jest nowością w scenkach z twarzą. Nowe sceny są pokazane na rysunkach 5 i 6.

scene2_d

Rysunek 5. scene2_d

scena2_e

Rysunek 6. scene2_e

Twierdzenia

  • num_faces == 3

scena2_e/test_continuous_obraz

Metoda

Test test_continuous_picture korzysta z sceny scene2_e, ale można go włączyć w dowolnej scenie z twarami. W ramach tego testu 50 ramek w rozdzielczości VGA zostało zarejestrowanych za pomocą pierwszego ustawienia żądania android.control.afMode = 4 (CONTINUOUS_PICTURE).

System 3A powinien się ustabilizować pod koniec przechwytywania 50 klatek.

Twierdzenia

  • 3A jest w stanie zjednoczonym na końcu przechwytywania.

scene_change/test_scene_change

Metoda

Włączono nowy test, który sprawdza, czy flaga android.control.afSceneChange jest zadeklarowana w przypadku zmiany sceny. Aby zmienić scenę, tablet wyświetla scenę z twarzy, a potem włącza i wyłącza się. Ta scena wykorzystuje scenę scene2_e, ale jest w niej oddzielna ze względu na wymagane sterowanie tabletem.

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

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

Schemat czasowy test_scene_change

Rysunek 7. Schemat czasowy test_scene_change

Zmień warunki:

  • Jeśli nastąpi zmiana sceny i afSceneChange == 1, test zwróci wartość PASS.
  • Jeśli nastąpi zmiana sceny i afSceneChange == 0, zmiana sceny przesunie się o 5 klatek wcześniej, aby afSceneChange miało więcej czasu na potwierdzenie.
  • 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 podczas rejestrowania.

Twierdzenia

  • Przełączniki ekranu (sceny).
  • Wartość flagi afSceneChange mieści się w zakresie [0, 1].
  • Jeśli nie ma zmiany sceny, 3A łączy się (funkcjonalnie identycznie jak test_continuous_picture).
  • Jeśli afSceneChange == 1, jasność musi się zmieniać w scenie.
  • PASS w ciągu 6 prób z zmianą czasu na podstawie poprzednich wyników.

scene6/test_zoom

Metoda

Do testowania funkcji android.control.zoomRatioRange wymagana jest nowa scena, ponieważ ustalone sceny albo nie mają elementu, który jest wystarczająco mały, aby można go było powiększyć (sceny [1, 2, 4]), albo zawierają wiele obiektów, które trudno jest zidentyfikować, co utrudnia wyodrębnianie cech (scena 3).

Rysunek 8 przedstawia nową scenę z regularnym układem okręgów. Tablica kółek zmniejsza wymagania dotyczące wyśrodkowania danych DUT/wykresów i umożliwia utworzenie okręgu zawsze w pobliżu środka zrobionego zdjęcia. W tej scenie tablica 9 x 5 kółek z czarną ramką pokrywa cały tablet. Jedno kółko jest zastąpione kwadratem w prawym górnym rogu, aby wskazać orientację. Rozmiary kół mają funkcję o powierzchni około 7500 pikseli (radius=50pixels) dla czujnika 4000 x 3000 z polem widzenia (FoV) około 80 stopni.

scena test_zoom

Rysunek 8. Scena test_zoom

Pixel 4 – znaleziony 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 w 4 etapach, gdy zoom zwiększa się z 1 do 8x. Ten zestaw zdjęć jest robiony bez specjalnej wycentrowania. Wyjątkiem jest przetestowanie w telefonie przysłony z 2 otworami w celu przetestowania przedniego i tylnego aparatu. Odchylenie od środka jest oczekiwane i jest widoczne, ponieważ tablet z wykresem jest nieco przesunięty w lewo od środka. Co więcej, wykres wydaje się wystarczający do testowania przy współczynnikach powiększenia wyższym niż 8x.

Znajdowanie kręgów

Test obejmuje metodę find_circle(), która korzysta z elementu findContours, aby znaleźć wszystkie kontury, a potem zawęzić wyszukiwanie kontur do odpowiednich okręgów, testując:

  • Kontury muszą mieć obszar większy niż 10 pikseli.
  • Kontury muszą mieć NUM_PTS >= 15.
  • Kontury muszą mieć czarne środki.
  • Kontury muszą przypominać koło, czyli ich pole musi być zbliżone do pola okręgu o promieniu pi*r2.

Zakres testowy

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

  • [1, 7] testów [1, 1,67, 2,33, 3, 3,67, 4,33, 5, 5,67, 6.33, 7]

Powiększenie zostaje zatrzymane, jeśli znaleziony okrąg dotyka krawędzi obrazu. W teście sprawdzamy, czy w trakcie testu osiągnięto odpowiedni poziom powiększenia (10 x).

Twierdzenia

  • Przy każdym ustawieniu powiększenia znajduje się co najmniej jeden okrąg.
  • Testowane jest 10 x lub maksymalnie android.control.zoomRatioRange.
  • Promień koła zmienia się wraz ze skalą (RTOL 10% od oczekiwanej).
  • Odsunięcie środka koła od środka skali wraz ze skalowaniem (RTOL 10% od wartości oczekiwanej).
  • Osiągnięto wystarczający poziom powiększenia (2x).

Zwiększono limit testowania aparatu (LIMITED)

W Androidzie 11 testy w tabeli poniżej sprawdzają kamery LIMITED. Oprócz nowych testów zaktualizowaliśmy test scene4/test_aspect_ratio_and_crop, aby umożliwić testowanie LIMITED urządzeń z interfejsem API na poziomie 30 lub wyższym.

Oświetlenie 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 tajny pierścień dekodera w Androidzie 11 ITS. Tajny dekoder pokazuje, jakie ustawienia testów są stosowane w przypadku poszczególnych testów. Bramka jest oznaczona kolorami, aby ułatwić przeglądanie. Główne elementy bramy to:

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

Większość testów przeprowadza się w aplikacjach MANUAL SENSOR, READ_3A, COMPUTE_TARGET_EXPOSURES i PER_FRAME_CONTROL. Dodatkowo testy włączone na urządzeniach LIMITED są wyróżnione na jasnozielono.

pierścień do dekodowania

Rysunek 10. Android 11 – tajny pierścień dekodujący