Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Kamera-ITS-Tests

Auf dieser Seite finden Sie eine umfassende Liste der Tests in der Camera Image Test Suite (ITS), die Teil des CTS-Verifizierers (Android Compatibility Test Suite) ist. ITS-Tests sind Funktionstests. Das bedeutet, dass sie nicht die Bildqualität messen, sondern prüfen, ob alle beworbenen Kamerafunktionen wie erwartet funktionieren. In diesem Dokument erfahren Entwickler und Tester, was die einzelnen Tests bewirken und wie sie Fehler bei Tests beheben können.

Kamera-ITS-Gates-Tests werden nach erforderlichen Kameraeigenschaften, API-Level und Media Performance Class (MPC)-Level durchgeführt. Für das API-Level verwendet ITS ro.product.first_api_level, um Tests zu begrenzen, die in einem bestimmten API-Level hinzugefügt wurden und die negative Nutzererfahrung für Funktionen in niedrigeren API-Levels testen. ITS verwendet ro.vendor.api_level, um Tests für Funktionen zu steuern, die in einem bestimmten API-Level hinzugefügt wurden und neue Hardwarefunktionen erfordern. Wenn ro.odm.build.media_performance_class für ein Gerät definiert ist, sind je nach MPC-Stufe bestimmte ITS-Tests erforderlich.

Tests werden nach Szene gruppiert:

scene0:Metadaten, Jitter, Gyroskop und Vibration erfassen
scene1:Belichtung, Empfindlichkeit, Belichtungswert (EV)-Korrektur, YUV im Vergleich zu JPEG und RAW
scene2:Gesichtserkennung, Tests, für die Farbszenen erforderlich sind
scene3:Verbesserung des Verbindungssignals, Objektivbewegung
scene4:Seitenverhältnis, Zuschneiden, Sichtfeld
scene5:Tönung der Linse
scene6:Zoom
scene7:Multi-Kameraschalter
scene8:Messung von Regionen für automatische Belichtung (AE) und automatischen Weißabgleich (AWB)
scene9:JPEG-Kompression
scene_extensions:Kameraerweiterungen
scene_tele:Teleobjektiv wechseln
scene_flash:Autoflash, Mindest-Framerate
scene_video:Frame-Drops
sensor_fusion:Zeitversatz zwischen Kamera und Gyroskop
feature_combination:Feature-Kombinationen
scene_ip:Bildparität zwischen der Standardkamera-App und der Jetpack Camera App (JCA)

In den einzelnen Abschnitten finden Sie eine Beschreibung der jeweiligen Szene.

scene0

Für Tests sind keine spezifischen Informationen zur Szene erforderlich. Für die Tests mit dem Gyroskop und der Vibration muss das Smartphone jedoch unbewegt sein.

test_jitter

Misst Jitter in Kamerazeitstempeln.

Getestete APIs:

Bestanden:Zwischen den Frames liegt ein Delta von mindestens 30 ms.

Beachten Sie in der folgenden Abbildung den kleinen Bereich der y-Achse. Der Jitter ist in diesem Diagramm tatsächlich gering.

Jitter-Diagramm für den Test

Abbildung 1. test_jitter-Diagramm.

test_metadata

Prüft die Gültigkeit von Metadateneinträgen anhand von Aufnahmeergebnissen und Kameraeigenschaftsobjekten. Bei diesem Test werden auto_capture_request-Belichtungs- und ‑Verstärkungswerte verwendet, da der Bildinhalt nicht wichtig ist.

Getestete APIs:

Bestanden:Hardwareebene, rollingShutterSkew-, frameDuration-Tags, timestampSource, croppingType, blackLevelPattern, pixel_pitch, Sichtfeld und hyperfokale Distanz sind vorhanden und haben gültige Werte.

test_request_capture_match

Hier wird geprüft, ob das Gerät die richtigen Belichtungs- und Verstärkungswerte schreibt, indem die Aufnahmemetadaten zurückgelesen werden.

Getestete APIs:

Bestanden:Die Werte für die Anfrage- und Erfassungsmetadaten stimmen für alle Aufnahmen überein.

test_sensor_events

Bei Geräten, die die Unterstützung von Sensorfusion bewerben, wird in diesem Test geprüft, ob das Gerät Sensorereignisse abfragt und ausgibt. Die erwarteten Sensoren sind Beschleunigungsmesser, Gyroskop und Magnetometer. Dieser Test funktioniert nur, wenn der Bildschirm eingeschaltet ist, d. h. das Gerät sich nicht im Stand-by-Modus befindet.

Getestete APIs:

Bestanden:Ereignisse für jeden Sensor werden empfangen.

test_solid_color_test_pattern

Tests, ob Testmuster mit einheitlicher Farbe für das Stummschalten der Kamera richtig generiert werden. Wenn die Stummschaltung der Kamera unterstützt wird, müssen einfarbige Testmuster unterstützt werden. Wenn die Stummschaltung der Kamera nicht unterstützt wird, werden Testbilder mit Vollfarben nur getestet, wenn die Funktion beworben wird.

Wenn Rohbilder unterstützt werden, wird auch die Farbzusammenstellung getestet. Die getesteten Farben sind Schwarz, Weiß, Rot, Blau und Grün. Bei Kameras, die keine RAW-Bilder unterstützen, wird nur Schwarz getestet.

Getestete APIs:

Bestanden:Die unterstützten einfarbigen Testmuster haben die richtige Farbe und es gibt nur geringe Abweichungen im Bild.

test_test_pattern

Testet den Parameter android.sensor.testPatternMode, um Frames für jedes gültige Testmuster zu erfassen, und prüft, ob die Frames für Volltonfarben und Farbbalken korrekt generiert werden. Dieser Test umfasst die folgenden Schritte:

Nimmt Bilder für alle unterstützten Testmuster auf.
Führt eine Korrektheitsprüfung für einfarbige Testmuster und Farbbalken durch.

Getestete APIs:

Bestanden:Unterstützte Testmuster werden korrekt generiert.

Beispiel für test_test_patterns

Abbildung 2. Beispiel für test_test_patterns.

test_tonemap_curve

Testet die Konvertierung des Testmusters von RAW zu YUV mit linearer Tonzuordnung. Für diesen Test ist android.sensor.testPatternMode = 2 (COLOR_BARS) erforderlich, um ein perfektes Bildmuster für die Tonzuordnungskonvertierung zu generieren. Prüft, ob die Pipeline korrekte Farbausgaben mit linearer Tonzuordnung und idealer Bildeingabe hat (basiert auf test_test_patterns).

Getestete APIs:

Bestanden:Das YUV- und das RAW-Bild sehen sich ähnlich.

test_tonemap_curve – Rohbeispiel

Abbildung 3: Rohbeispiel für test_tonemap_curve.

test_tonemap_curve-YUV-Beispiel

Abbildung 4: test_tonemap_curve – YUV-Beispiel.

test_unified_timestamp

Prüft, ob Bild- und Bewegungssensorereignisse im selben Zeitbereich liegen.

Getestete APIs:

Pass:Die Zeitstempel für die Bewegung liegen zwischen den beiden Zeitstempeln für die Bilder.

test_vibration_restriction

Testet, ob die Vibration des Geräts wie erwartet funktioniert.

Getestete APIs:

Bestanden:Das Gerät vibriert nicht, wenn es über die API zur Einschränkung von Kamera-Audio stummgeschaltet wird.

scene1_1

scene1 ist ein graues Diagramm. Das graue Chart muss die mittleren 30% des Sichtfelds der Kamera abdecken. Das graue Diagramm soll 3A (AE, AWB und AF) moderat herausfordern, da die zentrale Region keine Funktionen hat. In der Aufnahmeanfrage wird jedoch die gesamte Szene angegeben, die genügend Funktionen für die 3A-Konvergenz enthält.

RFoV-Kameras können im WFoV- oder RFoV-Prüfaufbau getestet werden. Wenn eine RFoV-Kamera im WFoV-Prüfstand getestet wird, wird das Diagramm um 2/3 skaliert, um einige Grenzen für das graue Diagramm im Sichtfeld festzulegen, damit die 3A-Konvergenz unterstützt wird. Ausführlichere Beschreibungen der Kameratestaufbauten finden Sie unter Camera ITS-in-a-box.

scene1 example

Abbildung 5: Diagramm für Szene 1 in voller Größe (links), Diagramm im Maßstab 2/3 (rechts).

test_ae_precapture_trigger

Testet den AE-Zustandsautomaten bei Verwendung des Precapture-Triggers. Erfasst fünf manuelle Anfragen, bei denen AE deaktiviert ist. Die letzte Anfrage enthält einen AE-Precapture-Trigger, der ignoriert werden sollte, da AE deaktiviert ist.

Getestete APIs:

Bestanden:Die AE konvergiert.

test_auto_vs_manual

Tests mit automatischen und manuellen Aufnahmen sehen gleich aus.

Getestete APIs:

Bestanden:Die manuellen Weißabgleichsverstärkungen und die in jedem Aufnahmeergebnis gemeldete Transformation stimmen mit dem automatischen Weißabgleich estimate des 3A-Algorithmus der Kamera überein.

Beispiel für den automatischen und manuellen Test von test_auto_vs_manual

Abbildung 6. test_auto_vs_manual auto example.

Beispiel für den Vergleich von automatischem und manuellem Weißabgleich

Abbildung 7. Beispiel für den automatischen und manuellen Weißabgleich.

Beispiel für die automatische und manuelle Transformation des Weißabgleichs

Abbildung 8. Beispiel für die manuelle Weißabgleichstransformation für test_auto_vs_manual.

test_black_white

Tests, ob das Gerät vollständig schwarze und weiße Bilder erzeugt. Es werden zwei Aufnahmen gemacht: Die erste mit extrem niedriger Verstärkung und kurzer Belichtung, was zu einem schwarzen Foto führt, und die zweite mit extrem hoher Verstärkung und langer Belichtung, was zu einem weißen Foto führt.

Getestete APIs:

Durchgang:Erstellt Schwarz-Weiß-Bilder. Gesättigte Kanäle weißer Bilder haben RGB-Werte von [255, 255, 255] mit einer Fehlerabweichung von weniger als 1 %.

test_black_white, schwarzes Beispiel

Abbildung 9. „test_black_white“, schwarzes Beispiel.

Beispiel für die automatische und manuelle Transformation des Weißabgleichs

Abbildung 10: test_black_white, weißes Beispiel.

test_black_white plot means example

Abbildung 11: test_black_white, Beispiel für das Zeichnen von Mittelwerten.

test_burst_capture

Prüft, ob die gesamte Erfassungspipeline mit der Geschwindigkeit der Erfassung in voller Größe und der CPU-Zeit mithalten kann.

Getestete APIs:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_BURST_CAPTURE

Bestanden:Es wird eine Serie von Bildern in voller Größe aufgenommen und auf Frame-Drops und Helligkeit geprüft.

test_burst_sameness_manual

Es werden 5 Serienaufnahmen mit jeweils 50 Bildern mit manueller Aufnahmeeinstellung gemacht und geprüft, ob alle Bilder identisch sind. Mit diesem Test können Sie herausfinden, ob es sporadische Frames gibt, die anders verarbeitet werden oder Artefakte aufweisen.

Getestete APIs:

Bestanden:Die Bilder sind visuell und in den RGB-Werten identisch.

Fehler:Zeigt am Anfang jedes Burst einen Anstieg oder Abfall des durchschnittlichen RGB-Diagramms an.

Die Toleranz beträgt 3% für first_API_level < 30.
Die Toleranz beträgt 2% für first_API_level >= 30.

test_burst_sameness_manual_mean

Abbildung 12: Beispiel für den manuellen Mittelwert von „test_burst_sameness“.

test_burst_sameness_manual_plot_means

Abbildung 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

Tests, bei denen die RAW-Streams nicht zugeschnitten werden können.

Getestete APIs:

Bestanden:YUV-Bilder werden in der Mitte zugeschnitten, RAW-Bilder jedoch nicht.

test_crop_region_raw comp raw crop example

Abbildung 14: Beispiel für den rohen Zuschnitt der Testregion.

test_crop_region_raw comp raw full example

Abbildung 15: test_crop_region_raw comp raw full example.

test_crop_region_raw comp YUV crop example

Abbildung 16: Beispiel für das Zuschneiden von YUV-Bildern mit test_crop_region_raw.

test_crop_region_raw_yuv_full-Beispiel

Abbildung 17. test_crop_region_raw YUV-Vollbeispiel.

test_crop_regions

Tests, ob das Zuschneiden von Regionen funktioniert. Nimmt ein vollständiges Bild auf und erstellt Patches von fünf verschiedenen Regionen (Ecken und Mitte). Nimmt Bilder mit einem für die fünf Regionen festgelegten Zuschnitt auf. Vergleicht die Werte des Patches und des zugeschnittenen Bildes.

Getestete APIs:

Bestanden:Das Bild des zugeschnittenen Bereichs stimmt mit dem Patch überein, der dem zugeschnittenen Bild entspricht.

test_ev_compensation

Prüft, ob die Belichtungswertkompensation angewendet wird. Der Test besteht aus einem grundlegenden und einem erweiterten Abschnitt.

Im Abschnitt „Basic“ wird getestet, ob die EV-Korrektur mit einem Bereich angewendet wird, der mit CONTROL_AE_COMPENSATION_STEP erstellt wurde. Bei jedem Kompensationswert werden acht Bilder aufgenommen.

Im erweiterten Bereich wird die Belichtung in acht Schritten erhöht und die gemessene Helligkeit mit der erwarteten Helligkeit verglichen. Die erwarteten Werte werden aus der Bildhelligkeit des Bildes ohne angewendete Belichtungskorrektur berechnet. Der erwartete Wert wird gesättigt, wenn die berechneten Werte den tatsächlichen Bildwertbereich überschreiten. Der Test schlägt fehl, wenn die erwarteten und gemessenen Werte nicht übereinstimmen oder wenn die Bilder innerhalb von fünf Schritten überbelichtet werden.

Getestete APIs:

Grundlegender Abschnitt bestanden:Die Bilder zeigen eine zunehmende Belichtung ohne Überbelichtung innerhalb von fünf Schritten.

test_ev_compensation_basic

Abbildung 18. test_ev_compensation_basic.

Erweiterter Abschnitt – bestanden:Erfasst eine Erhöhung der Luminanz, wenn die Einstellung für die Belichtungskorrektur erhöht wird. Die acht Frames, die für jede Einstellung der Belichtungskorrektur aufgenommen wurden, haben stabile Helligkeitswerte.

test_ev_compensation_advanced_plot_means

Abbildung 19. test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Tests, bei denen eine konstante Belichtung erreicht wird, wenn ISO und Belichtungszeit variieren. Es werden mehrere Aufnahmen mit ISO-Wert und Belichtungszeit gemacht, die so gewählt sind, dass sie sich gegenseitig ausgleichen. Die Ergebnisse sollten dieselbe Helligkeit haben, aber im Laufe der Sequenz sollte das Bild verrauschter werden. Prüft, ob die mittleren Pixelwerte der Stichprobe nahe beieinander liegen. Prüfen Sie, ob die Bilder nicht auf 0 oder 1 begrenzt sind, da sie sonst wie flache Linien aussehen. Der Test kann auch mit RAW-Bildern ausgeführt werden. Dazu müssen Sie das Flag debug in Ihrer Konfigurationsdatei festlegen.

Getestete APIs:

Bestanden:Die Bilder haben dieselbe Helligkeit, werden aber mit höherem ISO-Wert rauschanfälliger. RGB-Ebenen sind flach, wenn der Wert von ISO*exposure über den getesteten Gain-Bereich konstant ist.

Fehlermechanismus:In der folgenden Abbildung sehen Sie, dass die normalisierten durchschnittlichen RGB-Ebenenwerte (y-Achse) mit zunehmenden Gain-Multiplikatorwerten (x-Achse) von den niedrigen Gain-Multiplikatorwerten abweichen.

test_exposure_plot_means

Abbildung 20. test_exposure_plot_means.

test_exposure_mult=1.00.jpg

Abbildung 21. test_exposure_mult=1.00.

test_exposure_mult=64.00

Abbildung 22. test_exposure_mult=64.00.

test_latching

Tests, ob die Einstellungen (Belichtung und Verstärkung) für die Kameras FULL und LEVEL_3 im richtigen Frame beibehalten werden. Es werden mehrere Aufnahmen mit aufeinanderfolgenden Anfragen gemacht, wobei die Parameter der Aufnahmeanfrage zwischen den Aufnahmen variieren. Prüft, ob die Bilder die erwarteten Eigenschaften haben.

Getestete APIs:

android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL

Bestanden:Die Bilder [2, 3, 6, 8, 10, 12, 13] haben einen erhöhten ISO-Wert oder eine erhöhte Belichtung und weisen im Diagramm in der folgenden Abbildung höhere RGB-Mittelwerte auf.

Beispiel für das Diagramm „test_latching“

Abbildung 23: Beispiel für ein test_latching-Diagramm.

test_latching i=00

Abbildung 24. test_latching i=00.

test_latching i=01

Abbildung 25. test_latching i=01.

test_latching i=02

Abbildung 26. test_latching i=02.

test_latching i=03

Abbildung 27. test_latching i=03.

test_latching i=04

Abbildung 28. test_latching i=04.

test_latching i=05

Abbildung 29. test_latching i=05.

test_latching i=06

Abbildung 30. test_latching i=06.

test_latching i=07

Abbildung 31. test_latching i=07.

test_latching i=08

Abbildung 32. test_latching i=08.

test_latching i=09

Abbildung 33. test_latching i=09.

test_latching i=10

Abbildung 34. test_latching i=10.

test_latching i=11

Abbildung 35. test_latching i=11.

test_latching i=12

Abbildung 36. test_latching i=12.

test_linearity

Tests, bei denen die Geräteverarbeitung in lineare Pixel umgekehrt werden kann. Erfasst eine Reihe von Aufnahmen, während das Gerät auf ein einheitliches Ziel gerichtet ist.

Getestete APIs:

Bestanden:Die R-, G- und B-Werte müssen mit zunehmender Empfindlichkeit linear ansteigen.

Beispiel für den Mittelwert des Diagramms „test_linearity“

Abbildung 37: Beispiel für ein Diagramm mit Testmittelwerten für Linearität.

test_locked_burst

Testet die 3A-Sperre und den YUV-Burst (mit der automatischen Einstellung). Dieser Test ist so konzipiert, dass er auch auf eingeschränkten Geräten ohne MANUAL_SENSOR oder PER_FRAME_CONTROLS bestanden wird. Bei diesem Test wird die Konsistenz von YUV-Bildern geprüft. Die Prüfung der Framerate erfolgt im CTS.

Getestete APIs:

Bestanden:Die Aufnahmen sehen konsistent aus.

Beispiel für test_locked_burst frame0

Abbildung 38. Beispiel für Frame 0 von „test_locked_burst“.

Beispiel für test_locked_burst frame1

Abbildung 39: Beispiel für test_locked_burst frame1.

test_locked_burst_frame2

Abbildung 40: Beispiel für „test_locked_burst frame2“.

scene1_2

scene 1_2 ist eine funktional identische Kopie von scene 1_1, die eine Unterscenenstruktur implementiert, um die lange Dauer von scene 1 zu verkürzen.

test_param_color_correction

Tests, ob die android.colorCorrection.*-Parameter angewendet werden, wenn sie festgelegt sind. Es werden Aufnahmen mit unterschiedlichen Transformations- und Verstärkungswerten gemacht und getestet, ob sie entsprechend unterschiedlich aussehen. Die Transformation und die Steigerungen werden so ausgewählt, dass die Ausgabe immer roter oder blauer wird. Verwendet ein lineares Ton-Mapping.

Das Tone Mapping ist eine Technik, die in der Bildverarbeitung verwendet wird, um eine Reihe von Farben einer anderen zuzuordnen, um das Erscheinungsbild von HDR-Bildern (High Dynamic Range) in einem Medium mit einem begrenzten Dynamikumfang zu simulieren.

Getestete APIs:

Bestanden:Die R- und B-Werte werden entsprechend der Transformation erhöht.

Beispiel für die Darstellung von Mittelwerten für den Testparameter „Farbkorrektur“

Abbildung 41. Diagramm mit Beispiel für Mittelwerte für „test_param_color_correction“.

In den folgenden Abbildungen steht die x-Achse für die Erfassungsanfragen: 0 = Einheit, 1 = Rotverstärkung und 2 = Blauverstärkung.

test_param_color_correction req=0 unity example

Abbildung 42. test_param_color_correction req=0 Unity-Beispiel.

test_param_color_correctness req=1 red boost example

Abbildung 43. test_param_color_correctness req=1 red boost example.

test_param_color_correction req=2 blue boost example

Abbildung 44: Beispiel für „test_param_color_correction req=2 blue boost“.

test_param_flash_mode

Testet, ob der Parameter android.flash.mode angewendet wird. Legt die Belichtung manuell auf der dunklen Seite fest, sodass deutlich zu erkennen ist, ob der Blitz ausgelöst wurde oder nicht. Außerdem wird ein linearer Tonwert-Map verwendet. Prüft den Mittelpunkt des Kachelbilds, um festzustellen, ob ein großer Farbverlauf vorhanden ist, der darauf hinweist, dass der Blitz ausgelöst wurde.

Getestete APIs:

Bestanden:Das Bild in der Mitte der Kachel hat einen großen Farbverlauf, was bedeutet, dass der Blitz ausgelöst wurde.

Beispiel für test_param_flash_mode 1

Abbildung 45. Beispiel für test_param_flash_mode 1.

Beispiel für Kachel mit „test_param_flash_mode 1“

Abbildung 46. Beispiel für eine Kachel für „test_param_flash_mode“.

test_param_flash_mode_2 example

Abbildung 47. Beispiel für test_param_flash_mode 2.

Beispiel für Kachel „test_param_flash_mode 2“

Abbildung 48: Beispiel mit zwei Kacheln für „test_param_flash_mode“

test_param_noise_reduction

Testet, ob der Parameter android.noiseReduction.mode korrekt angewendet wird, wenn er festgelegt ist. Nimmt Bilder mit der Kamera bei schwacher Beleuchtung auf. Verwendet eine hohe analoge Verstärkung, um sicherzustellen, dass das aufgenommene Bild verrauscht ist. Es werden drei Bilder aufgenommen: eines ohne Rauschunterdrückung, eines mit schneller Rauschunterdrückung und eines mit hochwertiger Rauschunterdrückung. Es wird auch ein Bild mit geringer Verstärkung und ohne Rauschunterdrückung aufgenommen und die Varianz dieses Bilds als Baseline verwendet. Je höher das Signal-Rausch-Verhältnis (SNR), desto besser die Bildqualität.

Getestete APIs:

android.hardware.camera2.CaptureRequest#NOISE_REDUCTION_MODE

Bestanden:Das SNR variiert je nach Rauschunterdrückungsmodus und verhält sich ähnlich wie im folgenden Diagramm:

test_param_noise_reduction-Diagramm mit SNR-Beispiel

Abbildung 49: Beispiel für SNR-Diagramm für „test_param_noise_reduction“.

0: AUS, 1: SCHNELL, 2: HQ, 3: MIN , 4: ZSL

test_param_noise_reduction high gain nr=0 example

Abbildung 50. Beispiel für test_param_noise_reduction mit hoher Verstärkung und nr=0.

test_param_noise_reduction high gain nr=1 example

Abbildung 51. Beispiel für test_param_noise_reduction mit hoher Verstärkung und nr=1.

test_param_noise_reduction high gain nr=2 example

Abbildung 52: Beispiel für „test_param_noise_reduction“ mit hoher Verstärkung und „nr=2“.

test_param_noise_reduction high gain nr=3 example

Abbildung 53: Beispiel für „test_param_noise_reduction“ mit hoher Verstärkung und „nr=3“.

test_param_noise_reduction – Beispiel für niedrige Verstärkung

Abbildung 54: Beispiel für „test_param_noise_reduction“ mit niedriger Verstärkung.

test_param_shading_mode

Testet, ob der Parameter android.shading.mode angewendet wird.

Getestete APIs:

Bestanden:Die Schattierungsmodi werden wie erwartet umgeschaltet und die Karten für die Objektivschattierung werden wie erwartet geändert.

test_param_shading_mode lens shading map, mode 0 loop 0 example

Abbildung 55. test_param_shading_mode-Objektivschattierungskarte, Modus 0, Schleife 0.

test_param_shading_mode lens shading map, mode 1 loop 0 example

Abbildung 56: test_param_shading_mode-Objektivschattierungskarte, Modus 1, Schleife 0, Beispiel.

test_param_shading_mode lens shading map, mode 2 loop 0 example

Abbildung 57: test_param_shading_mode-Objektivschattierungskarte, Beispiel für Modus 2, Schleife 0.

test_param_tonemap_mode

Testet, ob der Parameter android.tonemap.mode angewendet wird. Wendet auf jeden R-, G- und B-Channel unterschiedliche Tonwertkurven an und prüft, ob die Ausgabebilder wie erwartet geändert werden. Dieser Test besteht aus zwei Tests: test1 und test2.

Getestete APIs:

Bestanden:

test1: Beide Bilder haben ein lineares Ton-Mapping, aber n=1 hat einen steileren Gradienten. Der G-Kanal (Grün) ist für das Bild n=1 heller.
test2: Derselbe Tonemapping-Vorgang, aber mit unterschiedlicher Länge. Die Bilder sind identisch.

test_param_tonemap_mode mit n=0

Abbildung 58: test_param_tonemap_mode mit n=0.

test_param_tonemap_mode mit n=1

Abbildung 59: test_param_tonemap_mode mit n=1.

test_post_raw_sensitivity_boost

Prüft die Steigerung der Rohsensitivität nach dem Post. Erstellt eine Reihe von RAW- und YUV-Bildern mit unterschiedlicher Empfindlichkeit, gibt die Kombination aus RAW-Empfindlichkeitsverstärkung aus und prüft, ob der mittlere Ausgabepixelwert mit den Anforderungseinstellungen übereinstimmt.

Getestete APIs:

Bestanden:Rohbilder werden dunkler, wenn der Boost zunimmt, während die Helligkeit von YUV-Bildern konstant bleibt.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

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

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

Abbildung 61: Beispiel für test_post_raw_sensitivity_boost mit Rohwert s=1792 und Steigerung=0200.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

Abbildung 62. Beispiel für test_post_raw_sensitivity_boost mit Rohdaten, s=0896 und boost=0400.

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

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

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

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

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

Abbildung 65: Beispiel für test_post_raw_sensitivity_boost mit Rohdaten, s=0112 und boost=3199.

test_post_raw_sensitivity_boost – Beispiel für Rohdatenplot

Abbildung 66: Beispiel für Rohdatenplot für test_post_raw_sensitivity_boost.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

Abbildung 67: test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example.

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

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

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

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

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

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

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

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

test_post_raw_sensitivity_boost_yuv_plot_means

Abbildung 72. test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

Erfasst eine Reihe von Rohbildern mit zunehmender Belichtungszeit und misst die Pixelwerte.

Getestete APIs:

Bestanden:Durch Erhöhen des ISO-Werts (Verstärkung) reagieren die Pixel empfindlicher auf Licht, sodass sich die Kurve nach links verschiebt.

Beispiel für „test_raw_exposure ISO=55“

Abbildung 73: Beispiel für „test_raw_exposure“ mit ISO 55.

10⁰ entspricht 1 ms, 10¹ entspricht 10 ms und 10⁻¹ entspricht 0, 1 ms.

Beispiel für „test_raw_exposure ISO=132“

Abbildung 74: Beispiel für „test_raw_exposure“ mit ISO 132.

Beispiel für „test_raw_exposure ISO=209“

Abbildung 75. Beispiel für test_raw_exposure ISO=209.

Beispiel für „test_raw_exposure ISO=286“

Abbildung 76. Beispiel für test_raw_exposure mit ISOs=286.

Beispiel für „test_raw_exposure ISO=363“

Abbildung 77. Beispiel für „test_raw_exposure“ mit ISO 363.

test_raw_exposure_s=440

Abbildung 78. Beispiel für „test_raw_exposure“ mit ISO=440.

test_reprocess_noise_reduction

Tests, die für Anfragen zur erneuten Verarbeitung von android.noiseReduction.mode angewendet werden. Erfasst neu verarbeitete Bilder mit der Kamera bei schwacher Beleuchtung. Verwendet eine hohe analoge Verstärkung, um zu prüfen, ob das aufgenommene Bild verrauscht ist. Nimmt drei neu verarbeitete Bilder auf, für „NR aus“, „Schnell“ und „Hohe Qualität“. Erfasst ein neu verarbeitetes Bild mit geringer Verstärkung und deaktivierter Rauschunterdrückung und verwendet die Varianz dieses Bilds als Baseline.

Getestete APIs:

android.hardware.camera2.CaptureResult#NOISE_REDUCTION_MODE

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

Typisches SNR-Diagramm im Vergleich zum NR-Modus

Abbildung 79. Beispiel für ein typisches Diagramm mit SNR im Vergleich zum NR-Modus.

test_tonemap_sequence

Testet eine Reihe von Aufnahmen mit verschiedenen Tonwertkurven. Es werden drei manuelle Aufnahmen mit einem linearen Tonemapping gemacht. Nimmt drei manuelle Aufnahmen mit dem Standard-Tonemapping auf. Berechnet das Delta zwischen jedem aufeinanderfolgenden Frame-Paar.

Getestete APIs:

Bestanden:Es gibt drei identische Frames, gefolgt von einem anderen Satz aus drei identischen Frames.

Beispiel für „test_tonemap_sequence i=0“

Abbildung 80. Beispiel für test_tonemap_sequence i=0.

test_tonemap_sequence i=1 example

Abbildung 81: Beispiel für test_tonemap_sequence i=1.

test_tonemap_sequence i=2 example

Abbildung 82. Beispiel für test_tonemap_sequence i=2.

test_tonemap_sequence i=3 example

Abbildung 83. Beispiel für test_tonemap_sequence i=3.

test_tonemap_sequence_i=4 example

Abbildung 84. Beispiel für test_tonemap_sequence i=4.

test_tonemap_sequence i=5 example

Abbildung 85. Beispiel für test_tonemap_sequence i=5.

test_yuv_jpeg_all

Tests, die sicherstellen, dass alle gemeldeten Größen und Formate für die Bildaufnahme funktionieren. Verwendet eine manuelle Anfrage mit einem linearen Tonemapping, sodass YUV und JPEG bei der Konvertierung durch das image_processing_utils-Modul gleich aussehen. Bilder werden nicht standardmäßig gespeichert, können aber durch Aktivieren von debug_mode gespeichert werden.

Getestete APIs:

Bestanden:Alle Bildzentren haben eine maximale quadratische Mittelwertabweichung (Root Mean Square, RMS) (Wert eines Signals) in RGB-konvertierten Bildern mit 3% des YUV-Bilds mit der höchsten Auflösung.

test_yuv_jpeg_all example

Abbildung 86: Beispiel für „test_yuv_jpeg_all“.

test_yuv_plus_dng

Tests, ob die gemeldeten Größen und Formate für die Bilderfassung funktionieren.

Getestete APIs:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

Bestanden:Der Test wird abgeschlossen und die angeforderten Bilder werden zurückgegeben.

Beispiel für test_yuv_plus_dng

Abbildung 87. Beispiel für test_yuv_plus_dng.

scene1_3

scene 1_3 ist eine funktional identische Kopie von scene 1_1, die eine Unterscenenstruktur implementiert, um die lange Dauer von scene 1 zu verkürzen.

test_capture_result

Tests, ob gültige Daten in CaptureResult-Objekten zurückgegeben werden. Der Test besteht aus einer automatischen Aufnahme, einer manuellen Aufnahme und einer zweiten automatischen Aufnahme.

Getestete APIs:

Bestanden:Die Metadaten sind für alle Aufnahmen gültig und die manuellen Einstellungen werden nicht in die zweite automatische Aufnahme übernommen. Stellt die Korrektur der Objektivschattierung für die Aufnahmen dar.

test_capture_result_plot_lsc_auto_ch0

Abbildung 88. test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

Prüft, ob die DNG-Rohmodellparameter korrekt sind. Das Diagramm zeigt die gemessene Varianz eines mittleren Bereichs der Graukarte in Rohaufnahmen, die über einen Bereich von Empfindlichkeiten hinweg aufgenommen wurden, und vergleicht diese Werte mit der Varianz, die bei jeder Empfindlichkeit vom DNG-Rauschmodell im Kamera-HAL erwartet wird (basierend auf den O- und S-Parametern, die in den Objekten des Aufnahmeergebnisses zurückgegeben werden). Weitere Informationen zum DNG-Rauschmodell finden Sie im folgenden Dokument zum DNG-Rauschmodell.

Getestete APIs:

Bestanden:Die DNG-RAW-Modellparameter sind korrekt. Die erwarteten RGB-Werte stimmen mit den gemessenen tatsächlichen RGB-Werten überein.

test_dng_noise_model_plog

Abbildung 89. test_dng_noise_model_plog.

test_jpeg

Tests, bei denen YUV-Bilder und Geräte-JPEG-Bilder konvertiert wurden, sehen gleich aus. Beim Test werden die mittleren 10% des Bildes verwendet, um den RGB-Wert zu berechnen und zu prüfen, ob er mit dem erwarteten Wert übereinstimmt.

Getestete APIs:

android.graphics.ImageFormat#JPEG

Bestanden:Die durchschnittliche RGB-Differenz zwischen den einzelnen Bildern beträgt weniger als 3%.

test_jpeg_fmt=jpg.jpg

Abbildung 90. test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

Abbildung 91: test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

Erstellt eine Reihe von Rohbildern mit zunehmender Verstärkung und misst das Rauschen. Nimmt nur Rohbilder in einer Serie auf.

Getestete APIs:

Bestanden:Jede Aufnahme ist lauter als die vorherige, da die Verstärkung zunimmt.

Verwendet die Varianz der Statistiken der mittleren Rasterzelle.

test_raw_burst_sensitivity_variance

Abbildung 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Es werden mehrere Rohbilder mit zunehmender Empfindlichkeit aufgenommen und das Rauschen (die Varianz) in den mittleren 10% des Bildes gemessen. Tests, bei denen jede Aufnahme lauter ist als die vorherige.

Getestete APIs:

Pass:Die Varianz nimmt mit jedem Schuss zu.

test_raw_sensitivity_variance

Abbildung 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

Tests, bei denen ein einzelner Frame als YUV- und JPEG-Ausgabe erfasst wird. Verwendet eine manuelle Anfrage mit einem linearen Tonemapping, sodass YUV und JPEG bei der Konvertierung durch das image_processing_utils-Modul gleich aussehen.

Getestete APIs:

Bestanden:YUV- und JPEG-Bilder sind ähnlich und haben einen RMS-Unterschied (Wert eines Signals) von weniger als 1 %.

test_yuv_plus_jpeg mit JPEG-Format

Abbildung 94. test_yuv_plus_jpeg mit JPEG-Format.

test_yuv_plus_jpeg mit YUV-Format

Abbildung 95: test_yuv_plus_jpeg mit YUV-Format.

test_yuv_plus_raw

Tests, bei denen ein einzelnes Bild sowohl als RAW-Ausgabe (10-Bit- und 12-Bit-RAW) als auch als YUV-Ausgabe erfasst wird, sofern dies unterstützt wird. Verwendet eine manuelle Anfrage mit linearer Tonzuordnung. Daher wird erwartet, dass RAW und YUV gleich sind. Vergleicht die RGB-Werte der mittleren 10% von in RGB konvertierten Bildern. Protokolleandroid.shading.mode

Getestete APIs:

Bestanden:YUV- und Rohbilder sind ähnlich und haben einen RMS-Unterschied (Effektivwert eines Signals) von weniger als 3,5 %.

test_yuv_plus_raw_shading=1_raw.jpg

Abbildung 96. test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

Abbildung 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

Führen Sie Tests CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY mit verschiedenen ISO-Einstellungen durch, um eine Korrelation zwischen höheren ISO-Werten und einem erhöhten Rauschen zu bestätigen.

Getestete APIs:

Bestanden:Höhere ISO-Werte führen zu einem höheren Rauschen.

Kriterien zum Überspringen von Tests

Der test_sensitivity_priority.py-Test wird übersprungen, wenn eines der folgenden Kriterien erfüllt ist:

Das Gerät hat ein erstes API‑Level (first_api_level) von 35 oder niedriger.
Das Gerät bewirbt CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY nicht in CONTROL_AE_AVAILABLE_PRIORITY_MODES.

test_exposure_time_priority

Führen Sie Tests CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY bei verschiedenen Belichtungszeiten durch und prüfen Sie, ob die Helligkeit im Bereich, in dem der ISO-Wert kompensiert werden kann, stabil ist.

Getestete APIs:

Bestanden:Die Helligkeit ist über alle Belichtungszeiten hinweg stabil (innerhalb der Toleranz), wenn der ISO-Wert innerhalb des Kompensationsbereichs liegt.

Kriterien zum Überspringen von Tests

Der test_exposure_time_priority-Test wird übersprungen, wenn eines der folgenden Kriterien erfüllt ist:

Das Gerät hat ein erstes API‑Level (first_api_level) von 35 oder niedriger.
Das Gerät bewirbt CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY nicht in CONTROL_AE_AVAILABLE_PRIORITY_MODES.

scene2_a

scene2_a hat drei Gesichter mit grauem Hintergrund und neutraler Kleidung. Die Gesichter wurden so ausgewählt, dass sie eine große Bandbreite an Hauttönen abdecken. Das Diagramm muss die richtige Ausrichtung haben, damit die Gesichtserkennung optimal funktioniert.

Beispiel für Szene 2

Abbildung 98: Beispiel für scene2_a.

test_autoframing

Testet das Autoframing-Verhalten des Kamerageräts. Es wird so stark gezoomt, dass keines der Gesichter in der Szene sichtbar ist. Der Autoframing-Modus wird aktiviert, indem AUTOFRAMING in CaptureRequest auf True gesetzt wird. Außerdem wird geprüft, ob alle Gesichter in der ursprünglichen Szene erkannt werden können, wenn der Status konvergiert (d. h. wenn AUTOFRAMING_STATE in CaptureResult auf AUTOFRAMING_STATE_CONVERGED gesetzt ist).

Getestete APIs:

Bestanden:Alle drei Gesichter werden erkannt.

test_display_p3

Tests Display P3 capture in JPEG using the ColorSpaceProfiles API. Tests, ob das aufgenommene JPEG ein geeignetes ICC-Profil im Header hat und ob das Bild Farben außerhalb des sRGB-Gamuts enthält.

Getestete APIs:

Bestanden:Das JPEG enthält ein Display P3-ICC-Profil und Farben außerhalb des sRGB-Farbraums.

test_effects

Erstellt ein Bild für unterstützte Kameraeffekte und prüft, ob sie richtig generiert werden. Im Test werden nur die Effekte OFF und MONO geprüft, aber Bilder für alle unterstützten Effekte gespeichert.

Getestete APIs:

Pass:Erfasst das Szenenbild mit Effekten OFF und ein monochromes Bild mit Effekten, die auf MONO festgelegt sind.

test_effects_MONO

Abbildung 99. test_effects_MONO.

test_exposure_keys_consistent

Bei diesem Test wird die durchschnittliche Helligkeit einer Aufnahme mit automatischer Belichtung mit einer Aufnahme ohne automatische Belichtung verglichen, bei der die Belichtungsparameter (Empfindlichkeit, Belichtungszeit, Bilddauer, Post-Raw-Empfindlichkeitsverstärkung) aus dem CaptureResult der Aufnahme mit automatischer Belichtung manuell angewendet werden.

Getestete APIs:

Bestanden:Der relative Unterschied in der Luminanz zwischen den beiden Aufnahmen beträgt weniger als 4 %.

test_format_combos

Es werden verschiedene Kombinationen von Ausgabeformaten getestet.

Getestete APIs:

Bestanden:Alle Kombinationen wurden erfasst.

test_num_faces

Testet die Gesichtserkennung.

Getestete APIs:

Bestanden:Es werden drei Gesichter gefunden.

test_num_faces face detection mode 1 example

Abbildung 100: Beispiel für den Gesichtserkennungsmodus 1 für test_num_faces.

test_reprocess_uv_swap

Tests, die prüfen, ob beim YUV-Reprocessing die U- und V-Ebenen nicht vertauscht werden. Dies wird durch die Berechnung der Summe der absoluten Differenzen (SAD) zwischen dem neu verarbeiteten Bild und einer nicht neu verarbeiteten Aufnahme erkannt. Wenn das Vertauschen der U- und V-Ausgabeebenen der neu verarbeiteten Aufnahme zu einem erhöhten SAD führt, wird davon ausgegangen, dass die Ausgabe die richtigen U- und V-Ebenen hat.

Getestete APIs:

Bestanden:Die U- und V-Ebenen werden nicht getauscht.

test_reprocess_uv_swap

Abbildung 101: Beispiel für „test_reprocess_uv_swap“.

scene2_b

test_preview_num_faces

Tests der Gesichtserkennung in der Vorschau mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen.

Getestete APIs:

Bestanden:Es werden drei Gesichter mit Gesichtsmerkmalen in den Begrenzungsrahmen für Gesichter gefunden.

test_num_faces_fd_mode_1

Abbildung 102: Beispiel für den Gesichtserkennungsmodus 1 von „test_num_faces“.

test_yuv_jpeg_capture_sameness

Es werden zwei Bilder im größten gemeinsamen YUV- und JPEG-Format mit demselben Seitenverhältnis wie das größte JPEG-Format aufgenommen, wobei eine Auflösung von 1920 × 1440 nicht überschritten wird. Setzt jpeg.quality auf 100 und erfasst eine Anfrage mit zwei Oberflächen. Konvertiert beide Bilder in RGB-Arrays und berechnet die dreidimensionale Wurzel der mittleren Fehlerquadratsumme (Root Mean Square, RMS) zwischen den beiden Bildern.

Außerdem wird in diesem Test geprüft, ob die YUV-Ausgaben für alle unterstützten Stream-Anwendungsfälle in etwa mit dem YUV-Anwendungsfall STILL_CAPTURE übereinstimmen.

Getestete APIs:

Bestanden:YUV- und JPEG-Bilder für den Anwendungsfall STILL_CAPTURE haben einen RMS-Wert (Root Mean Square, quadratischer Mittelwert eines Signals) von weniger als 3 %. YUV-Bilder für alle unterstützten Anwendungsfälle haben einen RMS-Wert von weniger als 10% im Vergleich zu YUV-Bildern mit dem Anwendungsfall STILL_CAPTURE.

scene2_c

test_num_faces

Testet die Gesichtserkennung mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen.

Getestete APIs:

Bestanden:Es werden drei Gesichter gefunden.

test_num_faces_fd_mode_1

Abbildung 103: Beispiel für den Gesichtserkennungsmodus „test_num_faces“.

test_jpeg_capture_perf_class

Testet die Latenz beim Aufnehmen von JPEG-Bildern für die Leistungsklasse S gemäß Abschnitt 2.2.7.2 Kamera im CDD.

Bestanden:Die JPEG-Aufnahmelatenz der Camera2-API MUSS bei einer Auflösung von 1080p für beide primären Kameras unter ITS-Beleuchtungsbedingungen (3.000 K) gemäß dem CTS-Kameraleistungstest unter 1.000 ms liegen.

test_camera_launch_perf_class

Testet die Latenz beim Starten der Kamera für die Leistungsklasse S gemäß Abschnitt 2.2.7.2 Kamera im CDD.

Bestanden:Die Startlatenz von Camera2 (Öffnen der Kamera bis zum ersten Vorschaubild) MUSS gemäß dem CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Primärkameras unter 600 ms liegen.

test_default_camera_hdr

Tests, bei denen die Standardkameraaufnahme Ultra HDR für die Leistungsklasse 15 ist, wie im Abschnitt 2.2.7.2 Kamera des CDD angegeben.

Bestanden:Die Standardaufnahme des Kamerapakets MUSS Ultra-HDR für ein Gerät der Leistungsklasse 15 sein.

scene2_d

test_preview_num_faces

Tests der Gesichtserkennung in der Vorschau mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen.

Getestete APIs:

Bestanden:Es werden drei Gesichter mit Gesichtsmerkmalen in den Begrenzungsrahmen für Gesichter gefunden.

scene2_e

test_continuous_picture

50 Frames mit VGA-Auflösung werden mit der ersten Einstellung der Erfassungsanfrage android.control.afMode = 4 (CONTINUOUS_PICTURE). erfasst.

Getestete APIs:

Bestanden:Das 3A-System stabilisiert sich bis zum Ende einer 50-Frame-Aufnahme.

test_num_faces

Testet die Gesichtserkennung mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden 3 Gesichter gefunden.

scene2_f

scene2_f hat drei Gesichter mit weißem Hintergrund und weißer Kleidung. Die Gesichter haben eine große Bandbreite an Hauttönen und einen hohen Kontrast zum Hintergrund.

scene2_f-Beispiel

Abbildung 104. Beispiel für scene2_f.

test_preview_num_faces

Testet die Gesichtserkennung mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen.

Getestete APIs:

Bestanden:Es werden drei Gesichter mit Gesichtsmerkmalen in den Begrenzungsrahmen für Gesichter gefunden.

test_num_faces_fd_mode_1

Abbildung 105. Beispiel für test_num_faces_fd_mode_1.

scene2_g

scene2_g hat drei Profilgesichter mit weißem Hintergrund und weißer Kleidung. Die Gesichter haben eine große Bandbreite an Hauttönen und einen hohen Kontrast zum Hintergrund.

Abbildung 106. Beispiel für scene2_g.

test_preview_num_faces

Testet die Gesichtserkennung mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen.

Getestete APIs:

Bestanden:Es werden drei Gesichter mit Gesichtsmerkmalen in den Begrenzungsrahmen für Gesichter gefunden.

test_preview_num_faces

Abbildung 107: Beispiel für „test_preview_num_faces“.

Szene 3

scene3 verwendet das ISO12233-Testbild und bei den meisten Tests wird eine Methode zum Extrahieren von Testbildern verwendet, um das Testbild in der Szene zu finden. Aus diesem Grund haben die meisten gespeicherten Bilder keine Ränder wie die Bilder für die Szenen 1, 2 oder 4, sondern nur das Diagramm. Das Diagramm muss die richtige Ausrichtung haben, damit die Diagrammsuche optimal funktioniert.

test_edge_enhancement

Testet, ob der Parameter android.edge.mode richtig angewendet wird. Erfasst Bilder ohne Neubearbeitung für jeden Edge-Modus und gibt die Schärfe des Ausgabebilds und die Metadaten des Erfassungsergebnisses zurück. Verarbeitet eine Aufnahmeanfrage mit einem bestimmten Edge-Modus, einer bestimmten Empfindlichkeit, Belichtungszeit, Fokusentfernung und einem bestimmten Ausgabeflächenparameter.

Bestanden:Der HQ-Modus (2) ist schärfer als der OFF-Modus (0). FAST-Modus (1) schärfer als der OFF-Modus. Der HQ-Modus ist schärfer oder gleich scharf wie der FAST-Modus.

Getestete APIs:

android.hardware.camera2.CaptureRequest#EDGE_MODE

Betroffene Kameraparameter:

EDGE_MODE

test_edge_enhancement_edge=0

Abbildung 108. Beispiel für test_edge_enhancement edge=0.

test_edge_enhancement edge=1 example

Abbildung 109: Beispiel für test_edge_enhancement edge=1 (schneller Modus).

test_edge_enhancement edge=2 example

Abbildung 110: Beispiel für test_edge_enhancement edge=2 (Modus „Hohe Qualität“).

test_flip_mirror

Prüft, ob das Bild gemäß 7.5.2 Frontkamera im CDD richtig ausgerichtet ist.

Gespiegelte, gedrehte oder auf den Kopf gestellte Bilder können anhand des Diamantsymbols in der Nähe der Mitte erkannt werden.

Bestanden:Das Bild wurde nicht gespiegelt, gedreht oder umgedreht.

Beispiel für einen Szenen-Patch für test_flip_mirror

Abbildung 111. Beispiel für einen test_flip_mirror-Szenenpatch.

test_imu_drift

Prüft, ob die Inertial Measurement Unit (IMU) 30 Sekunden lang stabile Ausgaben liefert, während das Gerät still steht und eine HD-Vorschau aufgenommen wird.

Getestete APIs:

Bestanden:

Die Drift des Gyroskops beträgt über den Testzeitraum weniger als 0,01 rad.
Die Varianz des Gyroskopsignals liegt während des Testzeitraums unter 1E-7 rad²/s²/Hz.
Die Abweichung des Rotationsvektors beträgt über den Testzeitraum weniger als 0,01 rad.
(Noch nicht vorgeschrieben) Die Drift des Gyroskops beträgt weniger als 1 Grad pro Sekunde.

test_imu_drift – Beispiel für Gyroskopdrift

Abbildung 112. Beispiel für die Gyroskop-Drift von test_imu_drift.

Beispiel für Drift des Rotationsvektors in „test_imu_drift“

Abbildung 113. Beispiel für den Test-IMU-Drift-Rotationsvektor.

test_landscape_to_portrait

Prüft, ob die Überschreibung von Quer- zu Hochformat für Sensoren im Querformat richtig funktioniert.

Getestete APIs:

Bestanden:Im Test wird ein Diagramm mit der erwarteten Drehung gefunden (0 Grad, wenn die Überschreibung von Quer- zu Hochformat deaktiviert ist, 90 Grad, wenn sie aktiviert ist).

Beispiel für test_landscape_to_portrait

Abbildung 114. Beispiel für test_landscape_to_portrait.

test_lens_movement_reporting

Prüft, ob das Flag für die Objektivbewegung richtig gemeldet wird. Es werden 24 Bilder in Serie aufgenommen, wobei die ersten 12 Bilder die optimale Fokusdistanz (ermittelt durch 3A) und die letzten 12 Bilder die minimale Fokusdistanz haben. Um Bild 12 herum bewegt sich das Objektiv, wodurch die Schärfe abnimmt. Die Schärfe stabilisiert sich schließlich, wenn sich das Objektiv in der endgültigen Position befindet.

Das Flag für die Objektivbewegung sollte in allen Frames gesetzt werden, in denen die Schärfe zwischen der Schärfe in den ersten Frames mit dem Objektiv in der optimalen Brennweite und der Schärfe in den letzten Frames mit dem Objektiv in der minimalen Brennweite liegt. Die genaue Position, an der sich das Objektiv bewegt, ist nicht wichtig. Wichtig ist, dass das Bewegungsflag gesetzt wird, wenn sich das Objektiv bewegt.

Getestete APIs:

Bestanden:Das Flag für die Objektivbewegung ist im Frame mit der Schärfeänderung True.

Fehlermechanismen:

lens_moving: True (android.hardware.camera2.CaptureResult#LENS_STATE = 1) in test_log.DEBUG wird nur in Frames bestätigt, in denen sich die Schärfe nicht ändert.
Frames mit lens_moving: False (android.hardware.camera2.CaptureResult#LENS_STATE = 0) in test_log.DEBUG weisen einen Schärfeunterschied zu den ersten Frames bei optimaler Brennweite oder den letzten Frames bei minimaler Brennweite auf.

test_reprocess_edge_enhancement

Testet, ob die unterstützten Methoden zur Neubearbeitung für die Kantenglättung ordnungsgemäß funktionieren. Verarbeitet eine Erfassungsanfrage mit einem bestimmten Edge-Modus für die Neubearbeitung und vergleicht verschiedene Modi mit deaktivierten Edge-Modi für die Neubearbeitung.

Getestete APIs:

Bestanden:Die Schärfe für die verschiedenen Kantenmodi ist korrekt. HQ (Modus 2) ist schärfer als OFF (Modus 0). Die Verbesserung zwischen den verschiedenen Modi ist ähnlich.

Beispiel für das Diagramm „test_reprocess_edge_enhancement“

Abbildung 115. Beispiel für ein Diagramm für test_reprocess_edge_enhancement.

Szene 4

scene4 besteht aus einem schwarzen Kreis auf weißem Hintergrund in einem Quadrat.

Tests in scene4 können empfindlich auf die Ausrichtung reagieren. Ab Android 15 können Sie daher check_alignment.py im Tools-Verzeichnis verwenden, um die Ausrichtung des DUT und des Charts zu prüfen.

scene4-Beispiel

Abbildung 116. Beispiel für scene4.

test_30_60fps_preview_fov_match

Tests, bei denen Vorschauvideos mit 30 FPS und 60 FPS dasselbe Sichtfeld haben. Beim Test werden zwei Videos aufgenommen, eines mit 30 fps und eines mit 60 fps. Aus jedem Video wird ein repräsentativer Frame ausgewählt und analysiert, um zu prüfen, ob die Änderungen des Sichtfelds in den beiden Videos den Spezifikationen entsprechen. Tests, ob das Seitenverhältnis des Kreises konstant bleibt, der Mittelpunkt des Kreises stabil bleibt und der Radius des Kreises konstant bleibt.

Getestete APIs:

Bestanden:Bilder werden nicht gestreckt, die Mitte der Bilder weicht nicht mehr als 3 % ab und die maximale Änderung des Seitenverhältnisses zwischen Videos mit 30 fps und 60 fps beträgt höchstens 7,5 %.

Fehlermechanismen:

Der Kreis im Video mit 30 fps unterscheidet sich deutlich in der Größe vom Kreis im Video mit 60 fps.
Der Kreis auf dem aufgenommenen Bild ist durch die Verarbeitungspipeline verzerrt.
Der Kreis im aufgenommenen Bild wird aufgrund eines extremen Seitenverhältnisses der Aufnahmeanfrage abgeschnitten, wodurch die Höhe oder Breite des Bildes reduziert wird.
Der Kreis auf dem aufgenommenen Bild hat eine Spiegelung in der Mitte und ist nicht vollständig gefüllt.

test_aspect_ratio_and_crop

Prüft, ob Bilder in der Bildpipeline verzerrt oder unerwartet zugeschnitten werden. Macht Fotos von einem Kreis in allen Formaten. Prüft, ob der Kreis verzerrt ist, sich vom Bildmittelpunkt entfernt und seine Größe bei unterschiedlichen Seitenverhältnissen oder Auflösungen nicht falsch ändert.

Getestete APIs:

Bestanden:Bilder werden nicht gestreckt, die Bildmitte weicht nicht um mehr als 3 % ab und das maximal mögliche Sichtfeld wird beibehalten.

Fehlermechanismen:

Die Kamera ist nicht auf den Kreis ausgerichtet, der auf dem Tablet in der Mitte der aufgenommenen Szene angezeigt wird.
Der Kreis auf dem aufgenommenen Bild ist durch die Verarbeitungspipeline verzerrt.
Das Bild mit der niedrigeren Auflösung wird in der Bildverarbeitung zweimal zugeschnitten, wodurch sich das Sichtfeld zwischen Bildern mit hoher und niedriger Auflösung unterscheidet.
Der Kreis im aufgenommenen Bild wird aufgrund eines extremen Seitenverhältnisses der Aufnahmeanfrage abgeschnitten, wodurch die Höhe oder Breite des Bildes reduziert wird.
Der Kreis auf dem aufgenommenen Bild hat eine Spiegelung in der Mitte und ist nicht vollständig gefüllt.

test_multi_camera_alignment

Testet die Parameter für die Kamerakalibrierung in Bezug auf die Kamerapositionierung für Systeme mit mehreren Kameras. Mit den physischen Unterkameras für mehrere Kameras wird ein Bild mit einer der physischen Kameras aufgenommen. Bestimmt den Kreismittelpunkt. Projiziert den Mittelpunkt des Kreises für jede Kamera auf die Weltkoordinaten. Vergleicht den Unterschied zwischen den Kreismittelpunkten der Kameras in Weltkoordinaten. Die Weltkoordinate wird zurück in Pixelkoordinaten projiziert und mit den Originalkoordinaten verglichen, um die Gültigkeit zu prüfen. Vergleicht die Kreisgrößen, um festzustellen, ob sich die Brennweiten der Kameras unterscheiden.

Getestete APIs:

Bestanden:Die Kreismittelpunkte und -größen in den projizierten Bildern entsprechen den erwarteten Werten im Vergleich zu den mit Kamera-Kalibrierungsdaten und Brennweiten aufgenommenen Bildern.

Fehlermechanismen:

LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION und LENS_POSE_ROTATION sind Designwerte und keine tatsächlichen Kalibrierungsdaten.
Das Kamerasystem ist für die Testkonfiguration nicht geeignet, z. B. wenn ein Weitwinkel- und ein Ultraweitwinkelkamerasystem mit dem RFoV-Prüfstand getestet werden. Weitere Informationen finden Sie unter Camera ITS-in-a-box – FAQs, Frage 1.

test_preview_aspect_ratio_and_crop

Ähnlich wie beim test_aspect_ratio_and_crop-Test für Standbilder werden die unterstützten Vorschauformate geprüft, um sicherzustellen, dass die Vorschaubilder nicht unangemessen gestreckt oder zugeschnitten werden. Prüft, ob sich das Seitenverhältnis des Kreises ändert, ob der Kreis auf den zugeschnittenen Bildern in der Mitte des Frames bleibt und ob sich die Größe des Kreises bei einem konstanten Format oder bei unterschiedlichen Auflösungen ändert (FoV-Prüfung).

Getestete APIs:

Bestanden:Bilder werden nicht gestreckt, die Bildmitte weicht nicht um mehr als 3 % ab und das maximal mögliche Sichtfeld wird beibehalten.

test_preview_stabilization_fov

Prüft die unterstützten Vorschaubilder, um sicherzustellen, dass das Sichtfeld richtig zugeschnitten wird. Beim Test werden zwei Videos aufgenommen: eines mit der Vorschau-Stabilisierung ON und eines mit der Vorschau-Stabilisierung OFF. Aus jedem Video wird ein repräsentativer Frame ausgewählt und analysiert, um zu prüfen, ob die Änderungen des Sichtfelds in den beiden Videos den Spezifikationen entsprechen.

Getestete APIs:

Bestanden:Das Seitenverhältnis des Kreises bleibt ungefähr konstant, die Position des Kreismittelpunkts bleibt stabil und die Größe des Kreises ändert sich um nicht mehr als 20%.

test_video_aspect_ratio_and_crop

Erstellt Videos eines Kreises in einem Quadrat in allen Videoformaten. Extrahieren Sie die Keyframes und prüfen Sie, ob sich das Seitenverhältnis des Kreises ändert, die zugeschnittenen Bilder den Kreis in der Mitte behalten und sich die Kreisgröße bei einem konstanten Format oder bei unterschiedlicher Auflösung nicht ändert (FoV-Prüfung).

Getestete APIs:

Bestanden:Videobilder werden nicht gestreckt, die Mitte der Bilder weicht um nicht mehr als 3 % ab und das maximal mögliche Sichtfeld wird beibehalten.

scene5

Für scene5 ist eine gleichmäßig beleuchtete graue Szene erforderlich. Dies wird durch einen Diffusor erreicht, der über dem Kameraobjektiv angebracht ist. Wir empfehlen den folgenden Diffusor: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

Bringen Sie einen Diffusor vor der Kamera an und richten Sie die Kamera auf eine Lichtquelle mit etwa 2.000 Lux aus. Für Bilder, die für scene5 aufgenommen werden, ist eine diffuse Beleuchtung ohne sichtbare Merkmale erforderlich. Hier ist ein Beispielbild:

scene5 example

Abbildung 117: Beispiel für die Aufnahme von Szene 5.

Da für diese Szene keine Tablets oder Controller erforderlich sind, wird das Testbed TEST_BED_MANUAL verwendet. Ein Beispiel finden Sie unter config.yml-Datei für manuelle Tests. Die Standarddatei config.yml enthält TEST_BED_MANUAL nicht, aber Sie können die Datei ändern, um sie einzufügen.

test_lens_shading_and_color_uniformity

Prüft, ob die Korrektur der Objektivschattierung richtig angewendet wird und die Farbe einer monochromen, einheitlichen Szene gleichmäßig verteilt ist. Führt diesen Test auf einem YUV-Frame mit automatischer 3A durch. Die Objektivschattierung wird anhand des Y-Kanals bewertet. Misst den durchschnittlichen y-Wert für jeden angegebenen Sample-Block und bestimmt „Bestanden“ oder „Nicht bestanden“ durch Vergleich mit dem mittleren y-Wert. Der Test zur Farbgleichmäßigkeit wird im Rot-Grün- und Blau-Grün-Raum durchgeführt.

Getestete APIs:

Bestanden:Im angegebenen Radius des Bildes muss die Varianz des Rot-Grün- und Blau-Grün-Werts unter 20% liegen, damit der Test bestanden wird.

scene6

scene6 ist ein Raster eindeutig identifizierbarer ArUco-Marker. Tests in scene6 können empfindlich auf die Ausrichtung reagieren. Ab Version 15 können Sie daher check_alignment.py im Tools-Verzeichnis verwenden, um die Ausrichtung des zu testenden Geräts und des Diagramms zu prüfen.

scene6

Abbildung 118. Beispiel für scene6.

test_in_sensor_zoom

Testet das Verhalten der In-Sensor-Zoomfunktion der Kamera, die zugeschnittene Rohbilder erzeugt.

Wenn der Stream-Anwendungsfall auf CROPPED_RAW eingestellt ist, werden im Test zwei Aufnahmen über den Zoom-Bereich hinweg gemacht: ein Rohbild mit vollem Sichtfeld und ein zugeschnittenes Rohbild. Beim Test werden die Bilder in RGB-Arrays konvertiert, das zugeschnittene Rohbild in voller Größe wird auf die von SCALER_RAW_CROP_REGION gemeldete Größe herunterskaliert und der 3D-RMS-Unterschied zwischen den beiden Bildern wird berechnet.

Getestete APIs:

Bestanden:Der 3D-RMS-Unterschied zwischen dem herunterskalierten, zugeschnittenen Rohbild und dem Rohbild mit dem vollen Sichtfeld ist geringer als der im Test festgelegte Grenzwert.

test_zoom

Testet das Zoomverhalten der Kamera vom Ultraweitwinkelobjektiv zum Weitwinkelobjektiv. Macht Aufnahmen über den gesamten Zoombereich und prüft, ob die ArUco-Marker größer werden, wenn die Kamera heranzoomt. Außerdem wird geprüft, ob sich die Position der Mittelmarkierung bei jeder Aufnahme vorhersagbar ändert. Der Abstand vom Mittelpunkt der Zentermarkierung zum Bildmittelpunkt kann sich entweder mit einer konstanten Rate in Bezug auf das Zoomverhältnis ändern, bis ein physischer Kamerawechsel erfolgt, oder er kann sich nach einem physischen Kamerawechsel monoton in Richtung der Position derselben Markierung ändern. Die Jetpack Camera App (JCA) muss vor dem Testen auf dem Gerät installiert werden.

Getestete APIs:

Bestanden:Die relative Größe des erfassten ArUco-Markers stimmt mit dem angeforderten Zoomverhältnis überein. So wird überprüft, ob die Kamera richtig zoomt und sich der Abstand des Markers zum Bildmittelpunkt gemäß den in der Testbeschreibung angegebenen Kriterien ändert.

test_zoom, um die Kontur der ArUco-Markierung zu finden, die dem Mittelpunkt am nächsten ist

Abbildung 119: Mit „test_zoom“ wird die Kontur der ArUco-Markierung ermittelt, die dem Mittelpunkt am nächsten ist.

test_low_latency_zoom

Testet das Zoomverhalten der Kamera bei niedriger Latenz. Erstellt Aufnahmen über den Zoom-Bereich mit android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) und prüft, ob die Markierungen in den Ausgabebildern mit den Zoomfaktoren in den Aufnahmemetadaten übereinstimmen. Dieselbe Kameraaufnahmesitzung wird verwendet, um 3A zu konvergieren und Aufnahmen zu machen.

Getestete APIs:

Bestanden:Die relative Größe des erfassten Markers stimmt mit den Metadaten des Zoomverhältnisses überein.

test_preview_video_zoom_match

Tests, bei denen während der Aufnahme und des Zoomens die Videovorschau und die Videoausgabe dieselbe Ausgabe anzeigen und aufzeichnen. Berechnet die Größe der Markierung, die dem Mittelpunkt am nächsten ist, bei verschiedenen Zoomverhältnissen und prüft, ob die Größe der Markierung mit dem Zoomverhältnis zunimmt.

Getestete APIs:

Bestanden:Die relative Größe des erfassten Markers stimmt mit dem angeforderten Zoomfaktor im Video und in der Vorschau überein.

Abbildung 120. HD_1280x720_key_frame.png (vor dem Zoomen).

Abbildung 121: preview_1280x720_key_frame.png (vor dem Zoomen).

Abbildung 122. HD_1280x720_key_frame.png (nach dem Zoomen).

Abbildung 123. preview_1280x720_key_frame.png (nach dem Zoomen).

test_preview_zoom

Es wird geprüft, ob das Zoomverhältnis jedes Vorschau-Frames den entsprechenden Aufnahmemetadaten vom Ultraweitwinkelobjektiv zum Weitwinkelobjektiv entspricht. Beim Test werden Vorschaubilder über den Zoom-Bereich hinweg aufgenommen und die ArUco-Markierung ermittelt, die sich am nächsten am Mittelpunkt befindet. Anschließend wird geprüft, ob sich die Position der Markierung in der Mitte bei jeder Aufnahme vorhersagbar ändert. Der Abstand vom Mittelpunkt der Zentermarkierung zum Bildmittelpunkt kann sich entweder mit einer konstanten Rate in Bezug auf das Zoomverhältnis ändern, bis ein physischer Kamerawechsel erfolgt, oder er kann sich nach einem physischen Kamerawechsel monoton in Richtung der Position derselben Markierung ändern.

Getestete APIs:

Bestanden:Die relative Größe des ausgewählten ArUco-Markers ist für das gemeldete Zoomverhältnis des entsprechenden Aufnahmeergebnisses für alle Vorschau-Frames korrekt. Die relative Entfernung der ausgewählten Markierung vom Bildmittelpunkt ist für das angegebene Zoomverhältnis des entsprechenden Aufnahmeergebnisses aller Vorschauframes genau.

test_preview_zoom-Bilder mit ausgewählter Markierung in der Nähe der Mitte

Abbildung 124. test_preview_zoom-Bilder mit ausgewählter Markierung, die sich am nächsten am Mittelpunkt befindet

test_session_characteristics_zoom

Testet den Zoombereich für alle unterstützten Sitzungskonfigurationen, die in CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION aufgeführt sind. Für jede dieser Konfigurationen wird geprüft, ob der in CameraDeviceSetup#getSessionCharacteristics zurückgegebene Zoombereich erreicht werden kann, wenn CameraDeviceSetup#isSessionConfigurationSupported den Wert true zurückgibt.

Getestete APIs:

Bestanden:Sowohl das minimale als auch das maximale Zoomverhältnis kann für jedes unterstützte SessionConfiguration erreicht werden, das in CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION aufgeführt ist.

scene7

scene7 ist ein rechteckiger Rahmen, der in vier gleich große Quadranten unterteilt ist, die jeweils mit einer anderen Farbe gefüllt sind. In der Mitte des Rechtecks befindet sich ein schräges Kantendiagramm für Schärfeprüfungen. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um genaue Koordinaten des Hauptrechteckrahmens bei unterschiedlichen Zoomfaktoren zu erhalten.

scene7

Abbildung 125. scene7.

test_multi_camera_switch

Bei diesem Test wird überprüft, ob beim Aufzeichnen einer Vorschau bei unterschiedlichen Zoomfaktoren der Wechsel zwischen dem Ultraweitwinkel- (UW) und dem Weitwinkelobjektiv (W) zu ähnlichen RGB-Werten führt.

Beim Test werden verschiedene Zoomfaktoren innerhalb des vordefinierten Bereichs verwendet, um eine dynamische Vorschauaufzeichnung durchzuführen und den Punkt zu ermitteln, an dem sich die physische Kamera ändert. Dieser Punkt markiert den Übergang vom Ultraweitwinkel- zum Weitwinkelobjektiv.

Die Frames, die am und vor dem Crossover-Punkt aufgenommen wurden, werden auf automatische Belichtung (AE), automatischen Weißabgleich (AWB) und Autofokus (AF) analysiert.

Bei der AE-Prüfung wird geprüft, ob die Änderung der Luminanz sowohl bei Bildern mit Ultraweitwinkel- als auch mit Weitwinkelobjektiv im erwarteten Bereich liegt. Beim AWB-Check wird geprüft, ob die Verhältnisse von Rot zu Grün und Blau zu Grün sowohl für UW- als auch für W-Objektivbilder innerhalb der Grenzwerte liegen. Beim AF-Check wird der Schärfe-Schätzwert anhand der durchschnittlichen Gradientenstärke zwischen UW- und W-Objektivbildern bewertet.

Wenn der Moiré-Effekt die Ergebnisse dieses Tests beeinträchtigt, verwenden Sie ein Tablet mit höherer Auflösung aus der Liste der von Camera ITS zugelassenen Tablets.

Getestete APIs:

Bestanden:Der Test gilt als bestanden, wenn die Prüfungen für AE und AWB bestanden wurden. Die Ergebnisse der AF-Prüfung werden nur zu Protokollierungszwecken verwendet. Im Folgenden finden Sie die Kriterien für die einzelnen Prüfungen:

AE-Prüfung: Die Änderung des Helligkeitswerts (Y-Wert) zwischen den Bildern des Ultraweitwinkel- und des Weitwinkelobjektivs muss für alle Farbfelder weniger als 4% betragen, wenn das Gerät sowohl ae_regions als auch awb_regions unterstützt. Wenn nur ae_regions unterstützt wird, müssen nur die Werte des grauen Farbfelds die Kriterien erfüllen.
AWB-Prüfung: Der Unterschied zwischen den Rot-Grün- und Blau-Grün-Werten für die Bilder des Ultraweitwinkel- und Weitwinkelobjektivs muss für das graue Farbfeld weniger als 3% und für andere Farbfelder weniger als 10% betragen, wenn das Gerät sowohl ae_regions als auch awb_regions unterstützt.
AF-Prüfung: Die Bildschärfe bei der Aufnahme mit dem Weitwinkelobjektiv muss höher sein als bei der Aufnahme mit dem Ultraweitwinkelobjektiv.

test_multi_camera_switch_gray_uw_y

Abbildung 126. Graues Feld, aufgenommen mit dem Ultraweitwinkelobjektiv.

test_multi_camera_switch_gray_w_y

Abbildung 127. Grauer Bereich, aufgenommen mit dem Weitwinkelobjektiv

scene8

scene8 ist ein rechteckiger Rahmen, der in vier gleich große Bereiche unterteilt ist. Jeder Bereich enthält ein Porträt, das mit einer anderen Belichtung aufgenommen oder mit einem anderen Farbton überlagert wurde (blauer Farbton, erhöhte Belichtung, verringerte Belichtung, gelber Farbton). Vier ArUco-Marker sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um genaue Koordinaten des Hauptrechteckrahmens zu erhalten.

scene8 example

Abbildung 128. Beispiel für scene8.

test_ae_awb_regions

Tests that the RGB and luma values differ when preview recording at different AE and AWB regions.

Beim Test wird eine 8‑Sekunden-Vorschauaufnahme erstellt. Dabei werden die AE- und AWB-Messung für jeweils 2 Sekunden in jedem Quadranten durchgeführt. Anschließend wird aus der Vorschauaufzeichnung jeder Region ein Frame extrahiert und anhand der extrahierten Frames werden die folgenden AE- und AWB-Prüfungen durchgeführt:

AE-Prüfung: Es wird geprüft, ob das Frame, in dem die Region mit verringerter Belichtung gemessen wird, einen um mehr als 1% erhöhten Luminanzwert aufweist als das Frame, in dem die Region mit erhöhter Belichtung gemessen wird. So wird überprüft, ob Bilder aufgehellt werden, wenn eine dunkle Region gemessen wird.
AWB-Prüfung: Es wird geprüft, ob das Verhältnis von Rot zu Blau (der durchschnittlichen RGB-Werte des Bildes) im Frame mit dem blauen Messbereich mehr als 2 % höher ist als im Frame mit dem gelben Messbereich. So wird sichergestellt, dass Bilder einen ausgeglichenen RGB-Wert haben, wenn eine gelbe (warme) oder blaue (kühle) Region gemessen wird.

Getestete APIs:

Bestanden:Die Prüfungen für AE und AWB werden beide bestanden.

test_ae_awb_regions_dark_region

Abbildung 129. Bildmessung in einem dunklen Bereich mit erhöhter Belichtung.

test_ae_awb_regions_light_region

Abbildung 130. Heller Bereich mit verringerter Belichtung.

Fehlermechanismen:

Für diesen Test ist es wichtig, dass alle vier ArUco-Marker korrekt erkannt werden. Wenn die erste Erkennung fehlschlägt, versucht das System einen zweiten Erkennungsdurchlauf mit einer Schwarz-Weiß-Version des Bildes. Das folgende Graustufenbild stellt den sekundären Verarbeitungsschritt dar:

Abbildung 131. ArUco-Markierungen sind nicht richtig ausgerichtet.

test_color_correction_mode_cct

Tests COLOR_CORRECTION_MODE bei verschiedenen Farbtemperaturen und ‑tönungen, wobei Änderungen der RGB-Verhältnisse im Vergleich zur Aufnahmeszene scene8 überprüft werden.

Getestete APIs:

Bestanden:Die RGB-Verhältnisse weisen die erwarteten Steigerungen oder Senkungen im Vergleich zu den ausgewählten Farbtemperaturen und ‑tönungen auf.

Kriterien zum Überspringen von Tests

Der test_color_correction_mode_cct-Test wird übersprungen, wenn eines der folgenden Kriterien erfüllt ist:

Das Gerät hat ein erstes API‑Level (first_api_level) von 35 oder niedriger.
Das Gerät bewirbt COLOR_CORRECTION_MODE_CCT nicht in COLOR_CORRECTION_AVAILABLE_ABERRATION_MODES.

scene9

scene9 besteht aus Tausenden von Kreisen mit zufälliger Größe und Farbe, um eine Szene mit sehr geringer Wiederholbarkeit zu erstellen und JPEG-Komprimierungsalgorithmen zu belasten.

scene9 example

Abbildung 132. Beispiel für scene9.

test_jpeg_high_entropy

Tests, die prüfen, ob die JPEG-Komprimierung der Kamera auf scene9 mit hoher Entropie und dem JPEG-Qualitätsfaktor auf 100 % funktioniert. Der Zoomfaktor wird erhöht, um zu prüfen, ob die auf dem Tablet angezeigte Szene das Sichtfeld der Kamera ausfüllt.

Getestete APIs:

Bestanden:Die JPEG-Datei wurde ordnungsgemäß komprimiert, geschrieben und von der Festplatte gelesen.

test_jpeg_quality

Testet die JPEG-Komprimierungsqualität der Kamera. Die JPEG-Qualitäten werden durch android.jpeg.quality gesteuert und es wird geprüft, ob sich die Quantisierungstabellen richtig ändern.

Getestete APIs:

Bestanden:Die Quantisierungsmatrix nimmt mit zunehmender Qualität ab. Die Matrix stellt den Teilungsfaktor dar.

Durchschnittliche DQT-Matrix für Luma und Chroma der Rückkamera des Pixel 4 im Vergleich zur JPEG-Qualität

Abbildung 133. Durchschnittliche DQT-Matrix für Helligkeit und Chroma der Rückkamera des Pixel 4 im Vergleich zur JPEG-Qualität.

Beispiel für einen fehlgeschlagenen test_jpeg_quality-Test

Abbildung 134. Beispiel für einen fehlgeschlagenen Test.

Hinweis : Bei Bildern mit sehr niedriger Qualität (jpeg.quality < 50) wird die Komprimierung in der Quantisierungsmatrix nicht erhöht.

scene_video

scene_video ist eine Videoszene mit vier verschiedenfarbigen Kreisen, die sich mit unterschiedlichen Bildraten vor einem weißen Hintergrund hin und her bewegen.

Abbildung 135. Beispiel für „scene_video“.

test_preview_frame_drop

Tests, bei denen die angeforderte Vorschau-Bildrate bei einer dynamischen Szene beibehalten wird. Dieser Test wird auf allen Kameras ausgeführt, die für Drittanbieter-Apps verfügbar sind.

Getestete APIs:

Bestanden:Die Vorschau-Bildrate liegt am oberen Ende des angeforderten Bildratenbereichs und die durchschnittliche Abweichung zwischen aufeinanderfolgenden Frames ist geringer als die im Test festgelegte relative Toleranz.

scene_extensions

Die scene_extensions-Tests sind für Kameraerweiterungen vorgesehen und müssen mit Camera ITS-in-a-Box durchgeführt werden, da sie eine präzise Steuerung der Testumgebung erfordern. Außerdem muss jeglicher Lichteinfall verhindert werden. Dazu müssen Sie möglicherweise das Testgerät, das zu testende Gerät und das Tablet mit einem Abdecktuch abdecken und Lichtlecks vom Frontdisplay des zu testenden Geräts beseitigen.

scene_hdr

Die scene_hdr-Szene besteht aus einem Porträt auf der linken Seite und einem QR-Code mit geringem Kontrast auf der rechten Seite.

scene_hdr

Abbildung 136. Beispiel für scene_hdr.

test_hdr_extension

Testet die HDR-Erweiterung. Es werden Aufnahmen mit und ohne aktivierte Erweiterung gemacht und geprüft, ob die Erweiterung den QR-Code besser erkennbar macht.

Getestete APIs:

Bestanden:Die HDR-Erweiterung reduziert die Anzahl der Kontraständerungen, die zum Erkennen des QR-Codes erforderlich sind, oder verringert den Farbverlauf über den QR-Code hinweg.

scene_low_light

Die Szene scene_low_light besteht aus einem Raster aus Quadraten in verschiedenen Grautönen auf einem schwarzen Hintergrund. Das Raster aus Quadraten ist von einer roten Umrisslinie umgeben. Die Quadrate sind in einer Hilbert-Kurve angeordnet.

scene_low_light-Beispiel

Abbildung 137. Beispiel für „scene_low_light“.

test_night_extension

Testet die Night-Erweiterung. Erstellt Aufnahmen mit aktivierter Erweiterung und führt Folgendes aus:

Erkennt das Vorhandensein von 20 Quadraten
Berechnet die Helligkeit, die durch jedes Quadrat begrenzt wird.
Berechnet den durchschnittlichen Luminanzwert der ersten 6 Quadrate gemäß der Ausrichtung des Hilbert-Kurvenrasters.
Berechnet die Differenz des Luminanzwerts aufeinanderfolgender Quadrate (z. B. Quadrat 2 – Quadrat 1) bis zu Quadrat 5 und Quadrat 6 (Quadrat 6 – Quadrat 5) und ermittelt den Durchschnitt der fünf berechneten Differenzen.

Bei Geräten mit Android 16 oder höher enthält die Aufnahmeanfrage eine abgerechnete Region, die dem Rechteck entspricht, das das Raster der Quadrate umgibt. Durch diese Ergänzung ändern sich die Kriterien für das Bestehen des Schwellenwerts.

Getestete APIs:

Bestanden:

Bei Geräten mit Android 16 oder höher muss der durchschnittliche Helligkeitswert der ersten sechs Quadraten mindestens 80 betragen und der durchschnittliche Unterschied im Helligkeitswert aufeinanderfolgender Quadrate bis zu Quadrat 5 und Quadrat 6 muss mindestens 18,75 betragen.
Bei Geräten mit Android 15 und niedriger muss der durchschnittliche Helligkeitswert der ersten sechs Quadraten mindestens 85 betragen und die durchschnittliche Differenz des Helligkeitswerts aufeinanderfolgender Quadrate bis zu Quadrat 5 und 6 muss mindestens 17 betragen.

Das folgende Luminanzdiagramm zeigt, wie ein bestandener Test aussieht.

Beispiel für eine bestandene Prüfung einer Nachtszene bei wenig Licht

Abbildung 138. Beispiel für eine bestandene Prüfung einer Nachtszene bei schwachem Licht.

test_low_light_boost_extension

Testet den Low Light Boost-AE-Modus. Wenn Camera2 den AE-Modus „Low Light Boost“ unterstützt, wird dieser Test für Camera2 ausgeführt. Wenn die Kameraerweiterung „Nachtmodus“ unterstützt wird und der AE-Modus „Low Light-Modus“ unterstützt wird, wird dieser Test auch für die Kameraerweiterung „Nachtmodus“ durchgeführt. Bei diesem Test wird der AE-Modus auf „Low Light Boost“ (Verstärkung bei wenig Licht) eingestellt, ein Frame aus der Vorschau aufgenommen und Folgendes ausgeführt:

Erkennt das Vorhandensein von 20 Kisten
Berechnet die Luminanz, die durch die einzelnen Felder begrenzt wird.
Berechnet den durchschnittlichen Luminanzwert der ersten 6 Quadrate gemäß der Ausrichtung des Hilbert-Kurvenrasters.
Berechnet die Differenz des Luminanzwerts aufeinanderfolgender Quadrate (z. B. Quadrat 2 – Quadrat 1) bis zu Quadrat 5 und Quadrat 6 (Quadrat 6 – Quadrat 5) und ermittelt den Durchschnitt der fünf berechneten Differenzen.

Getestete APIs:

Bestanden:

Bei Geräten mit Android 16 oder höher muss der durchschnittliche Helligkeitswert der ersten sechs Quadraten mindestens 54 betragen und die durchschnittliche Differenz des Helligkeitswerts aufeinanderfolgender Quadrate bis zu Quadrat 5 und 6 muss mindestens 17 betragen.
Bei Geräten mit Android 15 und niedriger muss der durchschnittliche Helligkeitswert der ersten sechs Quadraten mindestens 70 betragen und der durchschnittliche Unterschied im Helligkeitswert aufeinanderfolgender Quadrate bis zu Quadrat 5 und 6 muss mindestens 18 betragen.

scene_tele

Eine wichtige Voraussetzung für scene_tele-Tests ist, dass der Abstand des Testbilds mindestens dem Mindestfokussierungsabstand des Teleobjektivs entsprechen muss. Da dieser Mindestfokusabstand je nach Gerät variieren kann, müssen Sie Ihr Setup an die jeweilige Telekamera anpassen.

scene_tele-Einrichtung basierend auf der Fokusentfernung der Weitwinkel- und Telekamera

Abbildung 139: Einrichtung von „scene_tele“ basierend auf der Fokusentfernung der Weitwinkel- und Telekamera.

Weitere Informationen zur Einrichtung der Testhardware finden Sie unter Einrichtung des Tele-Verlängerungs-Rigs.

scene6_tele

Die scene6_tele-Szene besteht aus einem Raster von ArUco-Markern auf einem weißen Hintergrund.

Wenn die Aufnahmen mit dem modularen Rig überbelichtet aussehen, entfernen Sie die Frontplatte des modularen Rigs.scene6_tele

Trennen Sie die WFoV-Testvorrichtung von der Verlängerung und entfernen Sie die Smartphone-Halterung.

Abbildung 140. Trennen Sie die WFoV-Testvorrichtung von der Verlängerung und entfernen Sie die Smartphone-Halterung.

remove_front_plate

Abbildung 141. Entferne die Frontplatte.

test_zoom_tele

Testet das Zoomverhalten der Kamera vom Weitwinkel- zum Teleobjektiv. Der Test ist identisch mit test_zoom, testet aber das Zoomverhalten der Kamera vom Weitwinkel- zum Teleobjektiv.

Getestete APIs:

Bestanden:Die relative Größe der erfassten ArUco-Markierung stimmt mit dem angeforderten Zoomverhältnis überein. So wird überprüft, ob die Kamera richtig zoomt. Der Abstand der Markierung zur Bildmitte ändert sich gemäß den Kriterien in test_zoom.

test_preview_zoom_tele

Testet das Zoomverhalten der Kamera für Vorschaubilder vom Weitwinkelobjektiv zum Teleobjektiv. Der Test ist identisch mit test_preview_zoom, testet aber das Verhalten des Kamerazooms für Vorschaubilder vom Weitwinkelobjektiv zum Teleobjektiv.

Getestete APIs:

Bestanden:Die relative Größe des erfassten ArUco-Markers entspricht dem angeforderten Zoomfaktor. So wird überprüft, ob die Kamera richtig zoomt und der Abstand des Markers zur Bildmitte sich gemäß den Kriterien in test_preview_zoom ändert.

scene7_tele

scene7_tele ist identisch mit scene7, wurde aber für Tests mit dem Teleobjektiv eingerichtet. Es ist ein rechteckiger Rahmen, der in vier gleich große Quadranten unterteilt ist, die jeweils mit einer anderen Farbe gefüllt sind. In der Mitte des Rechtecks befindet sich ein schräges Kantendiagramm für Schärfeprüfungen. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um genaue Koordinaten des Hauptrechteckrahmens bei unterschiedlichen Zoomfaktoren zu erhalten.

test_multi_camera_switch_tele

Bei diesem Test wird geprüft, ob beim Aufzeichnen einer Vorschau bei unterschiedlichen Zoomfaktoren der Wechsel zwischen dem Weitwinkel- (W) und dem Teleobjektiv (Tele) zu ähnlichen RGB-Werten führt.

Die Frames, die am und vor dem Crossover-Punkt aufgenommen wurden, werden auf AE, AWB und AF analysiert.

Bei der AE-Prüfung wird geprüft, ob die Änderung der Helligkeit sowohl bei Weitwinkel- als auch bei Teleobjektivbildern im erwarteten Bereich liegt. Bei der AWB-Prüfung wird überprüft, ob die Verhältnisse von Rot zu Grün und Blau zu Grün sowohl bei Weitwinkel- als auch bei Teleobjektivbildern innerhalb der Grenzwerte liegen. Beim AF-Check wird der Schärfe-Schätzwert anhand der durchschnittlichen Gradientenstärke zwischen Weitwinkel- und Teleobjektivbildern bewertet.

Getestete APIs:

Bestanden:Damit der Test bestanden wird, müssen alle AE-, AWB- und AF-Prüfungen bestanden werden. Im Folgenden finden Sie die Kriterien für die einzelnen Prüfungen:

AE-Prüfung: Die Luma-Änderung zwischen den Bildern der Weitwinkel- und Telekamera muss weniger als 4 % betragen.
AWB-Prüfung: Im LAB-Farbraum darf der Delta-C-Wert zwischen Rot-Grün und Blau-Grün für Weitwinkel- und Teleobjektive nicht mehr als 10 betragen.
AF-Prüfung: Die Bildschärfe des Teleobjektivs muss höher sein als die des Weitwinkelobjektivs.

scene_flash

Für die scene_flash-Tests ist eine dunkle Szene im Sensor-Fusion-Kasten erforderlich.

test_auto_flash

Tests, bei denen der automatische Blitz in einer dunklen Szene für die Rück- und Frontkamera ausgelöst wird. Bei Frontkameras wird die Szene nicht durch einen physischen Blitz, sondern durch das Display beleuchtet. Bei diesem Test wird geprüft, ob der automatische Blitz ausgelöst wird. Dazu wird geprüft, ob die Mitte des Kachelbilds bei aktiviertem automatischen Blitz heller ist. Damit der automatische Blitz ausgelöst wird, muss die Beleuchtung im Prüfaufbau ausgeschaltet sein. Die Beleuchtung kann mit dem Arduino-Controller automatisch ausgeschaltet werden. Die Szene muss für den Test vollständig dunkel sein. Die Jetpack Camera App (JCA) muss vor dem Testen auf dem Gerät installiert werden. Der automatische Blitz für nach hinten gerichtete Kameras wird durch den AE-Status ausgelöst. Der automatische Blitz für nach vorn gerichtete Kameras wird jedoch nicht durch AE ausgelöst, sondern immer.

Getestete APIs:

Bestanden:Das Zentrum des Kachelbilds mit aktiviertem automatischen Blitz ist bei allen Kameras heller als das ursprüngliche Szenenbild.

test_flash_strength

Tests, mit denen geprüft wird, ob die Steuerung der Blitzstärke im Modus SINGLE korrekt implementiert ist.

Prüft, ob die Blitzstärke bei Verwendung der Kamera im SINGLE-Modus mit unterschiedlichen angeforderten Stärkeniveaus geändert wird, wenn das Gerät die Steuerung der Blitzstärke unterstützt. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der automatische Belichtungsmodus beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Wenn der Modus ON_AUTO_FLASH ist, hat die Blitzstärke keine Auswirkungen auf die Helligkeit.

Für den Test müssen die Lichter im Prüfstand ausgeschaltet sein. Die Lichter können mit dem Arduino-Controller automatisch ausgeschaltet werden. Die Szene muss vollständig dunkel sein, damit der Test richtig funktioniert.

Getestete APIs:

Bestanden:

Wenn der automatische Belichtungsmodus ON oder OFF ist, nimmt die Helligkeit der Bildbereiche mit zunehmender Blitzstärke von kein Blitz bis FLASH_SINGLE_STRENGTH_MAX_LEVEL zu. Wenn der Modus für die automatische Belichtung ON_AUTO_FLASH ist, liegt die Helligkeitsdifferenz der Bildbereiche innerhalb der Toleranz, wenn die Blitzstärke von kein Blitz bis FLASH_SINGLE_STRENGTH_MAX_LEVEL erhöht wird.

test_led_snapshot

Tests, ob die LED-Schnappschüsse das Bild nicht sättigen oder tönen.

Bei diesem Test wird der Sensor Fusion Box eine Beleuchtungssteuerung hinzugefügt, um die Beleuchtung zu steuern. Wenn die Beleuchtung auf OFF eingestellt ist, wird im Test eine Aufnahme mit dem Modus AUTO_FLASH auf ON gemacht. Während der Aufnahme wird eine Voraufnahmesequenz mit dem auf START eingestellten Trigger aePrecapture ausgeführt und die Aufnahmeabsicht auf Preview festgelegt, um die Aufnahme mit Blitz zu machen.

Da die Aufnahme aufgrund des Blitzes einen deutlichen Hotspot aufweist, wird im Test der Mittelwert des Blitzbilds der gesamten Aufnahme berechnet und geprüft, ob der Wert im Bereich (68, 102) liegt. Um zu prüfen, ob das Bild einigermaßen weißabgeglichen ist, werden die Rot-Grün- und Blau-Grün-Verhältnisse berechnet und geprüft, ob sie zwischen 0,95 und 1,05 liegen.

Getestete APIs:

Bestanden:Die Verhältnisse von Rot zu Grün und Blau zu Grün liegen zwischen 0,95 und 1,05. Der Mittelwert des Blitzbilds liegt im Bereich (68, 102).

test_night_mode_indicator

Testet die Funktionalität der Nachtmodus-Anzeige. Diese Funktion gibt an, ob die Kamera bei schlechten Lichtverhältnissen verwendet wird und ob eine Aufnahme mit der Kameraerweiterung „Nachtmodus“ sinnvoll ist. Diese Funktion ist nur auf Geräten verfügbar, die Kameraerweiterungen für den Nachtmodus unterstützen.

Bei diesem Test wird geprüft, ob die Anzeige für den Nachtmodus die Lichtverhältnisse während der Kameravorschau korrekt widerspiegelt. Der Test führt die folgenden Schritte aus:

Initialisierung:Im Test wird ein ItsSession initialisiert und es werden Kameraeigenschaften abgerufen. Außerdem wird eine Verbindung zum Beleuchtungscontroller hergestellt.
Überspringen von Bedingungen:Der Test wird übersprungen, wenn das Gerät das erforderliche API-Level oder die Funktion „Nachtmodus-Anzeige“ nicht unterstützt.
Camera2-Sitzung:
- Beim Test wird eine Vorschauaufnahmesitzung mit einer Camera2-Sitzung gestartet.
- Das Licht wird eingeschaltet und ein Vorschaubild wird aufgenommen.
- Bei diesem Test wird geprüft, ob sich die Anzeige für den Nachtmodus im Status OFF befindet.
- Das Licht wird ausgeschaltet und ein Vorschaubild wird aufgenommen.
- Bei diesem Test wird geprüft, ob sich die Anzeige für den Nachtmodus im Status ON befindet.
Sitzung zur Kameraerweiterung:
- Beim Test wird dasselbe Verfahren wie für die Camera2-Sitzung wiederholt, aber eine CameraExtension-Sitzung mit der Erweiterung EXTENSION_NIGHT verwendet.
Bereinigung:Der Test wird ItsSession beendet und die Beleuchtungssteuerung wird freigegeben.

Getestete APIs:

android.extension.nightModeIndicator

Bestanden:

Wenn die Lampe eingeschaltet ist, sollte sich die Nachtmodus-Anzeige im Status OFF befinden.
Wenn das Licht aus ist, sollte sich die Nachtmodus-Anzeige im Status ON befinden.
Gilt sowohl für Camera2- als auch für CameraExtension-Sitzungen.

test_preview_min_frame_rate

Testet, ob die Vorschau-Bildrate in einer dunklen Szene korrekt sinkt. Damit dieser Test richtig funktioniert, müssen die Lichter im Prüfstand vom Controller oder manuell vom Prüfer ausgeschaltet werden.

Getestete APIs:

Bestanden:Die Vorschau-Framerate liegt mindestens im angeforderten Frameratebereich und die Abweichung zwischen den Frames ist geringer als die im Test festgelegte absolute Toleranz.

test_torch_strength

Tests, mit denen geprüft wird, ob die Steuerung der Blitzstärke im Modus TORCH korrekt implementiert ist.

Prüft, ob sich die Taschenlampenstärke bei unterschiedlichen angeforderten Stärken ändert, wenn das Gerät die Steuerung der Blitzstärke während der Kameranutzung im TORCH-Modus unterstützt. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der automatische Belichtungsmodus beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Wenn der Modus ON_AUTO_FLASH ist, hat die Blitzstärke keine Auswirkungen auf die Helligkeit. Prüft, ob die Helligkeit der Taschenlampe während eines Burst-Modus gleich bleibt, und simuliert so eine Videoaufnahme. Für den Test müssen die Lichter im Prüfstand ausgeschaltet sein. Das kann automatisch über den Arduino-Controller erfolgen. Die Szene muss für den Test vollständig dunkel sein.

Getestete APIs:

Bestanden:

Wenn der automatische Belichtungsmodus ON oder OFF ist, nimmt die Helligkeit der Bild-Burst-Patches zu, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_TORCH_STRENGTH_MAX_LEVEL erhöht wird. Wenn der automatische Belichtungsmodus ON_AUTO_FLASH ist, liegt der Helligkeitsunterschied der Bildburst-Patches innerhalb der Toleranz, wenn die Blitzstärke von keinem Blitz auf FLASH_TORCH_STRENGTH_MAX_LEVEL erhöht wird.

sensor_fusion

Für Sensorfusionstests ist eine bestimmte Bewegung des Smartphones vor einem Schachbrettmuster und ArUco-Markern erforderlich. Achten Sie darauf, dass das Testbild flach montiert ist, um optimale Ergebnisse zu erzielen. Diagramme, die nicht flach sind, wirken sich auf die Rotationsberechnungen für viele Tests aus. Das Diagramm muss die Rückseite des Sensorfusions-Kästchens ausfüllen. Es muss in einer Größe von 43 × 43 cm gedruckt werden. (43 × 43 cm). Die sensor_fusion-Tests können mit der Sensor Fusion Box automatisiert werden.

Diagramm zur Sensorfusion

Abbildung 142. Diagramm zur Sensorfusion

Diagramm zur Sensorfusion im Rig

Abbildung 143. Diagramm zur Sensorfusion, das den Hintergrund des Sensorfusionsfelds ausfüllt.

test_lens_intrinsic_calibration

Tests, ob sich das optische Zentrum der intrinsischen Linse ändert, wenn sich die Linse aufgrund der optischen Bildstabilisierung (OIS) bewegt. Wenn intrinsische Linsenmuster unterstützt werden, wird getestet, ob sich das optische Zentrum der intrinsischen Linsenmuster ändert, wenn sich die Linse aufgrund von OIS bewegt.

Getestete APIs:

Bestanden:Die optische Mitte des Objektivs ändert sich um mindestens 1 Pixel. Wenn intrinsische Objektiv-Samples unterstützt werden, ändert sich das optische Zentrum der intrinsischen Objektiv-Samples um mindestens 1 Pixel.

Die folgende Abbildung ist ein Beispiel für ein test_lens_intrinsic_calibration-Diagramm, das Änderungen der Hauptpunkte in Pixeln für jeden Frame zeigt:

Abbildung 144. Beispiel für das Diagramm „test_lens_intrinsic_calibration“, in dem die Änderungen der Hauptpunkte in Pixeln für jeden Frame dargestellt sind.

test_multi_camera_frame_sync

Bei Tests, bei denen Zeitstempel von Frames, die von einer logischen Kamera erfasst wurden, innerhalb von 10 ms liegen, werden die Winkel von Quadraten innerhalb des Schachbrettmusters berechnet, um den Zeitstempel zu bestimmen.

Getestete APIs:

Bestanden:Der Winkel zwischen den Bildern der einzelnen Kameras ändert sich beim Drehen des Smartphones nicht wesentlich.

test_preview_distortion

Tests, bei denen die Verzeichnung in jedem Vorschau-Frame korrigiert wird, der bei verschiedenen Zoomstufen aufgenommen wurde. Für jeden Vorschau-Frame werden anhand der intrinsischen und extrinsischen Kameraparameter ideale Punkte berechnet.

Im Beispielbild sind die idealen Punkte grün und die tatsächlichen Punkte rot dargestellt. Der Verzerrungsfehler wird anhand des RMS-Pixelabstands zwischen den tatsächlichen und den idealen Punkten berechnet. Die grünen und roten Markierungen auf dem Bild dienen dazu, den Bereich des Verzerrungsfehlers visuell zu erkennen.

Abbildung 145. Bild eines Schachbrettmusters mit idealen Punkten in Grün und tatsächlichen Punkten in Rot.

Getestete APIs:

Bestanden:Der normalisierte Verzerrungsfehler jedes Vorschau-Frames ist kleiner als der im Test festgelegte Grenzwert.

test_preview_stabilization

Tests, bei denen das Vorschauvideo weniger rotiert wurde als beim Gyroskop.

Getestete APIs:

Bestanden:Die maximale Winkelrotation über Frames hinweg beträgt weniger als 70% der Gyroskoprotation.

Hier sind Beispielvideos mit und ohne Stabilisierung:

Abbildung 146. Beispielvideo mit Stabilisierung.

Abbildung 147. Beispielvideo ohne Stabilisierung.

test_sensor_fusion

Testet den Zeitstempelunterschied zwischen der Kamera und dem Gyroskop für AR- und VR-Anwendungen. Das Smartphone wird vor dem Schachbrettmuster zehnmal um 90 Grad gedreht. Die Bewegung dauert etwa 2 Sekunden. Dieser Test wird übersprungen, wenn kein Gyroskop vorhanden ist oder der Parameter REALTIME für die Zeitstempelquelle nicht aktiviert ist.

Beim test_sensor_fusion-Test werden mehrere Diagramme erstellt. Die beiden wichtigsten Diagramme für das Debugging sind:

test_sensor_fusion_gyro_events: Zeigt die Gyroskopereignisse für das Smartphone während des Tests. Bewegungen in X- und Y-Richtung deuten darauf hin, dass das Smartphone nicht sicher auf der Wandhalterung befestigt ist, was die Wahrscheinlichkeit eines bestandenen Tests verringert. Die Anzahl der Zyklen im Diagramm hängt von der Schreibgeschwindigkeit zum Speichern von Frames ab.

Abbildung 148: Beispiel für test_sensor_fusion-Gyroskopereignisse.
test_sensor_fusion_plot_rotations: Zeigt die Ausrichtung der Gyroskop- und Kameraereignisse an. In diesem Diagramm muss die Bewegung zwischen Kamera und Gyroskop innerhalb von +/-1 ms übereinstimmen.

Abbildung 149: Beispiel für Rotationen im Diagramm „test_sensor_fusion“.

Getestete APIs:

Bestanden:Die Zeitstempel von Kamera und Gyroskop weisen gemäß 7.3.9 Sensoren mit hoher Wiedergabetreue im CDD eine Abweichung von weniger als 1 ms auf.

Fehlermechanismen:

Offset-Fehler: Der Offset zwischen Kamera und Gyroskop ist nicht korrekt auf +/-1 ms kalibriert.
Frame-Drops: Die Pipeline ist nicht schnell genug, um 200 Frames nacheinander zu erfassen.
Socket-Fehler: adb kann keine zuverlässige Verbindung zum DUT herstellen, die lange genug für die Ausführung des Tests ist.
Das Diagramm ist nicht flach montiert. Im Diagramm test_sensor_fusion_plot_rotations gibt es Frames, in denen sich die Gyroskop- und Kameradrehung erheblich ändert, da die Kamera durch die nicht flachen Teile des Diagramms gedreht wird.
Die Kamera ist nicht flach montiert. Das Diagramm test_sensor_fusion_gyro_events zeigt die Bewegung in der X- und Y-Ebene. Dieser Fehler tritt häufiger bei Frontkameras auf, da die Rückkamera oft einen erhöhten Rand hat, der beim Anbringen der Rückseite des Smartphones an der Wandhalterung eine Neigung verursacht.

test_video_stabilization

Tests, bei denen das stabilisierte Video weniger gedreht wird als das Gyroskop.

Getestete APIs:

Bestanden:Die maximale Winkelrotation über Frames hinweg beträgt weniger als 60% der Gyroskoprotation.

Hier sind Beispielvideos mit und ohne Stabilisierung.

Abbildung 150. Beispielvideo mit Stabilisierung.

Abbildung 151. Beispielvideo ohne Stabilisierung.

test_video_stabilization_jca

Bei Tests, bei denen mit dem JCA stabilisierte Videos aufgenommen wurden, ist die Drehung geringer als beim Gyroskop. Die JCA muss vor dem Testen auf dem Gerät installiert werden.

Getestete APIs:

Bestanden:Die maximale Winkelrotation über Frames, die aus mit der JCA aufgenommenen Videos extrahiert wurden, beträgt weniger als 70% der Gyroskoprotation.

feature_combination

Die feature_combination-Tests prüfen, ob Funktionen richtig funktionieren, wenn mehrere Kamerafunktionen gleichzeitig aktiviert sind. Bei diesen Tests wird dasselbe Schachbrettmusterbild verwendet wie in der Sensor-Fusion-Szene.

test_feature_combination

Es werden alle Kombinationen aus verschiedenen Stream-Kombinationen, Videostabilisierungsmodus, Ziel-FPS-Bereich, 10‑Bit-HDR-Video und Ultra HDR getestet, die vom Kameragerät unterstützt werden.

Bei Android 16 und höher werden alle Kombinationen unterstützter Funktionen getestet und die Ergebnisse in einer Protobuf-Datei protokolliert. Fehlerbehauptungen werden nur für Kombinationen von Funktionen aufgerufen, für die isSessionConfigurationSupported den Wert True zurückgibt.

Getestete APIs:

Bestanden:Für jede unterstützte Funktionskombination:

Der Vorschau-Stream wird stabilisiert, wenn die Vorschau-Stabilisierung aktiviert ist.
Die Vorschau-Bildrate liegt innerhalb der konfigurierten AE_TARGET_FPS_RANGE.
Der Farbraum des aufgezeichneten Vorschau-Streams entspricht der Einstellung.
Die Ultra HDR-Aufnahme hat eine gültige Gain-Map.

scene_ip

In Android 16 und höher ermöglicht die Szene scene_ip Bildvergleichsprüfungen zwischen der Standardkamera-App und der Jetpack-Kamera-App (JCA), um größere Unterschiede zwischen aufgenommenen Bildern zu erkennen. Die JCA repliziert Aufnahmen von Social-Media-Apps und stellt ein Baseline-Bild bereit, das von Social-Media-Apps verarbeitet und optimiert wird.

Anforderungen an die Hardwareeinrichtung

Für scene_ip-Tests ist die folgende Hardwarekonfiguration erforderlich:

Die Tests werden in der ITS-in-a-box-Kamera der 2. Generation ausgeführt.
Die Beleuchtungs- und Servocontroller, die Teil des Gen2-Rigs sind, werden zur Steuerung der Testumgebung verwendet.
Im Gen2-Rig befindet sich ein Testfunktionsdiagramm.

test_chart_gen2

Abbildung 152. Beispiel für Gen2chart_sample

Kriterien zum Überspringen von Tests

Die scene_ip-Tests werden übersprungen, wenn eines der folgenden Kriterien erfüllt ist:

Das Gerät hat ein erstes API‑Level (first_api_level) von 35 oder niedriger.
Das Gerät ist kein Smartphone mit primären Front- und Rückkameras (z. B. ein Tablet oder Fernseher).

test_default_jca_ip

Es werden Aufnahmen des Testfunktionsdiagramms unter kontrollierten Lichtverhältnissen mit der Standardkamera-App und dem JCA gemacht und die folgenden Prüfungen durchgeführt:

FoV:Prüft, ob die Standardkamera-App und JCA-Aufnahmen dasselbe Sichtfeld (Field of View, FoV) haben. Bei dieser Prüfung wird der mittlere QR-Code verwendet, der aus dem Bild des Erfassungsdiagramms extrahiert wurde.
Helligkeit:Prüft, ob die zwischen der Standardkamera-App und JCA gemessene Helligkeitsdifferenz 10 nicht überschreitet. Bei dieser Prüfung wird der Patch für den dynamischen Bereich für die Helligkeitsmessung verwendet.
Weißabgleich:Prüft, ob die Differenz beim Weißabgleich zwischen der Standardkamera-App und JCA nicht mehr als 4 beträgt. Bei dieser Prüfung wird der Patch für den dynamischen Bereich für die Helligkeitsmessung verwendet.

Bestanden (einfacher Abschnitt):Der Test hat die Prüfungen für Sichtfeld, Helligkeit und Weißabgleich bestanden. In Android 16 ist dieser Test nicht vorgeschrieben (NOT_YET_MANDATED).

Kamera-ITS-Tests Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

scene0

test_jitter

test_metadata

test_request_capture_match

test_sensor_events

test_solid_color_test_pattern

test_test_pattern

test_tonemap_curve

test_unified_timestamp

test_vibration_restriction

scene1_1

test_ae_precapture_trigger

test_auto_vs_manual

test_black_white

test_burst_capture

test_burst_sameness_manual

test_crop_region_raw

test_crop_regions

test_ev_compensation

test_exposure_x_iso

test_latching

test_linearity

test_locked_burst

scene1_2

test_param_color_correction

test_param_flash_mode

test_param_noise_reduction

test_param_shading_mode

test_param_tonemap_mode

test_post_raw_sensitivity_boost

test_raw_exposure

test_reprocess_noise_reduction

test_tonemap_sequence

test_yuv_jpeg_all

test_yuv_plus_dng

scene1_3

test_capture_result

test_dng_noise_model

test_jpeg

test_raw_burst_sensitivity

test_raw_sensitivity

test_yuv_plus_jpeg

test_yuv_plus_raw

test_sensitivity_priority

test_exposure_time_priority

scene2_a

test_autoframing

test_display_p3

test_effects

test_exposure_keys_consistent

test_format_combos

test_num_faces

test_reprocess_uv_swap

scene2_b

test_preview_num_faces

test_yuv_jpeg_capture_sameness

scene2_c

test_num_faces

test_jpeg_capture_perf_class

test_camera_launch_perf_class

test_default_camera_hdr

scene2_d

test_preview_num_faces

scene2_e

test_continuous_picture

test_num_faces

scene2_f

test_preview_num_faces

scene2_g

test_preview_num_faces

Szene 3

test_edge_enhancement

test_flip_mirror

test_imu_drift

test_landscape_to_portrait

test_lens_movement_reporting

test_reprocess_edge_enhancement

Szene 4

test_30_60fps_preview_fov_match

Kamera-ITS-Tests