Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

Testy ITS kamery

Na tej stronie znajdziesz obszerną listę testów w ramach pakietu testów obrazu aparatu (ITS), który jest częścią weryfikatora pakietu testów zgodności Androida (CTS). Testy ITS to testy funkcjonalne, które nie mierzą jakości obrazu, ale sprawdzają, czy wszystkie reklamowane funkcje aparatu działają zgodnie z oczekiwaniami. Z tego dokumentu deweloperzy i testerzy dowiedzą się, do czego służą poszczególne testy i jak debugować błędy testów.

Testy bramki ITS aparatu są przeprowadzane na podstawie wymaganych właściwości aparatu, poziomu interfejsu API i poziomu klasy wydajności multimediów (MPC). W przypadku poziomu interfejsu API ITS używa parametru ro.product.first_api_level do ograniczania testów dodanych na określonym poziomie interfejsu API, które sprawdzają, czy funkcje na niższych poziomach interfejsu API nie powodują negatywnych doświadczeń użytkowników. ITS używa ro.vendor.api_level do testowania funkcji dodanych na określonym poziomie interfejsu API, które wymagają nowych możliwości sprzętowych. Jeśli dla urządzenia określona jest wartość ro.odm.build.media_performance_class, ITS wymaga wykonania określonych testów w zależności od poziomu MPC.

Testy są grupowane według sceny w ten sposób:

scene0: rejestrowanie danych o metadanych, jitterze, żyroskopie i wibracji.
scene1: ekspozycja, czułość, kompensacja wartości ekspozycji (EV), YUV w porównaniu z JPEG i RAW
scene2: wykrywanie twarzy, testy wymagające scen kolorowych
scene3: wzmacnianie krawędzi, ruch obiektywu
scene4: współczynnik proporcji, kadrowanie, pole widzenia
scene5: zacienienie obiektywu
scene6: Zoom
scene7: przełącznik wielu kamer
scene8: automatyczna ekspozycja (AE) i automatyczna regulacja balansu bieli (AWB) w pomiarze regionu
scene9: kompresja JPEG
scene_extensions: rozszerzenia dotyczące aparatu
scene_tele: przełączanie teleobiektywu
scene_flash: automatyczne flashe, minimalna liczba klatek na sekundę
scene_video: utrata klatek
sensor_fusion: przesunięcie czasu działania kamery i żyroskopu
feature_combination: Kombinacje funkcji
scene_ip: zgodność obrazu w domyślnej aplikacji aparatu i aplikacji aparatu Jetpack (JCA)

Opisy poszczególnych scen znajdziesz w odpowiednich sekcjach.

scene0

Testy nie wymagają żadnych konkretnych informacji o scenie. Podczas testowania żyroskopu i wibracji telefon musi być jednak nieruchomy.

test_jitter

Mierzy jitter w sygnaturach czasowych kamery.

Testowane interfejsy API:

Przechodzi: różnica między klatkami wynosi co najmniej 30 ms.

Na poniższym rysunku zwróć uwagę na mały zakres osi y. Na tym wykresie widać, że jitter jest niewielki.

wykres test_jitter

Rysunek 1. Wykres test_jitter.

test_metadata

Sprawdza poprawność wpisów metadanych, analizując wyniki przechwytywania i obiekty cech aparatu. Ten test używa wartości ekspozycji i wzmocnienia auto_capture_request, ponieważ zawartość obrazu nie jest ważna.

Testowane interfejsy API:

Prześlij: tagi rollingShutterSkew, frameDuration, timestampSource, croppingType, blackLevelPattern, pixel_pitch, pole widzenia (FoV) i odległość hiperfokalna są obecne i mają prawidłowe wartości.

test_request_capture_match

Testuje, czy urządzenie zapisuje prawidłowe wartości ekspozycji i wzmocnienia, odczytując metadane z sesji.

Testowane interfejsy API:

Prześlij: wartości metadanych żądania i zapisu są zgodne we wszystkich ujęciach.

test_sensor_events

W przypadku urządzeń, które reklamują obsługę fuzji czujników, ten test sprawdza, czy urządzenie wysyła zapytania i wypisuje zdarzenia czujnika. Wymagane czujniki to akcelerometr, żyroskop i magnetometr. Ten test działa tylko wtedy, gdy ekran jest włączony, co oznacza, że urządzenie nie jest w stanie gotowości.

Testowane interfejsy API:

Prześlij: otrzymywane są zdarzenia z każdego czujnika.

test_solid_color_test_pattern

Testuje, czy jednolite kolory w testowych wzorach są prawidłowo generowane w przypadku wyciszenia kamery. Jeśli wyciszanie aparatu jest obsługiwane, należy obsługiwać testowe wzory w jednolitym kolorze. Jeśli wyciszanie aparatu nie jest obsługiwane, testowe wzory w jednolitym kolorze są testowane tylko wtedy, gdy funkcja jest reklamowana.

Jeśli obrazy w formacie RAW są obsługiwane, testowane jest też przypisywanie kolorów. Testowane kolory to czarny, biały, czerwony, niebieski i zielony. W przypadku kamer, które nie obsługują obrazów w formacie RAW, testowany jest tylko czarny kolor.

Testowane interfejsy API:

Przeszedł: obsługiwane jednolite wzory testowe mają prawidłowy kolor, a obraz ma niską zmienność.

test_test_pattern

Testuje parametr android.sensor.testPatternMode w celu przechwytywania klatek dla każdego prawidłowego wzoru testowego i sprawdza, czy klatki są generowane prawidłowo w przypadku jednolitych kolorów i pasków kolorów. Ten test obejmuje te kroki:

Wykonywanie zdjęć według wszystkich obsługiwanych wzorów testowych.
Sprawdza poprawność wzoru testowego jednolitego koloru i pasków kolorów.

Testowane interfejsy API:

Przeszedł: obsługiwane wzorce testowe są generowane prawidłowo.

test_test_patterns example

Ilustracja 2. Przykład test_test_patterns.

test_tonemap_curve

Testuje konwersję testowego wzorca z formatu RAW na YUV z użyciem mapowania tonalnego liniowego. Ten test wymaga android.sensor.testPatternMode = 2 (COLOR_BARS), aby wygenerować idealny wzór obrazu do konwersji mapy tonacji. Sprawdza, czy łańcuch przetwarzania ma prawidłowe wyjścia kolorów z liniową mapą tonalną i idealnym wejściem obrazu (oparty na test_test_patterns).

Testowane interfejsy API:

Przechodzi: obrazy YUV i RAW są do siebie podobne.

Przykład test_tonemap_curve w postaci surowych danych

Ilustracja 3. Przykład danych wyjściowych test_tonemap_curve.

Przykład test_tonemap_curve YUV

Rysunek 4. Przykład YUV dla test_tonemap_curve.

test_unified_timestamp

Sprawdza, czy zdarzenia związane z obrazem i czujnikiem ruchu znajdują się w tej samej domenie czasowej.

Testowane interfejsy API:

Pass: sygnatury czasowe ruchu znajdują się między sygnaturami czasowymi dwóch obrazów.

test_vibration_restriction

Testuje, czy wibracje urządzenia działają zgodnie z oczekiwaniami.

Testowane interfejsy API:

Przechodzi: urządzenie nie wibruje, gdy zostanie wyciszone przez interfejs API ograniczeń dźwięku w aparacie.

scene1_1

scene1 to wykres w kolorze szarym. Szara tabela musi obejmować 30% środkowej części pola widzenia kamery. Wyniki na wykresie w kolorze szarym powinny być umiarkowanie lepsze od wyników 3A (AE, AWB i AF), ponieważ obszar w środku nie zawiera żadnych funkcji. Jednak żądanie przechwytywania określa całą scenę, która zawiera wystarczającą liczbę cech, aby 3A mogło się zbliżyć.

Kamery RFoV można testować w ramach platformy testowej WFoV lub RFoV. Jeśli kamera RFoV jest testowana w ramach platformy testowej WFoV, wykres jest skalowany o 2/3, aby określić niektóre granice dla szarego wykresu w przypadku pola widzenia, co ułatwia konwergencję 3A. Bardziej szczegółowe opisy urządzeń do testowania kamer znajdziesz w artykule ITS-in-a-box.

przykład1

Rysunek 5. Wykres pełnowymiarowy sceny1 (po lewej) i wykres pomniejszony do 2/3 (po prawej).

test_ae_precapture_trigger

Testuje maszynę stanów AE przy użyciu wyzwalacza przed przechwyceniem. Pokazuje 5 ręcznych żądań z wyłączonym AE. Ostatnie żądanie zawiera funkcję przedprzechwytywania AE, która powinna zostać zignorowana, ponieważ AE jest wyłączona.

Testowane interfejsy API:

Pass: AE zbiega się.

test_auto_vs_manual

Testy wykonane w trybie automatycznym i ręcznym wyglądają tak samo.

Testowane interfejsy API:

Pass: ręczne wzmocnienie i transformacja balansu bieli zgłoszone w każdej próbce obrazu są zgodne z automatycznym balansem bieli estimate z algorytmu 3A aparatu.

test_auto_vs_manual automatyczny

Rys. 6. Przykład testu automatycznego test_auto_vs_manual.

test_auto_vs_manual white balance example

Rysunek 7. Przykład test_auto_vs_manual do testowania balansu bieli.

test_auto_vs_manual przykład ręcznego ustawiania balansu bieli

Rys. 8. Przykład ręcznego dostosowania balansu bieli (plik test_auto_vs_manual).

test_black_white

Testuje, czy urządzenie wytwarza pełne obrazy czarno-białe. Wykonuje 2 zjęcia: pierwsze z bardzo niskim wzmocnieniem i krótkim czasem naświetlania, co powoduje, że zdjęcie jest czarne, a drugie z bardzo wysokim wzmocnieniem i długim czasem naświetlania, co powoduje, że zdjęcie jest białe.

Testowane interfejsy API:

Przejście: generuje czarno-białe obrazy. Nasycony kanał białych obrazów ma wartości RGB [255, 255, 255] z marginesem błędu poniżej 1%.

test_black_white, czarny przykład

Ilustracja 9. Przykład test_black_white w wersji czarnej.

test_auto_vs_manual przykład ręcznego ustawiania balansu bieli

Ilustracja 10. test_black_white, przykład białego.

test_black_white plot means example

Ilustracja 11. test_black_white, wykres oznacza przykład.

test_burst_capture

Sprawdzanie, czy cały potok przechwytywania jest w stanie nadążyć za szybkością przechwytywania w pełnym rozmiarze i czasem pracy procesora.

Testowane interfejsy API:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_BURST_CAPTURE

Przejście: rejestruje serię zdjęć w pełnym rozmiarze, sprawdza utratę klatek i jasność obrazu.

test_burst_sameness_manual

Wykonuje 5 ciągów po 50 zdjęć przy użyciu ustawień ręcznych i sprawdza, czy są one identyczne. Ten test pozwala określić, czy występują sporadyczne klatki, które zostały przetworzone inaczej lub zawierają artefakty.

Testowane interfejsy API:

Prześlij: obrazy są wizualnie identyczne i mają identyczne wartości RGB.

Niepowodzenie: pokazuje wzrost lub spadek średniej wartości RGB na początku każdego wybuchu.

Tolerancja wynosi 3%, gdy first_API_level < 30
Tolerancja wynosi 2%, gdy first_API_level >= 30

test_burst_sameness_manual_mean

Rys. 12. Przykład średniej wartości test_burst_sameness_manual.

test_burst_sameness_manual_plot_means

Rysunek 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

Sprawdzanie, czy strumienie RAW nie są usuwane.

Testowane interfejsy API:

Prześlij: obrazy YUV są przycinane w środku, ale nie obrazy RAW.

test_crop_region_raw comp raw crop example

Rys. 14. Przykład nieprzetworzonego kadrowania w komponencie test_crop_region_raw.

test_crop_region_raw comp raw full example

Rys. 15. Przykład funkcji test_crop_region_raw comp raw full.

Przykład wycinka YUV w test_crop_region_raw comp

Rys. 16. Przykład wycinka YUV w komponencie test_crop_region_raw.

test_crop_region_raw_yuv_full example

Rys. 17. Pełny przykład funkcji test_crop_region_raw w formacie YUV.

test_crop_regions

Testuje, czy regiony przycinania działają. Przejmuje pełny obraz i tworzy łaty w 5 różnych regionach (narożniki i centrum). Wykonywanie zdjęć z przycięciem ustawionym dla 5 regionów. Porównuje wartości pliku obrazu z pliku z przyciętym obrazem.

Testowane interfejsy API:

Przeszedł:obraz przyciętego obszaru jest zgodny z fragmentem odpowiadającym przyciętym zdjęciem.

test_ev_compensation

Testuje, czy zastosowano kompensację wartości ekspozycji (EV). Test składa się z sekcji podstawowej i zaawansowanej.

Sekcja podstawowa sprawdza, czy kompensacja EV jest stosowana za pomocą zakresu utworzonego za pomocą CONTROL_AE_COMPENSATION_STEP. Przy każdej wartości kompensacji rejestrowanych jest 8 ramek.

W sekcji zaawansowanej można zwiększyć ekspozycję w 8 krokach i sprawdzić zmierzoną jasność w porównaniu z oczekiwaną jasnością. Wartości oczekiwane są obliczane na podstawie jasności obrazu bez zastosowania kompensacji EV, a wartość oczekiwana osiąga nasycenie, gdy obliczone wartości przekraczają rzeczywisty zakres wartości obrazu. Test się nie powiedzie, jeśli oczekiwane wartości i zmierzone wartości nie są zgodne lub jeśli obrazy są prześwietlone w ciągu 5 kroków.

Testowane interfejsy API:

Podstawowe przejście przez sekcję: obrazy pokazują zwiększanie ekspozycji bez jej prześwietlenia w 5 krokach.

test_ev_compensation_basic

Rysunek 18. test_ev_compensation_basic.

Przetwarzanie zaawansowane: rejestruje wzrost luminacji wraz ze wzrostem ustawienia kompensacji EV. 8 ramek zarejestrowanych dla każdego ustawienia EV kompensacji mają stabilne wartości luminacji.

test_ev_compensation_advanced_plot_means

Rysunek 19. test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Testy, które sprawdzają, czy przy różnych wartościach ISO i czasu naświetlania uzyskuje się stałe naświetlenie. Wykonuje serię ujęć, w których czas naświetlania i wartość ISO są dobrane tak, aby się zrównoważyć. Wyniki powinny mieć tę samą jasność, ale w trakcie sekwencji obraz powinien stać się bardziej szumny. Sprawdza, czy średnie wartości próbek pikseli są zbliżone do siebie. Sprawdzanie, czy obrazy nie są ograniczone do 0 lub 1 (co powodowałoby, że wyglądałyby jak linie poziome). Test można też uruchomić z obrazami RAW, ustawiając w pliku konfiguracji flagę debug.

Testowane interfejsy API:

Pass: obrazy mają tę samą jasność, ale są bardziej ziarniste przy wyższym ISO. Płaskie płaszczyzny RGB występują, gdy wartość ISO*ekspozycji jest stała w przypadku testowanej przestrzeni wzmocnienia.

Mechanizm powodujący niepowodzenie: na poniższym rysunku widać, że wraz ze wzrostem wartości mnożnika wzmocnienia (oś X) uśrednione wartości na płaszczyźnie RGB (oś Y) zaczynają odbiegać od wartości mnożnika przy niskim wzmocnieniu.

test_exposure_plot_means

Rysunek 20. test_exposure_plot_means.

test_exposure_mult=1.00.jpg

Rysunek 21. test_exposure_mult=1.00.

test_exposure_mult=64.00

Rysunek 22. test_exposure_mult=64,00.

test_latching

Testuje, czy ustawienia (ekspozycja i wzmocnienie) są zablokowane na prawidłowej klatce w przypadku kamer FULL i LEVEL_3. Wykonuje serię ujęć, wysyłając kolejne żądania, przy czym zmienia parametry żądania rejestrowania między ujęciami. Sprawdzanie, czy obrazy mają oczekiwane właściwości.

Testowane interfejsy API:

android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL

Pozytywny wynik: obrazy [2, 3, 6, 8, 10, 12, 13] mają zwiększone ISO lub ekspozycję i wykazują się wyższymi wartościami średnich RGB na wykresie na rysunku poniżej.

test_latching plot means example

Rysunek 23. Przykładowy wykres test_latching.

test_latching i=00

Rys. 24. test_latching i=00.

test_latching i=01

Rysunek 25. test_latching i=01.

test_latching i=02

Rysunek 26. test_latching i=02.

test_latching i=03

Rys. 27. test_latching i=03.

test_latching i=04

Rysunek 28. test_latching i=04.

test_latching i=05

Rys. 29. test_latching i=05.

test_latching i=06

Rysunek 30. test_latching i=06.

test_latching i=07

Rys. 31. test_latching i=07.

test_latching i=08

Rys. 32. test_latching i=08.

test_latching i=09

Rys. 33. test_latching i=09.

test_latching i=10

Rysunek 34. test_latching i=10.

test_latching i=11

Rysunek 35. test_latching i=11.

test_latching i=12

Rysunek 36. test_latching i=12.

test_linearity

Testuje, czy przetwarzanie na urządzeniu może być odwrócone do pikseli liniowych. Rejestruje sekwencję ujęć, kierując urządzenie na jednolity obiekt.

Testowane interfejsy API:

Pass: wartości R, G i B muszą wzrastać liniowo wraz ze wzrostem czułości.

Przykład osi test_linearity

Rysunek 37. Przykład wykresu test_linearity.

test_locked_burst

Testuje blokowanie 3A i przerwany tryb YUV (z użyciem ustawienia automatycznego). Ten test jest zaprojektowany tak, aby zdać go nawet na urządzeniach z ograniczonymi możliwościami, które nie mają MANUAL_SENSOR ani PER_FRAME_CONTROLS. Test sprawdza spójność obrazu YUV, a sprawdzanie częstotliwości klatek odbywa się w CTS.

Testowane interfejsy API:

Prześlij: nagrania są spójne.

test_locked_burst frame0 example

Rys. 38. Przykład test_locked_burst frame0.

test_locked_burst frame1 example

Rys. 39. Przykład ramki 1 z poziomu test_locked_burst.

test_locked_burst_frame2

Ilustracja 40. Przykład ramki 2 z poziomu test_locked_burst.

scene1_2

scene 1_2 to funkcjonalnie identyczna kopia scene 1_1, która implementuje strukturę podsceny, aby skrócić czas trwania scene 1.

test_param_color_correction

Sprawdzanie, czy parametry android.colorCorrection.* są stosowane po ustawieniu. Wykonuje zdjęcia z różnymi wartościami przekształcenia i wzmocnienia, a następnie sprawdza, czy różnią się one od siebie. Transformacja i wzmocnienie są wybierane tak, aby sygnał wyjściowy był coraz bardziej czerwony lub niebieski. Używa mapy tonacji liniowej.

Mapowanie tonacji to technika stosowana w przetwarzaniu obrazu, która polega na mapowaniu jednego zbioru kolorów na inny w celu zbliżenia wyglądu obrazów o wysokim zakresie dynamicznym do medium o bardziej ograniczonym zakresie dynamicznym.

Testowane interfejsy API:

Pass: wartości R i B są wzmacniane zgodnie z transformacją.

Przykład wykresu test_param_color_correction z wartościami średnimi

Rysunek 41. Przykład znaczenia funkcji test_param_color_correction.

Na osi X na poniższych rysunkach znajdują się żądania przechwytywania: 0 = jedność, 1 = czerwony wzmacniacz, a 2 = niebieski wzmacniacz.

test_param_color_correction req=0 unity example

Rys. 42. Przykład test_param_color_correction req=0 w Unity.

test_param_color_correctness req=1 czerwony przykład wzmocnienia

Ilustracja 43. Przykład wzmocnienia koloru test_param_color_correctness req=1 w kolorze czerwonym.

test_param_color_correction req=2 niebieski przykład

Ilustracja 44. Przykład wzmocnienia koloru test_param_color_correction req=2 w niebieskim.

test_param_flash_mode

Sprawdzanie, czy parametr android.flash.mode jest stosowany. Ręcznie ustawia ekspozycję na ciemną stronę, aby było oczywiste, czy błysk został użyty, czy nie, i używa mapy tonacji liniowej. Sprawdza środek obrazu kafelka, aby sprawdzić, czy występuje duży gradient, który służy do weryfikacji, czy błysk został uruchomiony.

Testowane interfejsy API:

Przeszedł: środek obrazu ma duży gradient, co oznacza, że błysk został uruchomiony.

test_param_flash_mode 1 przykład

Rys. 45. Przykład użycia parametru test_param_flash_mode 1.

Przykład kafelka test_param_flash_mode 1

Rys. 46. Przykład pojedynczej płytki test_param_flash_mode.

przykład test_param_flash_mode_2

Rysunek 47. Przykład parametru test_param_flash_mode 2.

Przykład kafelka test_param_flash_mode 2

Rys. 48. Przykład dwóch kafelków test_param_flash_mode.

test_param_noise_reduction

Sprawdza, czy parametr android.noiseReduction.mode jest prawidłowo stosowany po ustawieniu. rejestrowanie obrazów w przyciemnionym pomieszczeniu; Używa wysokiego wzmocnienia analogowego, aby zapewnić prawidłowy poziom szumu na zarejestrowanym obrazie. Rejestruje 3 obrazy: z wyłączoną, szybką i wysoką jakością. Wykonuje też zdjęcie z małym wzmocnieniem i wyłączonym redukcją szumów, a różnicę między nimi wykorzystuje jako wartość bazową. Im wyższy stosunek sygnału do szumu, tym lepsza jakość obrazu.

Testowane interfejsy API:

android.hardware.camera2.CaptureRequest#NOISE_REDUCTION_MODE

Pass: SNR zmienia się w zależności od różnych trybów redukcji szumów i działa podobnie jak na wykresie poniżej:

Przykład wykresu SNR w ramach test_param_noise_reduction

Rysunek 49. Przykład wykresu SNRs w ramach parametru test_param_noise_reduction.

0: OFF, 1: FAST, 2: HQ, 3: MIN , 4: ZSL

test_param_noise_reduction high gain nr=0 example

Rys. 50. Przykład użycia parametru test_param_noise_reduction z wysoką wartością parametru nr=0.

test_param_noise_reduction high gain nr=1 przykład

Rysunek 51. Przykład parametru test_param_noise_reduction z wysoką wartością wzmocnienia nr 1.

test_param_noise_reduction high gain nr=2 przykład

Rys. 52. Przykład parametru test_param_noise_reduction z wysoką wartością nr=2.

test_param_noise_reduction high gain nr=3 przykład

Rys. 53. Przykład parametru test_param_noise_reduction z wysoką wartością nr=3.

test_param_noise_reduction low gain example

Rysunek 54. Przykład parametru test_param_noise_reduction z małym wzmocnieniem.

test_param_shading_mode

Sprawdzanie, czy parametr android.shading.mode jest stosowany.

Testowane interfejsy API:

Pass: tryb cieniowania jest przełączany, a mapy cieniowania obiektywu są modyfikowane zgodnie z oczekiwaniami.

test_param_shading_mode mapa cieniowania obiektywu, tryb 0 pętla 0 przykład

Rysunek 55. Przykład mapy cieniowania obiektywu w ramach test_param_shading_mode, tryb 0, pętla 0.

test_param_shading_mode mapa cieniowania obiektywu, tryb 1 pętla 0 przykład

Rysunek 56. Przykład mapy cieniowania obiektywu test_param_shading_mode, tryb 1, pętla 0.

test_param_shading_mode mapa cieniowania obiektywu, tryb 2 pętla 0 przykład

Rysunek 57. Przykład mapy cieniowania obiektywu w ramach test_param_shading_mode, tryb 2, pętla 0.

test_param_tonemap_mode

Sprawdzanie, czy parametr android.tonemap.mode jest stosowany. Stosuje różne krzywe mapowania odcieni do każdego kanału R, G i B oraz sprawdza, czy obrazy wyjściowe są zmodyfikowane zgodnie z oczekiwaniami. Ten test składa się z 2 testów: test1 i test2.

Testowane interfejsy API:

Pass:

test1: oba obrazy mają mapę tonalną liniową, ale n=1 ma bardziej stromy gradient. Kanał G (zielony) jest jaśniejszy na obrazie n=1.
test2: ta sama mapa tonacji, ale o innej długości. Obrazy są identyczne.

test_param_tonemap_mode z n=0

Rysunek 58. Parametr test_param_tonemap_mode z wartością n=0.

test_param_tonemap_mode z n=1

Rys. 59. Parametr test_param_tonemap_mode z wartością n=1.

test_post_raw_sensitivity_boost

Sprawdzanie wzmocnienia czułości pobierania. Wykonuje serię zdjęć w formacie RAW i YUV z różną czułością, publikuje kombinację wzmocnienia czułości RAW i sprawdza, czy średnia wartości pikseli na wyjściu odpowiada ustawieniom żądania.

Testowane interfejsy API:

Przepuść: obrazy w formacie RAW stają się ciemniejsze, gdy wzmacnianie jest coraz większe, a jasność obrazów w formacie YUV pozostaje stała.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

Rysunek 60. Przykład test_post_raw_sensitivity_boost raw s=3583 boost=0100.

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

Rys. 61. Przykład testu_post_raw_sensitivity_boost raw s=1792 boost=0200.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

Rysunek 62. Przykład testu_post_raw_sensitivity_boost raw s=0896 boost=0400.

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

Rysunek 63. Przykład testu_post_raw_sensitivity_boost raw s=0448 boost=0800.

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

Rysunek 64. Przykład test_post_raw_sensitivity_boost raw s=0224 boost=1600.

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

Rysunek 65. Przykład testu_post_raw_sensitivity_boost raw s=0112 boost=3199.

test_post_raw_sensitivity_boost raw plot means example

Rysunek 66. Przykład wykresu test_post_raw_sensitivity_boost.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 przykład

Rysunek 67. Przykład testu_post_raw_sensitivity_boost YUV s=0112 boost=3199.

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

Rysunek 68. Przykład testu test_post_raw_sensitivity_boost YUV s=0448 boost=0800.

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

Rysunek 69. Przykład testu_post_raw_sensitivity_boost YUV s=0896 boost=0400.

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

Rys. 70. Przykład testu_post_raw_sensitivity_boost YUV s=1792 boost=0200.

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 przykład

Rysunek 71. Przykład testu test_post_raw_sensitivity_boost YUV s=3585 boost=0100.

test_post_raw_sensitivity_boost_yuv_plot_means

Rysunek 72. test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

Wykonywanie serii zdjęć w formacie RAW z rosnącym czasem ekspozycji i mierzenie wartości pikseli.

Testowane interfejsy API:

Przejście: zwiększenie ISO (wzmocnienia) powoduje, że piksele stają się bardziej czułe na światło, a wykres przesuwa się w lewo.

test_raw_exposure ISO=55 przykład

Rysunek 73. Przykład test_raw_exposure ISO=55.

10⁰ to 1 ms, 10¹ to 10 ms, a 10⁻¹ to 0,1 ms.

test_raw_exposure ISO=132

Ilustracja 74. Przykład test_raw_exposure ISO=132.

test_raw_exposure ISO=209 przykład

Rysunek 75. Przykład test_raw_exposure ISO=209.

test_raw_exposure ISO=286

Rysunek 76. Przykład test_raw_exposure ISOs=286.

test_raw_exposure ISO=363

Rysunek 77. Przykład test_raw_exposure ISO=363.

test_raw_exposure_s=440

Ilustracja 78. Przykład test_raw_exposure ISO=440.

test_reprocess_noise_reduction

Testuje, czy android.noiseReduction.mode jest stosowany do ponownego przetwarzania żądań. Reprocesing zdjęć z niedostatecznym oświetleniem. Używa wysokiego wzmocnienia analogowego, aby sprawdzić, czy obraz jest szumny. Przetwarza 3 przetworzone ponownie obrazy: z wyłączonym NR, szybki i o wysokiej jakości. Rejestruje przetworzony ponownie obraz z niskim wzmocnieniem i wyłączonym NR, a następnie używa wariancji tego obrazu jako wartości bazowej.

Testowane interfejsy API:

android.hardware.camera2.CaptureResult#NOISE_REDUCTION_MODE

Przejście: FAST >= OFF, HQ >= FAST oraz HQ >> OFF.

Typowy wykres SNR w trybie NR

Rysunek 79. Przykład typowego wykresu SNR w trybie NR.

test_tonemap_sequence

Testuje sekwencję ujęć z różnymi krzywą mapowania tonacji. Wykonywanie 3 ujęć ręcznych z tonacją liniową. Wykonywanie 3 ujęć ręcznych z domyślną mapą tonalną. Oblicza różnicę między każdą kolejną parą klatek.

Testowane interfejsy API:

Przechodzi: 3 identyczne klatki, a następnie inny zestaw 3 identycznych klatek.

Przykład test_tonemap_sequence i=0

Rys. 80. Przykład test_tonemap_sequence i=0.

test_tonemap_sequence i=1 przykład

Rys. 81. Przykład test_tonemap_sequence i=1.

test_tonemap_sequence i=2 przykład

Rys. 82. Przykład test_tonemap_sequence i=2.

test_tonemap_sequence i=3 przykład

Ilustracja 83. Przykład test_tonemap_sequence i=3.

test_tonemap_sequence_i=4 example

Ilustracja 84. Przykład test_tonemap_sequence i=4.

test_tonemap_sequence i=5 przykład

Ilustracja 85. Przykład test_tonemap_sequence i=5.

test_yuv_jpeg_all

Sprawdzanie, czy wszystkie zgłaszane rozmiary i formaty do przechwytywania obrazu działają. Używa żądania ręcznego z tonowaniem liniowym, aby YUV i JPEG wyglądały tak samo po przekonwertowaniu przez moduł image_processing_utils. Obrazy nie są zapisywane domyślnie, ale można je zapisać, włączając funkcję debug_mode.

Testowane interfejsy API:

Prześlij: wszystkie środki obrazu mają maksymalną średnią kwadratową (RMS) (wartość sygnału) różnicy w przekonwertowanych na RGB obrazach z 3% najwyższej rozdzielczości obrazu YUV.

przykład test_yuv_jpeg_all

Rys. 86. Przykład test_yuv_jpeg_all.

test_yuv_plus_dng

Testuje, czy zgłaszane rozmiary i formaty do przechwytywania obrazu działają.

Testowane interfejsy API:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

Przeszedł: test się zakończył i zwrócił żądane obrazy.

przykład test_yuv_plus_dng

Rysunek 87. Przykład test_yuv_plus_dng.

scene1_3

scene 1_3 to funkcjonalnie identyczna kopia scene 1_1, która implementuje strukturę podsceny, aby skrócić czas trwania scene 1.

test_capture_result

Testuje, czy prawidłowe dane zwracają się w obiektach CaptureResult. Test składa się z ujęcia automatycznego, ujęcia ręcznego i drugiego ujęcia automatycznego.

Testowane interfejsy API:

Przepuść: metadane są ważne dla wszystkich przechwyceń, a ustawienia ręczne nie są przekazywane do drugiego automatycznego przechwycenia. Wykresowuje korektę cieniowania obiektywu dla zdjęć.

test_capture_result_plot_lsc_auto_ch0

Rysunek 88. test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

Sprawdzanie, czy parametry modelu DNG w formacie RAW są prawidłowe. Wykres przedstawia zmierzoną odchylenie standardowe środkowego fragmentu szarej karty w nieprzetworzonych zdjęciach wykonanych przy różnych czułościach. Wartości te są porównywane z wartościami odchylenia standardowego oczekiwanego przy każdej czułości przez model szumu DNG w interfejsie HAL aparatu (na podstawie parametrów O i S zwróconych w obiektach wyników rejestracji). Aby dowiedzieć się więcej o modelu szumu DNG, pobierz ten dokument na temat modelu szumu DNG.

Testowane interfejsy API:

Prześlij: parametry modelu surowego DNG są prawidłowe. Oczekiwane wartości RGB są zgodne z rzeczywistymi zmierzonymi wartościami RGB.

test_dng_noise_model_plog

Rysunek 89. test_dng_noise_model_plog.

test_jpeg

Testy przekonwertowanych obrazów YUV i obrazów JPEG z urządzenia wyglądają tak samo. Test bierze 10% obrazu w środku i oblicza wartość RGB, a następnie sprawdza, czy są one zgodne.

Testowane interfejsy API:

android.graphics.ImageFormat#JPEG

Przeszedł:średnia różnica RGB między obrazami jest mniejsza niż 3%.

test_jpeg_fmt=jpg.jpg

Rysunek 90. test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

Rysunek 91. test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

Wykonuje serię obrazów w formacie RAW z rosnącym wzmocnieniem i mierzy szum. rejestruje tylko w formacie raw w trybie seryjnym.

Testowane interfejsy API:

Przepuszczenie: każde kolejne ujęcie jest bardziej szumne od poprzedniego, ponieważ wzrasta wzmocnienie.

Używa wariancji komórki siatki statystyk pośrodku.

test_raw_burst_sensitivity_variance

Rysunek 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Wykonuje serię zdjęć w formacie RAW z rosnącą czułością i mierzy szum (wariację) w centralnych 10% obrazu. Sprawdzanie, czy każdy kolejny obraz jest bardziej zniekształcony niż poprzedni.

Testowane interfejsy API:

Pass: zmienność wzrasta z każdym strzałem.

test_raw_sensitivity_variance

Rysunek 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Testy rejestrowania pojedynczej klatki jako danych wyjściowych YUV i JPEG. Używa żądania ręcznego z tonowaniem liniowym, aby YUV i JPEG wyglądały tak samo po przekonwertowaniu przez moduł image_processing_utils.

Testowane interfejsy API:

Prześlij: obrazy YUV i JPEG są podobne i różnią się o mniej niż 1% RMS (wartość sygnału).

test_yuv_plus_jpeg w formacie JPEG

Rysunek 94. test_yuv_plus_jpeg w formacie JPEG.

test_yuv_plus_jpeg w formacie YUV

Rysunek 95. test_yuv_plus_jpeg w formacie YUV.

test_yuv_plus_raw

Testuje przechwytywanie pojedynczego obrazu w formacie RAW (10-bitowym i 12-bitowym) oraz YUV (jeśli jest obsługiwany). Używa żądania ręcznego z tonowaniem liniowym, więc spodziewane jest, że YUV i raw będą takie same. Porównuje wartości RGB obrazu przekształconego do formatu RGB w centrum. Dziennikiandroid.shading.mode.

Testowane interfejsy API:

Prześlij: obrazy YUV i w formacie RAW są podobne i różnią się o mniej niż 3,5% RMS (wartość średniokwadratowa kwadratowa sygnału).

test_yuv_plus_raw_shading=1_raw.jpg

Rysunek 96. test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

Rysunek 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

Testy CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITYz różnymi ustawieniami ISO, aby potwierdzić korelację między wyższym ISO a zwiększonym poziomem szumów.

Testowane interfejsy API:

Przechodzi: wyższe wartości ISO powodują wzrost poziomu szumu.

Testowanie kryteriów pomijania

Test test_sensitivity_priority.py jest pomijany, jeśli zostanie spełnione któreś z tych kryteriów:

Urządzenie ma pierwszy poziom interfejsu API (first_api_level) na poziomie 35 lub niższym.
Urządzenie nie wyświetla reklam CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY w CONTROL_AE_AVAILABLE_PRIORITY_MODES.

test_exposure_time_priority

Testuje CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY z różnymi czasami ekspozycji, sprawdzając stabilną jasność w zakresie, w którym ISO może to kompensować.

Testowane interfejsy API:

Przyjęcie: jasność jest stabilna (w ramach tolerancji) w czasie ekspozycji, jeśli ISO mieści się w zakresie kompensacji.

Testowanie kryteriów pomijania

Test test_exposure_time_priority jest pomijany, jeśli zostanie spełnione któreś z tych kryteriów:

Urządzenie ma pierwszy poziom interfejsu API (first_api_level) na poziomie 35 lub niższym.
Urządzenie nie wyświetla reklam CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY w CONTROL_AE_AVAILABLE_PRIORITY_MODES.

scene2_a

scene2_a przedstawia 3 twarze na szarym tle i w neutralnych ubraniach. Twarze mają różne odcienie skóry. Aby wykrywanie twarzy działało optymalnie, wykres musi mieć prawidłową orientację.

scene2_a example

Rysunek 98. Przykład scene2_a.

test_autoframing

Testuje zachowanie automatycznego kadrowania aparatu. Wykonuje duże powiększenie, aby żadne z twarzy w scenie nie było widoczne, włącza tryb automatycznego kadrowania, ustawiając wartość AUTOFRAMING w CaptureRequest na True, i sprawdza, czy wszystkie twarze w pierwotnej scenie można wykryć, gdy stan się zbliża (czyli gdy AUTOFRAMING_STATE w CaptureResult ma wartość AUTOFRAMING_STATE_CONVERGED).

Testowane interfejsy API:

Pozytywny: wykryto wszystkie 3 twarze.

test_display_p3

Testy Display P3 przechwytują w formacie JPEG za pomocą interfejsu API ColorSpaceProfiles. Sprawdzanie, czy przechwycony plik JPEG zawiera odpowiedni profil ICC w nagłówku i czy zawiera kolory spoza zakresu sRGB.

Testowane interfejsy API:

Przeszedł: plik JPEG zawiera profil ICC Display P3 i kolory spoza gamy sRGB.

test_effects

Wykonuje klatkę dla obsługiwanych efektów aparatu i sprawdza, czy są one generowane prawidłowo. Test sprawdza tylko efekty OFF i MONO, ale zapisuje obrazy dla wszystkich obsługiwanych efektów.

Testowane interfejsy API:

Pass: rejestruje obraz sceny z efektami OFF oraz obraz monochromatyczny z efektami ustawionymi na MONO.

test_effects_MONO

Rysunek 99. test_effects_MONO.

test_exposure_keys_consistent

Ten test porównuje średnią luminancję w przypadku obrazu z włączoną automatyczną ekspozycją z obrazem z wyłączoną automatyczną ekspozycją, w którym ręcznie stosuje się parametry ekspozycji (czułość, czas ekspozycji, czas trwania klatki, zwiększenie czułości po przetworzeniu w formacie RAW) otrzymane w CaptureResult obrazu z włączoną automatyczną ekspozycją.

Testowane interfejsy API:

Przechodzi: względna różnica w luminacji między dwoma obrazami jest mniejsza niż 4 procenty.

test_format_combos

Testowanie różnych kombinacji formatów wyjściowych.

Testowane interfejsy API:

Powodzenie: wszystkie kombinacje zostały prawidłowo przechwycone.

test_num_faces

Testuje wykrywanie twarzy.

Testowane interfejsy API:

Pass: znajduje 3 twarze.

test_num_faces tryb wykrywania twarzy 1 przykład

Rysunek 100. Przykład trybu wykrywania twarzy 1 (test_num_faces).

test_reprocess_uv_swap

Testuje, czy przetwarzanie YUV nie powoduje zamiany płaszczyzn U i V. Jest to wykrywane przez obliczenie sumy bezwzględnych różnic (SAD) między przetworzonym obrazem a nieprzetworzonym obrazem. Jeśli zamiana płaszczyzn wyjściowych U i V w przetworzonych ponownie danych prowadzi do zwiększenia wartości SAD, przyjmuje się, że dane wyjściowe mają prawidłowe płaszczyzny U i V.

Testowane interfejsy API:

Przechodzi: płaszczyzny U i V nie są zamieniane.

test_reprocess_uv_swap

Rysunek 101. Przykład testu reprocess_uv_swap.

scene2_b

test_preview_num_faces

Testowanie wykrywania twarzy w podglądzie z większą różnorodnością odcieni skóry w scenach z twarzami.

Testowane interfejsy API:

Przechodzi: znajduje 3 twarze z punktami orientacyjnymi twarzy w ich obrysach.

test_num_faces_fd_mode_1

Rys. 102. Przykład trybu wykrywania twarzy 1 (test_num_faces).

test_yuv_jpeg_capture_sameness

Wykonywanie dwóch zdjęć w największych wspólnych formatach YUV i JPEG o tych samych proporcjach co największy format JPEG, nieprzekraczający rozdzielczości 1920 x 1440. Ustawia jpeg.quality na 100 i przechwytuje żądanie dotyczące podwójnej powierzchni. Konwertuje oba obrazy na tablice RGB i oblicza 3D średniokwadratową różnicę (RMS) między nimi.

Test ten sprawdza też, czy dane wyjściowe YUV we wszystkich obsługiwanych przypadkach użycia strumieni są w wystarczającym stopniu podobne do danych YUV w przypadku użycia STILL_CAPTURE.

Testowane interfejsy API:

Przechodzi: obrazy YUV i JPEG w przypadku zastosowania STILL_CAPTURE różnią się o mniej niż 3% RMS (wartość RMS sygnału); obrazy YUV we wszystkich obsługiwanych przypadkach użycia różnią się o mniej niż 10% RMS od obrazów YUV w przypadku zastosowania STILL_CAPTURE.

scene2_c

test_num_faces

Testowanie wykrywania twarzy z większą różnorodnością odcieni skóry w scenach z twarzami.

Testowane interfejsy API:

Pass: znajduje 3 twarze.

test_num_faces_fd_mode_1

Ilustracja 103. Przykład trybu wykrywania twarzy test_num_faces.

test_jpeg_capture_perf_class

Testy opóźnienia rejestrowania JPEG dla klasy wydajności S zgodnie z opisem w sekcji 2.2.7.2 Camera w CDD.

Przyjęcie: KAMERA 2 MUSI mieć opóźnienie rejestrowania JPEG < 1000 ms w przypadku rozdzielczości 1080p zmierzonej za pomocą testu wydajności aparatu CTS w warunkach oświetlenia ITS (3000 K) dla obu głównych aparatów.

test_camera_launch_perf_class

Testy opóźnienia uruchamiania aparatu w przypadku klasy wydajności S zgodnie z opisem w sekcji 2.2.7.2 Camera w dokumentacji CDD.

Pozytywny: czas oczekiwania na uruchomienie aparatu 2 (od otwarcia aparatu do pierwszego podglądu) MUSI wynosić mniej niż 600 ms, zgodnie z wynikiem z testu PerformanceTest aparatu CTS w warunkach oświetlenia ITS (3000 K) dla obu głównych aparatów.

test_default_camera_hdr

Testy, które sprawdzają, czy domyślne przechwytywanie aparatem to ultra HDR w przypadku klasy wydajności 15 zgodnie z sekcją 2.2.7.2 Camera w CDD.

Prześlij: domyślne przechwytywanie pakietu kamery MUSI być w formacie ultra HDR na urządzeniu o klasie wydajności 15.

scene2_d

test_preview_num_faces

Testowanie wykrywania twarzy w podglądzie z większą różnorodnością odcieni skóry w scenach z twarzami.

Testowane interfejsy API:

Przechodzi: znajduje 3 twarze z punktami orientacyjnymi twarzy w ich obrysach.

scene2_e

test_continuous_picture

50 klatek w rozdzielczości VGA jest rejestrowanych za pomocą pierwszego ustawienia żądania rejestracji. android.control.afMode = 4 (CONTINUOUS_PICTURE).

Testowane interfejsy API:

Przechodzi: system 3A stabilizuje się do końca przechwytywania 50 klatek.

test_num_faces

Testowanie wykrywania twarzy z większą różnorodnością odcieni skóry w scenach z twarzami.

Testowane interfejsy API:

Przechodzi test: wykrywa 3 twarze.

scene2_f

scene2_f przedstawia 3 twarze na białym tle i w białej odzieży. Twarze mają szeroki zakres odcieni skóry i wysoki kontrast z tłem.

scene2_f example

Ilustracja 104. Przykład scene2_f.

test_preview_num_faces

Testowanie wykrywania twarzy z większą różnorodnością odcieni skóry w scenach z twarzami.

Testowane interfejsy API:

Przechodzi: znajduje 3 twarze z punktami orientacyjnymi twarzy w ich obrysach.

test_num_faces_fd_mode_1

Rys. 105. Przykład test_num_faces_fd_mode_1.

scene2_g

scene2_g składają się z 3 twarz na białym tle i w białej odzieży. Twarze mają szeroką gamę odcieni skóry i wysoki kontrast z tłem.

Rysunek 106. Przykład scene2_g.

test_preview_num_faces

Testowanie wykrywania twarzy z większą różnorodnością odcieni skóry w scenach z twarzami.

Testowane interfejsy API:

Pass: znajduje 3 twarze z punktami orientacyjnymi twarzy w ramkach.

test_preview_num_faces

Rys. 107. Przykład test_preview_num_faces.

scene3

scene3 używa wykresu ISO12233, a większość testów korzysta z metody wyodrębniania wykresu w scenie. Z tego powodu większość zapisanych obrazów nie ma ramek, jak w przypadku scen 1, 2 lub 4, tylko sam wykres. Aby wyszukiwarka wykresów działała optymalnie, wykres musi być w prawidłowej orientacji.

test_edge_enhancement

Sprawdza, czy parametr android.edge.mode jest prawidłowo stosowany. Przechwytuje obrazy nieprzetworzone w przypadku każdego trybu krawędzi i zwraca ostrość obrazu wyjściowego oraz metadane wyniku przechwycenia. Przetwarza żądanie rejestrowania z użyciem danego trybu krawędzi, czułości, czasu ekspozycji, odległości ogniskowej i parametru powierzchni wyjściowej.

Przepuść: tryb HQ (2) jest ostrzejszy niż tryb OFF (0). Tryb FAST (1) jest (1) ostrzejszy niż tryb OFF. Tryb HQ jest ostrzejszy lub równy trybowi FAST.

Testowane interfejsy API:

android.hardware.camera2.CaptureRequest#EDGE_MODE

Parametry aparatu, których to dotyczy:

EDGE_MODE

test_edge_enhancement_edge=0

Rys. 108. Przykład użycia parametru test_edge_enhancement z wartością edge=0.

test_edge_enhancement edge=1 example

Rys. 109. Przykład użycia funkcji test_edge_enhancement z parametrem edge=1 (tryb szybki).

test_edge_enhancement edge=2

Rys. 110. Przykład test_edge_enhancement edge=2 (tryb wysokiej jakości).

test_flip_mirror

Sprawdza, czy obraz jest prawidłowo zorientowany zgodnie z 7.5.2 Przedni aparat w CDD.

Obrazy odbite lustrzaniem, odwrócone lub obrócone można rozpoznać po diamencie w pobliżu środka.

Przeszedł: obraz nie jest odwrócony, odbity czy obrócony.

Przykład poprawki sceny test_flip_mirror

Ilustracja 111. Przykład plakietki sceny test_flip_mirror.

test_imu_drift

Sprawdza, czy jednostka pomiarowa bezwładności (IMU) ma stabilne dane wyjściowe przez 30 sekund, gdy urządzenie jest nieruchome i wykonuje podgląd w wysokiej rozdzielczości.

Testowane interfejsy API:

Pass:

Odchylenie żyroskopu jest mniejsze niż 0,01 rad w czasie testu.
Odchylenie pomiaru żyroskopu jest mniejsze niż 1E-7 rad²/s²/Hz w czasie testu.
Odchylenie wektora obrotu w czasie testu jest mniejsze niż 0,01 rad.
(nie jest to jeszcze wymagane) Odchylenie żyroskopu jest mniejsze niż 1 stopień na sekundę.

Przykład test_imu_drift drift żyroskopu

Ilustracja 112. Przykład driftu żyroskopu test_imu_drift.

Przykład wektora dryftu obrotowego test_imu_drift

Rys. 113. Przykład wektora dryftu rotacji test_imu_drift.

test_landscape_to_portrait

Sprawdza, czy przełączanie orientacji z poziomej na pionową działa prawidłowo w przypadku czujników w orientacji poziomej.

Testowane interfejsy API:

Przeszedł: test wykrywa wykres z oczekiwaną rotacją (0 stopni, gdy zastąpienie orientacji poziomej przez pionową jest wyłączone, 90 stopni, gdy jest włączone).

przykład test_landscape_to_portrait

Rys. 114. Przykład test_landscape_to_portrait.

test_lens_movement_reporting

Sprawdzanie, czy flaga ruchu obiektywu jest prawidłowo zgłaszana. Wykonuje serię 24 obrazów, z których pierwsze 12 jest rejestrowane z optymalną odległością ostrości (znalezioną przez 3A), a ostatnie 12 z minimalną odległością ostrości. W okolicach kadru 12 obiektyw się porusza, co powoduje spadek ostrości. Ostrość w końcu się ustabilizuje, gdy obiektyw osiągnie ostateczną pozycję.

Flaga ruchu obiektywu powinna być zaznaczona we wszystkich klatkach, w których ostrość jest pośrednia lub wyższa niż ostrość w pierwszych klatkach z obiektywem nieruchomym w optymalnej odległości ogniskowej oraz w ostatnich klatkach z obiektywem nieruchomym w minimalnej odległości ogniskowej. Nie ma znaczenia, w którym dokładnie ujęciu obiektyw się porusza: ważne jest, aby flaga ruchu była zaznaczona, gdy obiektyw się porusza.

Testowane interfejsy API:

Prześlij: w ramce ze zmianą ostrości flaga ruchu obiektywu ma wartość True.

Mechanizmy niepowodzenia:

lens_moving: True(android.hardware.camera2.CaptureResult#LENS_STATE = 1) w test_log.DEBUG jest zaznaczone tylko w ramkach, w których ostrość nie zmienia się.
Klatki z wartością lens_moving: False(android.hardware.camera2.CaptureResult#LENS_STATE = 0) w elementzie test_log.DEBUG mają inną ostrość niż pierwsze kilka klatek przy optymalnej odległości ogniskowej lub ostatnie kilka klatek przy minimalnej odległości ogniskowej.

test_reprocess_edge_enhancement

Testuje, czy obsługiwane metody ponownego przetwarzania służące do wzmacniania krawędzi działają prawidłowo. Przetwarza żądanie przechwycenia z określonym trybem ponownego przetwarzania krawędzi i porównuje różne tryby przechwycenia z wyłączonymi trybami ponownego przetwarzania krawędzi.

Testowane interfejsy API:

Prześlij: ostrość w różnych trybach krawędzi jest prawidłowa. HQ (tryb 2) jest ostrzejszy niż OFF (tryb 0), a poprawa między różnymi trybami jest podobna.

Przykład wykresu test_reprocess_edge_enhancement

Rysunek 115. Przykład wykresu test_reprocess_edge_enhancement.

scene4

scene4 składa się z czarnego koła na białym tle w kwadracie.

Testy w scene4 mogą być wrażliwe na wyrównanie, dlatego od Androida 15 możesz użyć check_alignment.py w katalogu tools, aby włączyć sprawdzanie wyrównania DUT i wykresu.

scene4 example

Rysunek 116. Przykład sceny 4.

test_30_60fps_preview_fov_match

Sprawdzanie, czy filmy w rozdzielczości 30 FPS i 60 FPS mają ten sam kąt widzenia. Podczas testu są rejestrowane 2 filmy: jeden z 30 FPS, a drugi z 60 FPS. Z każdego filmu wybieramy reprezentatywny kadr i analizujemy go, aby sprawdzić, czy zmiany pola widzenia w obu filmach są zgodne ze specyfikacją. Testuje, czy współczynnik kształtu koła pozostaje stały, środek koła pozostaje stabilny, a promień koła pozostaje stały.

Testowane interfejsy API:

Przeszedł: obrazy nie są rozciągnięte, środek obrazów nie różni się o więcej niż 3%, a maksymalna zmiana współczynnika proporcji między filmami w 30 FPS i 60 FPS nie przekracza 7,5%.

Mechanizmy niepowodzenia:

Krąg z filmu w 30 FPS jest znacznie mniejszy niż z filmu w 60 FPS.
Okrąg na zrobionym zdjęciu jest zniekształcony przez łańcuch przetwarzania.
Okrąg na zarejestrowanym obrazie jest przycięty z powodu skrajnie małej wysokości lub szerokości obrazu w prośbie o zapisanie.
Okrąg na zrobionym zdjęciu ma odbicie w środku i nie jest w pełni wypełniony.

test_aspect_ratio_and_crop

Sprawdza, czy obrazy nie są zniekształcone lub nieoczekiwanie przycięte w systemie przetwarzania obrazów. Robi zdjęcia koła w różnych formatach. Sprawdzanie, czy okrąg nie jest zniekształcony, czy nie przesuwa się z poziomu środka obrazu i czy nie zmienia nieprawidłowo rozmiaru przy różnych formatach obrazu lub rozdzielczościach.

Testowane interfejsy API:

Pozytywny: obrazy nie są rozciągnięte, środek obrazu nie różni się o więcej niż 3%, a zachowana jest maksymalna możliwa wartość FoV.

Mechanizmy niepowodzenia:

Kamera nie jest wyrównana z kółkiem wyświetlanym na tablecie w środku sceny.
Okrąg na zrobionym zdjęciu jest zniekształcony przez łańcuch przetwarzania.
Obraz o niższej rozdzielczości jest dwukrotnie przycięty w przepływie danych obrazu, co powoduje inny kąt widzenia na obrazach w wysokiej i niskiej rozdzielczości.
Okrąg na zarejestrowanym obrazie jest przycięty z powodu skrajnie małej wysokości lub szerokości obrazu w prośbie o zapisanie.
Okrąg na zrobionym zdjęciu ma odbicie w środku i nie jest w pełni wypełniony.

test_multi_camera_alignment

Testuje parametry kalibracji kamery związane z pozycjonowaniem kamery w systemach wielokamerowych. Korzystanie z fizycznych podkamer w ramach funkcji wielu kamer, aby zrobić zdjęcie za pomocą jednej z fizycznych kamer. Znajduje środek okręgu. Przekształca punkt środkowy koła na współrzędne światowe dla każdej kamery. Porównuje różnicę między środkami okręgów kamer w układzie światowym. Przeprojektowuje współrzędne geograficzne na współrzędne pikseli i porównuje je z oryginalnymi wartościami w celu sprawdzenia poprawności. Porównuje rozmiary kółek, sprawdzając, czy ogniskowa aparatów jest inna.

Testowane interfejsy API:

Przeszedł: okręgi mają prawidłowe środki i rozmiary na wyświetlanych obrazach w porównaniu z obrazami zarejestrowanymi przy użyciu danych kalibracji aparatu i ogniskowych długości ogniskowych.

Mechanizmy niepowodzenia:

Wartości LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION i LENS_POSE_ROTATION to wartości projektowe, a nie rzeczywiste dane kalibracji.
System kamery nie jest odpowiedni do konfiguracji testu, np. testowanie systemu kamery szerokokątnej i ultraszerokokątnej za pomocą urządzenia testowego RFoV. Więcej informacji znajdziesz w najczęstszych pytaniach dotyczących zestawu ITS-in-a-box (Q1).

test_preview_aspect_ratio_and_crop

Podobnie jak w przypadku testu test_aspect_ratio_and_crop, w przypadku testu test_aspect_ratio_and_crop sprawdzane są obsługiwane formaty podglądu, aby sprawdzić, czy ramki podglądu nie są nieprawidłowo rozciągnięte ani przycięte. Sprawdzanie, czy proporcje koła nie ulegają zmianie, czy przycięte obrazy zawierają okrąg w środku kadru i czy rozmiar koła nie zmienia się w przypadku stałego formatu lub różnych rozdzielczości (sprawdzanie pola widzenia).

Testowane interfejsy API:

Pozytywny: obrazy nie są rozciągnięte, środek obrazu nie różni się o więcej niż 3%, a zachowana jest maksymalna możliwa wartość FoV.

test_preview_stabilization_fov

Sprawdza obsługiwane rozmiary podglądu, aby upewnić się, że pole widzenia jest odpowiednio przycięte. Podczas testu są rejestrowane 2 filmy: jeden ze stabilizacja podgląduON, a drugi bez niejOFF. Z każdego filmu wybierany jest reprezentatywny kadr, który jest analizowany pod kątem zmiany pola widzenia w obu filmach.

Testowane interfejsy API:

Przechodzi: współczynnik proporcji koła pozostaje mniej więcej stały, położenie środka koła jest stabilne, a jego rozmiar zmienia się nie więcej niż o 20%.

test_video_aspect_ratio_and_crop

Nagrywa filmy w kółku w kwadracie we wszystkich formatach wideo. Wyodrębnia kluczowe klatki i sprawdza, czy proporcje koła się nie zmieniają, czy przycięte obrazy zawierają koło w środku i czy rozmiar koła nie zmienia się w przypadku stałego formatu lub innej rozdzielczości (sprawdzanie pola widzenia).

Testowane interfejsy API:

Prześlij: ramki wideo nie są rozciągnięte, środek ramek nie różni się o więcej niż 3%, a maksymalny możliwy kąt widzenia jest zachowany.

scene5

scene5 wymaga sceny w szarym kolorze o jednolitej jasności. Jest to możliwe dzięki dyfuzorowi umieszczonemu na obiektywie. Zalecamy użycie tego dyfuzora: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

Aby przygotować scenę, zamontuj dyfuzor przed aparatem i skieruj go w kierunku źródła światła o natężeniu około 2000 luksów. Zdjęcia wykonane w celuscene5 wymagają rozproszonego oświetlenia bez widocznych elementów. Oto przykładowy obraz:

scene5 example

Ilustracja 117. Przykład ujęcia w scenie 5.

test_lens_shading_and_color_uniformity

Sprawdza, czy korekcja cieniowania obiektywu jest prawidłowo zastosowana, a kolor jednolitej sceny monochromatycznej jest równomiernie rozłożony. Wykonuje ten test na podstawie ramki YUV z automatycznym 3A. Zacienienie obiektywu jest oceniane na podstawie kanału y. Mierzy średnią wartość y dla każdego określonego bloku próbki i określa, czy test się powiódł, czy nie, porównując z wartością środkową y. Test jednolitości kolorów jest przeprowadzany w przestrzeni barw czerwono-zielonej i niebiesko-zielonej.

Testowane interfejsy API:

Przeszedł: w przypadku obrazu o określonym promieniu zmienność wartości czerwono-zielonej i niebiesko-zielonej musi być mniejsza niż 20%, aby test został zaliczony.

scene6

scene6 to siatka jednoznacznie identyfikowalnych znaczników ArUco. Testy w scene6 mogą być wrażliwe na wyrównanie, dlatego od wersji 15 możesz używać check_alignment.py w katalogu narzędzi, aby włączyć sprawdzanie wyrównania testowanego obiektu danych i wykresu.

scene6

Rysunek 118. Przykład sceny 6.

test_in_sensor_zoom

Testuje działanie funkcji powiększenia na matrycy, która umożliwia tworzenie przyciętych obrazów w formacie RAW.

Gdy ustawienie przepływu danych jest ustawione na CROPPED_RAW, test wykonuje 2 zrzuty w zakresie zoomu: pełny obraz RAW w pełnym polu widzenia i przycięty obraz RAW. Test konwertuje obrazy na tablice RGB, zmniejsza rozmiar pełnowymiarowego przyciętego obrazu RAW do rozmiaru podanego przez SCALER_RAW_CROP_REGION i oblicza różnicę RMS w 3D między tymi dwoma obrazami.

Testowane interfejsy API:

Przeszedł: różnica RMS w przestrzeni 3D między pomniejszoną przyciętą wersją surowego obrazu i surowym obrazem w pełnym polu widzenia jest mniejsza niż próg ustawiony w teście.

test_zoom

Testuje zachowanie zoomu aparatu od obiektywu ultraszerokokątnego do obiektywu szerokokątnego. Wykonuje przechwytywanie w zakresie powiększenia i sprawdza, czy znaczniki ArUco powiększają się wraz z powiększaniem obrazu w kamerze. Test sprawdza też, czy pozycja znacznika środkowego zmienia się w przewidywalny sposób w przypadku każdego ujęcia. Odległość od środka znacznika środkowego do środka obrazu może się zmieniać w stałym tempie w zależności od współczynnika powiększenia aż do przełączenia fizycznej kamery lub może zmieniać się monotonicznie w kierunku lokalizacji tego samego znacznika po przełączeniu fizycznej kamery. Przed testowaniem na urządzeniu musisz zainstalować aplikację Jetpack Camera (JCA).

Testowane interfejsy API:

Przeszedł: względna wielkość zarejestrowanego znacznika ArUco jest zgodna z żądanym współczynnikiem powiększenia, co potwierdza, że aparat prawidłowo przybliża i oddala, a odległość znacznika od środka obrazu zmienia się zgodnie z kryteriami podanymi w opisie testu.

test_zoom, aby znaleźć kontur znacznika ArUco najbliższego środka;

Rys. 119. test_zoom, aby znaleźć kontur znacznika ArUco najbliższy środka.

test_low_latency_zoom

Testuje zachowanie zoomu o niskim opóźnieniu w kamerze. Wykonuje przechwytywanie w zakresie zoomu z android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) i sprawdza, czy znaczniki na wyjściowych obrazach pasują do współczynników powiększenia w metadanych przechwytywania. Ta sama sesja rejestrowania za pomocą aparatu jest używana do konwergencji 3A i do wykonywania zdjęć.

Testowane interfejsy API:

Prześlij: względna wielkość zarejestrowanego znacznika jest zgodna z metadanymi wyników w porównaniu ze współczynnikiem powiększenia.

test_preview_video_zoom_match

Testuje, czy podczas nagrywania i powiększania obraz w podglądzie i na wyjściu jest taki sam. Oblicza rozmiar znacznika najbliższego środka przy różnych współczynnikach powiększenia i sprawdza, czy rozmiar znacznika zwiększa się wraz ze wzrostem współczynnika powiększenia.

Testowane interfejsy API:

Prześlij: względna wielkość zarejestrowanego znacznika jest zgodna z żądanym współczynnikiem powiększenia w filmie i podglądzie.

Rysunek 120. HD_1280x720_key_frame.png (przed powiększeniem).

Rysunek 121. preview_1280x720_key_frame.png (przed powiększeniem).

Rysunek 122. HD_1280x720_key_frame.png (po powiększeniu).

Rysunek 123. Plik preview_1280x720_key_frame.png (po powiększeniu).

test_preview_zoom

Sprawdzanie, czy współczynnik powiększenia każdej ramki podglądu odpowiada odpowiednim metadanym rejestrowania z obiektywu ultraszerokokątnego na obiektyw szerokokątny. Test pobiera klatki podglądu w zakresie powiększenia i wykrywa znacznik ArUco znajdujący się najbliżej środka. Następnie sprawdza, czy pozycja znacznika środkowego zmienia się w przewidywalny sposób w przypadku każdego ujęcia. Odległość od środka znacznika środkowego do środka obrazu może się zmieniać w stałym tempie w zależności od współczynnika powiększenia aż do przełączenia fizycznej kamery lub może zmieniać się monotonicznie w kierunku lokalizacji tego samego znacznika po przełączeniu fizycznej kamery.

Testowane interfejsy API:

Prześlij: względna wielkość wybranego znacznika ArUco jest zgodna z raportowanym współczynnikiem powiększenia w odpowiednim wyniku przechwycenia w przypadku wszystkich klatek podglądu. Względna odległość wybranego znacznika od środka obrazu jest zgodna z podanym współczynnikiem powiększenia uzyskanym w wyniku wszystkich ramek podglądu.

test_preview_zoom obrazy pokazujące wybrany znacznik najbliżej środka

Rysunek 124. Obraz test_preview_zoom pokazujący wybrany znacznik najbliżej środka

test_session_characteristics_zoom

Testuje zakres współczynnika powiększenia dla wszystkich obsługiwanych konfiguracji sesji wymienionych w sekcji CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. W przypadku każdej z tych konfiguracji, jeśli CameraDeviceSetup#isSessionConfigurationSupportedzwraca wartość true, test sprawdza, czy można osiągnąć zakres współczynnika powiększenia zwracany przez CameraDeviceSetup#getSessionCharacteristics.

Testowane interfejsy API:

Pass: w przypadku każdego obsługiwanego SessionConfiguration wymienionego w CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION można osiągnąć zarówno minimalny, jak i maksymalny współczynnik powiększenia.

scene7

scene7 to prostokątny element podzielony na 4 równe kwadraty, z których każdy jest wypełniony innym kolorem. Pośrodku prostokąta znajduje się wykres nachylonej krawędzi do sprawdzania ostrości. Cztery znaczniki ArUco są wyrównane z 4 zewnętrznymi narożnikami prostokąta, aby ułatwić uzyskanie dokładnych współrzędnych głównego prostokątnego kadru przy różnych współczynnikach powiększenia.

scene7

Rysunek 125. Scena 7.

test_multi_camera_switch

Ten test sprawdza, czy podczas nagrywania podglądu przy różnych współczynnikach zoomu przełączanie między obiektywami ultraszerokokątnym (UW) i szerokokątnym (W) daje podobne wartości RGB.

Test wykorzystuje różne współczynniki powiększenia w ramach zdefiniowanego zakresu, aby wykonać dynamiczny zapis podglądu i określić punkt, w którym zmienia się fizyczne powiększenie kamery. Ten punkt oznacza przejście z obiektywu UW na obiektyw W.

Ramki uchwycone w miejscu przecięcia i przed nim są analizowane pod kątem automatycznej ekspozycji (AE), automatycznej regulacji balansu bieli (AWB) i automatycznego ustawiania ostrości (AF).

Sprawdzanie AE weryfikuje, czy zmiana luminacji mieści się w oczekiwanym zakresie zarówno w przypadku obrazów z obiektywem UW, jak i z obiektywem W. Sprawdzanie AWB weryfikuje, czy współczynniki czerwono-zielony i niebiesko-zielony mieszczą się w wartościach progowych zarówno w przypadku obrazów z obiektywem UW, jak i z obiektywem W. Sprawdzanie ostrości ocenia wartość oszacowania ostrości na podstawie średniej wartości gradienta między obrazami z obiektywu szerokokątnego i standardowego.

Jeśli podczas wykonywania tego testu efekt moiré zakłóca wyniki, użyj tabletu o wyższej rozdzielczości z listy zatwierdzonych przez ITS kamer.

Testowane interfejsy API:

Przeszedł: aby test zakończył się pomyślnie, testy AE i AWB muszą zakończyć się pomyślnie. Wyniki kontroli AF służą tylko do celów rejestrowania. Kryteria każdego z tych sprawdzeń:

Sprawdzanie AE: zmiana luminacji (wartość Y) między obrazami z obiektywu UW i W musi wynosić mniej niż 4% w przypadku wszystkich plam kolorów, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions. Jeśli obsługiwana jest tylko opcja ae_regions, to tylko wartości plamki koloru szarego muszą spełniać kryteria.
Sprawdzanie automatycznej regulacji balansu bieli: różnica między wartościami czerwono-zielonym i niebiesko-zielonym w przypadku obrazów z obiektywem szerokokątnym i standardowym musi być mniejsza niż 3% w przypadku szarego pola koloru oraz mniejsza niż 10% w przypadku innych pól koloru, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions.
Sprawdzanie AF: ostrość obrazu w przypadku obiektywu W musi być wyższa niż ostrość obrazu w przypadku obiektywu UW.

test_multi_camera_switch_gray_uw_y

Rysunek 126. Szara plama zrobiona przy użyciu obiektywu szerokokątnego.

test_multi_camera_switch_gray_w_y

Rysunek 127. Szara plama zrobiona obiektywem W.

scene8

scene8 to prostokątny kadr podzielony na 4 równe obszary, z których każdy zawiera portret zrobiony z różną ekspozycją lub nałożony z różnym odcieniem koloru (niebieski, zwiększona ekspozycja, zmniejszona ekspozycja, żółty). 4 znaczniki ArUco są wyrównane z 4 zewnętrznymi narożnikami prostokąta, aby uzyskać dokładne współrzędne głównej ramki prostokąta.

scene8 example

Rys. 128. Przykład sceny 8.

test_ae_awb_regions

Testuje, czy wartości RGB i luma różnią się podczas podglądu nagrywania w różnych regionach AE i AWB.

Test rejestruje 8-sekundowy podgląd, wykonując pomiar AE i AWB w każdym kwadracie przez 2 sekundy. Następnie test wyodrębnia kadr z każdego nagrania podglądu z każdego regionu i wykorzystuje wyodrębnione kadry do wykonania tych kontroli AE i AWB:

Sprawdzanie AE: sprawdza, czy klatka zmierzająca region o zmniejszonej ekspozycji ma zwiększoną wartość luminancji o więcej niż 1% w porównaniu z klatką zmierzającą region o zwiększonej ekspozycji. Sprawdza, czy obrazy są rozjaśniane podczas pomiaru ciemnego obszaru.
Sprawdzanie AWB: sprawdza, czy stosunek czerwonego do niebieskiego (średnich wartości RGB obrazu) w ramce z niebieskim obszarem pomiaru jest większy o ponad 2% niż w ramce z żółtym obszarem pomiaru. Dzięki temu obrazy mają zrównoważony kod RGB podczas pomiaru żółtego (ciepłego) lub niebieskiego (zimnego) regionu.

Testowane interfejsy API:

Przeszedł: oba testy AE i AWB zostały zaliczone.

test_ae_awb_regions_dark_region

Rysunek 129. Ramka zmierzająca ciemny obszar z podwyższoną ekspozycją.

test_ae_awb_regions_light_region

Rysunek 130. Ramka pomiaru ekspozycji w jaśniejszym obszarze z niższą ekspozycją.

Mechanizmy niepowodzenia:

Dokładne wykrywanie wszystkich 4 znaczników ArUco jest niezbędne w przypadku tego testu. Jeśli początkowe wykrycie zawiedzie, system spróbuje wykryć twarz po raz drugi, używając czarno-białej wersji obrazu. Ten obraz w szarościach przedstawia dodatkowy etap przetwarzania:

Rysunek 131. Niezgodność znaczników ArUco.

test_color_correction_mode_cct

Testy COLOR_CORRECTION_MODE w różnych temperaturach i odcieniach kolorów, weryfikujące zmiany współczynników RGB w stosunku do sceny scene8.

Testowane interfejsy API:

Pass: współczynniki RGB wskazują przewidywane wzrosty lub spadki w stosunku do wybranych temperatur i odsetek kolorów.

Testowanie kryteriów pomijania

Test test_color_correction_mode_cct jest pomijany, jeśli zostanie spełnione któreś z tych kryteriów:

Urządzenie ma pierwszy poziom interfejsu API (first_api_level) na poziomie 35 lub niższym.
Urządzenie nie wyświetla reklam COLOR_CORRECTION_MODE_CCT w COLOR_CORRECTION_AVAILABLE_ABERRATION_MODES.

scene9

scene9 składa się z tysięcy kół o losowych rozmiarach i kolorach, które tworzą scenę o bardzo niskiej powtarzalności, aby przetestować algorytmy kompresji JPEG.

scene9 example

Rys. 132. Przykład sceny 9.

test_jpeg_high_entropy

Testuje, czy kompresja JPEG w aparacie działa poprawnie w przypadku scene9 o wysokiej entropii i współczynniku jakości JPEG ustawionym na 100%. Wzrost współczynnika powiększenia pozwala sprawdzić, czy obraz wyświetlany na tablecie wypełnia pole widzenia kamery.

Testowane interfejsy API:

Przeszedł:plik JPEG został prawidłowo skompresowany, zapisany i odczytany z dysku.

test_jpeg_quality

Testuje jakość kompresji JPEG w aparacie. Przesyłaj różne jakości JPEG-a za pomocą funkcji android.jpeg.quality i sprawdzaj, czy tabele kwantyzacji zmieniają się prawidłowo.

Testowane interfejsy API:

Przekaz: wraz ze wzrostem jakości zmniejsza się macierz kwantyzacji. (Macierz reprezentuje współczynnik podziału).

Średnie wartości luminacji i chromatyczności w matryce DQT aparatu tylnego Pixela 4 w porównaniu z jakością JPEG

Rysunek 133. Średnie wartości luminacji i chromatyczności w macierzach DQT tylnego aparatu Pixela 4 w porównaniu z jakością JPEG.

Przykład testu test_jpeg_quality zakończonego niepowodzeniem

Rysunek 134. Przykład nieudanego testu

scene_video

scene_video to scena wideo składająca się z 4 kółek w różnych kolorach, które poruszają się w przód i w tył z różną częstotliwością klatek na białym tle.

Rys. 135. Przykład pliku scene_video.

test_preview_frame_drop

Testuje, czy żądana częstotliwość klatek podglądu jest utrzymywana w dynamicznej scenie. Ten test jest przeprowadzany na wszystkich kamerach, które są dostępne dla aplikacji innych firm.

Testowane interfejsy API:

Przeszedł: częstotliwość klatek podglądu jest maksymalną wartością z zakresu żądanej częstotliwości klatek, a średnia odchylenie między kolejnymi klatkami jest mniejsze od względnej tolerancji ustawionej w teście.

scene_extensions

Testy scene_extensions dotyczą rozszerzeń aparatu i wymagają użycia Camera ITS-in-a-Box, ponieważ wymagają precyzyjnego kontrolowania środowiska testowego. Dodatkowo należy kontrolować wszelkie wycieki światła. Może to wymagać przykrycia stanowiska testowego, urządzenia testowego i tabletu szmatką oraz wyeliminowania wycieku światła z ekranu przedniego urządzenia testowego.

scene_hdr

Scena scene_hdr składa się z portretu po lewej stronie i kodu QR o niskim kontraście po prawej.

scene_hdr

Rys. 136. Przykład scene_hdr.

test_hdr_extension

Testuje rozszerzenie HDR. Wykonuje uchwyty z włączoną i wyłączoną wtyczką i sprawdza, czy wtyczka ułatwia wykrywanie kodu QR.

Testowane interfejsy API:

Przepuść: rozszerzenie HDR zmniejsza liczbę zmian kontrastu potrzebnych do wykrycia kodu QR lub zmniejsza gradient w przypadku kodu QR.

scene_low_light

Scena scene_low_light składa się z siatki kwadratów w różnych odcieniach szarości na czarnym tle. Siatka kwadratów jest otoczona czerwoną obwódką. Kwadraty są ułożone w orientacji krzywej Hilberta.

Przykład scene_low_light

Rys. 137. Przykład scene_low_light.

test_night_extension

Testuje rozszerzenie Noc. Wykonuje przechwytywanie z włączonym rozszerzeniem i wykonuje te czynności:

Wykrywanie obecności 20 kwadratów
Oblicza luminancję ograniczoną przez każdy kwadrat.
Oblicza średnią wartość luminacji dla pierwszych 6 kwadratów zgodnie z orientacją siatki krzywej Hilberta
Oblicza różnicę wartości luminancji kolejnych kwadratów (np. kwadrat2 – kwadrat1) aż do kwadratów 5 i 6 (kwadrat6 – kwadrat5) oraz oblicza średnią z 5 obliczonych różnic.

W przypadku urządzeń z Androidem 16 lub nowszym prośba o przechwycenie obejmuje zmierzony obszar odpowiadający prostokątowi ograniczającemu siatkę kwadratów. Ta zmiana wpływa na kryteria progu.

Testowane interfejsy API:

Pass:

W przypadku urządzeń z Androidem 16 lub nowszym średnia wartość luma pierwszych 6 kwadratów musi wynosić co najmniej 80, a średnia różnica wartości luma kolejnych kwadratów (do kwadratu 5) musi wynosić co najmniej 18, 75.
W przypadku urządzeń z Androidem 15 lub starszym średnia wartość luminancji pierwszych 6 kwadratów musi wynosić co najmniej 85, a średnia różnica wartości luminancji kolejnych kwadratów do kwadratu 5 i 6 musi wynosić co najmniej 17.

Na wykresie luminancji widać, jak wygląda wynik testu, który kwalifikuje się do przejścia.

Przykład testu polegającego na wykonaniu zdjęcia nocnej sceny przy słabym oświetleniu

Rysunek 138. Przykład testu polegającego na wykonaniu zdjęcia nocnej sceny przy słabym oświetleniu.

test_low_light_boost_extension

Testowanie trybu AE wzmacniania w słabym oświetleniu. Jeśli Camera2 obsługuje tryb AE z wzmocnieniem w warunkach słabego oświetlenia, test jest wykonywany w przypadku Camera2. Jeśli rozszerzenie aparatu w trybie nocnym jest obsługiwane i obsługuje tryb AE z ulepszonym trybem automatycznym w przypadku słabego oświetlenia, test jest również wykonywany w przypadku rozszerzenia aparatu w trybie nocnym. Ten test ustawia tryb AE na wzmocnienie w warunkach słabego oświetlenia, pobiera kadr z podglądu i wykonuje te czynności:

Wykrywa obecność 20 pudeł
Oblicza luminancję ograniczoną przez każdy kwadrat
Oblicza średnią wartość luminacji dla pierwszych 6 kwadratów zgodnie z orientacją siatki krzywej Hilberta
Oblicza różnicę wartości luminancji kolejnych kwadratów (np. kwadrat2 – kwadrat1) aż do kwadratów 5 i 6 (kwadrat6 – kwadrat5) oraz oblicza średnią z 5 obliczonych różnic.

Testowane interfejsy API:

Pass:

W przypadku urządzeń z Androidem 16 lub nowszym średnia wartość luminancji pierwszych 6 kwadratów musi wynosić co najmniej 54, a średnia różnica wartości luminancji kolejnych kwadratów (do kwadratu 5 i 6) musi wynosić co najmniej 17.
W przypadku urządzeń z Androidem 15 lub starszym średnia wartość luminancji pierwszych 6 kwadratów musi wynosić co najmniej 70, a średnia różnica wartości luminancji kolejnych kwadratów do kwadratu 5 i 6 musi wynosić co najmniej 18.

scene_tele

Kluczowym wymaganiem w przypadku testów scene_tele jest to, aby odległość od tablicy była większa niż minimalna odległość ostrości teleobiektywu. Ponieważ minimalna odległość ostrości może się różnić w zależności od urządzenia, musisz skonfigurować ustawienia tak, aby pasowały do konkretnego teleobiektywu.

Ustawienie scene_tele na podstawie odległości ostrości kamery szerokokątnej i teleobiektywu

Ilustracja 139. Ustawienie scene_tele na podstawie odległości ostrości szerokiego kąta i teleobiektywu.

Więcej informacji o konfigurowaniu sprzętu testowego znajdziesz w artykule Konfigurowanie urządzenia do rozszerzania zasięgu teleskopu.

scene6_tele

Scena scene6_tele składa się z siatki markerów ArUco na białym tle.

Jeśli scene6_tele z modułowego zestawu jest prześwietlone, zdejmij płytkę przednią modułowego zestawu.

Odłącz platformę testową WFoV od przedłużenia i usuń uchwyt na telefon.

Odłącz platformę testową WFoV od przedłużenia i usuń uchwyt na telefon

Rysunek 140. Odłącz platformę testową WFoV od przedłużenia i usuń uchwyt na telefon.

remove_front_plate

Rysunek 141. Zdejmij płytę przednią.

test_zoom_tele

Testuje zachowanie zoomu aparatu od obiektywu szerokokątnego do teleobiektywu. Test jest identyczny jak test_zoom, ale sprawdza działanie zoomu aparatu od obiektywu szerokokątnego do teleobiektywu.

Testowane interfejsy API:

Przeszedł: względna wielkość zarejestrowanego znacznika ArUco jest zgodna z żądanym współczynnikiem powiększenia, co potwierdza, że aparat prawidłowo przybliża obraz, a odległość znacznika od środka obrazu zmienia się zgodnie z kryteriami wymienionymi w test_zoom.

test_preview_zoom_tele

Testuje zachowanie zoomu w przypadku ramek podglądu z obiektywu szerokokątnego do teleobiektywu. Test jest identyczny jak test_preview_zoom, ale sprawdza zachowanie zoomu aparatu w przypadku ramek podglądu od obiektywu szerokokątnego do teleobiektywu.

Testowane interfejsy API:

Przeszedł: rozmiar markera ArUco jest zgodny z żądanym współczynnikiem powiększenia, aby sprawdzić, czy aparat prawidłowo przybliża obraz, a odległość markera od środka obrazu zmienia się zgodnie z kryteriami wymienionymi w test_preview_zoom.

scene7_tele

scene7_tele jest identyczny z scene7, ale skonfigurowany do testowania teleobiektywu. Jest to prostokąt podzielony na 4 równe ćwiartki, z których każdy jest wypełniony innym kolorem. Pośrodku prostokąta znajduje się wykres nachylonej krawędzi do sprawdzania ostrości. Cztery znaczniki ArUco są wyrównane z 4 zewnętrznymi narożnikami prostokąta, aby ułatwić uzyskanie dokładnych współrzędnych głównego prostokątnego kadru przy różnych współczynnikach powiększenia.

test_multi_camera_switch_tele

Ten test sprawdza, czy podczas nagrywania podglądu przy różnych współczynnikach zoomu przełączanie między obiektywem szerokokątnym (W) a teleobiektywem (tele) powoduje podobne wartości RGB.

Ramki uchwycone w miejscu przecięcia i przed nim są analizowane pod kątem AE, AWB i AF.

Sprawdzanie AE weryfikuje, czy zmiana luminacji mieści się w oczekiwanym zakresie zarówno w przypadku zdjęć z obiektywem szerokokątnym, jak i z teleobiektywem. Sprawdzanie AWB weryfikuje, czy współczynniki czerwono-zielony i niebiesko-zielony mieszczą się w wartościach progowych zarówno w przypadku zdjęć z obiektywem szerokokątnym, jak i z teleobiektywem. Sprawdzanie ostrości ocenia wartość oszacowania ostrości na podstawie średniej wartości gradientu między obrazami z obiektywu szerokokątnego i teleobiektywu.

Testowane interfejsy API:

Zaliczenie: aby test zakończył się pomyślnie, wszystkie testy AE, AWB i AF muszą zakończyć się pomyślnie. Oto kryteria poszczególnych kontroli:

Sprawdzanie AE: zmiana luminacji między obrazami z obiektywu szerokokątnego i teleobiektywu musi być mniejsza niż 4%.
Sprawdzanie AWB: w przestrzeni kolorów LAB delta C między czerwono-zielonym a niebiesko-zielonym w przypadku obiektywów szerokokątnych i teleobiektywów nie może przekraczać 10.
Sprawdzanie AF: ostrość obrazu obiektywu tele musi być wyższa niż ostrość obiektywu szerokokątnego.

scene_flash

Testy scene_flash wymagają ciemnej sceny w polu sensor fusion.

test_auto_flash

Testuje, czy automatyczna lampa błyskowa jest włączana w ciemnych warunkach dla tylnego i przedniego aparatu. W przypadku przednich aparatów automatyczna lampa błyskowa wykorzystuje ekran do oświetlenia sceny, a nie fizyczną lampę błyskową. Test sprawdza, czy automatyczne włączanie lampy błyskowej działa prawidłowo, sprawdzając, czy środek obrazu kafelka jest jaśniejszy, gdy włączona jest automatyczna lampa błyskowa. Aby włączyć automatyczne miganie, światła w urządzeniu testowym muszą być wyłączone. Można je wyłączyć automatycznie za pomocą kontrolera Arduino. Aby test działał prawidłowo, scena musi być całkowicie ciemna. Przed testowaniem na urządzeniu musisz zainstalować aplikację Jetpack Camera (JCA). Automatyczna lampa błyskowa w przypadku tylnych aparatów zależy od stanu AE, ale automatyczna lampa błyskowa w przypadku przednich aparatów nie zależy od AE i jest zawsze włączana.

Testowane interfejsy API:

Prześlij: środek obrazu kafelka z włączoną automatyczną lampą błyskową jest jaśniejszy niż oryginalny obraz sceny dla wszystkich kamer.

test_flash_strength

Testuje, czy kontrola mocy błysku w trybie SINGLE jest prawidłowo zaimplementowana.

Sprawdzanie, czy jeśli urządzenie obsługuje kontrolę siły błysku podczas korzystania z kamery w trybie SINGLE, siła błysku zmienia się w zależności od różnych poziomów siły. Sprawdzanie, czy kontrola siły błysku działa z użyciem różnych AE_MODES. Jeśli na przykład tryb automatycznej ekspozycji to ON lub OFF, poziom siły błysku ma wpływ na jasność, a jeśli tryb to ON_AUTO_FLASH, poziom siły błysku nie ma wpływu na jasność.

Aby przeprowadzić test, należy wyłączyć światła w urządzeniu testowym. Światła można wyłączyć automatycznie za pomocą kontrolera Arduino. Aby test działał prawidłowo, scena musi być całkowicie ciemna.

Testowane interfejsy API:

Pass:

Gdy tryb automatycznej ekspozycji to ON lub OFF, jasność plam obrazu wzrasta wraz ze wzrostem poziomu siły błysku od braku błysku do FLASH_SINGLE_STRENGTH_MAX_LEVEL. Gdy tryb automatycznej ekspozycji to ON_AUTO_FLASH, różnica w jasności plam obrazu mieści się w dopuszczalnych granicach, ponieważ poziom siły błysku zwiększa się od FLASH_SINGLE_STRENGTH_MAX_LEVEL do FLASH_SINGLE_STRENGTH_MAX_LEVEL.

test_led_snapshot

Sprawdzanie, czy migawki LED nie nasycą ani nie zabarwią obrazu.

Ten test dodaje do Sensor Fusion Box kontroler oświetlenia, aby sterować światłami. Gdy światła są ustawione na OFF, test wykonuje przechwycenie z ustawieniami trybu AUTO_FLASH na ON. Podczas tego testu wykonywana jest sekwencja przed zrobieniem zdjęcia z użyciem aePrecapture, w której parametr aePrecapture jest ustawiony na START, a intencja robienia zdjęcia na Preview, aby wykonać zdjęcie przy użyciu lampy błyskowej.

Ponieważ obraz ma wyraźny punkt naświetlenia z powodu użycia lampy błyskowej, test oblicza średnią wartość obrazu z lampy błyskowej dla całego obrazu i sprawdza, czy ta wartość mieści się w zakresie (68, 102). Aby sprawdzić, czy obraz ma prawidłowo zrównoważony balans bieli, test oblicza współczynniki czerwono-zielony i niebiesko-zielony oraz sprawdza, czy mieszczą się one w przedziale od 0,95 do 1,05.

Testowane interfejsy API:

Przechodzi: współczynniki czerwono-zielony i niebiesko-zielony mieszczą się w zakresie od 0,95 do 1,05. Średnia wartość obrazu z błyskiem mieści się w zakresie (68, 102).

test_night_mode_indicator

Testuje działanie wskaźnika trybu nocnego, czyli funkcji, która informuje, czy aparat działa w warunkach słabego oświetlenia i czy skorzysta z rozszerzenia aparatu w trybie nocnym. Ta funkcja jest dostępna tylko na urządzeniach, które obsługują rozszerzenia trybu nocnego w aparacie.

Ten test sprawdza, czy wskaźnik trybu nocnego prawidłowo odzwierciedla warunki oświetleniowe podczas podglądu w aparacie. Test wykonuje te czynności:

Inicjowanie: test inicjuje obiekt ItsSession i pobiera właściwości kamery. Nawiązuje też połączenie z kontrolerem oświetlenia.
Warunki pominięcia: test jest pomijany, jeśli urządzenie nie obsługuje wymaganego poziomu interfejsu API lub funkcji wskaźnika trybu nocnego.
Camera2 Session:
- Test rozpoczyna sesję przechwytywania podglądu za pomocą sesji Camera2.
- Światło jest włączone i zrobiono ramkę podglądu.
- Test sprawdza, czy wskaźnik trybu nocnego jest w stanie OFF.
- Światło jest wyłączone, a ramka podglądu została zarejestrowana.
- Test sprawdza, czy wskaźnik trybu nocnego jest w stanie ON.
Sesja rozszerzenia aparatu:
- Test powtarza tę samą procedurę co w przypadku sesji Camera2, ale z użyciem sesji CameraExtension z rozszerzeniem EXTENSION_NIGHT.
Usuwanie: test zamyka ItsSession i zwalnia kontroler oświetlenia.

Testowane interfejsy API:

android.extension.nightModeIndicator

Pass:

Gdy światło jest włączone, wskaźnik trybu nocnego powinien być w stanie OFF.
Gdy światło jest wyłączone, wskaźnik trybu nocnego powinien być w stanie ON.
Dotyczy sesji Camera2 i CameraExtension.

test_preview_min_frame_rate

Testuje, czy liczba klatek podglądu zmniejsza się prawidłowo w ciemnej scenie. Aby test działał prawidłowo, światła w urządzeniu testowym muszą być wyłączone przez kontroler lub ręcznie przez operatora testu.

Testowane interfejsy API:

Przeszedł test: liczba klatek w podglądzie jest równa minimalnej wartości z zakresu żądanej liczby klatek, a różnica między klatkami jest mniejsza od bezwzględnej tolerancji określonej w teście.

test_torch_strength

Testuje, czy kontrola mocy błysku w trybie TORCH jest prawidłowo zaimplementowana.

Sprawdzanie, czy jeśli urządzenie obsługuje kontrolę natężenia błysku podczas korzystania z kamery w trybie TORCH, natężenie światła zmienia się w zależności od różnych poziomów natężenia. Sprawdzanie, czy kontrola siły błysku działa z użyciem różnych AE_MODES. Jeśli na przykład tryb automatycznej ekspozycji to ON lub OFF, poziom siły błysku ma wpływ na jasność, a jeśli tryb to ON_AUTO_FLASH, poziom siły błysku nie ma wpływu na jasność. Sprawdzanie, czy moc lampy pozostaje taka sama przez cały czas trwania migawki, symulując sesję nagrywania filmu. Aby przeprowadzić test, należy wyłączyć światła w testowanym urządzeniu. Można je wyłączyć automatycznie za pomocą kontrolera Arduino. Aby test działał prawidłowo, scena musi być całkowicie ciemna.

Testowane interfejsy API:

Pass:

Gdy tryb automatycznej ekspozycji to ON lub OFF, jasność plam z ekspozycji długiej migawki zwiększa się wraz ze wzrostem poziomu mocy lampy błyskowej od braku lampy błyskowej do FLASH_TORCH_STRENGTH_MAX_LEVEL. Gdy tryb automatycznej ekspozycji to ON_AUTO_FLASH, różnica w jasności poszczególnych ujęć w sekwencji mieści się w tolerancji, gdy poziom siły lampy błyskowej zwiększa się od braku lampy do FLASH_TORCH_STRENGTH_MAX_LEVEL.

sensor_fusion

Testy fuzji czujników wymagają określonego ruchu telefonu przed szachownicą i znacznikami ArUco. Aby uzyskać optymalne wyniki, sprawdź, czy karta testowa jest zamontowana na płasko. Wykresy, które nie są płaskie, wpływają na obliczenia rotacji w przypadku wielu testów. Wydruk musi wypełniać tył modułu sensorów hybrydowych, drukując w formacie 17 x 17 cali. (43 x 43 cm). Testy sensor_fusion można zautomatyzować za pomocą Sensor Fusion Box.

Wykres danych z różnych czujników

Rysunek 142. Wykres danych z sensorów.

Wykres łączenia danych z czujników w Rig

Rysunek 143. Schemat czujnika fuzji, który wypełnia tył pola czujnika fuzji.

test_lens_intrinsic_calibration

Testy, które sprawdzają, czy optyczny środek obiektywu zmienia się, gdy obiektyw się porusza z powodu optycznej stabilizacji obrazu (OIS). Jeśli próbki obiektywu są obsługiwane, testuje, czy środek optyczny próbek obiektywu zmienia się, gdy obiektyw porusza się z powodu OIS.

Testowane interfejsy API:

Pass: optyczny środek obiektywu zmienia się o co najmniej 1 piksel. Jeśli są obsługiwane próbki obiektywu, optyczne środki obiektywu próbek obiektywu zmieniają się o co najmniej 1 piksel.

Na rysunku poniżej przedstawiono przykładowy wykres test_lens_intrinsic_calibration pokazujący zmiany punktów głównych w pikselach w przypadku każdego kadru:

Rysunek 144. Przykład wykresu test_lens_intrinsic_calibration przedstawiającego zmiany głównych punktów w pikselach w przypadku każdej klatki.

test_multi_camera_frame_sync

Testuje, czy sygnatury czasowe ramki uchwycone przez logiczną kamerę mieszczą się w zakresie 10 ms, obliczając kąty kwadratów w siatce, aby określić sygnaturę czasową.

Testowane interfejsy API:

Pass: kąt między obrazami z każdej kamery nie zmienia się znacząco podczas obracania telefonu.

test_preview_distortion

Sprawdzanie, czy zniekształcenia są korygowane w ramkach podglądu wykonanych przy różnych poziomach powiększenia. W przypadku każdej ramki podglądu test oblicza punkty idealne na podstawie informacji o właściwościach aparatu i oprogramowania.

Na przykładowym obrazie punkty idealne są zaznaczone na zielono, a rzeczywiste – na czerwono. Błąd zniekształcenia jest obliczany na podstawie odległości RMS w pikselach między rzeczywistymi a idealnymi punktami. Zielone i czerwone wyróżnienia na obrazie służą do wizualnego wykrywania obszaru błędu zniekształcenia.

Rysunek 145. Obraz kratki z zielonymi punktami idealnymi i czerwonymi punktami rzeczywistymi

Testowane interfejsy API:

Przeszedł: skumulowany błąd zniekształcenia w ramce podglądu jest mniejszy niż próg ustawiony w teście.

test_preview_stabilization

Testy wykazały, że stabilizowany podgląd filmu obraca się mniej niż żyroskop.

Testowane interfejsy API:

Przechodzi: maksymalny kąt obrotu w ramkach klatek jest mniejszy niż 70% obrotu żyroskopu.

Oto przykładowe filmy ze stabilizacja i bez niej:

Rysunek 146. Przykładowy film ze stabilizacja

Rysunek 147. Przykładowy film bez stabilizacji.

test_sensor_fusion

Testuje różnicę w dacie i godzinie między aparatem a żyroskopem w przypadku aplikacji AR i VR. Telefon jest 10 razy obracany o 90 stopni przed wzorem szachownicy. Czas trwania ruchu to około 2 s. Ten test jest pomijany, jeśli nie ma używki żyroskopu lub jeśli parametr źródła sygnatury czasowejREALTIME nie jest włączony.

Test test_sensor_fusion generuje kilka wykresów. Dwa najważniejsze wykresy do debugowania to:

test_sensor_fusion_gyro_events: pokazuje zdarzenia żyroskopu telefonu podczas testu. Ruch w kierunkach x i y oznacza, że telefon nie jest pewnie zamocowany na płycie montażowej, co zmniejsza prawdopodobieństwo zaliczenia testu. Liczba cykli na wykresie zależy od szybkości zapisywania klatek.

Ilustracja 148. Przykład zdarzeń test_sensor_fusion z użyciem akcelerometru.
test_sensor_fusion_plot_rotations: pokazuje wyrównanie żyroskopu i zdarzeń z kamery. Wykres musi pokazywać ruch zgodny między kamerą a żyroskopem z dokładnością do +/-1 ms.

Rys. 149. Przykład obrotów wykresu test_sensor_fusion.

Testowane interfejsy API:

Przechodzi: przesunięcie sygnału zegarowego z kamery i żyroskopu jest mniejsze niż 1 ms zgodnie z 7.3.9 Wysokoprecyzyjne czujniki w CDD.

Mechanizmy niepowodzenia:

Błąd przesunięcia: przesunięcie kamery-czujnika żyroskopu nie jest prawidłowo skalibrowane w zakresie +/-1 ms.
Utrata klatek: łańcuch przetwarzania nie jest wystarczająco szybki, aby zarejestrować 200 klatek pod rząd.
Błędy gniazda: adb nie może niezawodnie połączyć się z badanym urządzeniem przez wystarczająco długi czas, aby wykonać test.
Wykres nie jest płaski. Wykres test_sensor_fusion_plot_rotationszawiera klatki, w których obrót żyroskopu i kamery znacznie się różni, gdy kamera obraca się wokół części wykresu, które nie są płaskie.
Kamera nie jest zamontowana płasko. Wykres test_sensor_fusion_gyro_events pokazuje ruch w płaszczyźnie XY. Ten błąd występuje częściej w przypadku przednich aparatów, ponieważ tylny aparat często ma uniesioną część, która jest wyższa od reszty obudowy telefonu, co powoduje przechylenie podczas montażu tyłu telefonu na płycie montażowej.

test_video_stabilization

Testy wykazały, że stabilizowany film obraca się mniej niż żyroskop.

Testowane interfejsy API:

Przechodzi: maksymalny kąt obrotu w ramach klatek jest mniejszy niż 60% obrotu żyroskopu.

Poniżej znajdziesz przykładowe filmy z stabilizacją i bez niej.

Rysunek 150. Przykładowy film ze stabilizacja

Rysunek 151. Przykładowy film bez stabilizacji.

test_video_stabilization_jca

Testy wykazały, że stabilizacja wideo wykonanego za pomocą JCA powoduje mniejsze obracanie niż w przypadku żyroskopu. Przed testowaniem na urządzeniu musisz zainstalować JCA.

Testowane interfejsy API:

Przepuszczenie: maksymalne przesunięcie kątowe na klatkach wyodrębnionych z filmu zarejestrowanego za pomocą JCA jest mniejsze niż 70% obrotu żyroskopu.

feature_combination

Testy feature_combination sprawdzają, czy funkcje działają prawidłowo, gdy włączonych jest kilka funkcji aparatu jednocześnie. Te testy wykorzystują ten sam obraz szachownicy, który jest używany w scenie fuzji danych z czujników.

test_feature_combination

Testuje wszystkie kombinacje różnych strumieni, tryb stabilizacji obrazu, docelowy zakres liczby klatek na sekundę, 10-bitowy film HDR i Ultra HDR, które są obsługiwane przez urządzenie z kamerą.

W przypadku Androida 16 i nowszych test wykonuje wszystkie kombinacje obsługiwanych funkcji i zapisuje wyniki w pliku proto. Zasady sprawdzania błędów są wywoływane tylko w przypadku kombinacji funkcji, dla których funkcja isSessionConfigurationSupported zwraca wartość True.

Testowane interfejsy API:

Przekaz: w przypadku każdej obsługiwanej kombinacji funkcji:

Jeśli włączona jest stabilizacja podglądu, strumień podglądu jest stabilizowany.
Liczba klatek na sekundę w podglądzie mieści się w skonfigurowanym zakresie AE_TARGET_FPS_RANGE.
Przestrzeń kolorów nagranego strumienia podglądu jest zgodna z ustawieniami.
Zdjęcie w ultra HDR ma prawidłową mapę wzmocnienia.

scene_ip

W Androidzie 16 i nowszych scena scene_ip umożliwia sprawdzanie zgodności zdjęć między domyślną aplikacją aparatu a aplikacją Jetpack Camera (JCA), aby wykrywać główne różnice między zrobionymi zdjęciami. JCA odtwarza obrazy zrobione aplikacją do mediów społecznościowych i zawiera obraz odniesienia, który aplikacje do mediów społecznościowych przetwarzają i ulepszają.

Wymagania dotyczące konfiguracji sprzętu

Do testów scene_ip wymagana jest następująca konfiguracja sprzętowa:

Testy są wykonywane na kamerze Gen2 ITS-in-a-box.
Sterowniki oświetlenia i serwomechanizmów, które są częścią urządzenia Gen2, służą do sterowania środowiskiem testowym.
W ramach platformy Gen2 znajduje się wykres funkcji testowej.

test_chart_gen2

Rysunek 152. Przykład Gen2chart_sample.

Testowanie kryteriów pomijania

Testy scene_ip są pomijane, jeśli zostanie spełnione którekolwiek z tych kryteriów:

Urządzenie ma pierwszy poziom interfejsu API (first_api_level) na poziomie 35 lub niższym.
Urządzenie nie jest telefonem z przednim i tylnym głównym aparatem (np. tabletem lub telewizorem).

test_default_jca_ip

Wykonuje testy wykresu funkcji w kontrolowanych warunkach oświetleniowych za pomocą domyślnej aplikacji do obsługi aparatu i JCA. Wykonuje te czynności:

Pole widzenia: sprawdza, czy domyślna aplikacja do obsługi aparatu i JCA mają takie samo pole widzenia. Ta kontrola korzysta z funkcji kodu QR w środku, wyodrębnionego z obrazu wykresu.
Jasność: sprawdza, czy różnica jasności zmierzona między domyślną aplikacją aparatu a JCA nie przekracza 10. Ten test używa poprawki dynamicznego zakresu do pomiaru jasności.
Balans bieli: sprawdza, czy różnica między balansem bieli w domyślnej aplikacji aparatu a JCA nie przekracza 4. Ten test używa poprawki dynamicznego zakresu do pomiaru jasności.

Przejście podstawowej sekcji: test przechodzi testy pola widzenia, jasności i balansu bieli. W Androidzie 16 ten test nie jest wymagany (NOT_YET_MANDATED).

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

scene0

test_jitter

test_metadata

test_request_capture_match

test_sensor_events

test_solid_color_test_pattern

test_test_pattern

test_tonemap_curve

test_unified_timestamp

test_vibration_restriction

scene1_1

test_ae_precapture_trigger

test_auto_vs_manual

test_black_white

test_burst_capture

test_burst_sameness_manual

test_crop_region_raw

test_crop_regions

test_ev_compensation

test_exposure_x_iso

test_latching

test_linearity

test_locked_burst

scene1_2

test_param_color_correction

test_param_flash_mode

test_param_noise_reduction

test_param_shading_mode

test_param_tonemap_mode

test_post_raw_sensitivity_boost

test_raw_exposure

test_reprocess_noise_reduction

test_tonemap_sequence

test_yuv_jpeg_all

test_yuv_plus_dng

scene1_3

test_capture_result

test_dng_noise_model

test_jpeg

test_raw_burst_sensitivity

test_raw_sensitivity

test_yuv_plus_jpeg

test_yuv_plus_raw

test_sensitivity_priority

test_exposure_time_priority

scene2_a

test_autoframing

test_display_p3

test_effects

test_exposure_keys_consistent

test_format_combos

test_num_faces

test_reprocess_uv_swap

scene2_b

test_preview_num_faces

test_yuv_jpeg_capture_sameness

scene2_c

test_num_faces

test_jpeg_capture_perf_class

test_camera_launch_perf_class

test_default_camera_hdr

scene2_d

test_preview_num_faces

scene2_e

test_continuous_picture

test_num_faces

scene2_f

test_preview_num_faces

scene2_g

test_preview_num_faces

scene3

test_edge_enhancement

test_flip_mirror

test_imu_drift

test_landscape_to_portrait

test_lens_movement_reporting

test_reprocess_edge_enhancement

scene4

test_30_60fps_preview_fov_match

Testy ITS kamery