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

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

Testy ITS kamery

Na tej stronie znajdziesz pełną listę testów w pakiecie Camera Image Test Suite (ITS), który jest częścią weryfikatora pakietu CTS (Android Compatibility Test Suite). 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.

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 ograniczać 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ń, ż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: wzmacnianie sygnału Wi-Fi, 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), pomiar obszaru
scene9: kompresja JPEG
scene_extensions: rozszerzenia aparatu
scene_tele: przełączanie teleobiektywu;
scene_flash: automatyczny błysk, minimalna liczba klatek na sekundę
scene_video: spadek liczby klatek
sensor_fusion: przesunięcie czasowe kamery i żyroskopu.
feature_combination: kombinacje funkcji
scene_ip: porównywalność obrazów z domyślnej aplikacji aparatu i aplikacji 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:

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

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 wzmocnieniaauto_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 (FoV) i odległość hiperfokalna są obecne i mają prawidłowe wartości.

test_request_capture_match

Test, który sprawdza, czy urządzenie zapisuje prawidłowe wartości ekspozycji i wzmocnienia, odczytując metadane przechwytywania.

Testowane interfejsy API:

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

Testy, które sprawdzają, czy jednolite wzorce testowe są generowane prawidłowo w przypadku wyciszenia 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:

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

test_vibration_restriction

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

Testowane interfejsy API:

Pass: 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 kamery znajdziesz w artykule Camera ITS-in-a-box.

przykład sceny 1

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

test_ae_precapture_trigger

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

Testowane interfejsy API:

Zaliczone: AE zbiega się.

test_auto_vs_manual

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

Testowane interfejsy API:

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

Rysunek 6. test_auto_vs_manual auto example.

Przykład testu automatycznego i ręcznego balansu bieli

Ilustracja 7. Przykład testu porównującego automatyczny i ręczny balans bieli.

test_auto_vs_manual manual white balance transform example

Rysunek 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. Wykonuje 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:

Przepustka: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% różnicy.

test_black_white, black example

Ilustracja 9. test_black_white, przykład czarny.

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.

Niepowodzenie: na początku każdego impulsu na wykresie średniej wartości RGB widać nagły wzrost lub spadek.

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

test_burst_sameness_manual_mean

Ilustracja 12. Przykład średniej test_burst_sameness_manual.

test_burst_sameness_manual_plot_means

Rysunek 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

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

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 test_crop_region_raw comp YUV.

test_crop_region_raw_yuv_full example

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

test_crop_regions

Testy, które sprawdzają, czy regiony przycinania działają. Pobiera pełny obraz i tworzy wycinki z 5 różnych regionów (narożniki 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 (Zgodność): 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 EV 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 zastosowanej 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.

Zaawansowany test 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 zmieniających się wartościach ISO i czasie ekspozycji. Wykonuje serię zdjęć z ustawieniami ISO i czasu naświetlania dobranymi tak, aby się wzajemnie równoważyły. Wyniki powinny mieć tę 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*exposure jest stała w testowanym zakresie wzmocnienia.

Mechanizm niepowodzenia: 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 do odpowiedniej klatki 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 wartości ISO lub ekspozycji i wykazują wyższe średnie wartości RGB na wykresie na poniższym rysunku.

test_latching plot means example

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

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 CTS.

Testowane interfejsy API:

Zaliczone: przechwyty są spójne.

test_locked_burst frame0 example

Rysunek 38. Przykład ramki test_locked_burst frame0.

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, które sprawdzają, czy parametry android.colorCorrection.* są stosowane po ich ustawieniu. Wykonuje 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 dane wyjściowe były coraz bardziej czerwone lub niebieskie. Używa liniowego mapowania tonalnego.

Mapowanie tonów 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:

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

test_param_color_correction plot means example

Ilustracja 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. test_param_color_correction req=2 blue boost example.

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 użyta, i stosuje liniowe mapowanie tonalne. 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 – przykład kafelka

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

test_param_noise_reduction

Sprawdza, czy parametr android.noiseReduction.mode jest prawidłowo stosowany, gdy jest ustawiony. Rejestruje obrazy przy słabym oświetleniu. Używa wysokiego wzmocnienia analogowego, aby zapewnić, że zarejestrowany obraz będzie zaszumiony. Rejestruje 3 zdjęcia: z wyłączoną redukcją szumów, z szybką redukcją szumów i z redukcją szumów o wysokiej jakości. Robi też zdjęcie 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

Pass: SNR różni się w zależności od różnych trybów redukcji szumów i zachowuje się podobnie jak na poniższym wykresie:

test_param_noise_reduction plot SNRs example

Rysunek 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. test_param_noise_reduction high gain nr=0 example.

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.

test_param_noise_reduction low gain example

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

Pass: 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. Mapa cieniowania obiektywu test_param_shading_mode, 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. test_param_shading_mode lens shading map, mode 2 loop 0 example.

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ść. Obrazy są takie same.

test_param_tonemap_mode z n=0

Rysunek 58. test_param_tonemap_mode z n=0.

test_param_tonemap_mode z n=1

Ilustracja 59. test_param_tonemap_mode z n=1.

test_post_raw_sensitivity_boost

Sprawdza zwiększenie 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: obrazy RAW stają się ciemniejsze wraz ze wzrostem wzmocnienia, a jasność obrazów YUV pozostaje stała.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

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

Rysunek 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

Rysunek 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

Ilustracja 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.

test_raw_exposure ISO=132 example

Ilustracja 74. Przykład test_raw_exposure ISO=132.

test_raw_exposure ISO=209 example

Rysunek 75. Przykład test_raw_exposure ISO=209.

Przykład test_raw_exposure ISO=286

Rysunek 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

Ilustracja 78. Przykład test_raw_exposure ISO=440.

test_reprocess_noise_reduction

Testy, w przypadku których android.noiseReduction.mode jest stosowany do ponownego przetwarzania żądań. Rejestruje przetworzone obrazy przy słabym oświetleniu. Używa wysokiego wzmocnienia analogowego, aby sprawdzić, czy przechwycony obraz jest zaszumiony. Rejestruje 3 przetworzone obrazy: bez redukcji szumów, z szybką redukcją szumów i z redukcją szumów o wysokiej jakości. Rejestruje ponownie 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: występują 3 identyczne klatki, po których następuje inny zestaw 3 identycznych klatek.

test_tonemap_sequence i=0 example

Rysunek 80. Przykład test_tonemap_sequence i=0.

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

Ilustracja 85. Przykład test_tonemap_sequence i=5.

test_yuv_jpeg_all

Testy, w których wszystkie zgłoszone rozmiary i formaty przechwytywania obrazu działają. Używa ręcznego żądania 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 obrazów mają maksymalną średnią kwadratową różnicę (RMS) (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

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

Testowane interfejsy API:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

Pass (Zaliczone): test został ukończony i zwrócono żą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 prawidłowe dane są zwracane w obiektach CaptureResult. Test składa się z automatycznego robienia zdjęć, ręcznego robienia zdjęć i drugiego automatycznego robienia zdjęć.

Testowane interfejsy API:

Sukces: metadane są prawidłowe dla wszystkich zdjęć, a ustawienia ręczne nie przenikają do drugiego zdjęcia automatycznego. Wykreśla korekcję cieniowania obiektywu dla przechwytywanych 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 obrazy JPEG z urządzenia zostały przekonwertowane, wyglądają tak samo. Test pobiera środkowe 10% obrazu, oblicza wartość RGB i sprawdza, czy się zgadzają.

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

Rysunek 90. test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

Rysunek 91. test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

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

Testowane interfejsy API:

Zaliczone: każdy strzał jest głośniejszy od poprzedniego, ponieważ wzmocnienie rośnie.

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

Rysunek 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Testuje przechwytywanie pojedynczej klatki w formacie YUV i JPEG. Używa ręcznego żądania 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 (Zaliczone): obrazy YUV i JPEG są podobne, a różnica RMS (wartość sygnału) jest mniejsza niż 1%.

test_yuv_plus_jpeg w formacie JPEG

Rysunek 94. test_yuv_plus_jpeg w formacie JPEG.

test_yuv_plus_jpeg w formacie YUV

Rysunek 95. test_yuv_plus_jpeg w formacie YUV.

test_yuv_plus_raw

Testy rejestrujące pojedynczą klatkę 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 10% obrazów przekonwertowanych na 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

Ilustracja 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

Testy CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY przy różnych ustawieniach 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 ma 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 przy różnych czasach naświetlania, sprawdzanie stabilnej jasności w zakresie, w którym ISO może kompensować.

Testowane interfejsy API:

Pass (Zaliczone): jasność jest stabilna (w zakresie tolerancji) w różnych czasach naświetlania, 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 ma 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 ma 3 twarze na szarym tle i jest ubrana 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

Ilustracja 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 pierwotnej 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świetlanie 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:

Pass:plik JPEG zawiera profil ICC Display P3 i kolory spoza gamutu 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 (Zaliczone): 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:

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

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:znajduje 3 twarze z punktami charakterystycznymi w ramkach ograniczających twarz.

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 popularnych 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 dwóch powierzchni. Konwertuje oba obrazy na tablice RGB i oblicza trójwymiarową średnią kwadratową różnicę (RMS) między nimi.

Dodatkowo ten test sprawdza, 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:

Zaliczone: 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ę RMS mniejszą niż 10% w porównaniu z obrazami YUV w przypadku STILL_CAPTURE.

scena2_c

test_num_faces

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

Testowane interfejsy API:

Sukces: 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 rejestrowania obrazu JPEG w przypadku rozdzielczości 1080p MUSI być mniejsze niż 1000 ms w przypadku obu aparatów głównych, zgodnie z pomiarami testu wydajności aparatu CTS w warunkach oświetleniowych ITS (3000 K).

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 w przypadku obu aparatów głównych, zgodnie z pomiarami wykonanymi w ramach testu wydajności aparatu CTS w warunkach oświetleniowych ITS (3000 K).

test_default_camera_hdr

Sprawdza, czy domyślne przechwytywanie obrazu z aparatu jest w formacie Ultra HDR w przypadku urządzeń klasy 15 zgodnie z sekcją 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:znajduje 3 twarze z punktami charakterystycznymi w ramkach ograniczających twarz.

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 większej różnorodności odcieni skóry w scenach z twarzami.

Testowane interfejsy API:

Sukces: wykryto 3 twarze.

scene2_f

scene2_f – 3 twarze na białym tle i w białych ubraniach. Twarze mają szeroki zakres odcieni skóry i wysoki kontrast z tłem.

scene2_f example

Ilustracja 104. Przykład scene2_f.

test_preview_num_faces

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

Testowane interfejsy API:

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

test_num_faces_fd_mode_1

Rysunek 105. Przykład test_num_faces_fd_mode_1.

scene2_g

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

Rysunek 106. Przykład scene2_g.

test_preview_num_faces

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

Testowane interfejsy API:

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

test_preview_num_faces

Rysunek 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 sam wykres. Aby wyszukiwarka wykresów działała optymalnie, wykres musi być prawidłowo zorientowany.

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.

Pass: tryb HQ (2) jest ostrzejszy niż tryb OFF (0). 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 108. test_edge_enhancement edge=0 example.

test_edge_enhancement edge=1 example

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

test_edge_enhancement edge=2 example

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

test_flip_mirror

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

Odbite, odwrócone lub obrócone obrazy można rozpoznać po ikonie diamentu w pobliżu środka.

Pass:obraz nie jest odwrócony, odbity ani obrócony.

Przykład poprawki sceny test_flip_mirror

Ilustracja 111. Przykład 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:

Odchylenie żyroskopu jest mniejsze 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

Rysunek 112. Przykład dryfu żyroskopu test_imu_drift.

test_imu_drift – przykład dryfu wektora rotacji

Rysunek 113. 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ępowanie orientacji poziomej pionową jest wyłączone, 90 stopni, gdy jest włączone).

Przykład testu test_landscape_to_portrait

Rysunek 114. 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 klatek jest wykonywanych w optymalnej odległości od obiektu (ustalonej przez 3A), a ostatnie 12 klatek w minimalnej odległości od obiektu. 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 klatka, w której obiektyw się porusza, nie jest ważna. Ważne jest, aby flaga ruchu była ustawiona, gdy obiektyw się porusza.

Testowane interfejsy API:

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

Mechanizmy awaryjne:

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 przy optymalnej odległości ogniskowej lub ostatnich kilku klatek przy minimalnej odległości ogniskowania.

test_reprocess_edge_enhancement

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

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óżnica między poszczególnymi trybami jest podobna.

Przykład wykresu test_reprocess_edge_enhancement

Ilustracja 115. 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 urządzenia i wykresu.

przykład scene4

Rysunek 116. Przykład scene4.

test_30_60fps_preview_fov_match

Sprawdza, czy filmy podglądowe w 30 kl./s i 60 kl./s mają to samo pole widzenia. Test obejmuje nagranie 2 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. Sprawdza, 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 awaryjne:

Okrąg z filmu nagranego w 30 kl./s znacznie różni się rozmiarem od okręgu 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 (Zaliczone): obrazy nie są rozciągnięte, środki obrazów nie różnią się o więcej niż 3%, a maksymalne możliwe pole widzenia jest zachowane.

Mechanizmy awaryjne:

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 przetwarzania 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. Rzutuje środek okręgu na współrzędne świata dla każdej kamery. Porównuje różnicę między środkami okręgów kamer we współrzędnych świata. 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:

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

Mechanizmy awaryjne:

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.

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 (Zaliczone): obrazy nie są rozciągnięte, środki obrazów nie różnią się o więcej niż 3%, a maksymalne możliwe pole widzenia jest zachowane.

test_preview_stabilization_fov

Sprawdza obsługiwane rozmiary podglądu, aby upewnić się, że pole widzenia jest odpowiednio przycięte. Test obejmuje 2 filmy: jeden ze stabilizacją podgląduON i drugi 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:

Pass (Zaliczone): współczynnik proporcji okręgu pozostaje mniej więcej stały, położenie środka okręgu jest stabilne, a rozmiar okręgu 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ągane, środki klatek nie różnią się o więcej niż 3%, a maksymalne możliwe pole widzenia jest zachowane.

scena5

scene5 wymaga równomiernie 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 kamerą i skieruj ją 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 cech. Oto przykładowy obraz:

scene5 example

Ilustracja 117. Przykład przechwytywania sceny 5.

test_lens_shading_and_color_uniformity

Sprawdza, czy korekcja cieniowania obiektywu jest stosowana prawidłowo i czy kolor monochromatycznej sceny jest równomiernie rozłożony. Przeprowadza ten test na klatce YUV z automatycznym 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:

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

scena6

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

scena6

Rysunek 118. Przykład scene6.

test_in_sensor_zoom

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

Jeśli w przypadku strumienia ustawisz wartość CROPPED_RAW, test wykona 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:

Zaliczone: różnica RMS 3D między zmniejszonym przycię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 do momentu przełączenia aparatu fizycznego lub może zmieniać się monotonicznie w kierunku położenia tego samego znacznika po przełączeniu aparatu fizycznego. 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 znacznika ArUco najbliższy środka.

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

test_low_latency_zoom

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

Testowane interfejsy API:

Pass: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 wyświetlają i nagrywają ten sam obraz podglądu i obraz wyjściowy. Oblicza rozmiar znacznika najbliższego środka przy różnych współczynnikach powiększenia i sprawdza, czy rozmiar znacznika rośnie 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 120. HD_1280x720_key_frame.png (przed powiększeniem).

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

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

Ilustracja 123. 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 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 do momentu przełączenia aparatu fizycznego lub może zmieniać się monotonicznie w kierunku położenia tego samego znacznika po przełączeniu aparatu fizycznego.

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żej środka

Ilustracja 124. Obrazy test_preview_zoom pokazujące wybrany znacznik najbliższy środka

test_session_characteristics_zoom

Testuje zakres współczynnika powiększenia dla wszystkich obsługiwanych konfiguracji sesji wymienionych w CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. 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:

Pass:w przypadku każdego obsługiwanego urządzenia 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ę ukośny wykres krawędzi do sprawdzania ostrości. Cztery markery ArUco są wyrównane z czterema zewnętrznymi rogami prostokąta, aby ułatwić uzyskanie dokładnych współrzędnych głównej ramki prostokąta przy różnych współczynnikach powiększenia.

scene7

Rysunek 125. scene7.

test_multi_camera_switch

Ten test sprawdza, czy podczas nagrywania podglądu przy różnych współczynnikach powiększenia przełączanie 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 nagrać dynamiczny podgląd i określić moment, w którym zmienia się aparat fizyczny. 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 obrazów z obiektywów UW i W. Sprawdzanie automatycznego 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ść szacunkową 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:

Zaliczone: aby test został zaliczony, testy AE i AWB muszą zakończyć się pomyślnie. 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 szarego pola koloru.
Sprawdzanie automatycznego balansu bieli: różnica między wartościami czerwono-zielonymi i niebiesko-zielonymi w przypadku zdjęć z obiektywów ultraszerokokątnego i szerokokątnego musi być mniejsza niż 3% w przypadku szarego pola kolorów i mniejsza niż 10% w przypadku innych pól kolorów, 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 126. Szara plama sfotografowana obiektywem ultraszerokokątnym.

test_multi_camera_switch_gray_w_y

Rysunek 127. Szara plama sfotografowana obiektywem szerokokątnym.

scene8

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 (niebieski odcień, zwiększona ekspozycja, zmniejszona ekspozycja, żółty odcień). 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 128. 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 nagrywa 8-sekundowy podgląd, 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 mierząca region o zmniejszonej ekspozycji ma wartość luminancji większą o ponad 1% niż klatka mierząca region 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 (Zaliczone): obie kontrole AE i AWB zostały zaliczone.

test_ae_awb_regions_dark_region

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

test_ae_awb_regions_light_region

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

Mechanizmy awaryjne:

W tym teście kluczowe jest dokładne wykrycie 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 131. Niezgodność 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 ma 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.

scena9

scene9 składa się z tysięcy okręgów o losowych rozmiarach i kolorach, które tworzą scenę o bardzo niskiej powtarzalności, co pozwala sprawdzić działanie algorytmów kompresji JPEG.

Przykład scene9

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

Przykład nieudanego testu test_jpeg_quality

Rysunek 134. Przykład nieudanego testu.

scene_video

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

Ilustracja 135. 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 udostępnianych aplikacjom innych firm.

Testowane interfejsy API:

Zaliczone: liczba klatek podglądu jest maksymalna w zakresie żądanej liczby klatek, 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

Rysunek 136. Przykład scene_hdr.

test_hdr_extension

Testuje rozszerzenie HDR. Robi zrzuty ekranu z włączonym i wyłączonym rozszerzeniem i 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 o 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 137. Przykład scene_low_light.

test_night_extension

Testuje rozszerzenie Night. Robi zrzuty ekranu z włączonym rozszerzeniem 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 uzupełnienie 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 aż do kwadratów 5 i 6 musi wynosić co najmniej 18, 75.
W przypadku urządzeń z Androidem 15 i 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 138. Przykład testu sceny nocnej przy słabym oświetleniu.

test_low_light_boost_extension

Testuje tryb AE Słabe oświetlenie. 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 aż 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 139. 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

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

Jeśli zdjęcia wykonane za pomocą scene6_tele są prześwietlone w modułowej platformie, zdejmij przednią płytę modułowej platformy.

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

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

remove_front_plate

Rysunek 141. Zdejmij przednią płytę.

test_zoom_tele

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

Testowane interfejsy API:

Wynik pozytywny: 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 kamery w przypadku klatek podglądu z obiektywu szerokokątnego do teleobiektywu. Test jest identyczny jak test_preview_zoom, ale sprawdza zachowanie zoomu kamery w przypadku klatek podglądu z obiektywu szerokokątnego do teleobiektywu.

Testowane interfejsy API:

Pozytywny: względny rozmiar zarejestrowanego znacznika ArUco jest zgodny z wymaganym współczynnikiem powiększenia, co potwierdza, że aparat prawidłowo powiększa obraz, a odległość znacznika od środka obrazu zmienia się zgodnie z kryteriami 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ę ukośny wykres krawędzi do sprawdzania ostrości. Cztery markery ArUco są wyrównane z czterema 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.

Test wykorzystuje różne współczynniki powiększenia w określonym zakresie, aby nagrać dynamiczny podgląd i określić moment, w którym zmienia się aparat fizyczny. Ten punkt oznacza przejście z obiektywu szerokokątnego na teleobiektyw.

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ęć zrobionych 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 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.

test_auto_flash

Testy, które sprawdzają, czy automatyczny błysk jest wyzwalany w ciemnej scenie 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 urządzeniu testowym muszą być wyłączone. Można je wyłączyć automatycznie za pomocą kontrolera Arduino. Aby test działał prawidłowo, scena musi być całkowicie ciemna. Przed rozpoczęciem testowania na urządzeniu musi być zainstalowana aplikacja Jetpack Camera App (JCA). Automatyczna lampa błyskowa w przypadku tylnych aparatów jest wyzwalana na podstawie stanu AE, ale w przypadku przednich aparatów nie jest od niego zależna i jest zawsze wyzwalana.

Testowane interfejsy API:

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

test_flash_strength

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

Sprawdza, czy w trybie SINGLE siła błysku zmienia się w zależności od żądanego poziomu, jeśli urządzenie obsługuje sterowanie siłą błysku podczas korzystania z aparatu. 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 rośnie 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 przy użyciu 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 użyciem lampy błyskowej, test oblicza średnią wartość obrazu z lampą błyskową dla całego przechwyconego obrazu i sprawdza, czy mieści się ona w zakresie (68, 102). Aby sprawdzić, czy obraz ma odpowiedni balans bieli, test oblicza stosunek czerwieni do zieleni i niebieskiego do zieleni oraz sprawdza, czy mieści się on w przedziale od 0,95 do 1,05.

Testowane interfejsy API:

Zaliczone: stosunek czerwieni do zieleni i niebieskiego do zieleni mieści się w zakresie od 0,95 do 1,05. Średnia wartość obrazu z błyskiem lampy błyskowej 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 w takich warunkach warto użyć rozszerzenia aparatu w trybie nocnym. 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ą sesji Camera2.
- Światło włącza się 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 trybieTORCH jest prawidłowo zaimplementowana.

Sprawdza, czy jeśli urządzenie obsługuje sterowanie siłą błysku podczas korzystania z aparatu w trybie TORCH, siła latarki zmienia się w zależności od żą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ść. 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 zdjęć seryjnych 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 zdjęć seryjnych mieści się w zakresie tolerancji, gdy siła błysku wzrasta od braku błysku do FLASH_TORCH_STRENGTH_MAX_LEVEL.

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 142. Wykres fuzji czujników.

Wykres fuzji czujników w Rig

Rysunek 143. 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 próbki wewnętrzne obiektywu są obsługiwane, testy, które zmieniają środek optyczny próbek wewnętrznych obiektywu, gdy obiektyw przesuwa się z powodu optycznej stabilizacji obrazu.

Testowane interfejsy API:

Pass:wewnętrzne centrum optyczne 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ładzie poniżej przedstawiono wykres test_lens_intrinsic_calibration pokazujący zmiany punktów głównych w pikselach w przypadku każdej klatki:

Rysunek 144. 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 każdego aparatu 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świetlenia na obrazie służą do wizualnego wykrywania obszaru błędu zniekształcenia.

Rysunek 145. 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 146. Przykładowy film ze stabilizacją.

Rysunek 147. Przykładowy film bez stabilizacji.

test_sensor_fusion

Sprawdza różnicę w znacznikach czasu 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 płycie montażowej, co zmniejsza prawdopodobieństwo pomyślnego przejścia testu. Liczba cykli na wykresie zależy od szybkości zapisu podczas zapisywania klatek.

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

Rysunek 149. Przykład obrotów na wykresie test_sensor_fusion.

Testowane interfejsy API:

Pass:przesunięcie sygnatur czasowych kamery i żyroskopu jest mniejsze niż 1 ms zgodnie z sekcją 7.3.9 High Fidelity Sensors w CDD.

Mechanizmy awaryjne:

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żna niezawodnie połączyć się z testowanym urządzeniem na wystarczająco długo, aby przeprowadzić test.
Wykres nie jest zamontowany na płaskiej powierzchni. Wykres test_sensor_fusion_plot_rotations zawiera 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ść, która powoduje, że telefon jest przechylony, gdy tylna część telefonu jest przymocowana do płytki montażowej.

test_video_stabilization

Testy, w których stabilizowany film 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 150. Przykładowy film ze stabilizacją.

Rysunek 151. Przykładowy film bez stabilizacji.

test_video_stabilization_jca

Testy, w których stabilizowano nagrania wideo wykonane za pomocą JCA, wykazały, że obrót jest mniejszy niż w przypadku żyroskopu. 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 z fuzją 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, a wyniki są zapisywane w pliku proto. Asercje niepowodzenia są wywoływane tylko w przypadku kombinacji funkcji, dla których funkcja isSessionConfigurationSupported zwraca wartość True.

Testowane interfejsy API:

Spełnia wymagania:w przypadku każdej obsługiwanej kombinacji funkcji:

Strumień podglądu jest stabilizowany, jeśli stabilizacja podglądu jest włączona.
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ć główne różnice między zarejestrowanymi obrazami. JCA odtwarza zrzuty z aplikacji społecznościowych i dostarcza obraz odniesienia, który jest następnie przetwarzany i ulepszany przez aplikacje społecznościowe.

Wymagania dotyczące konfiguracji sprzętu

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

Testy są przeprowadzane w kamerze Gen2 ITS-in-a-box.
Kontrolery oświetlenia i 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 152. 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 ma 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 testowej 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 poprawkę zakresu dynamicznego do pomiaru jasności.
Balans bieli: sprawdza, czy różnica balansu bieli między domyślną aplikacją aparatu a JCA nie przekracza 4. Ten test wykorzystuje poprawkę zakresu dynamicznego do pomiaru jasności.

Podstawowy test zdany: test spełnia wymagania dotyczące pola widzenia, jasności i balansu bieli. W Androidzie 16 ten test nie jest wymagany (NOT_YET_MANDATED).

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

scene0

test_jitter

test_metadata

test_request_capture_match

test_sensor_events

test_solid_color_test_pattern

test_test_pattern

test_tonemap_curve

test_unified_timestamp

test_vibration_restriction

scene1_1

test_ae_precapture_trigger

test_auto_vs_manual

test_black_white

test_burst_capture

test_burst_sameness_manual

test_crop_region_raw

test_crop_regions

test_ev_compensation

test_exposure_x_iso

test_latching

test_linearity

test_locked_burst

scene1_2

test_param_color_correction

test_param_flash_mode

test_param_noise_reduction

test_param_shading_mode

test_param_tonemap_mode

test_post_raw_sensitivity_boost

test_raw_exposure

test_reprocess_noise_reduction

test_tonemap_sequence

test_yuv_jpeg_all

test_yuv_plus_dng

scene1_3

test_capture_result

test_dng_noise_model

test_jpeg

test_raw_burst_sensitivity

test_raw_sensitivity

test_yuv_plus_jpeg

test_yuv_plus_raw

test_sensitivity_priority

test_exposure_time_priority

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

scena2_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