W 2026 r., aby dostosować się do naszego modelu stabilnego rozwoju trunk i zapewnić stabilność platformy w ekosystemie, będziemy publikować kod źródłowy w AOSP w drugim i czwartym kwartale. Do tworzenia i współtworzenia AOSP używaj gałęzi android-latest-release. Gałąź manifestu android-latest-release będzie zawsze odwoływać się do najnowszej wersji przesłanej do AOSP. Więcej informacji znajdziesz w artykule Zmiany w AOSP.

Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Testy ITS kamery

Na tej stronie znajdziesz pełną listę testów w ramach zestawu testów Camera Image Test Suite (ITS), który jest częścią weryfikatora Android Compatibility Test Suite (CTS). Testy ITS to testy funkcjonalne, co oznacza, że nie mierzą jakości obrazu, ale sprawdzają, czy wszystkie reklamowane funkcje aparatu działają zgodnie z oczekiwaniami. Ten dokument zawiera informacje dla deweloperów i testerów na temat tego, co robią poszczególne testy i jak debugować błędy testów.

Testy ITS są aktualizowane lub dodawane w każdej wersji Androida, zgodnie z informacjami podanymi w informacjach o wersji Camera ITS dla danej wersji Androida. Aktualizacje są wprowadzane na podstawie błędów zgłaszanych przez użytkowników lub deweloperów. Dodatki są wprowadzane na podstawie błędów zgłaszanych przez użytkowników lub deweloperów oraz weryfikacji prawidłowego działania nowych funkcji platformy aparatu.

W Androidzie 17 i nowszych testy Camera ITS są podzielone na 2 aktywności w aplikacji CTS Verifier, aby umożliwić równoległe wykonywanie i skrócić czas testowania: jedna aktywność dotyczy testów feature_combination i sensor_fusion, a druga – wszystkich pozostałych testów. Więcej informacji znajdziesz w sekcji Skracanie czasu testowania.

Testy Camera ITS są filtrowane według 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 ro.product.first_api_level do bramkowania testów dodanych na określonym poziomie interfejsu API, które sprawdzają, czy funkcje na niższych poziomach interfejsu API nie powodują negatywnych wrażeń użytkowników. ITS używa ro.vendor.api_level do blokowania testów funkcji dodanych na określonym poziomie interfejsu API, które wymagają nowych możliwości sprzętowych. Jeśli dla urządzenia zdefiniowano ro.odm.build.media_performance_class, ITS wymaga uruchomienia określonych testów w zależności od poziomu MPC.

Testy są pogrupowane według scen w tych sekcjach:

Sceny testowe na tablecie

scene0: przechwytywanie metadanych, jitter, żyroskop, wibracje
scene1: ekspozycja, czułość, kompensacja wartości ekspozycji (EV), YUV a JPEG i RAW
scene2: wykrywanie twarzy, testy wymagające scen kolorowych.
scene3: ulepszanie krawędzi, ruch obiektywu
scene4: format obrazu, przycinanie, pole widzenia.
scene6: Zoom
scene7: przełącznik wielu kamer
scene8: pomiar regionu automatycznej ekspozycji (AE) i automatycznego balansu bieli (AWB)
scene9: kompresja JPEG
scene_extensions: rozszerzenia aparatu
scene_tele: Przełączanie teleobiektywu
scene_video: pominięte klatki

Sceny testowe oparte na zestawie Gen2 / sensor_fusion

feature_combination: kombinacje funkcji
scene_flash: automatyczna lampa błyskowa, minimalna liczba klatek
scene_gen2_chart: testy z użyciem papierowej tablicy Gen2.
scene_ip: równoważność obrazu między domyślną aplikacją aparatu a aplikacją Jetpack Camera App (JCA)
sensor_fusion: przesunięcie czasu aparatu i żyroskopu

Scena testowa z dyfuzorem

scene5: winietowanie

Scena testowa na tablecie z szeroką gamą kolorów

scene_wide_gamut: profil i zakres kolorów o szerokiej gamie.

Opisy poszczególnych scen znajdziesz w odpowiednich sekcjach.

Sceny testowe na tablecie

scene0

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

test_jitter

Mierzy jitter w sygnaturach czasowych kamery.

Przetestowane interfejsy API:

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

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

test_jitter plot

Rysunek 1. Wykres test_jitter.

test_metadata

Sprawdza poprawność wpisów metadanych, analizując wyniki przechwytywania i obiekty charakterystyki aparatu. W tym teście używane są wartości ekspozycji i wzmocnienia auto_capture_request, ponieważ zawartość obrazu nie jest istotna. Jest to test typu fast-FAIL, ponieważ działa w krótkim czasie, wymaga minimalnej konfiguracji i sygnalizuje znaczną liczbę testów, które nie powiodły się na dalszych etapach. Nie należy uruchamiać całego zestawu testów, dopóki test test_metadata nie zakończy się wynikiem POZYTYWNYM.

Przetestowane interfejsy API:

Zaliczone: poziom sprzętowy, tagi rollingShutterSkew, frameDuration, timestampSource, croppingType, blackLevelPattern, pixel_pitch, pole widzenia i odległość hiperfokalna są obecne i mają prawidłowe wartości.

test_request_capture_match

Sprawdza, czy urządzenie zapisuje prawidłowe wartości ekspozycji i wzmocnienia, odczytując metadane przechwytywania. Jest to test typu fast-FAIL, ponieważ wymaga minimalnej konfiguracji i sygnalizuje znaczną liczbę nieudanych testów na dalszych etapach. Nie należy uruchamiać całego zestawu testów, dopóki test test_request_capture_match nie zakończy się wynikiem POZYTYWNYM.

Przetestowane interfejsy API:

Zaliczone: wartości metadanych żądania i przechwytywania 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 wyświetla zdarzenia czujników. Oczekiwane 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 trybie czuwania. Jest to test typu fast-FAIL, ponieważ działa krótko, wymaga minimalnej konfiguracji i sygnalizuje niepowodzenie testu fuzji czujników. Testy sceny sensor_fusion nie powinny być uruchamiane, chyba że test_sensor_events ma wynik PASS lub SKIP.

Przetestowane interfejsy API:

Zaliczone: zdarzenia są odbierane z każdego czujnika.

test_solid_color_test_pattern

Sprawdza, czy wzorce testowe jednolitego koloru są prawidłowo generowane na potrzeby wyciszania kamery. Jeśli obsługiwane jest wyciszanie kamery, muszą być obsługiwane wzorce testowe w jednolitym kolorze. Jeśli wyciszanie kamery nie jest obsługiwane, wzorce testowe jednolitego koloru są testowane tylko wtedy, gdy ta funkcja jest reklamowana.

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

Przetestowane interfejsy API:

Zaliczone: obsługiwane jednolite wzory testowe mają prawidłowy kolor, a obraz charakteryzuje się niską wariancją.

test_test_pattern

Testuje parametr android.sensor.testPatternMode, aby przechwytywać klatki dla każdego prawidłowego wzorca testowego, i sprawdza, czy klatki są prawidłowo generowane dla jednolitych kolorów i pasków kolorów. Ten test obejmuje te kroki:

Przechwytuje obrazy dla wszystkich obsługiwanych wzorców testowych.
Sprawdza poprawność wzorca testowego jednolitego koloru i pasów kolorów.

Przetestowane interfejsy API:

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

Przykład test_test_patterns

Rysunek 2. Przykład test_test_patterns.

test_tonemap_curve

Testuje konwersję wzorca testowego z formatu RAW na YUV z linearnym mapowaniem tonalnym. Ten test wymaga android.sensor.testPatternMode = 2 (COLOR_BARS) do wygenerowania idealnego wzoru obrazu na potrzeby konwersji mapowania tonów. Sprawdza, czy potok ma prawidłowe dane wyjściowe kolorów z linearnym mapowaniem tonalnym i idealnymi danymi wejściowymi obrazu (zależy od test_test_patterns).

Przetestowane interfejsy API:

Zaliczenie: obrazy YUV i RAW wyglądają podobnie.

test_tonemap_curve raw example

Rysunek 3. Przykład nieprzetworzonego obrazu test_tonemap_curve.

Przykład test_tonemap_curve YUV

Rysunek 4. Przykład test_tonemap_curve YUV.

test_unified_timestamp

Sprawdza, czy zdarzenia czujnika obrazu i ruchu znajdują się w tej samej domenie czasowej. Jest to test typu fast-FAIL, ponieważ trwa krótko, wymaga minimalnej konfiguracji i sygnalizuje niepowodzenie testu fuzji czujników. Testy sceny sensor_fusion nie powinny być uruchamiane, chyba że test_unified_timestamp ma stan PASS lub SKIP.

Przetestowane interfejsy API:

Zaliczone: sygnatury czasowe ruchu znajdują się między sygnaturami czasowymi 2 obrazów.

test_vibration_restriction

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

Przetestowane interfejsy API:

Zaliczone: urządzenie nie wibruje, gdy jest wyciszone przez interfejs API ograniczeń dźwięku aparatu.

scene1_1

scene1 to szary wykres. Szara tablica musi zajmować 30% środka pola widzenia aparatu. Szara karta powinna stanowić umiarkowane wyzwanie dla funkcji 3A (AE, AWB i AF), ponieważ w środkowym obszarze nie ma żadnych elementów. Jednak żądanie przechwycenia określa całą scenę, która zawiera wystarczającą liczbę funkcji, aby umożliwić konwergencję 3A.

Kamery RFoV można testować na stanowisku testowym WFoV lub RFoV. Jeśli kamera z RFoV jest testowana na stanowisku testowym WFoV, wykres jest skalowany o 2/3, aby określić pewne granice dla szarego wykresu w FoV, co ułatwia konwergencję 3A. Szczegółowe opisy stanowisk testowych aparatów znajdziesz w artykule Camera ITS-in-a-box.

przykład scene1

Rysunek 5. Wykres sceny 1 w pełnym rozmiarze (po lewej), wykres w skali 2/3 (po prawej).

test_ae_precapture_trigger

Testuje maszynę stanów AE podczas używania aktywatora wstępnego przechwytywania. Przechwytuje 5 ręcznych żądań z wyłączoną automatyczną ekspozycją. Ostatnie żądanie zawiera aktywator wstępnego przechwytywania AE, który powinien zostać zignorowany, ponieważ AE jest wyłączone.

Przetestowane interfejsy API:

Zaliczone: AE zbiega się.

test_auto_vs_manual

Testy, które zarejestrowały zdjęcia automatyczne i ręczne, wyglądają tak samo.

Przetestowane interfejsy API:

Zaliczenie: ręczne wzmocnienia balansu bieli i transformacja zgłaszane w każdym wyniku przechwytywania są zgodne z automatycznym balansem bieli estimate z algorytmu 3A aparatu.

test_auto_vs_manual auto example

Rysunek 6. Przykład automatycznego testu test_auto_vs_manual.

test_auto_vs_manual white balance example

Rysunek 7. Przykład balansu bieli test_auto_vs_manual.

Przykład przekształcenia ręcznego balansu bieli test_auto_vs_manual

Rysunek 8. Przykład przekształcenia ręcznego balansu bieli test_auto_vs_manual.

test_black_white

Sprawdza, czy urządzenie generuje pełne obrazy czarno-białe. Robi 2 zdjęcia: pierwsze z bardzo niskim wzmocnieniem i krótką ekspozycją, co daje czarne zdjęcie, a drugie z bardzo wysokim wzmocnieniem i długą ekspozycją, co daje białe zdjęcie.

Przetestowane interfejsy API:

Pass:tworzy obrazy czarno-białe. Nasycone kanały białych obrazów mają wartości RGB [255, 255, 255] z marginesem błędu mniejszym niż 1%.

test_black_white, black example

Rysunek 9. test_black_white, przykład czerni.

Przykład przekształcenia ręcznego balansu bieli test_auto_vs_manual

Rysunek 10. test_black_white, przykład z białym tłem.

test_black_white plot means example

Rysunek 11. Przykład wykresu średnich dla test_black_white.

test_burst_capture

Sprawdza, czy cały potok przechwytywania może nadążyć za szybkością przechwytywania pełnowymiarowego i czasem pracy procesora.

Przetestowane interfejsy API:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_BURST_CAPTURE

Zaliczone: wykonuje serię zdjęć w pełnym rozmiarze, sprawdza, czy nie ma pominiętych klatek, i sprawdza jasność obrazu.

test_burst_sameness_manual

Wykonuje 5 serii po 50 zdjęć z ręcznym ustawieniem przechwytywania i sprawdza, czy wszystkie są identyczne. Użyj tego testu, aby sprawdzić, czy występują sporadyczne klatki, które są przetwarzane inaczej lub zawierają artefakty.

Przetestowane interfejsy API:

Zaliczone: obrazy są identyczne pod względem wizualnym i wartości RGB.

Niepowodzenie: na początku każdej serii na wykresie średniej RGB widoczny jest skok lub spadek.

Tolerancja wynosi 3% dla first_API_level < 30
Tolerancja wynosi 2% dla first_API_level >= 30

test_burst_sameness_manual_mean

Rysunek 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

Sprawdza, czy strumieni RAW nie można przycinać.

Przetestowane interfejsy API:

Zaliczenie: obrazy YUV są przycinane do środka, ale nie obrazy RAW.

test_crop_region_raw comp raw crop example

Rysunek 14. Przykład przycięcia obrazu RAW w teście test_crop_region_raw.

test_crop_region_raw comp raw full example

Rysunek 15. Pełny przykład test_crop_region_raw comp raw.

Przykład przycięcia YUV w test_crop_region_raw comp

Rysunek 16. Przykład przycięcia YUV w test_crop_region_raw comp.

Przykład test_crop_region_raw_yuv_full

Rysunek 17. Pełny przykład test_crop_region_raw YUV.

test_crop_regions

Testuje, czy regiony przycinania działają. Pobiera pełny obraz i tworzy fragmenty z 5 różnych obszarów (rogi i środek). Robi zdjęcia z przycięciem ustawionym dla 5 regionów. Porównuje wartości obrazu wycinka i przyciętego obrazu.

Przetestowane interfejsy API:

Zaliczony: obraz przyciętego obszaru pasuje do fragmentu odpowiadającego przyciętemu obrazowi.

test_ev_compensation

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

Sekcja podstawowa sprawdza, czy kompensacja EV jest stosowana przy użyciu zakresu utworzonego za pomocą CONTROL_AE_COMPENSATION_STEP. Dla każdej wartości kompensacji rejestrowanych jest 8 klatek.

Sekcja zaawansowana zwiększa ekspozycję w 8 krokach i sprawdza zmierzoną jasność w porównaniu z oczekiwaną. Wartości oczekiwane są obliczane na podstawie jasności obrazu bez zastosowanej kompensacji EV, a wartość oczekiwana nasyca się, jeśli obliczone wartości przekraczają rzeczywisty zakres wartości obrazu. Test zakończy się niepowodzeniem, jeśli wartości oczekiwane i zmierzone nie będą się zgadzać lub jeśli obrazy zostaną prześwietlone w ciągu 5 kroków.

Przetestowane interfejsy API:

Sekcja podstawowa – zaliczenie: obrazy pokazują rosnącą ekspozycję bez prześwietlenia w 5 krokach.

test_ev_compensation_basic

Rysunek 18. test_ev_compensation_basic.

Zaawansowany test sekcji: rejestruje wzrost luminancji wraz ze wzrostem ustawienia kompensacji EV. 8 klatek zarejestrowanych dla każdego ustawienia kompensacji EV ma stabilne wartości luminancji.

test_ev_compensation_advanced_plot_means

Rysunek 19. test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Sprawdza, czy stała ekspozycja jest osiągana przy różnych wartościach ISO i czasu ekspozycji. Wykonuje serię zdjęć z ISO i czasem ekspozycji dobranymi tak, aby się równoważyły. Wyniki powinny mieć taką samą jasność, ale w miarę postępu sekwencji obraz powinien być coraz bardziej zaszumiony. Sprawdza, czy średnie wartości pikseli próbki są zbliżone do siebie. Sprawdza, czy obrazy nie są ograniczone do wartości 0 lub 1 (co sprawiłoby, że wyglądałyby jak płaskie linie). Test można też przeprowadzić z obrazami RAW, ustawiając flagę debug w pliku konfiguracji.

Przetestowane interfejsy API:

Zaliczone: obrazy mają tę samą jasność, ale przy wyższej czułości ISO pojawia się więcej szumów. Płaszczyzny RGB są płaskie, gdy wartość ISO*ekspozycja jest stała w testowanym zakresie wzmocnienia.

Mechanizm niepowodzenia: na poniższym rysunku, gdy wartości mnożnika wzmocnienia (oś X) rosną, znormalizowane średnie wartości płaszczyzny RGB (oś Y) zaczynają odbiegać od wartości mnożnika niskiego wzmocnienia.

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ą blokowane na odpowiedniej klatce w przypadku kamer FULL i LEVEL_3. Wykonuje serię zdjęć, wysyłając żądania jedno po drugim, zmieniając parametry żądania przechwytywania między zdjęciami. Sprawdza, czy obrazy mają oczekiwane właściwości.

Przetestowane interfejsy API:

android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL

Zatwierdzone: obrazy [2, 3, 6, 8, 10, 12, 13] mają zwiększoną czułość ISO lub ekspozycję i wykazują wyższe średnie wartości RGB na wykresie na poniższym rysunku.

test_latching plot means example

Rysunek 23. Przykład średnich na wykresie test_latching.

test_latching i=00

Rysunek 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

Rysunek 27. test_latching i=03.

test_latching i=04

Rysunek 28. test_latching i=04.

test_latching i=05

Rysunek 29. test_latching i=05.

test_latching i=06

Rysunek 30. test_latching i=06.

test_latching i=07

Rysunek 31. test_latching i=07.

test_latching i=08

Rysunek 32. test_latching i=08.

test_latching i=09

Rysunek 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

Sprawdza, czy przetwarzanie na urządzeniu można odwrócić do pikseli liniowych. Rejestruje sekwencję ujęć, gdy urządzenie jest skierowane na jednolity cel.

Przetestowane interfejsy API:

Zaliczone: wartości R, G, B muszą rosnąć liniowo wraz ze wzrostem czułości.

test_linearity plot means example

Rysunek 37. Przykład wykresu test_linearity plot means.

test_locked_burst

Testuje blokadę 3A i serię zdjęć YUV (przy użyciu ustawienia automatycznego). Ten test powinien zakończyć się powodzeniem nawet na urządzeniach o ograniczonych możliwościach, które nie mają funkcji MANUAL_SENSOR ani PER_FRAME_CONTROLS. Test sprawdza spójność obrazu YUV, a test liczby klatek jest częścią CTS.

Przetestowane interfejsy API:

Zaliczone:ujęcia wyglądają spójnie.

test_locked_burst frame0 example

Rysunek 38. Przykład klatki 0 w teście test_locked_burst.

test_locked_burst frame1 example

Rysunek 39. Przykład klatki 1 testu test_locked_burst.

test_locked_burst_frame2

Rysunek 40. Przykład klatki 2 testu 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

Sprawdza, czy parametry android.colorCorrection.* są stosowane, gdy są ustawione. Robi zdjęcia z różnymi wartościami przekształcenia i wzmocnienia, a następnie sprawdza, czy odpowiednio się różnią. Przekształcenie i wzmocnienia są dobierane tak, aby dane wyjściowe były coraz bardziej czerwone lub niebieskie. Używa liniowego mapowania tonów.

Mapowanie tonów to technika używana w przetwarzaniu obrazu do mapowania jednego zestawu kolorów na inny w celu przybliżenia wyglądu obrazów o wysokim zakresie dynamiki na nośniku o bardziej ograniczonym zakresie dynamiki.

Przetestowane interfejsy API:

Zaliczone: wartości R i B są zwiększane zgodnie z przekształceniem.

test_param_color_correction plot means example

Rysunek 41. Przykład średniej wartości wykresu test_param_color_correction.

Na poniższych rysunkach oś X przedstawia żądania przechwytywania: 0 = jedność, 1 = wzmocnienie czerwieni, 2 = wzmocnienie niebieskiego.

test_param_color_correction req=0 unity example

Rysunek 42. Przykład test_param_color_correction req=0 unity.

test_param_color_correctness req=1 red boost example

Rysunek 43. Przykład test_param_color_correctness req=1 red boost.

test_param_color_correction req=2 blue boost example

Rysunek 44. Przykład test_param_color_correction req=2 blue boost.

test_param_flash_mode

Sprawdza, czy parametr android.flash.mode jest stosowany. Ręcznie ustawia ekspozycję na ciemną stronę, aby było jasne, czy lampa błyskowa została uruchomiona, i używa liniowej mapy tonalnej. Sprawdza środek obrazu kafelka, aby zobaczyć, czy powstał duży gradient, co pozwala sprawdzić, czy lampa błyskowa została uruchomiona.

Przetestowane interfejsy API:

Zaliczone: na środku obrazu kafelka występuje duży gradient, co oznacza, że lampa błyskowa została uruchomiona.

test_param_flash_mode 1 example

Rysunek 45. Przykład test_param_flash_mode 1.

test_param_flash_mode 1 tile example

Rysunek 46. Przykład kafelka test_param_flash_mode.

test_param_flash_mode_2 example

Rysunek 47. Przykład test_param_flash_mode 2.

test_param_flash_mode 2 tile example

Rysunek 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, gdy jest ustawiony. Aparat robi zdjęcia przy słabym oświetleniu. Używa wysokiego wzmocnienia analogowego, aby zapewnić, że przechwycony obraz jest zaszumiony. Robi 3 zdjęcia: z wyłączoną redukcją szumów, szybkie i wysokiej jakości. Przechwytuje też obraz z niskim wzmocnieniem i wyłączoną redukcją szumów, a następnie używa jego wariancji jako wartości bazowej. Im wyższy stosunek sygnału do szumu (SNR), tym lepsza jakość obrazu.

Przetestowane interfejsy API:

android.hardware.camera2.CaptureRequest#NOISE_REDUCTION_MODE

Zaliczenie: SNR różni się w zależności od trybu redukcji szumów i zachowuje się podobnie jak na tym wykresie:

test_param_noise_reduction plot SNRs example

Rysunek 49. Przykładowe wartości SNR na wykresie test_param_noise_reduction.

0: WYŁ., 1: SZYBKO, 2: WYSOKA JAKOŚĆ, 3: MIN., 4: ZSL

test_param_noise_reduction high gain nr=0 example

Rysunek 50. Przykład test_param_noise_reduction high gain nr=0.

test_param_noise_reduction high gain nr=1 example

Rysunek 51. Przykład test_param_noise_reduction high gain nr=1.

test_param_noise_reduction high gain nr=2 example

Rysunek 52. Przykład test_param_noise_reduction high gain nr=2.

test_param_noise_reduction high gain nr=3 example

Rysunek 53. Przykład test_param_noise_reduction high gain nr=3.

test_param_noise_reduction low gain example

Rysunek 54. Przykład parametru test_param_noise_reduction z niskim wzmocnieniem.

test_param_shading_mode

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

Przetestowane interfejsy API:

Wynik pozytywny: tryby cieniowania są przełączane, 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 test_param_shading_mode, tryb 0, pętla 0.

test_param_shading_mode lens shading map, mode 1 loop 0 example

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

test_param_shading_mode lens shading map, mode 2 loop 0 example

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

test_param_tonemap_mode

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

Przetestowane interfejsy API:

Pass:

test1: oba obrazy mają liniowe mapowanie tonów, ale n=1 ma bardziej stromy gradient. Kanał G (zielony) jest jaśniejszy na obrazie n=1.
test2: to samo mapowanie tonów, ale inna długość. Grafika jest taka sama.

test_param_tonemap_mode z n=0

Rysunek 58. test_param_tonemap_mode z n=0.

test_param_tonemap_mode z n=1

Rysunek 59. test_param_tonemap_mode z n=1.

test_post_raw_sensitivity_boost

Sprawdza wzmocnienie czułości po przetworzeniu danych RAW. Przechwytuje zestaw obrazów RAW i YUV z różną czułością, publikuje kombinację wzmocnienia czułości RAW i sprawdza, czy średnia wartość pikseli wyjściowych odpowiada ustawieniom żądania.

Przetestowane interfejsy API:

Wynik pozytywny: obrazy RAW stają się ciemniejsze wraz ze wzrostem wzmocnienia, a jasność obrazów 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

Rysunek 61. Przykład test_post_raw_sensitivity_boost raw s=1792 boost=0200.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

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

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

Rysunek 63. Przykład test_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 test_post_raw_sensitivity_boost raw s=0112 boost=3199.

test_post_raw_sensitivity_boost raw plot means example

Rysunek 66. Przykład wykresu nieprzetworzonych średnich wartości test_post_raw_sensitivity_boost.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

Rysunek 67. Przykład test_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 test_post_raw_sensitivity_boost YUV s=0896 boost=0400.

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

Rysunek 70. Przykład test_post_raw_sensitivity_boost YUV s=1792 boost=0200.

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

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

test_post_raw_sensitivity_boost_yuv_plot_means

Rysunek 72. Przykład test_post_raw_sensitivity_boost_yuv_plot_means.

test_raw_exposure

Rejestruje zestaw nieprzetworzonych obrazów z rosnącym czasem ekspozycji i mierzy wartości pikseli.

Przetestowane interfejsy API:

Zaliczenie: zwiększenie czułości ISO (wzmocnienia) sprawia, że piksele są bardziej wrażliwe na światło, więc wykres przesuwa się w lewo.

test_raw_exposure ISO=55 example

Rysunek 73. Przykład test_raw_exposure ISO=55.

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

Przykład test_raw_exposure ISO=132

Rysunek 74. Przykład test_raw_exposure ISO=132.

test_raw_exposure ISO=209 example

Rysunek 75. Przykład test_raw_exposure ISO=209.

test_raw_exposure ISO=286 – przykład

Rysunek 76. Przykład test_raw_exposure ISOs=286.

Przykład test_raw_exposure ISO=363

Rysunek 77. Przykład test_raw_exposure ISO=363.

test_raw_exposure_s=440

Rysunek 78. Przykład test_raw_exposure ISO=440.

test_reprocess_noise_reduction

Sprawdza, czy android.noiseReduction.mode jest stosowany w przypadku próśb o ponowne przetworzenie. Przetwarza ponownie zdjęcia zrobione aparatem przy słabym oświetleniu. Używa wysokiego wzmocnienia analogowego, aby sprawdzić, czy przechwycony obraz jest zaszumiony. Zapisuje 3 przetworzone obrazy: z wyłączoną redukcją szumów, szybką i wysokiej jakości. Przechwytuje przetworzony obraz z niskim wzmocnieniem i wyłączoną redukcją szumów, a następnie używa jego wariancji jako wartości bazowej.

Przetestowane interfejsy API:

android.hardware.camera2.CaptureResult#NOISE_REDUCTION_MODE

Zaliczenie: FAST >= OFF, HQ >= FAST i HQ >> OFF.

Wykres typowego SNR w porównaniu z trybem NR

Rysunek 79. Przykładowy wykres typowego trybu SNR i NR.

test_tonemap_sequence

Testuje sekwencję ujęć z różnymi krzywymi mapowania tonów. Robi 3 zdjęcia ręczne z linearnym mapowaniem tonów. Robi 3 zdjęcia ręczne z domyślnym mapowaniem tonów. Oblicza różnicę między każdą kolejną parą klatek.

Przetestowane interfejsy API:

Zaliczone: występują 3 identyczne klatki, po których następuje inny zestaw 3 identycznych klatek.

test_tonemap_sequence i=0 example

Rysunek 80. Przykład test_tonemap_sequence i=0.

Przykład test_tonemap_sequence i=1

Rysunek 81. Przykład test_tonemap_sequence i=1.

test_tonemap_sequence i=2 example

Rysunek 82. Przykład test_tonemap_sequence i=2.

test_tonemap_sequence i=3 example

Rysunek 83. Przykład test_tonemap_sequence i=3.

Przykład test_tonemap_sequence_i=4

Rysunek 84. Przykład test_tonemap_sequence i=4.

test_tonemap_sequence i=5 example

Rysunek 85. Przykład test_tonemap_sequence i=5.

test_yuv_jpeg_all

Sprawdza, czy wszystkie zgłoszone rozmiary i formaty robienia zdjęć działają. Używa żądania ręcznego z liniowym mapowaniem tonów, aby obrazy YUV i JPEG wyglądały tak samo po przekonwertowaniu przez moduł image_processing_utils. Obrazy nie są domyślnie zapisywane, ale można je zapisać, włączając debug_mode.

Przetestowane interfejsy API:

Wynik pozytywny: wszystkie środki obrazów mają maksymalną różnicę średniej kwadratowej (RMS) (wartość sygnału) w obrazach przekonwertowanych na RGB z 3% obrazu YUV o najwyższej rozdzielczości.

Przykład test_yuv_jpeg_all

Rysunek 86. Przykład test_yuv_jpeg_all.

test_yuv_plus_dng

Sprawdza, czy zgłoszone rozmiary i formaty robienia zdjęć działają.

Przetestowane interfejsy API:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

Zaliczony: test został zakończony i zwrócił żądane obrazy.

test_yuv_plus_dng example

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

Sprawdza, czy w obiektach CaptureResult zwracane są prawidłowe dane. Test składa się z automatycznego przechwytywania, ręcznego przechwytywania i drugiego automatycznego przechwytywania.

Przetestowane interfejsy API:

Zaliczenie: metadane są prawidłowe we wszystkich ujęciach, a ustawienia ręczne nie są przenoszone do drugiego ujęcia automatycznego. Wykreśla korekcję cieniowania obiektywu dla zdjęć.

test_capture_result_plot_lsc_auto_ch0

Rysunek 88. test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

Sprawdza, czy parametry modelu DNG RAW są prawidłowe. Wykres przedstawia zmierzoną wariancję środkowego fragmentu szarej karty na zdjęciach RAW wykonanych przy różnych czułościach i porównuje te wartości z wariancją oczekiwaną przy każdej czułości przez model szumu DNG w warstwie HAL aparatu (na podstawie parametrów O,S zwracanych w obiektach wyników przechwytywania). Więcej informacji o modelu szumu DNG znajdziesz w dokumencie Model szumu DNG.

Przetestowane interfejsy API:

Zaliczone: parametry modelu DNG RAW są prawidłowe. Oczekiwane wartości RGB odpowiadają rzeczywistym zmierzonym wartościom RGB.

test_dng_noise_model_plog

Rysunek 89. test_dng_noise_model_plog.

test_jpeg

Testy, które przekonwertowały obrazy YUV i obrazy JPEG z urządzenia, wyglądają tak samo. Test pobiera środkowe 10% obrazu, oblicza wartość RGB i sprawdza, czy wartości są zgodne.

Przetestowane interfejsy API:

android.graphics.ImageFormat#JPEG

Zaliczone: średnia różnica RGB między poszczególnymi 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

Rejestruje zestaw obrazów RAW ze zwiększonym wzmocnieniem i mierzy szum. Zapisuje tylko pliki RAW w trybie zdjęć seryjnych.

Przetestowane interfejsy API:

Zaliczenie: każde ujęcie jest bardziej zaszumione niż poprzednie, ponieważ wzmocnienie rośnie.

Używa wariancji środkowej komórki siatki statystyk.

test_raw_burst_sensitivity_variance

Rysunek 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Przechwytuje zestaw nieprzetworzonych obrazów o rosnącej czułości i mierzy szum (wariancję) w środkowych 10% obrazu. Sprawdza, czy każdy strzał jest głośniejszy od poprzedniego.

Przetestowane interfejsy API:

Zaliczenie: wariancja zwiększa się z każdym ujęciem.

test_raw_sensitivity_variance

Rysunek 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Testy rejestrujące pojedynczą klatkę jako dane wyjściowe YUV i JPEG. Używa żądania ręcznego z liniowym mapowaniem tonów, aby obrazy YUV i JPEG wyglądały tak samo po przekonwertowaniu przez moduł image_processing_utils.

Przetestowane interfejsy API:

Zaliczone: obrazy YUV i JPEG są podobne, a różnica między nimi wynosi mniej niż 1% RMS (wartość sygnału).

test_yuv_plus_jpeg z formatem JPEG

Rysunek 94. test_yuv_plus_jpeg z formatem JPEG.

test_yuv_plus_jpeg z formatem YUV

Rysunek 95. test_yuv_plus_jpeg z formatem YUV.

test_yuv_plus_raw

Testuje przechwytywanie pojedynczej klatki jako danych wyjściowych w formacie RAW (10-bitowym i 12-bitowym) i YUV, jeśli jest to obsługiwane. Używa żądania ręcznego z liniowym mapowaniem tonów, więc dane RAW i YUV powinny być takie same. Porównuje wartości RGB środkowych 10% obrazów przekonwertowanych na RGB. Dziennikiandroid.shading.mode.

Przetestowane interfejsy API:

Zaliczone: obrazy YUV i RAW są podobne, a różnica między nimi wynosi mniej niż 3,5% RMS (wartość skuteczna 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

Testuje CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY przy różnych ustawieniach ISO, aby potwierdzić korelację między wyższym ISO a zwiększonym poziomem szumów.

Przetestowane interfejsy API:

Wynik pozytywny: wyższa wartość ISO powoduje zwiększenie poziomu szumu.

Kryteria pomijania testów

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

Urządzenie ma pierwszy poziom API (first_api_level) 35 lub niższy.
Urządzenie nie rozgłasza 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 przy różnych czasach ekspozycji, sprawdzając stabilność jasności w zakresie, w którym ISO może ją kompensować.

Przetestowane interfejsy API:

Zaliczone: jasność jest stabilna (w granicach tolerancji) w różnych czasach ekspozycji, jeśli ISO mieści się w zakresie kompensacji.

Kryteria pomijania testów

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

Urządzenie ma pierwszy poziom API (first_api_level) 35 lub niższy.
Urządzenie nie rozgłasza CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY w CONTROL_AE_AVAILABLE_PRIORITY_MODES.

scene2_a

scene2_a zawiera 3 twarze na szarym tle i neutralne ubrania. Twarze są dobierane tak, aby reprezentowały szeroki zakres odcieni 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 działanie automatycznego kadrowania kamery. Wykonuje duże powiększenie, tak aby żadna z twarzy w scenie nie była widoczna, włącza tryb automatycznego kadrowania, ustawiając AUTOFRAMING w CaptureRequest na True, i sprawdza, czy wszystkie twarze w oryginalnej scenie mogą zostać wykryte, gdy stan się zbiega (czyli gdy AUTOFRAMING_STATE w CaptureResult jest ustawione na AUTOFRAMING_STATE_CONVERGED).

Przetestowane interfejsy API:

Zaliczone: wykryto wszystkie 3 twarze.

test_display_p3

Testuje przechwytywanie w przestrzeni kolorów Display P3 w formacie JPEG za pomocą interfejsu API ColorSpaceProfiles. Sprawdza, czy przechwycony plik JPEG ma w nagłówku odpowiedni profil ICC i czy obraz zawiera kolory spoza gamy sRGB.

Przetestowane interfejsy API:

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

test_effects

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

Przetestowane interfejsy API:

Pass:rejestruje obraz sceny z efektami OFF i 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ę obrazu zarejestrowanego z włączoną automatyczną ekspozycją z obrazem zarejestrowanym z wyłączoną automatyczną ekspozycją, który ręcznie stosuje parametry ekspozycji (czułość, czas ekspozycji, czas trwania klatki, wzmocnienie czułości po RAW) otrzymane w CaptureResult obrazu zarejestrowanego z włączoną automatyczną ekspozycją.

Przetestowane interfejsy API:

Wynik pozytywny: względna różnica luminancji między 2 ujęciami jest mniejsza niż 4%.

test_format_combos

Testuje różne kombinacje formatów wyjściowych.

Przetestowane interfejsy API:

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

test_num_faces

Testuje wykrywanie twarzy.

Przetestowane interfejsy API:

Zaliczenie: wykrycie 3 twarzy.

test_num_faces face detection mode 1 example

Rysunek 100. Przykład testu test_num_faces w trybie wykrywania twarzy 1.

test_reprocess_uv_swap

Sprawdza, czy ponowne przetwarzanie YUV nie zamienia płaszczyzn U i V. Jest to wykrywane przez obliczenie sumy bezwzględnych różnic (SAD) między przetworzonym obrazem a nieprzetworzonym ujęciem. Jeśli zamiana wyjściowych płaszczyzn U i V przetworzonego przechwytywania powoduje zwiększenie SAD, zakłada się, że dane wyjściowe mają prawidłowe płaszczyzny U i V.

Przetestowane interfejsy API:

Zaliczone: płaszczyzny U i V nie są zamienione.

test_reprocess_uv_swap

Rysunek 101. Przykład test_reprocess_uv_swap.

scene2_b

scene2_b zawiera 3 twarze na szarym tle i neutralne ubrania. Twarze są dobierane tak, aby reprezentowały szeroki zakres odcieni skóry. Aby wykrywanie twarzy działało optymalnie, wykres musi mieć prawidłową orientację.

test_preview_num_faces

Testuje wykrywanie twarzy w podglądzie przy większej różnorodności odcieni skóry w scenach z twarzami.

Przetestowane interfejsy API:

Zaliczenie: wykryto 3 twarze z punktami orientacyjnymi w ramkach ograniczających.

test_num_faces_fd_mode_1

Rysunek 102. Przykład trybu wykrywania twarzy 1 w test_num_faces.

test_yuv_jpeg_capture_sameness

Robi 2 zdjęcia, używając największych wspólnych formatów YUV i JPEG o tym samym formacie obrazu co największy format JPEG, który nie przekracza rozdzielczości 1920 x 1440. Ustawia wartość jpeg.quality na 100 i rejestruje żądanie dotyczące 2 platform. Konwertuje oba obrazy na tablice RGB i oblicza trójwymiarową różnicę średniokwadratową (RMS) między nimi.

Dodatkowo ten test sprawdza, czy dane wyjściowe YUV we wszystkich obsługiwanych przypadkach użycia strumienia są podobne do danych YUV w przypadku użycia STILL_CAPTURE.

Przetestowane interfejsy API:

Zaliczenie: obrazy YUV i JPEG w przypadku zastosowania STILL_CAPTURE mają różnicę RMS (wartość skuteczna sygnału) mniejszą niż 3%. Obrazy YUV we wszystkich obsługiwanych przypadkach zastosowania mają różnicę CIELAB mniejszą niż 4% w porównaniu z obrazami YUV w przypadku zastosowania STILL_CAPTURE.

scene2_c

test_num_faces

Testuje wykrywanie twarzy przy większej różnorodności odcieni skóry w scenach z twarzami.

Przetestowane interfejsy API:

Zaliczenie: wykrycie 3 twarzy.

test_num_faces_fd_mode_1

Rysunek 103. Przykład trybu wykrywania twarzy test_num_faces.

test_jpeg_capture_perf_class

Testuje czas oczekiwania na przechwycenie obrazu JPEG w przypadku klasy wydajności S zgodnie z opisem w sekcji 2.2.7.2 Aparat w dokumencie CDD.

Zaliczenie: czas oczekiwania na przechwycenie obrazu JPEG przez interfejs camera2 MUSI wynosić < 1000 ms w rozdzielczości 1080p, zgodnie z pomiarem testu PerformanceTest aparatu CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu aparatów głównych.

test_camera_launch_perf_class

Testuje czas oczekiwania na uruchomienie aparatu w przypadku klasy wydajności S zgodnie z opisem w sekcji 2.2.7.2 Aparat dokumentu CDD.

Zaliczenie: opóźnienie uruchamiania camera2 (od otwarcia aparatu do pierwszej klatki podglądu) MUSI wynosić < 600 ms, mierzone przez test wydajności aparatu CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu aparatów głównych.

test_default_camera_hdr

Testy sprawdzające, czy domyślne przechwytywanie aparatu to Ultra HDR w przypadku klasy wydajności 15, zgodnie z opisem w sekcji 2.2.7.2 Aparat dokumentu CDD.

Zaliczenie: domyślny pakiet aparatu MUSI obsługiwać Ultra HDR na urządzeniu klasy wydajności 15.

scene2_d

test_preview_num_faces

Testuje wykrywanie twarzy w podglądzie przy większej różnorodności odcieni skóry w scenach z twarzami.

Przetestowane interfejsy API:

Zaliczenie: wykryto 3 twarze z punktami orientacyjnymi w ramkach ograniczających.

scene2_e

test_continuous_picture

50 klatek w rozdzielczości VGA jest rejestrowanych z ustawieniem „najpierw żądanie przechwycenia” android.control.afMode = 4 (CONTINUOUS_PICTURE).

Przetestowane interfejsy API:

Wynik pozytywny: system 3A stabilizuje się przed końcem 50-klatkowego nagrania.

test_num_faces

Testuje wykrywanie twarzy przy większej różnorodności odcieni skóry w scenach z twarzami.

Przetestowane interfejsy API:

Zaliczenie: wykryto 3 twarze.

scene2_f

scene2_f ma 3 twarze na białym tle i białe ubranie. Twarze mają szeroki zakres odcieni skóry i wysoki kontrast z tłem.

scene2_f example

Rysunek 104. Przykład scene2_f.

test_preview_num_faces

Testuje wykrywanie twarzy przy większej różnorodności odcieni skóry w scenach z twarzami.

Przetestowane interfejsy API:

Zaliczenie: wykryto 3 twarze z punktami orientacyjnymi w ramkach ograniczających.

test_num_faces_fd_mode_1

Rysunek 105. Przykład test_num_faces_fd_mode_1.

scene2_g

scene2_g – 3 twarze z profilu na białym tle, w białych ubraniach. Twarze mają różne odcienie skóry i wysoki kontrast z tłem.

Rysunek 106. Przykład scene2_g.

test_preview_num_faces

Testuje wykrywanie twarzy przy większej różnorodności odcieni skóry w scenach z twarzami.

Przetestowane interfejsy API:

Zaliczenie: wykryto 3 twarze z punktami orientacyjnymi w ramkach ograniczających.

test_preview_num_faces

Rysunek 107. Przykład test_preview_num_faces.

scene3

scene3 używa tablicy ISO12233, a większość testów wykorzystuje metodę wyodrębniania tablicy, aby znaleźć ją w scenie. Z tego powodu większość zapisanych obrazów nie ma obramowania, jak obrazy w scenach 1, 2 i 4, ale zawiera tylko wykres. Aby wyszukiwarka wykresów działała optymalnie, wykres musi być prawidłowo zorientowany. W Androidzie 17 i nowszych wersjach scena 3 używa znaczników ArUco do wykrywania wykresów.

scene3_aruco_chart

Rysunek 108. Wykres scene3.

test_edge_enhancement

Sprawdza, czy parametr android.edge.mode jest prawidłowo stosowany. Przechwytuje obrazy bez ponownego przetwarzania dla każdego trybu krawędzi i zwraca ostrość obrazu wyjściowego oraz metadane wyniku przechwytywania. Przetwarza żądanie przechwytywania z danym trybem krawędzi, czułością, czasem ekspozycji, odległością ostrości i parametrem powierzchni wyjściowej. W Androidzie 17 i nowszych używa znaczników ArUco do definiowania obszaru wykresu, który zawiera niezbędne ostre krawędzie.

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

Przetestowane interfejsy API:

android.hardware.camera2.CaptureRequest#EDGE_MODE

Parametry kamery, których dotyczy problem:

EDGE_MODE

test_edge_enhancement_edge=0

Rysunek 109. Przykład test_edge_enhancement edge=0.

test_edge_enhancement edge=1 example

Rysunek 110. Przykład test_edge_enhancement edge=1 (tryb szybki).

test_edge_enhancement edge=2 example

Rysunek 111. Przykład test_edge_enhancement edge=2 (tryb wysokiej jakości).

test_flip_mirror

Sprawdza, czy obraz jest prawidłowo zorientowany zgodnie z sekcją 7.5.2 Przedni aparat w dokumencie CDD. W Androidzie 17 i nowszych wersjach używa znaczników ArUco do sprawdzania obecności i orientacji wykresu. Obrazy odwrócone, odwrócone lustrzanie lub obrócone można rozpoznać po rombie w pobliżu środka.

Zaliczenie: wszystkie znaczniki są wykrywane i prawidłowo wyrównane. Obraz nie jest odwrócony, odbity ani obrócony.

Przykładowy fragment sceny test_flip_mirror

Rysunek 112. Przykładowy fragment sceny test_flip_mirror.

test_imu_drift

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

Przetestowane interfejsy API:

Pass:

Dryf żyroskopu jest mniejszy niż 0,01 rad w czasie testu.
Wariancja odczytu żyroskopu jest mniejsza niż 1E-7 rad²/s²/Hz w czasie testu.
Dryf wektora obrotu jest mniejszy niż 0,01 rad w czasie testu.
(Nie jest jeszcze wymagane) Dryf żyroskopu jest mniejszy niż 1 stopień na sekundę.

Przykład dryfu żyroskopu test_imu_drift

Rysunek 113. Przykład dryftu żyroskopu w teście test_imu_drift.

Przykład dryfu wektora obrotu test_imu_drift

Rysunek 114. Przykład dryftu wektora obrotu test_imu_drift.

test_landscape_to_portrait

Sprawdza, czy zastępowanie orientacji poziomej pionową działa prawidłowo w przypadku czujników zorientowanych poziomo.

Przetestowane interfejsy API:

Zaliczenie: test wykrywa wykres z oczekiwanym obrotem (0 stopni, gdy zastąpienie orientacji poziomej pionową jest wyłączone, 90 stopni, gdy jest włączone).

test_landscape_to_portrait example

Rysunek 115. Przykład test_landscape_to_portrait.

test_lens_movement_reporting

Sprawdza, czy flaga ruchu obiektywu jest prawidłowo raportowana. Rejestruje serię 24 zdjęć, przy czym pierwsze 12 klatek jest wykonywanych przy optymalnej odległości ostrości (określonej przez 3A), a ostatnie 12 klatek – przy minimalnej odległości ostrości. W okolicach klatki 12 obiektyw się porusza, co powoduje spadek ostrości. Ostrość ostatecznie się stabilizuje, gdy obiektyw przesuwa się do pozycji końcowej.

Flaga ruchu obiektywu powinna być ustawiona we wszystkich klatkach, w których ostrość jest pośrednia między ostrością w pierwszych kilku klatkach, gdy obiektyw jest nieruchomy przy optymalnej odległości ogniskowej, a ostatnimi kilkoma klatkami, gdy obiektyw jest nieruchomy przy minimalnej odległości ogniskowej. Dokładna klatka, w której obiektyw się porusza, nie jest ważna. Istotne jest to, że flaga ruchu jest ustawiona, gdy obiektyw się porusza.

Na Androidzie 17 i nowszych ten test wykorzystuje znaczniki ArUco do określenia obszaru wykresu, który zawiera niezbędne ostre krawędzie. Ta metoda zapewnia stabilne wykrywanie w przypadku aparatów od ultraszerokokątnych po teleobiektywy.

Przetestowane interfejsy API:

Zaliczony: flaga ruchu obiektywu ma wartość True w klatce ze zmianą ostrości.

Mechanizmy awarii:

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

test_reprocess_edge_enhancement

Sprawdza, czy obsługiwane metody ponownego przetwarzania na potrzeby wzmacniania sygnału Wi-Fi działają prawidłowo. Przetwarza żądanie przechwycenia z danym trybem krawędzi ponownego przetwarzania i porównuje różne tryby przechwytywania z wyłączonymi trybami krawędzi ponownego przetwarzania.

Przetestowane interfejsy API:

Wynik pozytywny: 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 116. Przykładowy wykres test_reprocess_edge_enhancement.

scene4

scene4 składa się z czarnego koła na białym tle wewnątrz kwadratu.

Testy w scenie 4 mogą być wrażliwe na wyrównanie, dlatego od Androida 15 możesz używać narzędzia check_alignment.py w katalogu narzędzi, aby sprawdzić wyrównanie testowanego urządzenia i wykresu.

scene4 example

Rysunek 117. Przykład scene4.

test_30_60fps_preview_fov_match

Sprawdza, czy podgląd filmów w 30 kl./s i 60 kl./s ma takie samo pole widzenia. Test rejestruje 2 filmy: jeden z 30 kl./s, a drugi z 60 kl./s. Z każdego filmu wybierana jest reprezentatywna klatka, która jest analizowana w celu sprawdzenia, czy zmiany pola widzenia w obu filmach mieszczą się w specyfikacji. Sprawdza, czy format obrazu okręgu pozostaje stały, środek okręgu pozostaje stabilny, a promień okręgu pozostaje stały.

Przetestowane interfejsy API:

Zaliczone: obrazy nie są rozciągnięte, środki obrazów nie różnią się o więcej niż 3%, a maksymalna zmiana formatu obrazu między filmami 30 kl./s i 60 kl./s nie przekracza 7,5%.

Mechanizmy awarii:

Okrąg z filmu 30 kl./s znacznie różni się rozmiarem od okręgu z filmu 60 kl./s.
Okrąg na zrobionym zdjęciu jest zniekształcony przez proces przetwarzania.
Okrąg na zarejestrowanym obrazie jest przycięty z powodu żądania przechwycenia obrazu o ekstremalnym formacie obrazu, co zmniejsza wysokość lub szerokość obrazu.
Okrąg na zrobionym zdjęciu ma odbicie w środku i nie wydaje się całkowicie wypełniony.

test_aspect_ratio_and_crop

Sprawdza, czy obrazy nie są zniekształcone lub nieoczekiwanie przycięte w potoku obrazów. Robi zdjęcia okręgu we wszystkich formatach. Sprawdza, czy okrąg nie jest zniekształcony, nie przesuwa się ze środka obrazu i nie zmienia nieprawidłowo rozmiaru przy różnych formatach obrazu lub rozdzielczościach.

Przetestowane interfejsy API:

Zaliczone: obrazy nie są rozciągnięte, środki obrazów nie różnią się o więcej niż 3%, a maksymalne możliwe pole widzenia jest zachowane.

Mechanizmy awarii:

Kamera nie jest wyrównana z okręgiem wyświetlanym na tablecie pośrodku zarejestrowanej sceny.
Okrąg na zrobionym zdjęciu jest zniekształcony przez proces przetwarzania.
Obraz o niższej rozdzielczości jest podwójnie przycinany w procesie przetwarzania obrazu, co powoduje, że obrazy o wysokiej i niskiej rozdzielczości mają różne pola widzenia.
Okrąg na zarejestrowanym obrazie jest przycięty z powodu żądania przechwycenia obrazu o ekstremalnym formacie obrazu, co zmniejsza wysokość lub szerokość obrazu.
Okrąg na zrobionym zdjęciu ma odbicie w środku i nie wydaje się całkowicie wypełniony.

test_multi_camera_alignment

Testuje parametry kalibracji kamery związane z pozycjonowaniem kamery w systemach z wieloma kamerami. Korzystając z fizycznych aparatów podrzędnych, robi zdjęcie jednym z nich. Znajduje środek okręgu. Rzutuje środek okręgu na współrzędne świata dla każdej kamery. Porównuje różnicę między środkami okręgów kamer we współrzędnych świata. Ponownie rzutuje współrzędne świata na współrzędne pikseli i porównuje je z oryginałami w celu sprawdzenia poprawności. Porównuje rozmiary okręgów, sprawdzając, czy ogniskowe aparatów są różne.

Przetestowane interfejsy API:

Wynik pozytywny: środki i rozmiary okręgów są zgodne z oczekiwanymi na rzutowanych obrazach w porównaniu z obrazami przechwyconymi przy użyciu danych kalibracji aparatu i ogniskowych.

Mechanizmy awarii:

LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION i LENS_POSE_ROTATION to wartości projektowe, a nie rzeczywiste dane kalibracji.
System aparatów nie jest odpowiedni do konfiguracji testowej, np. testowanie systemu aparatów z obiektywem szerokokątnym i ultraszerokokątnym za pomocą platformy testowej RFoV. Więcej informacji znajdziesz w odpowiedzi na pytanie 1 w najczęstszych pytaniach dotyczących zestawu Camera ITS-in-a-box.

test_preview_aspect_ratio_and_crop

Podobnie jak w przypadku testu test_aspect_ratio_and_crop dotyczącego zdjęć, sprawdza obsługiwane formaty podglądu, aby upewnić się, że klatki podglądu nie są rozciągnięte ani nieprawidłowo przycięte. Sprawdza, czy format obrazu koła się nie zmienia, czy przycięte obrazy utrzymują koło w środku kadru i czy rozmiar koła nie zmienia się w przypadku stałego formatu lub różnych rozdzielczości (sprawdzanie pola widzenia).

Przetestowane interfejsy API:

Wynik pozytywny: obrazy nie są rozciągnięte, ich środki nie różnią się o więcej niż 3%, a maksymalne możliwe pole widzenia jest zachowane.

test_preview_stabilization_fov

Sprawdza obsługiwane rozmiary podglądu, aby upewnić się, że pole widzenia jest odpowiednio przycięte. Test rejestruje 2 filmy: jeden ze stabilizacją podglądu ON, a drugi ze stabilizacją podglądu OFF. Z każdego filmu wybierana jest reprezentatywna klatka, która jest analizowana w celu sprawdzenia, czy zmiany pola widzenia w obu filmach mieszczą się w specyfikacji.

Przetestowane interfejsy API:

Zaliczenie: format obrazu okręgu pozostaje mniej więcej stały, położenie środka okręgu pozostaje stabilne, a rozmiar okręgu zmienia się o nie więcej niż 20%.

test_video_aspect_ratio_and_crop

Nagrywa filmy przedstawiające okrąg wewnątrz kwadratu we wszystkich formatach wideo. Wyodrębnia klatki kluczowe i sprawdza, czy format obrazu koła się nie zmienia, czy przycięte obrazy utrzymują koło w środku i czy rozmiar koła nie zmienia się w przypadku stałego formatu lub innej rozdzielczości (sprawdzanie pola widzenia).

Przetestowane interfejsy API:

Zaliczone: klatki filmu nie są rozciągnięte, środek klatek nie różni się o więcej niż 3% i zachowane jest maksymalne możliwe pole widzenia.

scene6

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

scene6

Rysunek 118. Przykład scene6.

test_in_sensor_zoom

Testuje działanie funkcji zoomu w matrycy aparatu, która generuje przycięte obrazy RAW.

Jeśli przypadek użycia strumienia jest ustawiony na CROPPED_RAW, test wykonuje 2 zdjęcia w zakresie powiększenia: obraz RAW z pełnym polem widzenia i przycięty obraz RAW. Test konwertuje obrazy na tablice RGB, zmniejsza pełnowymiarowy przycięty obraz RAW do rozmiaru podanego przez SCALER_RAW_CROP_REGION i oblicza różnicę 3D RMS między tymi 2 obrazami.

Przetestowane interfejsy API:

Wynik pozytywny: różnica 3D RMS między pomniejszonym przyciętym obrazem RAW a obrazem RAW z pełnym polem widzenia jest mniejsza niż próg ustawiony w teście.

test_zoom

Testuje działanie zoomu aparatu od obiektywu ultraszerokokątnego do szerokokątnego. Wykonuje zdjęcia w zakresie powiększenia i sprawdza, czy znaczniki ArUco powiększają się wraz z powiększeniem obrazu przez aparat. Test sprawdza też, czy pozycja znacznika środka zmienia się w przewidywalny sposób podczas każdego przechwytywania. Odległość od środka znacznika środkowego do środka obrazu może zmieniać się ze stałą szybkością w stosunku do współczynnika powiększenia aż do fizycznego przełączenia aparatu lub może zmieniać się monotonicznie w kierunku lokalizacji tego samego znacznika po fizycznym przełączeniu aparatu. Przed rozpoczęciem testów na urządzeniu musi być zainstalowana aplikacja Jetpack Camera (JCA).

Przetestowane interfejsy API:

Wynik pozytywny: względny rozmiar zarejestrowanego znacznika ArUco jest zgodny z wymaganym współczynnikiem powiększenia, co potwierdza, że aparat prawidłowo powiększa obraz, a odległość znacznika od środka obrazu zmienia się zgodnie z kryteriami podanymi w opisie testu.

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

Rysunek 119. test_zoom do znajdowania konturu znacznika ArUco najbliżej środka.

test_low_latency_zoom

Testuje działanie powiększenia aparatu przy niskim opóźnieniu. Wykonuje zdjęcia w zakresie powiększenia za pomocą android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) i sprawdza, czy znaczniki na obrazach wyjściowych odpowiadają współczynnikom powiększenia w metadanych zdjęcia. Ta sama sesja przechwytywania z kamery jest używana do konwergencji 3A i robienia zdjęć.

Przetestowane interfejsy API:

Zaliczone: względny rozmiar zarejestrowanego znacznika jest zgodny z metadanymi wyniku współczynnika powiększenia.

test_preview_video_zoom_match

Testuje, czy podczas nagrywania i powiększania podgląd i wyjście wideo wyświetlają i nagrywają te same dane wyjściowe. 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.

Przetestowane interfejsy API:

Zaliczone: względny rozmiar zarejestrowanego znacznika jest zgodny 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. preview_1280x720_key_frame.png (po powiększeniu).

test_preview_zoom

Sprawdza, czy współczynnik powiększenia każdej klatki podglądu odpowiada odpowiednim metadanym przechwytywania z obiektywu ultraszerokokątnego i szerokokątnego. Test pobiera klatki podglądu w zakresie powiększenia i znajduje znacznik ArUco najbliżej środka. Następnie test sprawdza, czy pozycja znacznika środka zmienia się w przewidywalny sposób podczas każdego przechwytywania. Odległość od środka znacznika środkowego do środka obrazu może zmieniać się ze stałą szybkością w stosunku do współczynnika powiększenia aż do fizycznego przełączenia aparatu lub może zmieniać się monotonicznie w kierunku lokalizacji tego samego znacznika po fizycznym przełączeniu aparatu.

Przetestowane interfejsy API:

Zaliczenie: względny rozmiar wybranego znacznika ArUco jest prawidłowy dla zgłoszonego współczynnika powiększenia odpowiedniego wyniku przechwytywania we wszystkich klatkach podglądu. Względna odległość wybranego znacznika od środka obrazu jest dokładna w przypadku zgłoszonego współczynnika powiększenia odpowiadającego wynikowi przechwytywania wszystkich klatek podglądu.

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

Rysunek 124. Obrazy test_preview_zoom pokazujące wybrany znacznik najbliżej środka

test_session_characteristics_zoom

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

Przetestowane interfejsy API:

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

scene7

scene7 to prostokątna ramka podzielona na 4 równe części, z których każda jest wypełniona innym kolorem. Na środku prostokąta znajduje się wykres ze skośną krawędzią do sprawdzania ostrości. 4 znaczniki ArUco są wyrównane z 4 zewnętrznymi rogami prostokąta, aby ułatwić uzyskanie dokładnych współrzędnych głównej ramki prostokąta przy różnych współczynnikach powiększenia.

scene7

Rysunek 125. scene7.

test_multi_camera_switch

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

Test wykorzystuje różne współczynniki powiększenia w zdefiniowanym zakresie, aby wykonać dynamiczne nagranie podglądu i określić moment, w którym zmienia się fizyczny aparat. Ten punkt oznacza przejście z obiektywu UW na obiektyw W.

Klatki zarejestrowane w momencie przekroczenia punktu i przed nim są analizowane pod kątem automatycznej ekspozycji (AE), automatycznego balansu bieli (AWB) i autofokusa (AF).

Test AE sprawdza, czy zmiana luminancji mieści się w oczekiwanym zakresie zarówno w przypadku obrazów z obiektywu UW, jak i W. Sprawdzenie AWB polega na sprawdzeniu, czy stosunek czerwieni do zieleni i niebieskiego do zieleni mieści się w wartościach progowych zarówno w przypadku obrazów z obiektywu UW, jak i W. Sprawdzanie AF ocenia wartość szacunkową ostrości na podstawie średniej wielkości gradientu między obrazami z obiektywu ultraszerokokątnego i szerokokątnego.

Jeśli podczas wykonywania tego testu efekt mory zakłóca wyniki, użyj tabletu o wyższej rozdzielczości z listy tabletów zatwierdzonych do testu Camera ITS.

Przetestowane interfejsy API:

Zaliczenie: aby test zakończył się pomyślnie, testy AE i AWB muszą zakończyć się pomyślnie. Wyniki sprawdzania AF są używane tylko do celów logowania. Oto kryteria poszczególnych testów:

Sprawdzanie AE: zmiana luminancji (wartość Y) między obrazami z obiektywów UW i W musi być mniejsza niż 4% w przypadku wszystkich pól kolorów, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions. Jeśli obsługiwany jest tylko tryb ae_regions, kryteria muszą spełniać tylko wartości próbek szarości.
Sprawdzanie automatycznego balansu bieli: różnica między wartościami czerwono-zielonymi i niebiesko-zielonymi w przypadku obrazów z obiektywów UW i W musi być mniejsza niż 3% w przypadku szarego wzornika kolorów i mniejsza niż 10% w przypadku innych wzorników kolorów, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions.
Sprawdzenie AF: ostrość obrazu w przypadku obiektywu szerokokątnego musi być wyższa niż w przypadku obiektywu ultraszerokokątnego.

test_multi_camera_switch_gray_uw_y

Rysunek 126. Szary fragment zdjęcia zrobionego obiektywem szerokokątnym.

test_multi_camera_switch_gray_w_y

Rysunek 127. Szary fragment zdjęcia zrobionego obiektywem szerokokątnym.

scene8

scene8 to prostokątna ramka podzielona na 4 równe obszary, z których każdy zawiera portret zrobiony z inną ekspozycją lub z nałożonym innym odcieniem koloru (niebieski odcień, zwiększona ekspozycja, zmniejszona ekspozycja, żółty odcień). 4 znaczniki ArUco są wyrównane z 4 zewnętrznymi rogami prostokąta, aby uzyskać dokładne współrzędne głównej ramki prostokąta.

scene8 example

Rysunek 128. Przykład scene8.

test_ae_awb_regions

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

Test rejestruje 8-sekundowe nagranie podglądu, wykonując pomiary AE i AWB w każdej ćwiartce przez 2 sekundy. Następnie test wyodrębnia klatkę z nagrania podglądu każdego regionu i używa wyodrębnionych klatek do przeprowadzenia tych testów AE i AWB:

Sprawdzanie AE: sprawdza, czy klatka, w której mierzony jest region ze zmniejszoną ekspozycją, ma wartość luminancji większą o ponad 1% od klatki, w której mierzony jest region ze zwiększoną ekspozycją. Sprawdza to, czy obrazy są rozjaśniane podczas pomiaru ciemnego obszaru.
Sprawdzanie automatycznego balansu bieli: sprawdza, czy stosunek czerwieni do niebieskiego (średnich wartości RGB obrazu) w ramce z niebieskim obszarem pomiaru jest o ponad 2% wyższy niż w ramce z żółtym obszarem pomiaru. Dzięki temu obrazy mają zrównoważoną wartość RGB podczas pomiaru żółtego (ciepłego) lub niebieskiego (zimnego) obszaru.

Przetestowane interfejsy API:

Zaliczone: testy AE i AWB zostały zaliczone.

test_ae_awb_regions_dark_region

Rysunek 129. Pomiar kadru w ciemnym obszarze ze zwiększoną ekspozycją.

test_ae_awb_regions_light_region

Rysunek 130. Pomiar kadru w jaśniejszym obszarze ze zmniejszoną ekspozycją.

Mechanizmy awarii:

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

Rysunek 131. Nieprawidłowe wyrównanie znaczników ArUco.

test_color_correction_mode_cct

Testuje COLOR_CORRECTION_MODE przy różnych temperaturach kolorów i odcieniach, sprawdzając zmiany współczynników RGB w porównaniu ze sceną przechwytywania, scene8.

Przetestowane interfejsy API:

Zaliczone: współczynniki RGB wykazują oczekiwane wzrosty lub spadki w stosunku do wybranych temperatur kolorów i odcieni.

Kryteria pomijania testów

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

Urządzenie ma pierwszy poziom API (first_api_level) 35 lub niższy.
Urządzenie nie rozgłasza COLOR_CORRECTION_MODE_CCT w COLOR_CORRECTION_AVAILABLE_ABERRATION_MODES.

scene9

scene9 składa się z tysięcy okręgów o różnych rozmiarach i kolorach, które tworzą scenę o bardzo niskiej powtarzalności, co pozwala na testowanie algorytmów kompresji JPEG.

scene9 example

Rysunek 132. Przykład scene9.

test_jpeg_high_entropy

Testuje, czy kompresja JPEG aparatu działa na urządzeniu scene9 z wysoką entropią i współczynnikiem jakości JPEG ustawionym na 100%. Współczynnik powiększenia jest zwiększany, aby sprawdzić, czy scena wyświetlana na tablecie wypełnia pole widzenia kamery.

Przetestowane interfejsy API:

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

test_jpeg_quality

Testuje jakość kompresji JPEG aparatu. Przechodzi przez wartości jakości JPEG android.jpeg.quality i sprawdza, czy tabele kwantyzacji zmieniają się prawidłowo.

Przetestowane interfejsy API:

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

Średnie wartości macierzy DQT luminancji i chrominancji tylnego aparatu Pixela 4 w porównaniu z jakością JPEG

Rysunek 133. Średnie wartości macierzy DQT luminancji i chrominancji tylnego aparatu Pixela 4 w porównaniu z jakością JPEG.

Przykład nieudanego testu test_jpeg_quality

Rysunek 134. Przykład nieudanego testu.

scene_extensions

Testy scene_extensions dotyczą rozszerzeń aparatu i muszą korzystać z zestawu Camera ITS-in-a-Box, ponieważ wymagają precyzyjnej kontroli nad środowiskiem testowym. Dodatkowo należy kontrolować wszelkie przecieki światła. Może to wymagać przykrycia stanowiska testowego, testowanego urządzenia i tabletu folią malarską, a także wyeliminowania przecieku światła z przedniego ekranu testowanego urządzenia.

scene_hdr

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

scene_hdr

Rysunek 135. Przykład scene_hdr.

test_hdr_extension

Testuje rozszerzenie HDR. Wykonuje zrzuty z włączonym i wyłączonym rozszerzeniem i sprawdza, czy rozszerzenie ułatwia wykrywanie kodu QR.

Przetestowane interfejsy API:

Zaliczone: rozszerzenie HDR zmniejsza liczbę zmian kontrastu potrzebnych do wykrycia kodu QR lub zmniejsza gradient w kodzie 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.

scene_low_light example

Rysunek 136. Przykład scene_low_light.

test_night_extension

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

Wykrywa obecność 20 kwadratów
Oblicza luminancję ograniczoną przez każdy kwadrat
Oblicza średnią wartość luma pierwszych 6 kwadratów zgodnie z orientacją siatki krzywej Hilberta.
Oblicza różnicę wartości luma kolejnych kwadratów (np. kwadrat 2 – kwadrat 1) aż do kwadratów 5 i 6 (kwadrat 6 – kwadrat 5) i znajduje średnią z 5 obliczonych różnic.

W przypadku urządzeń z Androidem 16 lub nowszym żądanie przechwycenia obejmuje region pomiaru odpowiadający prostokątowi ograniczającemu siatkę kwadratów. Ten dodatek zmienia kryteria zaliczenia progu.

Przetestowane interfejsy API:

Pass:

W przypadku urządzeń z Androidem 16 lub nowszym średnia wartość luminancji pierwszych 6 kwadratów musi wynosić co najmniej 80, a średnia różnica wartości luminancji kolejnych kwadratów do kwadratów 5 i 6 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 kwadratów 5 i 6 musi wynosić co najmniej 17.

Poniższy wykres luminancji pokazuje, jak wygląda wynik testu, który zakończył się powodzeniem.

Przykład testu sceny nocnej przy słabym oświetleniu, który zakończył się powodzeniem

Rysunek 137. Przykład sceny nocnej przy słabym oświetleniu, która przeszła test.

test_low_light_boost_extension

Testuje tryb AE słabego oświetlenia. Jeśli Camera2 obsługuje tryb AE wzmocnienia przy słabym oświetleniu, ten test jest przeprowadzany dla Camera2. Jeśli rozszerzenie aparatu w trybie nocnym jest obsługiwane i obsługuje tryb AE ulepszonego oświetlenia, ten test jest przeprowadzany również w przypadku rozszerzenia aparatu w trybie nocnym. Ten test ustawia tryb AE na ulepszenie przy słabym oświetleniu, pobiera klatkę z podglądu i wykonuje te czynności:

Wykrywa obecność 20 pudełek
Oblicza luminancję ograniczoną przez każde pole
Oblicza średnią wartość luma pierwszych 6 kwadratów zgodnie z orientacją siatki krzywej Hilberta.
Oblicza różnicę wartości luma kolejnych kwadratów (np. kwadrat 2 – kwadrat 1) aż do kwadratów 5 i 6 (kwadrat 6 – kwadrat 5) i znajduje średnią z 5 obliczonych różnic.

Przetestowane 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 kwadratów 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 kwadratów 5 i 6 musi wynosić co najmniej 18.

scene_tele

Kluczowym wymaganiem w przypadku testów scene_tele jest to, że odległość od wykresu musi być co najmniej równa minimalnej odległości ostrzenia teleobiektywu. Ta minimalna odległość ogniskowania może się różnić w zależności od urządzenia, dlatego musisz skonfigurować ustawienia pod kątem konkretnego teleobiektywu.

Konfiguracja scene_tele na podstawie odległości ostrzenia aparatu szerokokątnego i teleobiektywu

Rysunek 138. Konfiguracja scene_tele na podstawie odległości ostrzenia aparatu szerokokątnego i teleobiektywu.

Więcej informacji o konfigurowaniu sprzętu testowego znajdziesz w artykule Konfigurowanie platformy z teleobiektywem.

scene6_tele

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

Jeśli zdjęcia zrobione aparatem scene6_tele wyglądają na prześwietlone w zestawie modułowym, zdejmij przednią płytkę zestawu modułowego.

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

Rysunek 139. Odłącz platformę testową WFoV od przedłużenia i zdejmij uchwyt na telefon.

remove_front_plate

Rysunek 140. Zdejmij przednią płytkę.

test_zoom_tele

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

Przetestowane interfejsy API:

test_preview_zoom_tele

Testuje działanie zoomu aparatu w przypadku klatek podglądu od obiektywu szerokokątnego do teleobiektywu. Test jest identyczny z test_preview_zoom, ale sprawdza działanie zoomu aparatu w przypadku klatek podglądu od obiektywu szerokokątnego do teleobiektywu.

Przetestowane interfejsy API:

scene7_tele

scene7_tele jest identyczny z scene7, ale jest skonfigurowany do testowania teleobiektywu. Jest to prostokątna ramka podzielona na 4 równe części, z których każda jest wypełniona innym kolorem. Na środku prostokąta znajduje się wykres ze skośną krawędzią do sprawdzania ostrości. 4 znaczniki ArUco są wyrównane z 4 zewnętrznymi rogami prostokąta, aby ułatwić uzyskanie dokładnych współrzędnych głównej ramki prostokąta 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 powiększenia przełączanie się między obiektywem szerokokątnym (W) a teleobiektywem (tele) daje podobne wartości RGB.

Klatki zarejestrowane w momencie przekroczenia punktu i przed nim są analizowane pod kątem AE, AWB i AF.

Test AE sprawdza, czy zmiana luminancji mieści się w oczekiwanym zakresie zarówno w przypadku obrazów z obiektywu szerokokątnego, jak i teleobiektywu. Sprawdzenie AWB polega na sprawdzeniu, czy stosunek czerwieni do zieleni i niebieskiego do zieleni mieści się w wartościach progowych zarówno w przypadku obrazów z obiektywu szerokokątnego, jak i teleobiektywu. Kontrola AF ocenia wartość szacunkową ostrości na podstawie średniej wielkości gradientu między obrazami z obiektywu szerokokątnego i teleobiektywu.

Przetestowane interfejsy API:

Zaliczenie: aby test został zaliczony, muszą zostać zaliczone testy AE, AWB i AF. Kryteria poszczególnych testów:

Sprawdzenie AE: zmiana luminancji między obrazami z obiektywu szerokokątnego i teleobiektywu musi być mniejsza niż 4%.
Sprawdzanie AWB: w przestrzeni barw LAB delta C między czerwonym i zielonym oraz niebieskim i zielonym w przypadku obiektywu szerokokątnego i teleobiektywu nie może przekraczać 10.
Sprawdzenie AF: ostrość obrazu z teleobiektywu musi być wyższa niż w przypadku obiektywu szerokokątnego.

scene_video

scene_video to scena wideo składająca się z 4 różnokolorowych kółek poruszających się w przód i w tył z różną liczbą klatek na białym tle.

Rysunek 141. Przykład scene_video.

test_preview_frame_drop

Sprawdza, czy żądana liczba klatek podglądu jest utrzymywana w dynamicznej scenie. Ten test jest przeprowadzany na wszystkich aparatach, które są dostępne dla aplikacji innych firm.

Przetestowane interfejsy API:

Zaliczenie: liczba klatek podglądu jest równa maksymalnej liczbie klatek z żądanego zakresu, a średnia różnica między kolejnymi klatkami jest mniejsza niż względna tolerancja ustawiona w teście.

Sceny testowe oparte na platformie Gen2 / sensor_fusion

feature_combination

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

test_feature_combination

Testuje wszystkie kombinacje różnych kombinacji strumieni, trybu stabilizacji filmu, docelowego zakresu klatek na sekundę, 10-bitowego filmu HDR i Ultra HDR, które są obsługiwane przez aparat.

W przypadku Androida 16 i nowszych test uruchamia wszystkie kombinacje obsługiwanych funkcji i zapisuje wyniki w pliku proto. Asercje niepowodzenia są wywoływane tylko w przypadku kombinacji funkcji, dla których isSessionConfigurationSupported zwraca True.

Przetestowane interfejsy API:

Zaliczenie: dla każdej obsługiwanej kombinacji funkcji:

Jeśli stabilizacja podglądu jest włączona, strumień podglądu jest stabilizowany.
Liczba klatek podglądu mieści się w skonfigurowanym zakresie AE_TARGET_FPS_RANGE.
Przestrzeń barw nagranego strumienia podglądu jest zgodna z ustawioną.
Zdjęcie Ultra HDR ma prawidłową mapę wzmocnienia.

scene_flash

Testy scene_flash wymagają ciemnej sceny w pudełku do fuzji czujników. W Androidzie 17 i nowszych testowanie scene_flash można przeprowadzać za pomocą platformy Gen2.

test_auto_flash

Testy sprawdzające, czy automatyczna lampa błyskowa jest uruchamiana w ciemnej scenie w przypadku 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 automatyczna lampa błyskowa jest uruchamiana, sprawdzając, czy środek obrazu kafelka jest jaśniejszy, gdy automatyczna lampa błyskowa jest włączona. Aby uruchomić automatyczną lampę błyskową, należy wyłączyć światła w stanowisku testowym. Światła można wyłączyć automatycznie za pomocą kontrolera Arduino. Aby test działał prawidłowo, scena musi być całkowicie ciemna. Przed rozpoczęciem testów na urządzeniu musi być zainstalowana aplikacja Jetpack Camera (JCA). Automatyczna lampa błyskowa w tylnych aparatach jest uruchamiana na podstawie stanu AE, ale automatyczna lampa błyskowa w przednich aparatach nie zależy od AE i jest zawsze uruchamiana.

W Androidzie 17 i nowszych testuje poziomy powiększenia inne niż 1x, aby sprawdzić, czy wszystkie obsługiwane zakresy powiększenia działają prawidłowo.

Przetestowane interfejsy API:

Zaliczone: środek obrazu kafelka z włączoną automatyczną lampą błyskową jest jaśniejszy niż oryginalny obraz sceny we wszystkich aparatach.

test_flash_strength

Sprawdza, czy kontrola mocy lampy błyskowej w trybie SINGLE jest prawidłowo zaimplementowana.

Sprawdza, czy jeśli urządzenie obsługuje sterowanie mocą lampy błyskowej podczas korzystania z aparatu w trybie SINGLE, moc lampy błyskowej zmienia się w zależności od żądanych poziomów. Sprawdza, czy kontrola mocy lampy błyskowej działa z różnymi AE_MODES. Jeśli na przykład tryb automatycznej ekspozycji to ON lub OFF, poziom mocy lampy błyskowej ma wpływ na jasność, a jeśli tryb to ON_AUTO_FLASH, poziom mocy lampy błyskowej nie ma wpływu na jasność.

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

Przetestowane interfejsy API:

Pass:

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

test_led_snapshot

Sprawdza, czy zdjęcia z lampą LED nie są prześwietlone ani zabarwione.

Ten test dodaje kontroler oświetlenia do urządzenia Sensor Fusion Box, aby sterować oświetleniem. Gdy oświetlenie jest ustawione na OFF, test wykonuje zdjęcie w trybie AUTO_FLASH ustawionym na ON. Podczas tego przechwytywania test uruchamia sekwencję przed przechwyceniem z ustawieniem aePrecapture ustawionym na START i ustawia intencję przechwytywania na Preview, aby wykonać przechwytywanie z lampą błyskową.

Ponieważ zdjęcie ma charakterystyczny punkt aktywny z powodu lampy błyskowej, test oblicza średnią wartość obrazu z lampą błyskową dla całego zdjęcia i sprawdza, czy mieści się ona w zakresie (68, 102). Aby sprawdzić, czy obraz ma odpowiedni balans bieli, test oblicza stosunek czerwieni do zieleni i niebieskiego do zieleni, a następnie sprawdza, czy te wartości mieszczą się w zakresie od 0,95 do 1,05.

Przetestowane interfejsy API:

Zaliczenie: stosunek czerwieni do zieleni i niebieskiego do zieleni mieści się w zakresie od 0,95 do 1,05. Średnia wartość obrazu z lampą błyskową mieści się w zakresie (68, 102).

test_night_mode_indicator

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

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

Inicjowanie: test inicjuje ItsSession i pobiera właściwości aparatu. Nawiązuje też połączenie ze sterownikiem 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.
Sesja Camera2:
- Test rozpoczyna sesję przechwytywania podglądu za pomocą sesji Camera2.
- Światło zostanie włączone i zostanie przechwycona klatka podglądu.
- Test sprawdza, czy wskaźnik trybu nocnego jest w stanie OFF.
- Światło zostanie wyłączone i zostanie przechwycona klatka podglądu.
- 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 używa sesji CameraExtension z rozszerzeniem EXTENSION_NIGHT.
Czyszczenie: test zamyka ItsSession i zwalnia kontroler oświetlenia.

Przetestowane 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

Sprawdza, czy liczba klatek podglądu prawidłowo zmniejsza się w ciemnej scenie. Aby ten test działał prawidłowo, oświetlenie w stanowisku testowym musi zostać wyłączone przez kontroler lub ręcznie przez operatora testu.

Przetestowane interfejsy API:

Zaliczone: liczba klatek podglądu jest równa co najmniej minimalnej wartości z żądanego zakresu, a różnica między klatkami jest mniejsza niż bezwzględna tolerancja ustawiona w teście.

test_torch_strength

Sprawdza, czy kontrola mocy lampy błyskowej w trybie TORCH jest prawidłowo zaimplementowana.

Sprawdza, czy jeśli urządzenie obsługuje sterowanie mocą lampy błyskowej podczas korzystania z aparatu w trybie TORCH, moc latarki zmienia się w zależności od żądanego poziomu. Sprawdza, czy kontrola mocy lampy błyskowej działa z różnymi AE_MODES. Jeśli na przykład tryb automatycznej ekspozycji to ON lub OFF, poziom mocy lampy błyskowej ma wpływ na jasność, a jeśli tryb to ON_AUTO_FLASH, poziom mocy lampy błyskowej nie ma wpływu na jasność. Sprawdza, czy moc latarki pozostaje taka sama przez cały czas trwania serii, symulując sesję nagrywania filmu. Aby przeprowadzić test, należy wyłączyć światła w stanowisku testowym. Światła można wyłączyć automatycznie za pomocą kontrolera Arduino. Aby test działał prawidłowo, scena musi być całkowicie ciemna.

Przetestowane interfejsy API:

Pass:

Gdy tryb automatycznej ekspozycji jest ustawiony na ON lub OFF, jasność fragmentów serii zdjęć wzrasta wraz ze wzrostem poziomu siły błysku od braku błysku do FLASH_TORCH_STRENGTH_MAX_LEVEL. Gdy tryb automatycznej ekspozycji jest ustawiony na ON_AUTO_FLASH, różnica w jasności fragmentów serii zdjęć mieści się w granicach tolerancji, gdy poziom siły błysku wzrasta od braku błysku do FLASH_TORCH_STRENGTH_MAX_LEVEL.

scene_gen2_chart

W Androidzie 17 i nowszych wersjach scene_gen2_chart korzysta z papierowej tablicy Gen2.

Ta tablica testowa zawiera próbki twarzy, kod QR, fragmenty w skali szarości, gwiazdę Siemensa, tablicę kolorów i pochylone kwadraty.

test_chart_gen2

Rysunek 142. Przykładowy wykres Gen2.

test_tonemap_sequence

Ten test ocenia domyślną krzywą mapowania tonów urządzenia w porównaniu z krzywą liniową i 2 krzywymi wykładniczymi (jedną z jednolitymi punktami i drugą z niejednolitymi punktami). Aby wynik był pozytywny, jasność krzywej domyślnej musi przekraczać jasność krzywej liniowej i wykładniczej. Dodatkowo krzywa liniowa musi być jaśniejsza niż krzywe wykładnicze, a obie krzywe wykładnicze powinny mieć podobne poziomy jasności.

Test sprawdza też dokładność domyślnej krzywej urządzenia. W tym celu wyodrębnia domyślną krzywą, ponownie ją wprowadza, a następnie porównuje jasność wynikowego obrazu z obrazem oryginalnej domyślnej krzywej.

Wykres sekwencji mapowania tonów testowych

Rysunek 143. Wykres sekwencji mapowania tonów testowych.

Przetestowane interfejsy API:

Zaliczone: różnica jasności między krzywą domyślną a liniową wynosi ponad 15%, a między 2 krzywymi wykładniczymi – mniej niż 8%.

test_multi_camera_switch

Ten test sprawdza spójność kolorów i ekspozycji podczas dynamicznych przejść zoomu. Sprawdza, czy przełączanie się między obiektywem ultraszerokokątnym (UW) a szerokokątnym (W) podczas nagrywania podglądu pozwala zachować niemal identyczne wartości CIELAB, co zapobiega widocznym zmianom w wrażeniach użytkownika.

Test wykonuje dynamiczne nagrywanie podglądu w określonym zakresie zoomu, aby wywołać fizyczny punkt „przejścia” aparatu, w którym obiektyw ultraszerokokątny przełącza się na obiektyw szerokokątny. Test identyfikuje dokładną klatkę, w której następuje przełączenie obiektywu. Klatki bezpośrednio poprzedzające i następujące po tym punkcie są rejestrowane i analizowane pod kątem stabilności automatycznej ekspozycji (AE) i automatycznego balansu bieli (AWB).

Sprawdzenie AE potwierdza, że wahania luminancji pozostają w akceptowalnym zakresie podczas przełączania obiektywów. Sprawdzenie AWB polega na weryfikacji, czy stosunek czerwieni do zieleni i niebieskiego do zieleni mieści się w określonych progach neutralności kolorów.

Przetestowane interfejsy API:

Zaliczenie: aby test został zaliczony, muszą zostać zaliczone te testy AE i AWB:

Sprawdzanie AE: zmiana luminancji (wartość Y) między obrazami z obiektywów UW i W musi być mniejsza niż 4% w przypadku wszystkich pól kolorów, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions. Jeśli obsługiwany jest tylko tryb ae_regions, kryteria muszą spełniać tylko wartości szarych pól.
Sprawdzanie automatycznego balansu bieli: różnica między wartościami czerwono-zielonymi i niebiesko-zielonymi w przypadku obrazów z obiektywów UW i W musi być mniejsza niż 3% w przypadku szarego wzornika kolorów i mniejsza niż 10% w przypadku innych wzorników kolorów, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions.

uw_dynamic_range_patch_cell_8

Rysunek 144. Szary fragment zdjęcia zrobionego obiektywem szerokokątnym.

w_dynamic_range_patch_cell_7

Rysunek 145. Szary fragment zdjęcia zrobionego obiektywem szerokokątnym.

scene_ip

W Androidzie 16 i nowszych scena scene_ip umożliwia sprawdzanie zgodności obrazów między domyślną aplikacją aparatu a aplikacją aparatu Jetpack (JCA) w celu identyfikowania głównych różnic między przechwyconymi obrazami. JCA replikuje zdjęcia z aplikacji społecznościowych i udostępnia obraz bazowy, który aplikacje społecznościowe następnie przetwarzają i ulepszają.

Wymagania dotyczące konfiguracji sprzętu

Do testów scene_ip wymagana jest ta konfiguracja sprzętu:

Testy są wykonywane w pudełku ITS-in-a-box z kamerą 2 generacji.
Do sterowania środowiskiem testowym służą kontrolery oświetlenia i serwomechanizmów, które są częścią platformy Gen2.
W urządzeniu Gen2 znajduje się wykres funkcji testowych.

test_chart_gen2

Rysunek 146. Przykład Gen2chart_sample.

Kryteria pomijania testów

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

Urządzenie ma pierwszy poziom API (first_api_level) 35 lub niższy.
Urządzenie nie jest telefonem z głównym aparatem przednim i tylnym (np. tablet lub telewizor).

test_default_jca_ip

Robi zdjęcia wykresu funkcji testowej w kontrolowanych warunkach oświetleniowych przy użyciu domyślnej aplikacji aparatu i JCA, a następnie przeprowadza te testy:

FoV:sprawdza, czy domyślna aplikacja aparatu i zdjęcia JCA mają takie samo pole widzenia. Ta kontrola wykorzystuje funkcję środkowego kodu QR wyodrębnioną z przechwyconego obrazu wykresu.
Jasność: sprawdza, czy różnica jasności mierzona między domyślną aplikacją aparatu a JCA nie przekracza 10. Ten test wykorzystuje łatkę zakresu dynamicznego do pomiaru jasności.
Balans bieli: sprawdza, czy różnica balansu bieli między domyślną aplikacją aparatu a JCA nie przekracza 4. Ten test wykorzystuje łatkę zakresu dynamicznego do pomiaru jasności.
Odwzorowanie kolorów: sprawdza, czy różnica w odwzorowaniu kolorów między domyślną aplikacją aparatu a JCA nie przekracza 6.

Zaliczone: test zalicza testy pola widzenia, jasności i balansu bieli. W Androidzie 16 ten test nie jest wymagany (NOT_YET_MANDATED). W Androidzie 17 i nowszych wymagane są testy zgodności pola widzenia, jasności i balansu bieli. W Androidzie 17 sprawdzanie renderowania kolorów nie jest wymagane (NOT_YET_MANDATED).

test_jca_jpegr_ip

Sprawdza, czy różnica balansu bieli między podglądem JPEG_R JCA a zrobionymi zdjęciami nie przekracza 4.

Przetestowane interfejsy API:

Zaliczenie: różnica balansu bieli między podglądem JCA a przechwyconym obrazem JPEG_R mieści się w zakresie progu (domyślnie 4).

sensor_fusion

Testy fuzji czujników wymagają określonego ruchu telefonu przed wzorem szachownicy i znacznikami ArUco. Aby uzyskać optymalne wyniki, upewnij się, że tablica testowa jest zamontowana płasko. Wykresy, które nie są płaskie, wpływają na obliczenia obrotu w przypadku wielu testów. Wydrukowana plansza musi wypełniać tylną ściankę pudełka do fuzji czujników, dlatego jej wymiary powinny wynosić 17 x 17 cali. (43 x 43 cm). Testy sensor_fusion można zautomatyzować za pomocą pudełka do fuzji czujników.

Wykres fuzji czujników

Rysunek 147. Wykres fuzji czujników.

Wykres fuzji czujników w Rig

Rysunek 148. Tabela fuzji czujników, która wypełnia tył skrzynki bezpiecznikowej fuzji czujników.

test_lens_intrinsic_calibration

Sprawdza, czy środek optyczny obiektywu zmienia się, gdy obiektyw porusza się z powodu optycznej stabilizacji obrazu (OIS). Jeśli próbki wewnętrzne obiektywu są obsługiwane, testuje, czy środek optyczny próbek wewnętrznych obiektywu zmienia się, gdy obiektyw porusza się pod wpływem optycznej stabilizacji obrazu.

Przetestowane interfejsy API:

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

Poniższy rysunek przedstawia przykładowy wykres test_lens_intrinsic_calibration, który pokazuje zmiany punktów głównych w pikselach dla każdej klatki:

Rysunek 149. Przykład wykresu test_lens_intrinsic_calibration pokazującego zmiany punktów głównych w pikselach dla każdej klatki.

test_multi_camera_frame_sync

Testuje, czy sygnatury czasowe klatek zarejestrowane przez kamerę logiczną mieszczą się w zakresie 10 ms, obliczając kąty kwadratów na szachownicy w celu określenia sygnatury czasowej.

Przetestowane interfejsy API:

Wynik pozytywny: kąt między obrazami z poszczególnych aparatów nie zmienia się znacząco podczas obracania telefonu.

test_preview_distortion

Sprawdza, czy zniekształcenia są korygowane w każdej klatce podglądu wykonanej przy różnych poziomach powiększenia. W przypadku każdej klatki podglądu test oblicza idealne punkty na podstawie parametrów wewnętrznych i zewnętrznych aparatu.

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

Rysunek 150. Obraz przedstawiający szachownicę z idealnymi punktami oznaczonymi na zielono i rzeczywistymi punktami oznaczonymi na czerwono.

Przetestowane interfejsy API:

Zaliczenie: znormalizowany błąd zniekształcenia każdej klatki podglądu jest mniejszy niż próg ustawiony w teście.

test_preview_stabilization

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

Przetestowane interfejsy API:

Zaliczone: maksymalny kąt obrotu w klatkach jest mniejszy niż 70% obrotu żyroskopu.

Poniżej znajdziesz przykładowe filmy ze stabilizacją i bez niej:

Rysunek 151. Przykładowy film ze stabilizacją.

Rysunek 152. Przykładowy film bez stabilizacji.

test_sensor_fusion

Testuje różnicę sygnatur czasowych między aparatem a żyroskopem w aplikacjach AR i VR. Telefon jest obracany o 90 stopni 10 razy przed wzorem szachownicy. Ruch trwa około 2 sekund w obie strony. Ten test jest pomijany, jeśli nie ma żyroskopu lub jeśli parametr źródła sygnatury czasowej REALTIME nie jest włączony.

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

test_sensor_fusion_gyro_events: pokazuje zdarzenia żyroskopu telefonu podczas testu. Ruch w kierunku x i y oznacza, że telefon nie jest bezpiecznie zamontowany na uchwycie ściennym, co zmniejsza prawdopodobieństwo zaliczenia testu. Liczba cykli na wykresie zależy od szybkości zapisu klatek.

Rysunek 153. Przykładowe zdarzenia żyroskopu test_sensor_fusion.
test_sensor_fusion_plot_rotations: pokazuje wyrównanie zdarzeń żyroskopu i kamery. Ten wykres musi pokazywać zgodny ruch między aparatem a żyroskopem z dokładnością do +/-1 ms.

Rysunek 154. Przykładowe obroty wykresu test_sensor_fusion.

Przetestowane interfejsy API:

Zaliczone: przesunięcie sygnatur czasowych aparatu i żyroskopu jest mniejsze niż 1 ms zgodnie z sekcją 7.3.9 Czujniki High Fidelity w dokumencie CDD.

Mechanizmy awarii:

Błąd przesunięcia: przesunięcie między aparatem a żyroskopem nie jest prawidłowo skalibrowane w zakresie +/-1 ms.
Gubienie klatek: potok nie jest wystarczająco szybki, aby przechwycić 200 klatek z rzędu.
Błędy gniazda: adb nie może połączyć się z testowanym urządzeniem na wystarczająco długi czas, aby przeprowadzić test.
Tablica nie jest zamontowana płasko. Na wykresie test_sensor_fusion_plot_rotations są klatki, w których obrót żyroskopu i kamery znacznie się różni, gdy kamera obraca się w częściach wykresu, które nie są płaskie.
Kamera nie jest zamontowana na płasko. Wykres test_sensor_fusion_gyro_events pokazuje ruch w płaszczyznach X i Y. Ten problem występuje częściej w przypadku przednich aparatów, ponieważ tylny aparat często ma wypukłość, która powoduje przechylenie podczas montowania tylnej części telefonu na uchwycie.

test_video_stabilization

Wycofany: ten test został wycofany z Androida 17. W przypadku Androida 17 i nowszych ten test jest zastępowany przez test_video_stabilization_jca.

Testuje, czy stabilizowany film obraca się mniej niż żyroskop.

Przetestowane interfejsy API:

Zaliczone: maksymalny kąt obrotu w klatkach jest mniejszy niż 60% obrotu żyroskopu.

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

Rysunek 155. Przykładowy film ze stabilizacją.

Rysunek 156. Przykładowy film bez stabilizacji.

test_video_stabilization_jca

Testy, które wykazały, że stabilizowany film nagrany za pomocą JCA obraca się mniej niż żyroskop. Przed rozpoczęciem testów na urządzeniu musi być zainstalowana aplikacja JCA.

Przetestowane interfejsy API:

Zaliczenie: maksymalny kąt obrotu klatek wyodrębnionych z filmu nagranego za pomocą JCA jest mniejszy niż 70% obrotu żyroskopu (4).

Scena testowa z dyfuzorem

scene5

scene5 wymaga jednolicie oświetlonej szarej sceny. Służy do tego dyfuzor umieszczony na obiektywie aparatu. Zalecamy ten dyfuzor: http://www.edmundoptics.com/optics/windows-diffusers/optical-diffusers/opal-diffusing-glass/46168/.

Aby przygotować scenę, przymocuj dyfuzor przed aparatem i skieruj aparat na źródło światła o natężeniu około 2000 luksów. Zdjęcia zrobione na potrzeby scene5 wymagają rozproszonego oświetlenia bez widocznych cech. Oto przykładowy obraz:

scene5 example

Rysunek 157. Przykładowe ujęcie sceny 5.

Ponieważ w tej scenie nie są wymagane tablety ani kontrolery, testy używają platformy testowej TEST_BED_MANUAL. Przykład znajdziesz w pliku config.yml do testowania ręcznego. Domyślny plik config.yml nie zawiera TEST_BED_MANUAL, ale możesz go zmodyfikować, aby go dodać.

test_lens_shading_and_color_uniformity

Sprawdza, czy korekcja cieniowania obiektywu jest stosowana prawidłowo, a kolor monochromatycznej, jednolitej sceny jest równomiernie rozłożony. Przeprowadza ten test na klatce YUV z automatycznym 3A. Winietowanie jest oceniane na podstawie kanału Y. Mierzy średnią wartość y dla każdego określonego bloku próbki i określa, czy wynik jest pozytywny czy negatywny, porównując go z wartością środkową y. Test jednolitości kolorów jest oceniany w przestrzeni czerwono-zielonej i niebiesko-zielonej.

Przetestowane interfejsy API:

Zaliczenie: w określonym promieniu obrazu wariancja wartości czerwono-zielonej i niebiesko-zielonej musi być mniejsza niż 20%.

Mechanizmy awarii:

Nadmierne winietowanie na zdjęciach
Artefakty czarnej ramki na obrazach

test_lens_shading_and_color_uniformity_y_plane

Rysunek 158. test_lens_shading_and_color_uniformity_y_plane.

test_lens_shading_and_color_uniformity_color_uniformity_result

Rysunek 159. test_lens_shading_and_color_uniformity_color_uniformity.

test_lens_shading_and_color_uniformity_lens_shading_result

Rysunek 160. test_lens_shading_and_color_uniformity_lens_shading_result.

Scena testowa na tablecie z szeroką gamą kolorów

scene_wide_gamut

scene_wide_gamut to prostokątna ramka podzielona na 4 równe części, z których każda jest wypełniona innym kolorem. Wymaga to, aby tablet wyświetlał wykres w szerokiej gamie kolorów, a testowane urządzenie zrobiło zdjęcie ekranu w szerokiej gamie kolorów.

Te testy sprawdzają, czy przechwycony obraz jest zgodny z prawidłowym profilem i zakresem kolorów.

test_display_p3

Testuje przechwytywanie Display P3 w formacie JPEG za pomocą interfejsu API ColorSpaceProfiles. Sprawdza, czy przechwycony plik JPEG ma w nagłówku odpowiedni profil ICC i czy obraz zawiera określony percentyl kolorów spoza gamy sRGB.

Przetestowane interfejsy API:

Zaliczony: plik JPEG zawiera profil ICC Display P3 i ponad 1% kolorów spoza gamy sRGB.

test_display_p3 example

Rysunek 161. Przykład test_display_p3.

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

Sceny testowe na tablecie

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

Testy ITS kamery