Aby zachować zgodność z naszym modelem rozwoju gałęzi głównej i zapewnić stabilność platformy w ekosystemie, w II i IV kwartale 2026 r. opublikujemy kod źródłowy w AOSP. Do tworzenia i współtworzenia AOSP zalecamy używanie android-latest-release zamiast aosp-main. Gałąź android-latest-release manifestu zawsze będzie odnosić się do najnowszej wersji przesłanej do AOSP. Więcej informacji znajdziesz w sekcji Zmiany w AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Testy ITS kamery

Na tej stronie znajdziesz pełną listę testów wchodzących w skład pakietu Camera Image Test Suite (ITS), który jest częścią weryfikatora pakietu 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 pozwala deweloperom i testerom zrozumieć, co robią poszczególne testy i jak debugować błędy testów.

W Androidzie 17 i nowszych testy Camera ITS są podzielone na 2 aktywności w aplikacji CTS Verifier, co umożliwia równoległe wykonywanie testów i skraca czas testowania: jedna aktywność dotyczy testów feature_combination i sensor_fusion, a druga – wszystkich pozostałych testów.

Testy Camera ITS są dzielone na kategorie 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, aby ograniczyć testy dodane na określonym poziomie interfejsu API, które testują negatywne doświadczenia użytkowników związane z funkcjami na niższych poziomach interfejsu API. ITS używa ro.vendor.api_level do ograniczania 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 wartość ro.odm.build.media_performance_class, ITS wymaga przeprowadzenia określonych testów w zależności od poziomu MPC.

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

scene0: przechwytywanie metadanych, drgań, danych z żyroskopu i wibracji;
scene1: ekspozycja, czułość, kompensacja wartości ekspozycji (EV), YUV a JPEG i RAW
scene2: wykrywanie twarzy, testy wymagające scen kolorowych
scene3: wyostrzenie krawędzi, ruch obiektywu
scene4: format obrazu, kadrowanie, pole widzenia;
scene5: cieniowanie obiektywu,
scene6: powiększenie
scene7: przełącznik wielu kamer
scene8: automatyczna ekspozycja (AE) i automatyczny balans bieli (AWB)
scene9: kompresja JPEG
scene_extensions: rozszerzenia aparatu
scene_tele: przełączanie teleobiektywu;
scene_flash: automatyczny błysk, minimalna liczba klatek na sekundę
scene_video: utrata klatek;
scene_gen2_chart: testy z użyciem papierowej karty Gen2;
scene_wide_gamut: szeroka gama kolorów i zakres
sensor_fusion: przesunięcie czasowe kamery i żyroskopu;
feature_combination: kombinacje funkcji
scene_ip: zgodność obrazu między domyślną aplikacją aparatu a aplikacją aparatu Jetpack (JCA);

Opis każdej sceny znajdziesz w odpowiedniej sekcji.

scene0

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

test_jitter

Mierzy drgania w sygnaturach czasowych kamery.

Testowane interfejsy API:

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

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

wykres rozrzutu testu

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.

Testowane interfejsy API:

Pass: tagi na poziomie sprzętu 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

Testy, które sprawdzają, czy urządzenie zapisuje prawidłowe wartości ekspozycji i wzmocnienia, odczytując metadane przechwytywania.

Testowane interfejsy API:

Pass (Zaliczone): wartości metadanych w żądaniu i w przechwyconych danych 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 o zdarzenia czujników i je wyświetla. Oczekiwane czujniki to akcelerometr, żyroskop i magnetometr. Ten test działa tylko wtedy, gdy ekran jest włączony, czyli urządzenie nie jest w trybie gotowości.

Testowane interfejsy API:

Pass (Zaliczone): otrzymywane są zdarzenia z każdego czujnika.

test_solid_color_test_pattern

Testuje, czy jednolite wzorce testowe są prawidłowo generowane na potrzeby wyciszania kamery. Jeśli wyciszanie kamery jest obsługiwane, muszą być obsługiwane jednolite wzorce testowe. Jeśli wyciszanie kamery nie jest obsługiwane, testowane są tylko jednolite wzorce testowe, jeśli funkcja jest reklamowana.

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

Testowane interfejsy API:

Pozytywny: obsługiwane jednolite wzorce testowe mają prawidłowy kolor, a na obrazie występuje niewielka wariancja.

test_test_pattern

Testuje parametr android.sensor.testPatternMode, aby rejestrować klatki dla każdego prawidłowego wzorca testowego, i sprawdza, czy klatki są prawidłowo generowane w przypadku jednolitych kolorów i pasków kolorów. Test ten obejmuje te czynności:

Rejestruje obrazy dla wszystkich obsługiwanych wzorców testowych.
Przeprowadza test poprawności dla jednolitego wzorca testowego i pasków kolorów.

Testowane interfejsy API:

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

Przykład test_test_patterns

Ilustracja 2. Przykład test_test_patterns.

test_tonemap_curve

Testuje konwersję wzorca testowego z formatu RAW na YUV z liniowym mapowaniem tonalnym. Ten test wymaga, aby android.sensor.testPatternMode = 2 (COLOR_BARS) wygenerował idealny wzór obrazu do konwersji mapy tonalnej. Sprawdza, czy potok ma prawidłowe dane wyjściowe kolorów z liniowym mapowaniem tonalnym i idealnym obrazem wejściowym (zależy od test_test_patterns).

Testowane interfejsy API:

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

test_tonemap_curve – przykład surowy

Ilustracja 3. Przykład surowego pliku test_tonemap_curve.

Przykład test_tonemap_curve YUV

Rysunek 4. Przykład test_tonemap_curve YUV.

test_unified_timestamp

Sprawdza, czy zdarzenia z czujnika obrazu i ruchu występują w tej samej domenie czasowej.

Testowane interfejsy API:

Pass: znaczniki czasu ruchu znajdują się między znacznikami czasu dwóch obrazów.

test_vibration_restriction

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

Testowane interfejsy API:

Wynik pozytywny: urządzenie nie wibruje, gdy jest wyciszone przez interfejs API ograniczeń dźwięku z kamery.

scene1_1

scene1 to szary wykres. Szara karta musi zajmować środkowe 30% pola widzenia aparatu. Szara karta powinna stanowić umiarkowane wyzwanie dla 3A (AE, AWB i AF), ponieważ środkowa część nie ma żadnych cech. Żądanie przechwytywania określa jednak całą scenę, która zawiera wystarczającą liczbę funkcji, aby algorytm 3A mógł zbiegać się w jednym punkcie.

Kamery RFoV można testować na stanowisku testowym WFoV lub RFoV. Jeśli kamera RFoV jest testowana na stanowisku testowym WFoV, wykres jest skalowany o 2/3, aby określić niektóre granice szarego wykresu w polu widzenia, co ułatwia zbieżność 3A. Szczegółowe opisy stanowisk testowych do testowania aparatów znajdziesz w artykule Camera ITS-in-a-box.

przykład sceny 1

Rysunek 5. Wykres sceny1 w pełnym rozmiarze (z lewej) i w skali 2/3 (z prawej).

test_ae_precapture_trigger

Testuje automat stanu AE podczas korzystania z wyzwalacza wstępnego przechwytywania. Rejestruje 5 ręcznych próśb z wyłączonym AE. Ostatnie żądanie ma wyzwalacz wstępnego przechwytywania AE, który należy zignorować, ponieważ AE jest wyłączone.

Testowane interfejsy API:

Pass: AE converges.

test_auto_vs_manual

Testy, w których wykonano zdjęcia automatyczne i ręczne, wyglądają tak samo.

Testowane interfejsy API:

Pass: ręczne ustawienia balansu bieli i przekształcenia zgłoszone w każdym wyniku przechwytywania są zgodne z automatycznym balansem bieli estimate z algorytmu 3A aparatu.

test_auto_vs_manual auto example

Ilustracja 6. test_auto_vs_manual auto example.

test_auto_vs_manual white balance example

Ilustracja 7. Przykład testu automatycznego i ręcznego balansu bieli.

test_auto_vs_manual manual white balance transform example

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

test_black_white

Test, który sprawdza, czy urządzenie generuje w pełni czarno-białe obrazy. Robi 2 zdjęcia: pierwsze z bardzo niskim wzmocnieniem i krótkim czasem naświetlania, co daje czarne zdjęcie, a drugie z bardzo wysokim wzmocnieniem i długim czasem naświetlania, co daje białe zdjęcie.

Testowane interfejsy API:

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

test_black_white, czarny przykład

Ilustracja 9. test_black_white, przykład czerni.

test_auto_vs_manual manual white balance transform example

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

test_black_white plot means example

Ilustracja 11. test_black_white, przykład wykresu średnich.

test_burst_capture

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

Testowane interfejsy API:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_BURST_CAPTURE

Zaliczone: rejestruje serię zdjęć w pełnym rozmiarze, sprawdza, czy nie brakuje klatek i czy jasność obrazu jest odpowiednia.

test_burst_sameness_manual

Wykonuje 5 serii po 50 zdjęć z ręcznym ustawieniem rejestrowania 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.

Testowane interfejsy API:

Zgodność: obrazy są identyczne wizualnie i pod względem wartości RGB.

Błąd: na początku każdego impulsu widać skok lub spadek na wykresie średniej wartości RGB.

Tolerancja wynosi 3% dla first_API_level < 30
Tolerancja wynosi 2% w przypadku wartości first_API_level >= 30.

test_burst_sameness_manual_mean

Rysunek 12. Przykład średniej wartości testu test_burst_sameness_manual.

test_burst_sameness_manual_plot_means

Rysunek 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

Sprawdza, czy strumienie RAW nie mogą być przycinane.

Testowane interfejsy API:

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

test_crop_region_raw comp raw crop example

Ilustracja 14. test_crop_region_raw comp raw crop example.

test_crop_region_raw comp raw full example

Ilustracja 15. test_crop_region_raw comp raw full example.

test_crop_region_raw comp YUV crop example

Ilustracja 16. Przykład wycinania YUV w komponencie test_crop_region_raw.

test_crop_region_raw_yuv_full example

Ilustracja 17. test_crop_region_raw YUV – pełny przykład.

test_crop_regions

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

Testowane interfejsy API:

Pass:obraz przyciętego regionu pasuje do fragmentu odpowiadającego przyciętemu obrazowi.

test_ev_compensation

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

W sekcji podstawowej testuje się, czy kompensacja ekspozycji jest stosowana przy użyciu zakresu utworzonego za pomocą funkcji CONTROL_AE_COMPENSATION_STEP. Przy 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ą. Oczekiwane wartości są obliczane na podstawie jasności obrazu bez kompensacji ekspozycji. Oczekiwana wartość osiąga maksymalny poziom, jeśli obliczone wartości przekraczają zakres rzeczywistej wartości obrazu. Test kończy się niepowodzeniem, jeśli oczekiwane i zmierzone wartości nie są zgodne lub jeśli obrazy są prześwietlone w ciągu 5 kroków.

Testowane interfejsy API:

Podstawowy test sekcji: obrazy pokazują rosnącą ekspozycję bez prześwietlenia w 5 krokach.

test_ev_compensation_basic

Rysunek 18. test_ev_compensation_basic.

Zaawansowane przejście sekcji: rejestruje wzrost luminancji wraz ze wzrostem ustawienia kompensacji EV. Osiem 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

Testy, w których uzyskuje się stałą ekspozycję przy różnych wartościach ISO i czasie ekspozycji. Wykonuje serię zdjęć z wartościami ISO i czasem ekspozycji dobranymi tak, aby się wzajemnie równoważyły. Wyniki powinny mieć taką samą jasność, ale w trakcie sekwencji obraz powinien stawać się 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ć na obrazach RAW, ustawiając w pliku konfiguracyjnym flagę debug.

Testowane interfejsy API:

Pass: obrazy mają tę samą jasność, ale przy wyższym ISO stają się bardziej zaszumione. Płaszczyzny RGB są płaskie, gdy wartość ISO*ekspozycja jest stała w testowanym zakresie wzmocnienia.

Mechanizm awaryjny: na poniższym rysunku w miarę wzrostu wartości mnożnika wzmocnienia (oś X) znormalizowane średnie wartości płaszczyzny RGB (oś Y) zaczynają odbiegać od wartości mnożnika wzmocnienia przy niskim wzmocnieniu.

test_exposure_plot_means

Rysunek 20. test_exposure_plot_means.

test_exposure_mult=1.00.jpg

Rysunek 21. test_exposure_mult=1.00.

test_exposure_mult=64.00

Rysunek 22. test_exposure_mult=64.00.

test_latching

Sprawdza, czy ustawienia (ekspozycja i wzmocnienie) są prawidłowo stosowane w przypadku kamer FULL i LEVEL_3. Wykonuje serię zdjęć za pomocą kolejnych żądań, zmieniając parametry żądania przechwytywania między zdjęciami. Sprawdza, czy obrazy mają oczekiwane właściwości.

Testowane interfejsy API:

android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL

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

test_latching plot means example

Ilustracja 23. Wykres test_latching oznacza przykład.

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

Testy, które pokazują, że przetwarzanie na urządzeniu można odwrócić do pikseli liniowych. Rejestruje serię zdjęć, gdy urządzenie jest skierowane na jednolity cel.

Testowane interfejsy API:

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

test_linearity plot means example

Rysunek 37. Wykres test_linearity oznacza przykład.

test_locked_burst

Testy blokady 3A i serii YUV (z użyciem ustawienia automatycznego). Ten test ma być zaliczany nawet na urządzeniach o ograniczonych możliwościach, które nie mają MANUAL_SENSOR ani PER_FRAME_CONTROLS. Test sprawdza spójność obrazu YUV, a sprawdzanie liczby klatek na sekundę odbywa się w ramach CTS.

Testowane interfejsy API:

Pozytywny: zrzuty ekranu wyglądają spójnie.

test_locked_burst frame0 example

Rysunek 38. Przykład ramki 0 test_locked_burst.

test_locked_burst frame1 example

Ilustracja 39. Przykład ramki test_locked_burst frame1.

test_locked_burst_frame2

Rysunek 40. Przykład ramki test_locked_burst frame2.

scene1_2

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

test_param_color_correction

Testy, w których parametry android.colorCorrection.* są stosowane po ustawieniu. Robi zdjęcia z różnymi wartościami przekształcenia i wzmocnienia oraz sprawdza, czy wyglądają one odpowiednio inaczej. Przekształcenie i wzmocnienie są wybierane tak, aby kolor wyjściowy stawał się coraz bardziej czerwony lub niebieski. Używa liniowego mapowania tonalnego.

Mapowanie odcieni to technika stosowana w przetwarzaniu obrazów, która polega na mapowaniu 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.

Testowane interfejsy API:

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

test_param_color_correction plot means example

Rysunek 41. Wykres test_param_color_correction oznacza przykład.

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

test_param_color_correction req=0 unity example

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

test_param_color_correctness req=1 red boost example

Ilustracja 43. test_param_color_correctness req=1 red boost example.

test_param_color_correction req=2 blue boost example

Ilustracja 44. Przykład zwiększenia niebieskiego w przypadku parametru test_param_color_correction req=2.

test_param_flash_mode

Sprawdza, czy parametr android.flash.mode jest stosowany. Ręcznie ustawia ekspozycję na ciemną stronę, aby było widać, czy lampa błyskowa została wyzwolona, czy nie, i używa liniowego mapowania tonalnego. Sprawdza środek obrazu z kafelka, aby zobaczyć, czy jest tam duży gradient, który został utworzony w celu sprawdzenia, czy lampa błyskowa została uruchomiona.

Testowane interfejsy API:

Zaliczone: środek obrazu kafelka ma 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

Ilustracja 46. Przykład jednego kafelka test_param_flash_mode.

Przykład test_param_flash_mode_2

Rysunek 47. Przykład test_param_flash_mode 2.

test_param_flash_mode 2 tile example

Ilustracja 48. Przykład dwóch kafelków parametru test_param_flash_mode.

test_param_noise_reduction

Sprawdza, czy parametr android.noiseReduction.mode jest prawidłowo stosowany, gdy jest ustawiony. Rejestruje obrazy aparatem przy słabym oświetleniu. Używa wysokiego wzmocnienia analogowego, aby zapewnić, że zarejestrowany obraz będzie zaszumiony. Rejestruje 3 obrazy: z wyłączoną redukcją szumów, z szybką redukcją szumów i z redukcją szumów o wysokiej jakości. Rejestruje też obraz z niskim wzmocnieniem i wyłączoną redukcją szumów, a jego wariancję wykorzystuje jako wartość bazową. Im wyższy stosunek sygnału do szumu (SNR), tym lepsza jakość obrazu.

Testowane interfejsy API:

android.hardware.camera2.CaptureRequest#NOISE_REDUCTION_MODE

Zaliczone: 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

Ilustracja 49. Wykres test_param_noise_reduction przedstawiający przykładowe wartości SNR.

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

test_param_noise_reduction high gain nr=0 example

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

test_param_noise_reduction high gain nr=1 example

Ilustracja 51. test_param_noise_reduction high gain nr=1 example.

test_param_noise_reduction high gain nr=2 example

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

test_param_noise_reduction high gain nr=3 example

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

Przykład test_param_noise_reduction z niskim wzmocnieniem

Ilustracja 54. Przykład test_param_noise_reduction z niskim wzmocnieniem.

test_param_shading_mode

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

Testowane interfejsy API:

Zaliczone: tryby cieniowania są przełączane, a mapy cieniowania obiektywu są modyfikowane zgodnie z oczekiwaniami.

test_param_shading_mode lens shading map, mode 0 loop 0 example

Ilustracja 55. test_param_shading_mode – mapa cieniowania obiektywu, tryb 0, pętla 0.

test_param_shading_mode lens shading map, mode 1 loop 0 example

Ilustracja 56. Mapa cieniowania obiektywu test_param_shading_mode, tryb 1, pętla 0.

test_param_shading_mode mapa cieniowania obiektywu, tryb 2, pętla 0

Ilustracja 57. Mapa cieniowania obiektywu test_param_shading_mode, przykład pętli 0 w trybie 2.

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 i B oraz sprawdza, czy obrazy wyjściowe zostały zmodyfikowane zgodnie z oczekiwaniami. Ten test składa się z 2 części: test1 i test2.

Testowane interfejsy API:

Pass:

test1: oba obrazy mają liniowe mapowanie tonalne, ale n=1 ma bardziej stromy gradient. Kanał G (zielony) jest jaśniejszy w przypadku obrazu n=1.
test2: Ta sama mapa 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. Rejestruje zestaw obrazów RAW i YUV o różnej czułości, publikuje kombinację wzmocnienia czułości RAW i sprawdza, czy średnia pikseli wyjściowych jest zgodna z ustawieniami żądania.

Testowane interfejsy API:

Pass: w przypadku obrazów RAW wraz ze wzrostem wzmocnienia obraz staje się ciemniejszy, a jasność obrazów YUV pozostaje stała.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

Ilustracja 60. test_post_raw_sensitivity_boost raw s=3583 boost=0100 example.

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

Ilustracja 61. test_post_raw_sensitivity_boost raw s=1792 boost=0200 example.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

Ilustracja 62. test_post_raw_sensitivity_boost raw s=0896 boost=0400 example.

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

Ilustracja 63. test_post_raw_sensitivity_boost raw s=0448 boost=0800 example.

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

Ilustracja 64. test_post_raw_sensitivity_boost raw s=0224 boost=1600 example.

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

Ilustracja 65. Przykład test_post_raw_sensitivity_boost raw s=0112 boost=3199.

test_post_raw_sensitivity_boost raw plot means example

Ilustracja 66. test_post_raw_sensitivity_boost raw plot means example.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

Ilustracja 67. test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example.

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

Ilustracja 68. test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example.

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

Ilustracja 69. test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example.

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

Rysunek 70. test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example.

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

Ilustracja 71. test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example.

test_post_raw_sensitivity_boost_yuv_plot_means

Rysunek 72. test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

Rejestruje zestaw obrazów w formacie RAW z coraz dłuższym czasem ekspozycji i mierzy wartości pikseli.

Testowane interfejsy API:

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

Przykład test_raw_exposure ISO=55

Ilustracja 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

Ilustracja 74. Przykład test_raw_exposure ISO=132.

Przykład test_raw_exposure ISO=209

Rysunek 75. Przykład test_raw_exposure ISO=209.

Przykład test_raw_exposure ISO=286

Ilustracja 76. Przykład test_raw_exposure ISOs=286.

test_raw_exposure ISO=363 example

Ilustracja 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

Testy, w przypadku których android.noiseReduction.mode jest stosowany do żądań ponownego przetwarzania. Rejestruje przetworzone obrazy przy słabym oświetleniu. Używa wysokiego wzmocnienia analogowego, aby sprawdzić, czy przechwycony obraz jest zaszumiony. Rejestruje 3 przetworzone obrazy: z wyłączoną redukcją szumów, z szybką redukcją szumów i z redukcją szumów w wysokiej jakości. Rejestruje przetworzony obraz z niskim wzmocnieniem i wyłączoną redukcją szumów, a jego wariancję wykorzystuje jako wartość bazową.

Testowane interfejsy API:

android.hardware.camera2.CaptureResult#NOISE_REDUCTION_MODE

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

Typowy wykres SNR w porównaniu z trybem NR

Rysunek 79. Typowy wykres SNR w porównaniu z trybem NR.

test_tonemap_sequence

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

Testowane interfejsy API:

Pass: 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.

test_tonemap_sequence i=1 example

Rysunek 81. Przykład test_tonemap_sequence i=1.

test_tonemap_sequence i=2 example

Ilustracja 82. Przykład test_tonemap_sequence i=2.

test_tonemap_sequence i=3 example

Ilustracja 83. Przykład test_tonemap_sequence i=3.

test_tonemap_sequence_i=4 example

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

Testy, które sprawdzają, czy wszystkie zgłoszone rozmiary i formaty przechwytywania obrazu działają. Wykorzystuje ręczne żądanie z liniowym mapowaniem tonalnym, dzięki czemu formaty YUV i JPEG wyglądają 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.

Testowane interfejsy API:

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

test_yuv_jpeg_all example

Rysunek 86. Przykład test_yuv_jpeg_all.

test_yuv_plus_dng

Sprawdza, czy zgłoszone rozmiary i formaty przechwytywania obrazu działają.

Testowane interfejsy API:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

Zaliczone: test został ukończony i zwrócił żądane obrazy.

Przykład test_yuv_plus_dng

Rysunek 87. Przykład test_yuv_plus_dng.

scene1_3

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

test_capture_result

Testuje, czy w obiektach CaptureResult zwracane są prawidłowe dane. Test składa się z zdjęć automatycznych, ręcznego robienia zdjęć i drugich zdjęć automatycznych.

Testowane interfejsy API:

Pass (Zaliczone): metadane są prawidłowe dla wszystkich zdjęć, a ustawienia ręczne nie przenikają do drugiego zdjęcia automatycznego. Wykreśla korekcję cieniowania obiektywu dla przechwyconych obrazów.

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 surowych zdjęciach wykonanych w zakresie czułości i porównuje te wartości z wariancją oczekiwaną przy każdej czułości przez model szumu DNG w HAL aparatu (na podstawie parametrów O i S zwracanych w obiektach wyników przechwytywania). Więcej informacji o modelu szumu DNG znajdziesz w tym dokumencie: DNG Noise Model.

Testowane interfejsy API:

Pass (Zaliczone): parametry modelu DNG są prawidłowe. Oczekiwane wartości RGB są zgodne z rzeczywistymi wartościami RGB.

test_dng_noise_model_plog

Rysunek 89. test_dng_noise_model_plog.

test_jpeg

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

Testowane 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

Ilustracja 90. test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

Ilustracja 91. test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

Rejestruje zestaw obrazów w formacie RAW z coraz większym wzmocnieniem i mierzy szum. Rejestruje tylko pliki RAW w trybie zdjęć seryjnych.

Testowane interfejsy API:

Pass: każdy kolejny strzał jest bardziej zaszumiony od poprzedniego, ponieważ wzmocnienie jest coraz większe.

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

test_raw_burst_sensitivity_variance

Rysunek 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Rejestruje zestaw obrazów RAW o coraz większej czułości i mierzy szum (wariancję) w 10% środkowej części obrazu. Sprawdza, czy każde ujęcie jest bardziej zaszumione niż poprzednie.

Testowane interfejsy API:

Podanie: odchylenie rośnie z każdym strzałem.

test_raw_sensitivity_variance

Ilustracja 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Testuje przechwytywanie pojedynczej klatki w formatach YUV i JPEG. Wykorzystuje ręczne żądanie z liniowym mapowaniem tonalnym, dzięki czemu formaty YUV i JPEG wyglądają tak samo po przekonwertowaniu przez moduł image_processing_utils.

Testowane interfejsy API:

Pass:obrazy YUV i JPEG są podobne, a różnica RMS (wartość sygnału) jest mniejsza niż 1%.

test_yuv_plus_jpeg w formacie JPEG

Ilustracja 94. test_yuv_plus_jpeg w formacie JPEG.

test_yuv_plus_jpeg w formacie YUV

Rysunek 95. test_yuv_plus_jpeg w formacie YUV.

test_yuv_plus_raw

Testuje przechwytywanie pojedynczej klatki w formacie RAW (10-bitowy i 12-bitowy RAW) oraz YUV, jeśli jest to obsługiwane. Używa ręcznego żądania z liniowym mapowaniem tonalnym, więc oczekuje się, że dane RAW i YUV będą takie same. Porównuje wartości RGB w środku przekonwertowanych obrazów RGB (10% wartości RGB). Dziennikiandroid.shading.mode.

Testowane interfejsy API:

Pozytywny: obrazy YUV i RAW są podobne, a różnica RMS (wartość średnia kwadratowa sygnału) jest mniejsza niż 3,5%.

test_yuv_plus_raw_shading=1_raw.jpg

Rysunek 96. test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

Rysunek 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

Testy CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY różnych ustawień ISO, aby potwierdzić korelację między wyższym ISO a większym poziomem szumu.

Testowane interfejsy API:

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

Kryteria pomijania testu

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

Urządzenie musi mieć pierwszy poziom API (first_api_level) 35 lub niższy.
Urządzenie nie emituje sygnału CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY w CONTROL_AE_AVAILABLE_PRIORITY_MODES.

test_exposure_time_priority

Testy CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY w różnych czasach naświetlania, sprawdzanie stabilnej jasności w zakresie, w którym ISO może kompensować.

Testowane interfejsy API:

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

Kryteria pomijania testu

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

Urządzenie musi mieć pierwszy poziom API (first_api_level) 35 lub niższy.
Urządzenie nie emituje sygnału CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY w CONTROL_AE_AVAILABLE_PRIORITY_MODES.

scena2_a

scene2_a – 3 twarze na szarym tle, osoby ubrane w neutralne ubrania. Twarze zostały wybrane tak, aby reprezentowały szeroką gamę odcieni skóry. Aby wykrywanie twarzy działało optymalnie, wykres musi być prawidłowo zorientowany.

scene2_a example

Rysunek 98. Przykład scene2_a.

test_autoframing

Testuje automatyczne kadrowanie 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 można wykryć, gdy stan się ustabilizuje (czyli gdy AUTOFRAMING_STATE w CaptureResult zostanie ustawione na AUTOFRAMING_STATE_CONVERGED).

Testowane interfejsy API:

Sukces: wykryto wszystkie 3 twarze.

test_display_p3

Testy Wyświetl P3 przechwytywanie w formacie JPEG za pomocą interfejsu ColorSpaceProfiles API. Sprawdza, czy przechwycony plik JPEG ma w nagłówku odpowiedni profil ICC i czy obraz zawiera kolory spoza gamutu sRGB.

Testowane interfejsy API:

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

test_effects

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

Testowane interfejsy API:

Przejście: rejestruje obraz sceny z efektami OFF i monochromatyczny obraz z efektami ustawionymi na MONO.

test_effects_MONO

Rysunek 99. test_effects_MONO.

test_exposure_keys_consistent

Ten test porównuje średnią luminancję zdjęcia z włączoną automatyczną ekspozycją ze zdjęciem z wyłączoną automatyczną ekspozycją, w którym ręcznie zastosowano parametry ekspozycji (czułość, czas ekspozycji, czas trwania klatki, zwiększenie czułości po przetworzeniu danych RAW) otrzymane w CaptureResult zdjęcia z włączoną automatyczną ekspozycją.

Testowane interfejsy API:

Pass: względna różnica luminancji między dwoma zdjęciami jest mniejsza niż 4%.

test_format_combos

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

Testowane interfejsy API:

Powodzenie: wszystkie kombinacje zostały zarejestrowane.

test_num_faces

Testuje wykrywanie twarzy.

Testowane interfejsy API:

Pass:wykrywa 3 twarze.

test_num_faces face detection mode 1 example

Ilustracja 100. Przykład trybu wykrywania twarzy test_num_faces 1.

test_reprocess_uv_swap

Testy, które sprawdzają, czy ponowne przetwarzanie YUV nie zamienia płaszczyzn U i V. Wykrywa się to przez obliczenie sumy bezwzględnych różnic (SAD) między przetworzonym obrazem a nieprzetworzonym zdjęciem. Jeśli zamiana płaszczyzn U i V w przetworzonym nagraniu spowoduje wzrost SAD, przyjmuje się, że dane wyjściowe mają prawidłowe płaszczyzny U i V.

Testowane interfejsy API:

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

test_reprocess_uv_swap

Ilustracja 101. Przykład test_reprocess_uv_swap.

scena2_b

scene2_b – 3 twarze na szarym tle, osoby ubrane w neutralne ubrania. Twarze zostały wybrane tak, aby reprezentowały szeroką gamę odcieni skóry. Aby wykrywanie twarzy działało optymalnie, wykres musi być prawidłowo zorientowany.

test_preview_num_faces

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

Testowane interfejsy API:

Pass:wykrywa 3 twarze z punktami charakterystycznymi w ramkach ograniczających.

test_num_faces_fd_mode_1

Ilustracja 102. Przykład trybu wykrywania twarzy test_num_faces 1.

test_yuv_jpeg_capture_sameness

Wykonuje 2 zdjęcia w największych wspólnych formatach YUV i JPEG o takich samych proporcjach jak największy format JPEG, ale nie przekraczających 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ą średnią kwadratową różnicę (RMS) między nimi.

Ten test sprawdza też, czy dane wyjściowe YUV dla wszystkich obsługiwanych przypadków użycia strumienia są w rozsądnym stopniu podobne do danych YUV w przypadku użycia STILL_CAPTURE.

Testowane interfejsy API:

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

scene2_c

test_num_faces

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

Testowane interfejsy API:

Pass:wykrywa 3 twarze.

test_num_faces_fd_mode_1

Ilustracja 103. Przykład trybu wykrywania twarzy test_num_faces.

test_jpeg_capture_perf_class

Testuje opóźnienie rejestrowania obrazów JPEG w przypadku klasy wydajności S zgodnie z sekcją 2.2.7.2 Aparat w CDD.

Zaliczone: opóźnienie przechwytywania JPEG w przypadku camera2 MUSI być mniejsze niż 1000 ms w rozdzielczości 1080p, zgodnie z pomiarami wykonanymi w ramach testu wydajności aparatu CTS w warunkach oświetleniowych ITS (3000 K) w przypadku obu aparatów głównych.

test_camera_launch_perf_class

Testuje opóźnienie uruchomienia aparatu w przypadku klasy wydajności S zgodnie z sekcją 2.2.7.2 Aparat w CDD.

Wymagania: opóźnienie uruchomienia interfejsu Camera2 (od otwarcia aparatu do pierwszej klatki podglądu) MUSI wynosić < 600 ms, zgodnie z pomiarami wykonanymi w ramach testu wydajności aparatu CTS w warunkach oświetleniowych ITS (3000 K) w przypadku obu aparatów głównych.

test_default_camera_hdr

Sprawdza, czy domyślne przechwytywanie obrazu z aparatu jest w formacie Ultra HDR, zgodnie z wymaganiami klasy 15 określonymi w sekcji 2.2.7.2 Aparat dokumentu CDD.

Wymagania spełnione: domyślne przechwytywanie pakietu kamery MUSI być w formacie ultra HDR w przypadku urządzenia klasy wydajności 15.

scene2_d

test_preview_num_faces

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

Testowane interfejsy API:

Pass:wykrywa 3 twarze z punktami charakterystycznymi w ramkach ograniczających.

scene2_e

test_continuous_picture

50 klatek w rozdzielczości VGA jest rejestrowanych przy użyciu ustawienia „capture request first” (najpierw żądanie rejestrowania). android.control.afMode = 4 (CONTINUOUS_PICTURE).

Testowane interfejsy API:

Zaliczone: system 3A ustabilizuje się do końca 50-klatkowej sekwencji.

test_num_faces

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

Testowane interfejsy API:

Zaliczone: wykryto 3 twarze.

scene2_f

scene2_f ma 3 twarze na białym tle i w białych ubraniach. Twarze mają szeroką gamę odcieni skóry i wysoki kontrast z tłem.

Przykład scene2_f

Rysunek 104. Przykład scene2_f.

test_preview_num_faces

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

Testowane interfejsy API:

Pass:wykrywa 3 twarze z punktami charakterystycznymi w ramkach ograniczających.

test_num_faces_fd_mode_1

Rysunek 105. Przykład test_num_faces_fd_mode_1.

scene2_g

scene2_g ma 3 profile na białym tle i w białych ubraniach. Twarze mają szeroką gamę odcieni skóry i wysoki kontrast z tłem.

Ilustracja 106. Przykład scene2_g.

test_preview_num_faces

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

Testowane interfejsy API:

Pass:wykrywa 3 twarze z punktami charakterystycznymi w ramkach ograniczających.

test_preview_num_faces

Ilustracja 107. Przykład test_preview_num_faces.

scena3

scene3 korzysta z tabeli ISO12233, a większość testów wykorzystuje metodę wyodrębniania tabeli, aby znaleźć ją w scenie. Dlatego większość zapisanych obrazów nie ma obramowań, jak obrazy scen 1, 2 i 4, tylko wykres. Aby wyszukiwarka wykresów działała optymalnie, wykres musi być prawidłowo zorientowany. W Androidzie 17 i nowszych wersjach funkcja scene3 używa znaczników ArUco do wykrywania wykresów.

scene3_aruco_chart

Ilustracja 108. Wykres sceny 3.

test_edge_enhancement

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

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

Testowane interfejsy API:

android.hardware.camera2.CaptureRequest#EDGE_MODE

Parametry aparatu, których dotyczy problem:

EDGE_MODE

test_edge_enhancement_edge=0

Ilustracja 109. Przykład test_edge_enhancement edge=0.

test_edge_enhancement edge=1 example

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

test_edge_enhancement edge=2 example

Ilustracja 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 dokumentacji CDD. W Androidzie 17 i nowszych wersjach do weryfikacji obecności i orientacji wykresu używane są znaczniki ArUco. Obrazy odbite lustrzanie, odwrócone lub obrócone można rozpoznać po rombie w pobliżu środka.

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

Przykład poprawki sceny test_flip_mirror

Ilustracja 112. Przykład poprawki sceny test_flip_mirror.

test_imu_drift

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

Testowane 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.
Odchylenie wektora rotacji jest mniejsze niż 0,01 rad w czasie testu.
(Nie jest jeszcze wymagane) Odchylenie żyroskopu jest mniejsze niż 1 stopień na sekundę.

test_imu_drift – przykład dryfu żyroskopu

Ilustracja 113. Przykład dryfu żyroskopu test_imu_drift.

test_imu_drift – przykład dryfu wektora rotacji

Rysunek 114. Przykład dryfu wektora rotacji test_imu_drift.

test_landscape_to_portrait

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

Testowane interfejsy API:

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

Przykład test_landscape_to_portrait

Rysunek 115. Przykład test_landscape_to_portrait.

test_lens_movement_reporting

Sprawdza, czy flaga ruchu obiektywu jest prawidłowo zgłaszana. Rejestruje serię 24 zdjęć, z których pierwsze 12 ma optymalną odległość ostrzenia (ustaloną przez 3A), a ostatnie 12 – minimalną odległość ostrzenia. Około klatki 12 obiektyw się przesuwa, co powoduje spadek ostrości. Ostrość stabilizuje się, gdy obiektyw osiągnie pozycję końcową.

Flaga ruchu obiektywu powinna być ustawiona we wszystkich klatkach, w których ostrość jest pośrednia między ostrością w pierwszych kilku klatkach, w których obiektyw jest nieruchomy w optymalnej odległości ogniskowej, a ostrością w ostatnich kilku klatkach, w których obiektyw jest nieruchomy w minimalnej odległości ogniskowej. Dokładna liczba klatek, o którą przesuwa się obiektyw, nie ma znaczenia. Ważne jest, aby flaga ruchu była ustawiona, gdy obiektyw się porusza.

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

Testowane interfejsy API:

Zaliczone: flaga ruchu obiektywu to True w klatce ze zmianą ostrości.

Mechanizmy, które nie działają:

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

test_reprocess_edge_enhancement

Sprawdza, czy obsługiwane metody ponownego przetwarzania w celu wyostrzenia krawędzi działają prawidłowo. Przetwarza żądanie przechwytywania w danym trybie ponownego przetwarzania i porównuje różne tryby z przechwytywaniem z wyłączonymi trybami ponownego przetwarzania.

Testowane interfejsy API:

Zaliczone: ostrość w przypadku różnych trybów krawędzi jest prawidłowa. HQ (tryb 2) jest ostrzejszy niż OFF (tryb 0), a różnice między poszczególnymi trybami są podobne.

Przykład wykresu test_reprocess_edge_enhancement

Ilustracja 116. Przykład wykresu test_reprocess_edge_enhancement.

scena4

scene4 składa się z czarnego okręgu na białym tle w kwadracie.

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

przykład sceny 4

Rysunek 117. Przykład scene4.

test_30_60fps_preview_fov_match

Sprawdza, czy filmy podglądowe o częstotliwości 30 kl./s i 60 kl./s mają to samo pole widzenia. Test obejmuje nagranie dwóch filmów: jednego z 30 kl./s i drugiego 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. Testy, które sprawdzają, czy proporcje okręgu pozostają stałe, środek okręgu pozostaje stabilny, a promień okręgu pozostaje stały.

Testowane interfejsy API:

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

Mechanizmy, które nie działają:

Kółko z filmu nagranego w 30 kl./s znacznie różni się rozmiarem od kółka z filmu nagranego w 60 kl./s.
Okrąg na zarejestrowanym obrazie jest zniekształcony przez potok przetwarzania.
Okrąg na zarejestrowanym obrazie jest przycięty z powodu ekstremalnego formatu obrazu, który zmniejsza jego wysokość lub szerokość.
Okrąg na zrobionym zdjęciu ma w środku odbicie i nie jest w pełni wypełniony.

test_aspect_ratio_and_crop

Sprawdza, czy obrazy 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 i rozdzielczościach.

Testowane interfejsy API:

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

Mechanizmy, które nie działają:

Kamera nie jest ustawiona w linii z okręgiem wyświetlanym na tablecie pośrodku rejestrowanej sceny.
Okrąg na zarejestrowanym obrazie jest zniekształcony przez potok przetwarzania.
Obraz o niższej rozdzielczości jest dwukrotnie przycinany w potoku obrazu, co powoduje różnicę w polu widzenia między obrazami o wysokiej i niskiej rozdzielczości.
Okrąg na zarejestrowanym obrazie jest przycięty z powodu ekstremalnego formatu obrazu, który zmniejsza jego wysokość lub szerokość.
Okrąg na zrobionym zdjęciu ma w środku odbicie i nie jest w pełni wypełniony.

test_multi_camera_alignment

Testuje parametry kalibracji kamery związane z pozycjonowaniem kamery w systemach wielokamerowych. Korzystając z fizycznych podkamer, robi zdjęcie jedną z nich. Znajduje środek okręgu. Wyświetla środek okręgu w współrzędnych świata dla każdej kamery. Porównuje różnicę między środkami okręgów kamer we współrzędnych świata. Przekształca współrzędne świata z powrotem na współrzędne pikseli i porównuje je z oryginalnymi współrzędnymi w celu sprawdzenia poprawności. Porównuje rozmiary okręgów, sprawdzając, czy ogniskowe aparatów są różne.

Testowane interfejsy API:

Zaliczone: środki i rozmiary okręgów w obrazach wyświetlanych są zgodne z obrazami zarejestrowanymi przy użyciu danych kalibracji aparatu i ogniskowych.

Mechanizmy, które nie działają:

LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION i LENS_POSE_ROTATION to wartości projektowe, a nie rzeczywiste dane kalibracyjne.
System aparatów nie jest odpowiedni do konfiguracji testowej, np. testowanie systemu aparatów szerokokątnych i ultraszerokokątnych za pomocą urządzenia testowego RFoV. Więcej informacji znajdziesz w odpowiedzi na pytanie 1 w sekcji najczęstszych pytań dotyczących ITS-in-a-box dla aparatu.

test_preview_aspect_ratio_and_crop

Podobnie jak test test_aspect_ratio_and_crop w przypadku zdjęć sprawdza obsługiwane formaty podglądu, aby upewnić się, że klatki podglądu nie są nieprawidłowo rozciągnięte ani przycięte. Sprawdza, czy proporcje okręgu nie ulegają zmianie, przycięte obrazy zachowują okrąg na środku kadru, a rozmiar okręgu nie zmienia się w przypadku stałego formatu lub przy różnych rozdzielczościach (sprawdzanie pola widzenia).

Testowane interfejsy API:

Pass: obrazy nie są rozciągane, środki obrazów 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 obejmuje nagranie 2 filmów: jednego ze stabilizacją podgląduON i drugiego ze stabilizacją podgląduOFF. 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.

Testowane interfejsy API:

Zaliczone: format koła pozostaje w przybliżeniu stały, środek koła jest stabilny, a rozmiar koła zmienia się nie więcej niż o 20%.

test_video_aspect_ratio_and_crop

Nagrywa filmy przedstawiające okrąg w kwadracie we wszystkich formatach wideo. Wyodrębnia klatki kluczowe i sprawdza, czy proporcje okręgu nie ulegają zmianie, przycięte obrazy zachowują okrąg na środku, a rozmiar okręgu nie zmienia się w przypadku stałego formatu lub przy różnej rozdzielczości (sprawdzanie pola widzenia).

Testowane interfejsy API:

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

scena5

scene5 wymaga jednolicie oświetlonej szarej sceny. Jest to możliwe dzięki dyfuzorowi umieszczonemu na obiektywie aparatu. Zalecamy stosowanie tego dyfuzora:www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

Aby przygotować scenę, zamocuj dyfuzor przed aparatem i skieruj go na źródło światła o natężeniu około 2000 luksów. Zdjęcia wykonane na potrzeby scene5 muszą być wykonane w rozproszonym świetle, bez widocznych elementów. Oto przykładowy obraz:

scene5 example

Ilustracja 118. Przykład przechwytywania sceny 5.

Ponieważ w tej scenie nie są wymagane tablety ani kontrolery, testy wykorzystują platformę testową TEST_BED_MANUAL. Przykład znajdziesz w artykule Plik config.yml testów ręcznych. 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 ustawianiem 3A. Cieniowanie obiektywu jest oceniane na podstawie kanału Y. Mierzy średnią wartość y dla każdego określonego bloku próbki i określa wynik pozytywny lub negatywny, porównując ją ze środkową wartością y. Test jednolitości kolorów jest przeprowadzany w przestrzeni czerwono-zielonej i niebiesko-zielonej.

Testowane interfejsy API:

Zaliczone: przy określonym promieniu obrazu wariancja wartości czerwono-zielonej i niebiesko-zielonej musi być mniejsza niż 20%, aby test został zaliczony.

Mechanizmy, które nie działają:

Nadmierne winietowanie na obrazach
Artefakty w postaci czarnej ramki na obrazach

test_lens_shading_and_color_uniformity_y_plane

Rysunek 119. test_lens_shading_and_color_uniformity_y_plane.

test_lens_shading_and_color_uniformity_color_uniformity_result

Rysunek 120. test_lens_shading_and_color_uniformity_color_uniformity.

test_lens_shading_and_color_uniformity_lens_shading_result

Rysunek 121. test_lens_shading_and_color_uniformity_lens_shading_result.

scena6

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

scena6

Rysunek 122. Przykład scene6.

test_in_sensor_zoom

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

Gdy 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 wykadrowany obraz RAW. Test przekształca obrazy w tablice RGB, zmniejsza rozmiar pełnowymiarowego przyciętego obrazu RAW do rozmiaru podanego przez SCALER_RAW_CROP_REGION i oblicza trójwymiarową różnicę RMS między dwoma obrazami.

Testowane interfejsy API:

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

test_zoom

Testuje zachowanie 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ększaniem obrazu przez aparat. Test sprawdza też, czy pozycja znacznika środkowego zmienia się w przewidywalny sposób podczas każdego przechwytywania. Odległość od środka znacznika środkowego do środka obrazu może zmieniać się w stałym tempie w stosunku do współczynnika powiększenia aż do przełączenia kamery fizycznej lub może zmieniać się monotonicznie w kierunku położenia tego samego znacznika po przełączeniu kamery fizycznej. Przed rozpoczęciem testowania na urządzeniu musi być zainstalowana aplikacja Jetpack Camera App (JCA).

Testowane interfejsy API:

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

test_zoom, aby znaleźć kontur markera ArUco najbliższy środka.

Rysunek 123. test_zoom, aby znaleźć kontur znacznika ArUco najbliższy środka.

test_low_latency_zoom

Testuje działanie powiększenia z niskim opóźnieniem. Wykonuje zdjęcia w zakresie powiększenia z wartością 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 wykonywania zdjęć.

Testowane interfejsy API:

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

test_preview_video_zoom_match

Testy, które podczas nagrywania i powiększania sprawdzają, czy podgląd wideo i wyjście wideo wyświetlają i nagrywają to samo wyjście. Oblicza rozmiar markera najbliższego środka przy różnych współczynnikach powiększenia i sprawdza, czy rozmiar markera zwiększa się wraz ze wzrostem współczynnika powiększenia.

Testowane interfejsy API:

Zaliczone: względny rozmiar zarejestrowanego markera jest zgodny z żądanym współczynnikiem powiększenia w filmie i podglądzie.

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

Ilustracja 125. preview_1280x720_key_frame.png (przed powiększeniem).

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

Ilustracja 127. preview_1280x720_key_frame.png (po powiększeniu).

test_preview_zoom

Sprawdza, czy współczynnik powiększenia każdej ramki podglądu jest zgodny z odpowiednimi metadanymi przechwytywania z obiektywu ultraszerokokątnego do obiektywu szerokokątnego. Test obejmuje klatki podglądu w zakresie powiększenia i wyszukuje znacznik ArUco najbliższy środka. Następnie test sprawdza, czy pozycja znacznika środkowego zmienia się w przewidywalny sposób podczas każdego przechwytywania. Odległość od środka znacznika środkowego do środka obrazu może zmieniać się w stałym tempie w stosunku do współczynnika powiększenia aż do przełączenia kamery fizycznej lub może zmieniać się monotonicznie w kierunku położenia tego samego znacznika po przełączeniu kamery fizycznej.

Testowane interfejsy API:

Pass (Zaliczone): względny rozmiar wybranego markera ArUco jest prawidłowy w przypadku zgłoszonego współczynnika powiększenia odpowiedniego wyniku przechwytywania dla wszystkich klatek podglądu. Względna odległość wybranego markera od środka obrazu jest dokładna w przypadku zgłoszonego współczynnika powiększenia odpowiedniego wyniku przechwytywania wszystkich klatek podglądu.

Obrazy test_preview_zoom przedstawiające wybrany znacznik najbliższy środka

Ilustracja 128. 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 sekcji CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. W przypadku każdej z tych konfiguracji, jeśli CameraDeviceSetup#isSessionConfigurationSupported zwraca true, test sprawdza, czy można osiągnąć zakres współczynnika powiększenia zwrócony w CameraDeviceSetup#getSessionCharacteristics.

Testowane interfejsy API:

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

scene7

scene7 to prostokątna ramka podzielona na 4 równe kwadranty, z których każdy jest wypełniony innym kolorem. Na środku prostokąta znajduje się wykres z ukośną krawędzią do sprawdzania ostrości. Cztery 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 129. scene7.

test_multi_camera_switch

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

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

Klatki zarejestrowane w punkcie przejścia i przed nim są analizowane pod kątem automatycznej ekspozycji (AE), automatycznego balansu bieli (AWB) i automatycznego ustawiania ostrości (AF).

Sprawdzanie AE weryfikuje, czy zmiana luminancji mieści się w oczekiwanym zakresie w przypadku zdjęć zrobionych obiektywami UW i W. Sprawdzanie balansu bieli weryfikuje, czy stosunki czerwieni do zieleni i niebieskiego do zieleni mieszczą się w wartościach progowych w przypadku zdjęć z obiektywów ultraszerokokątnego i szerokokątnego. Sprawdzanie AF ocenia wartość szacowania ostrości na podstawie średniej wielkości gradientu między obrazami z obiektywu UW i W.

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

Testowane interfejsy API:

Zakończony powodzeniem: aby test zakończył się powodzeniem, testy AE i AWB muszą zakończyć się powodzeniem. Wyniki sprawdzania AF są używane tylko do celów logowania. Kryteria każdego sprawdzenia są następujące:

Sprawdzanie AE: zmiana luminancji (wartość Y) między obrazami z obiektywu ultraszerokokątnego i szerokokątnego 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ługiwana jest tylko wartość ae_regions, kryteria muszą spełniać tylko wartości dotyczące szarego pola koloru.
Sprawdzanie automatycznego balansu bieli: różnica między wartościami czerwono-zielonymi i niebiesko-zielonymi w przypadku zdjęć zrobionych obiektywami UW i W musi być mniejsza niż 3% w przypadku szarego pola koloru i mniejsza niż 10% w przypadku innych pól koloru, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions.
Sprawdzanie AF: ostrość obrazu z obiektywu szerokokątnego musi być większa niż ostrość obrazu z obiektywu ultraszerokokątnego.

test_multi_camera_switch_gray_uw_y

Rysunek 130. Szara plama sfotografowana obiektywem ultraszerokokątnym.

test_multi_camera_switch_gray_w_y

Rysunek 131. Szara plama sfotografowana obiektywem szerokokątnym.

scena8

scene8 to prostokątna ramka podzielona na 4 równe części, z których każda zawiera portret wykonany z inną ekspozycją lub z nałożonym innym odcieniem koloru (odcień niebieski, zwiększona ekspozycja, zmniejszona ekspozycja, odcień żółty). Cztery markery 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 132. Przykład scene8.

test_ae_awb_regions

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

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

Sprawdzanie AE: weryfikuje, czy klatka, w której pomiar światła w regionie o zmniejszonej ekspozycji ma wartość luminancji większą o ponad 1% niż klatka, w której pomiar światła w regionie o zwiększonej ekspozycji. Potwierdza to, że obrazy są rozjaśniane podczas pomiaru ciemnego obszaru.
Sprawdzanie automatycznego balansu bieli: weryfikuje, czy stosunek czerwieni do niebieskiego (średnich wartości RGB obrazu) w klatce z niebieskim obszarem pomiarowym jest o ponad 2% wyższy niż w klatce z żółtym obszarem pomiarowym. Sprawdza to, czy obrazy mają zrównoważoną wartość RGB podczas pomiaru obszaru żółtego (ciepłego) lub niebieskiego (chłodnego).

Testowane interfejsy API:

Pass:oba sprawdzenia (AE i AWB) zakończyły się powodzeniem.

test_ae_awb_regions_dark_region

Rysunek 133. Pomiar światła w ciemnym obszarze kadru ze zwiększoną ekspozycją.

test_ae_awb_regions_light_region

Rysunek 134. Pomiar światła w jaśniejszym obszarze klatki ze zmniejszoną ekspozycją.

Mechanizmy, które nie działają:

W tym teście kluczowe jest dokładne wykrywanie wszystkich 4 markerów ArUco. Jeśli pierwsze wykrywanie się nie powiedzie, system spróbuje wykryć tekst po raz drugi za pomocą czarno-białej wersji obrazu. Poniższy obraz w odcieniach szarości przedstawia drugi etap przetwarzania:

Rysunek 135. Niewłaściwe ułożenie znaczników ArUco.

test_color_correction_mode_cct

Testy COLOR_CORRECTION_MODE w różnych temperaturach barwowych i odcieniach, weryfikacja zmian w proporcjach RGB w porównaniu ze sceną rejestracji, scene8.

Testowane interfejsy API:

Zaliczone: stosunki RGB wykazują oczekiwane wzrosty lub spadki w stosunku do wybranych temperatur barwowych i odcieni.

Kryteria pomijania testu

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

Urządzenie musi mieć pierwszy poziom API (first_api_level) 35 lub niższy.
Urządzenie nie emituje sygnału COLOR_CORRECTION_MODE_CCT w COLOR_CORRECTION_AVAILABLE_ABERRATION_MODES.

scene9

scene9 składa się z tysięcy okręgów o losowych rozmiarach i kolorach, tworzących scenę o bardzo niskiej powtarzalności, co pozwala przetestować algorytmy kompresji JPEG.

przykład sceny 9

Rysunek 136. Przykład scene9.

test_jpeg_high_entropy

Testy, które sprawdzają, czy kompresja JPEG działa na 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.

Testowane interfejsy API:

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

test_jpeg_quality

Testuje jakość kompresji JPEG w aparacie. Krok JPEG qualities through android.jpeg.quality i sprawdza, czy tabele kwantyzacji zmieniają się prawidłowo.

Testowane 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 137. Średnie wartości macierzy DQT luminancji i chrominancji tylnego aparatu Pixela 4 w porównaniu z jakością JPEG.

test_jpeg_quality failed test example

Rysunek 138. Przykład nieudanego testu.

scene_video

scene_video to scena wideo składająca się z 4 różnokolorowych okręgów, które poruszają się w przód i w tył z różną liczbą klatek na sekundę na białym tle.

Rysunek 139. Przykład scene_video.

test_preview_frame_drop

Testuje, czy żądana liczba klatek podglądu jest utrzymywana w dynamicznej scenie. Ten test jest przeprowadzany na wszystkich kamerach, które są udostępniane aplikacjom innych firm.

Testowane interfejsy API:

Zaliczone: liczba klatek podglądu na sekundę jest maksymalna w zakresie żądanej liczby klatek na sekundę, a średnia różnica między kolejnymi klatkami jest mniejsza niż tolerancja względna ustawiona w teście.

scene_extensions

Testy scene_extensions są przeznaczone dla rozszerzeń aparatu i muszą być przeprowadzane za pomocą Camera ITS-in-a-Box, ponieważ wymagają precyzyjnej kontroli środowiska testowego. Dodatkowo należy kontrolować wszystkie wycieki światła. Może to wymagać przykrycia stanowiska testowego, urządzenia i tabletu folią ochronną, a także wyeliminowania wycieku światła z przedniego ekranu 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

Ilustracja 140. Przykład scene_hdr.

test_hdr_extension

Testuje rozszerzenie HDR. Robi zdjęcia z włączonym i wyłączonym rozszerzeniem oraz sprawdza, czy rozszerzenie ułatwia wykrywanie kodu QR.

Testowane 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ą linią. Kwadraty są ułożone w orientacji krzywej Hilberta.

scene_low_light example

Rysunek 141. Przykład scene_low_light.

test_night_extension

Testuje rozszerzenie Night. Robi zrzuty ekranu, gdy rozszerzenie jest włączone, i wykonuje te czynności:

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

W przypadku urządzeń z Androidem 16 lub nowszym żądanie przechwytywania zawiera region pomiarowy odpowiadający prostokątowi ograniczającemu siatkę kwadratów. To dodanie zmienia kryteria zaliczenia progu.

Testowane 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 aż do kwadratów 5 i 6 musi wynosić co najmniej 17.

Poniższy wykres luminancji pokazuje, jak wygląda wynik testu, który został zaliczony.

Przykład testu sceny nocnej przy słabym oświetleniu

Rysunek 142. Przykład testu sceny nocnej przy słabym oświetleniu.

test_low_light_boost_extension

Testuje tryb AE wzmocnienia przy słabym oświetleniu. Jeśli Camera2 obsługuje tryb AE ze wzmocnieniem przy słabym oświetleniu, test jest przeprowadzany w przypadku Camera2. Jeśli rozszerzenie aparatu w trybie nocnym jest obsługiwane i obsługuje tryb AE z wzmocnieniem przy słabym oświetleniu, ten test jest również przeprowadzany w przypadku rozszerzenia aparatu w trybie nocnym. Ten test ustawia tryb AE na wzmocnienie 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ść luminancji pierwszych 6 kwadratów zgodnie z orientacją siatki krzywej Hilberta.
Oblicza różnicę w wartości luminancji kolejnych kwadratów (np. kwadrat 2 – kwadrat 1) aż do kwadratów 5 i 6 (kwadrat 6 – kwadrat 5) i wyznacza średnią z 5 obliczonych różnic.

Testowane interfejsy API:

Pass:

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

scene_tele

Kluczowym wymaganiem w przypadku testów scene_tele jest to, aby odległość od wykresu była co najmniej równa minimalnej odległości ogniskowania teleobiektywu. Minimalna odległość ostrzenia 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 nastawiania ostrości aparatu szerokokątnego i teleobiektywu;

Ilustracja 143. Konfiguracja scene_tele na podstawie odległości ogniskowej aparatu szerokokątnego i teleobiektywu.

Więcej informacji o konfigurowaniu sprzętu testowego znajdziesz w artykule Konfigurowanie platformy do testowania teleobiektywów.

scene6_tele

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

Jeśli zdjęcia zrobione za pomocą scene6_tele są prześwietlone w modułowym statywie, zdejmij przednią płytkę z modułowego statywu.

Odłącz stanowisko testowe WFoV od przedłużacza i zdejmij uchwyt na telefon.

Rysunek 144. Odłącz stanowisko testowe WFoV od przedłużacza i zdejmij uchwyt na telefon.

remove_front_plate

Rysunek 145. Zdejmij przednią płytę.

test_zoom_tele

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

Testowane interfejsy API:

Pass (Zaliczone): względny rozmiar zarejestrowanego markera ArUco jest zgodny z wymaganym współczynnikiem powiększenia, co potwierdza, że aparat prawidłowo powiększa obraz, a odległość markera od środka obrazu zmienia się zgodnie z kryteriami wymienionymi w test_zoom.

test_preview_zoom_tele

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

Testowane interfejsy API:

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

scene7_tele

scene7_tele jest identyczny z scene7, ale skonfigurowany do testowania teleobiektywu. Jest to prostokątna ramka podzielona na 4 równe ćwiartki, z których każda jest wypełniona innym kolorem. Na środku prostokąta znajduje się wykres z ukośną krawędzią do sprawdzania ostrości. Cztery 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 między obiektywem szerokokątnym (W) a teleobiektywem (tele) daje podobne wartości RGB.

Klatki zarejestrowane w punkcie przejścia i przed nim są analizowane pod kątem AE, AWB i AF.

Sprawdzanie AE weryfikuje, czy zmiana luminancji mieści się w oczekiwanym zakresie w przypadku zdjęć wykonanych obiektywem szerokokątnym i teleobiektywem. Sprawdzanie AWB weryfikuje, czy stosunki czerwieni do zieleni i niebieskiego do zieleni mieszczą się w wartościach progowych w przypadku zdjęć zrobionych zarówno obiektywem szerokokątnym, jak i teleobiektywem. Sprawdzanie AF ocenia wartość szacowania ostrości na podstawie średniej wielkości gradientu między obrazami z obiektywu szerokokątnego i teleobiektywu.

Testowane interfejsy API:

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

Sprawdzenie AE: zmiana luminancji między zdjęciami z obiektywu szerokokątnego i teleobiektywu musi być mniejsza niż 4%.
Sprawdzanie automatycznego balansu bieli: w przestrzeni kolorów LAB różnica delta C między czerwienią a zielenią oraz niebieskim a zielenią w przypadku obiektywu szerokokątnego i teleobiektywu nie może przekraczać 10.
Sprawdzanie AF: ostrość obrazu z teleobiektywu musi być większa niż w przypadku obiektywu szerokokątnego.

scene_flash

Testy scene_flash wymagają ciemnej sceny w polu fuzji czujników. W Androidzie 17 i nowszym testowanie scene_flash można przeprowadzać za pomocą platformy Gen2.

test_auto_flash

Testy, które sprawdzają, czy automatyczny błysk jest wyzwalany w ciemnym otoczeniu w przypadku tylnego i przedniego aparatu. W przypadku przednich aparatów automatyczna lampa błyskowa wykorzystuje ekran do oświetlania sceny, a nie fizyczną lampę błyskową. Test sprawdza, czy automatyczny błysk jest wyzwalany, poprzez sprawdzenie, czy środek obrazu kafelka jest jaśniejszy, gdy automatyczny błysk jest włączony. Aby wywołać automatyczny błysk, światła w stanowisku testowym muszą być wyłączone. Można je wyłączyć automatycznie za pomocą kontrolera Arduino. Aby test działał prawidłowo, scena musi być całkowicie ciemna. Przed rozpoczęciem testowania na urządzeniu musi być zainstalowana aplikacja Jetpack Camera App (JCA). Automatyczna lampa błyskowa w przypadku tylnych aparatów jest uruchamiana na podstawie stanu AE, ale w przypadku przednich aparatów nie zależy od AE i jest zawsze uruchamiana.

W Androidzie 17 i nowszych testuje poziomy powiększenia inne niż 1x, aby sprawdzić prawidłowe działanie w całym zakresie obsługiwanych powiększeń.

Testowane interfejsy API:

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

test_flash_strength

Testy, które sprawdzają, czy kontrola siły błysku w trybie SINGLE jest zaimplementowana prawidłowo.

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

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

Testowane interfejsy API:

Pass:

Gdy tryb automatycznej ekspozycji to ON lub OFF, jasność fragmentów obrazu zwiększa się wraz ze wzrostem siły błysku od braku błysku do FLASH_SINGLE_STRENGTH_MAX_LEVEL. Gdy tryb automatycznej ekspozycji to ON_AUTO_FLASH, różnica jasności fragmentów obrazu mieści się w 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 wykonane za pomocą diody LED nie są prześwietlone ani nie mają zafarbu.

Ten test dodaje kontroler oświetlenia do urządzenia Sensor Fusion Box, aby sterować oświetleniem. Gdy światła są ustawione na OFF, test wykonuje zdjęcie w trybie AUTO_FLASH ustawionym na ON. Podczas tego przechwytywania test uruchamia sekwencję przed przechwytywaniem z wyzwalaczem aePrecapture ustawionym na START i ustawia zamiar przechwytywania na Preview, aby wykonać przechwytywanie z błyskiem.

Ponieważ przechwycony obraz ma charakterystyczny obszar interaktywny spowodowany przez lampę błyskową, test oblicza średnią wartość obrazu z lampą błyskową dla całego przechwyconego obrazu i sprawdza, czy wartość mieści się w zakresie (68, 102). Aby sprawdzić, czy obraz ma odpowiedni balans bieli, test oblicza stosunek czerwieni do zieleni i niebieskiego do zieleni oraz sprawdza, czy stosunki te mieszczą się w przedziale od 0,95 do 1,05.

Testowane interfejsy API:

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

test_night_mode_indicator

Testuje funkcjonalność wskaźnika trybu nocnego, który informuje, czy aparat działa w słabym oświetleniu i czy warto użyć rozszerzenia aparatu w trybie nocnym do zrobienia zdjęcia. 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 obiekt ItsSession i pobiera właściwości aparatu. Ustanawia też połączenie z kontrolerem oświetlenia.
Warunki pominięcia: test jest pomijany, jeśli urządzenie nie obsługuje wymaganego poziomu API lub funkcji wskaźnika trybu nocnego.
Sesja Camera2:
- Test rozpoczyna sesję przechwytywania podglądu za pomocą Camera2.
- Światło jest włączone i zostaje zarejestrowana ramka podglądu.
- Test sprawdza, czy wskaźnik trybu nocnego jest w stanie OFF.
- Światło wyłącza się i zostaje zarejestrowana ramka 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 kończy się ItsSession i zwalnia kontroler oświetlenia.

Testowane interfejsy API:

android.extension.nightModeIndicator

Pass:

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

test_preview_min_frame_rate

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

Testowane interfejsy API:

Pass (Zaliczone): liczba klatek podglądu jest na minimalnym poziomie żądanego zakresu liczby klatek, a różnica między klatkami jest mniejsza niż tolerancja bezwzględna ustawiona w teście.

test_torch_strength

Testy, które sprawdzają, czy kontrola siły błysku w trybie TORCH jest zaimplementowana prawidłowo.

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

Testowane interfejsy API:

Pass:

Gdy tryb automatycznej ekspozycji to ON lub OFF, jasność fragmentów serii zdjęć wzrasta wraz ze wzrostem siły błysku od braku błysku do FLASH_TORCH_STRENGTH_MAX_LEVEL. Gdy tryb automatycznej ekspozycji to ON_AUTO_FLASH, różnica w jasności fragmentów serii zdjęć mieści się w zakresie 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 wykresu papierowego Gen2.

Ten wzorzec testowy składa się z próbek twarzy, kodu QR, pól w skali szarości, gwiazdy Siemensa, karty kolorów i pochylonych kwadratów.

test_chart_gen2

Rysunek 146. 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 dwiema krzywymi wykładniczymi (jedną z równomiernie rozmieszczonymi punktami, a drugą z punktami rozmieszczonymi nierównomiernie). Aby wynik był pozytywny, jasność domyślnej krzywej musi być większa niż jasność krzywych 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 się domyślną krzywą, ponownie ją wprowadza, a następnie porównuje jasność uzyskanego obrazu z jasnością obrazu z oryginalną domyślną krzywą.

Testowanie wykresu sekwencji mapowania odcieni

Rysunek 147. Wykres sekwencji mapowania odcieni testowych.

Testowane interfejsy API:

Pass:różnica jasności między domyślną a liniową krzywą jest większa niż 15%, a różnica między dwiema krzywymi wykładniczymi jest mniejsza niż 8%.

test_multi_camera_switch

Ten test weryfikuje spójność kolorów i ekspozycji podczas przejść dynamicznego powiększenia. Sprawdza, czy przełączanie między obiektywami ultraszerokokątnym (UW) i szerokokątnym (W) podczas nagrywania podglądu utrzymuje niemal identyczne wartości CIELAB, co zapobiega widocznym zmianom w wrażeniach użytkownika.

Test wykonuje dynamiczne nagrywanie podglądu w określonym zakresie powiększenia, aby wywołać fizyczny punkt „przejścia” kamery, w którym obiektyw ultraszerokokątny przełącza się na obiektyw szerokokątny. Test określa dokładną klatkę, w której następuje zmiana 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).

Sprawdzanie AE potwierdza, że wahania luminancji podczas przekazywania obiektywu pozostają w dopuszczalnym zakresie. Sprawdzanie AWB weryfikuje, czy stosunki czerwieni do zieleni i niebieskiego do zieleni mieszczą się w określonych progach neutralności kolorów.

Testowane interfejsy API:

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

Sprawdzanie AE: zmiana luminancji (wartość Y) między obrazami z obiektywu ultraszerokokątnego i szerokokątnego 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ługiwana jest tylko wartość ae_regions, kryteria muszą spełniać tylko wartości dotyczące szarego pola koloru.
Sprawdzanie automatycznego balansu bieli: różnica między wartościami czerwono-zielonymi i niebiesko-zielonymi w przypadku zdjęć zrobionych obiektywami UW i W musi być mniejsza niż 3% w przypadku szarego pola koloru i mniejsza niż 10% w przypadku innych pól koloru, jeśli urządzenie obsługuje zarówno ae_regions, jak i awb_regions.

uw_dynamic_range_patch_cell_8

Rysunek 148. Szara plama sfotografowana obiektywem ultraszerokokątnym.

w_dynamic_range_patch_cell_7

Rysunek 149. Szara plama sfotografowana obiektywem szerokokątnym.

scene_wide_gamut

scene_wide_gamut to prostokątna ramka podzielona na 4 równe kwadranty, z których każdy jest wypełniony innym kolorem. Wymaga to wyświetlania wykresu na tablecie w szerokiej gamie kolorów i zrobienia zdjęcia ekranu w szerokiej gamie kolorów na urządzeniu testowym.

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

test_display_p3

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

Testowane interfejsy API:

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

test_display_p3 example

Rysunek 150. Przykład test_display_p3.

sensor_fusion

Testy fuzji czujników wymagają wykonania określonych ruchów telefonem przed wzorem szachownicy i markerami ArUco. Aby uzyskać optymalne wyniki, sprawdź, czy karta testowa jest zamontowana na płaskiej powierzchni. Wykresy, które nie są płaskie, wpływają na obliczenia rotacji w przypadku wielu testów. Wykres musi wypełniać tył pudełka z czujnikami, a jego wymiary po wydrukowaniu powinny wynosić 17 x 17 cali. (43 x 43 cm). Testy sensor_fusion można zautomatyzować za pomocą Sensor Fusion Box.

Wykres fuzji czujników

Rysunek 151. Wykres fuzji czujników.

Wykres fuzji czujników w platformie

Rysunek 152. Wykres fuzji czujników wypełniający pole fuzji czujników.

test_lens_intrinsic_calibration

Testy, które sprawdzają, czy środek optyczny obiektywu zmienia się, gdy obiektyw przesuwa się z powodu optycznej stabilizacji obrazu (OIS). Jeśli obsługiwane są próbki parametrów wewnętrznych obiektywu, testy, które zmieniają optyczne centrum próbek parametrów wewnętrznych obiektywu, gdy obiektyw przesuwa się z powodu optycznej stabilizacji obrazu.

Testowane interfejsy API:

Pass:środek optyczny obiektywu zmienia się o 1 piksel lub więcej. Jeśli próbki parametrów wewnętrznych obiektywu są obsługiwane, środki optyczne próbek parametrów wewnętrznych obiektywu zmieniają się o 1 piksel lub więcej.

Na przykład na tym wykresie test_lens_intrinsic_calibration widać zmiany punktów głównych w pikselach w przypadku każdej klatki:

Rysunek 153. 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

Testy, które określają sygnatury czasowe zarejestrowane przez kamerę logiczną, mają dokładność do 10 ms. W tym celu obliczane są kąty kwadratów na szachownicy.

Testowane interfejsy API:

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

test_preview_distortion

Sprawdź, czy zniekształcenia są korygowane w każdej ramce podglądu przy różnych poziomach powiększenia. W przypadku każdej ramki podglądu test oblicza idealne punkty na podstawie parametrów wewnętrznych i zewnętrznych kamery.

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

Rysunek 154. Ilustracja przedstawiająca szachownicę z idealnymi punktami oznaczonymi na zielono i rzeczywistymi punktami oznaczonymi na czerwono.

Testowane interfejsy API:

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

test_preview_stabilization

Testy, w których stabilizowany film w podglądzie obraca się mniej niż żyroskop.

Testowane interfejsy API:

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

Oto przykładowe filmy ze stabilizacją i bez niej:

Rysunek 155. Przykładowy film ze stabilizacją.

Rysunek 156. Przykładowy film bez stabilizacji.

test_sensor_fusion

Sprawdza różnicę w sygnaturze czasowej między kamerą a żyroskopem w przypadku aplikacji 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 urządzenie nie ma żyroskopu lub jeśli parametr źródła sygnatury czasowejREALTIME nie jest włączony.

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

test_sensor_fusion_gyro_events: Wyświetla zdarzenia żyroskopu telefonu podczas testu. Ruch w kierunku osi X i Y oznacza, że telefon nie jest bezpiecznie zamontowany na uchwycie ściennym, co zmniejsza prawdopodobieństwo pomyślnego przejścia testu. Liczba cykli na wykresie zależy od szybkości zapisu podczas zapisywania klatek.

Rysunek 157. Przykład zdarzeń żyroskopu test_sensor_fusion.
test_sensor_fusion_plot_rotations: pokazuje wyrównanie żyroskopu i zdarzeń kamery. Wykres musi pokazywać zgodny ruch kamery i żyroskopu z dokładnością do +/-1 ms.

Rysunek 158. Przykład wykresu obrotów test_sensor_fusion.

Testowane interfejsy API:

Zaliczone: odchylenie sygnatur czasowych kamery i żyroskopu jest mniejsze niż 1 ms zgodnie z sekcją 7.3.9 Czujniki o wysokiej wierności w CDD.

Mechanizmy, które nie działają:

Błąd przesunięcia: przesunięcie kamery i żyroskopu nie jest prawidłowo skalibrowane w zakresie +/-1 ms.
Spadki liczby klatek: potok nie jest wystarczająco szybki, aby zarejestrować 200 klatek z rzędu.
Błędy gniazda: adb nie może niezawodnie połączyć się z testowanym urządzeniem na wystarczająco długo, aby przeprowadzić test.
Wykres nie jest zamontowany na płaskiej powierzchni. Na wykresie test_sensor_fusion_plot_rotations widać klatki, w których żyroskop i obrót kamery znacznie się różnią, ponieważ kamera obraca się w miejscach wykresu, które nie są płaskie.
Kamera nie jest zamontowana na płaskiej powierzchni. Wykres test_sensor_fusion_gyro_events pokazuje ruch w płaszczyznach X i Y. Ta awaria występuje częściej w przypadku przednich aparatów, ponieważ tylny aparat często ma wypukłość w stosunku do reszty obudowy telefonu, co powoduje nachylenie podczas mocowania tylnej części telefonu do płytki montażowej.

test_video_stabilization

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

Testy, w których stabilizacja wideo obraca się mniej niż żyroskop.

Testowane 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 159. Przykładowy film ze stabilizacją.

Rysunek 160. Przykładowy film bez stabilizacji.

test_video_stabilization_jca

Testy, w których stabilizowano filmy nagrane za pomocą JCA, wykazały, że obracają się one mniej niż żyroskop. Przed rozpoczęciem testowania musisz zainstalować JCA na urządzeniu.

Testowane interfejsy API:

Zaliczone: maksymalny kąt obrotu w klatkach wyodrębnionych z filmu zarejestrowanego za pomocą JCA jest mniejszy niż 70% obrotu żyroskopu.

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 strumieni, trybów stabilizacji obrazu, 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 wersji test obejmuje wszystkie kombinacje obsługiwanych funkcji i zapisuje wyniki w pliku proto. Asercje niepowodzenia są wywoływane tylko w przypadku kombinacji funkcji, dla których funkcja isSessionConfigurationSupported zwraca wartość True.

Testowane interfejsy API:

Zaliczone: w przypadku 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ń kolorów nagranego strumienia podglądu jest zgodna z ustawioną wartością.
Zdjęcie w trybie ultra HDR ma prawidłową mapę wzmocnienia.

scene_ip

W Androidzie 16 i nowszych wersjach scena scene_ip umożliwia sprawdzanie podobieństwa obrazów między domyślną aplikacją aparatu a aplikacją aparatu Jetpack (JCA), aby wykrywać duże różnice między zarejestrowanymi obrazami. JCA odtwarza zdjęcia z aplikacji społecznościowych i dostarcza obraz bazowy, który aplikacje społecznościowe następnie przetwarzają i ulepszają.

Wymagania dotyczące konfiguracji sprzętu

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

Testy są przeprowadzane w zestawie ITS-in-a-box z kamerą Gen2.
Oświetlenie i kontrolery serwomechanizmów, które są częścią platformy Gen2, służą do sterowania środowiskiem testowym.
W urządzeniu Gen2 znajduje się wykres funkcji testowych.

test_chart_gen2

Rysunek 161. Przykład Gen2chart_sample.

Kryteria pomijania testu

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

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

test_default_jca_ip

Wykonuje zdjęcia wykresu funkcji testowych w kontrolowanych warunkach oświetleniowych za pomocą domyślnej aplikacji aparatu i JCA oraz przeprowadza te testy:

Pole widzenia: sprawdza, czy domyślna aplikacja aparatu i JCA mają takie samo pole widzenia. Ten test wykorzystuje funkcję środkowego kodu QR wyodrębnioną z obrazu wykresu.
Jasność: sprawdza, czy różnica jasności zmierzona między domyślną aplikacją aparatu a JCA nie przekracza 10. Ten test wykorzystuje dynamiczną łatkę zakresu 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 dynamiczną łatkę zakresu do pomiaru jasności.
Renderowanie kolorów: sprawdza, czy różnica w renderowaniu kolorów między domyślną aplikacją aparatu a JCA nie przekracza 6.

Pass (Zaliczone): test zalicza sprawdzenie pola widzenia, jasności i balansu bieli. W przypadku Androida 16 ten test nie jest wymagany (NOT_YET_MANDATED). W przypadku Androida 17 i nowszych wymagane są testy porównawcze 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 zarejestrowanymi obrazami nie przekracza 4.

Testowane interfejsy API:

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

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

scene0

test_jitter

test_metadata

test_request_capture_match

test_sensor_events

test_solid_color_test_pattern

test_test_pattern

test_tonemap_curve

test_unified_timestamp

test_vibration_restriction

scene1_1

test_ae_precapture_trigger

test_auto_vs_manual

test_black_white

test_burst_capture

test_burst_sameness_manual

test_crop_region_raw

test_crop_regions

test_ev_compensation

test_exposure_x_iso

test_latching

test_linearity

test_locked_burst

scene1_2

test_param_color_correction

test_param_flash_mode

test_param_noise_reduction

test_param_shading_mode

test_param_tonemap_mode

test_post_raw_sensitivity_boost

test_raw_exposure

test_reprocess_noise_reduction

test_tonemap_sequence

test_yuv_jpeg_all

test_yuv_plus_dng

scene1_3

test_capture_result

test_dng_noise_model

test_jpeg

test_raw_burst_sensitivity

test_raw_sensitivity

test_yuv_plus_jpeg

test_yuv_plus_raw

test_sensitivity_priority

test_exposure_time_priority

scena2_a

test_autoframing

test_display_p3

test_effects

test_exposure_keys_consistent

test_format_combos

test_num_faces

test_reprocess_uv_swap

scena2_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

scena3

test_edge_enhancement

test_flip_mirror

test_imu_drift

test_landscape_to_portrait

test_lens_movement_reporting

test_reprocess_edge_enhancement

scena4

test_30_60fps_preview_fov_match

Testy ITS kamery