Kamera-ITS-Tests

Auf dieser Seite findest du eine umfassende Liste der Tests der Camera Image Test Suite (ITS), die Teil des Android Compatibility Test Suite (CTS) Verifiers 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 wird Entwicklern und Testern erläutert, was die einzelnen Tests bewirken und wie Testfehler behoben werden können.

ITS-Tests werden mit jeder Android-Version aktualisiert oder hinzugefügt, wie in den Versionshinweisen zur Kamera-ITS für die jeweilige Android-Version beschrieben. Updates werden durch von Nutzern oder Entwicklern gemeldete Fehler ausgelöst. Ergänzungen werden durch von Nutzern oder Entwicklern gemeldete Fehler und die Validierung des korrekten Verhaltens neuer Kamera-Framework-Funktionen vorgenommen.

In Android 17 und höher werden die Kamera-ITS-Tests in CTS Verifier in zwei Aktivitäten aufgeteilt, um eine parallele Ausführung zu ermöglichen und die Testzeit zu verkürzen: eine Aktivität für feature_combination- und sensor_fusion-Tests und eine weitere für alle anderen Tests. Weitere Informationen finden Sie unter Testzeit reduzieren.

Die Kamera-ITS-Tests werden nach erforderlichen Kameraeigenschaften, API-Level und MPC-Level (Media Performance Class) gefiltert. Für das API-Level verwendet ITS ro.product.first_api_level, um Tests zu filtern, die in einem bestimmten API-Level hinzugefügt wurden und negative Nutzererfahrungen 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, müssen für ITS bestimmte Tests ausgeführt werden, je nach MPC-Stufe.

Die Tests sind nach Szene in die folgenden Abschnitte unterteilt:

Tablet-basierte Testszenen

  • scene0: Metadaten, Jitter, Gyroskop, Vibration erfassen
  • scene1: Belichtung, Empfindlichkeit, Belichtungskorrektur (LW), YUV im Vergleich zu JPEG und RAW
  • scene2: Gesichtserkennung, Tests, die Farbszenen erfordern
  • scene3: Verbesserung des Verbindungssignals, Bewegung des Objektivs
  • scene4: Seitenverhältnis, Zuschneiden, Sichtfeld
  • scene6: Zoom
  • scene7: Multi-Kamera-Wechsel
  • scene8: Regionenmessung für automatische Belichtung (AE) und automatischen Weißabgleich (AWB)
  • scene9: JPEG-Komprimierung
  • scene_extensions: Kameraerweiterungen
  • scene_tele: Teleobjektivwechsel
  • scene_video: Frame-Drops

Gen2-Rig / sensor_fusion-basierte Testszenen

Diffusorbasierte Testszene

Tablet-basierte Testszene mit großem Farbraum

Eine Beschreibung der einzelnen Szenen finden Sie in den entsprechenden Abschnitten.

Tablet-basierte Testszenen

scene0

Für Tests sind keine spezifischen Szeneninformationen erforderlich. Für Gyroskop- und Vibrationstests muss das Smartphone jedoch stillstehen.

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.

test_jitter plot

Abbildung 1. test_jitter-Diagramm.

test_metadata

Testet die Gültigkeit von Metadateneinträgen und prüft die Aufnahmeergebnisse und die Objekte mit Kameraeigenschaften. Für diesen Test werden die Belichtungs- und Verstärkungswerte von auto_capture_request verwendet, da der Bildinhalt nicht wichtig ist. Dies ist ein Fast-FAIL-Test, da er in kurzer Zeit ausgeführt wird, nur minimale Einrichtung erfordert und eine erhebliche Anzahl von Tests signalisiert, die nachgelagert fehlschlagen. Die gesamte Test-Suite sollte erst ausgeführt werden, wenn test_metadata erfolgreich abgeschlossen wurde.

Getestete APIs:

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

test_request_capture_match

Es wird getestet, ob das Gerät die richtigen Belichtungs- und Verstärkungswerte schreibt, indem die Aufnahmemetadaten zurückgelesen werden. Dies ist ein Fast-FAIL-Test, da er nur minimalen Einrichtungsaufwand erfordert und eine erhebliche Anzahl von nachgelagerten Tests signalisiert, die fehlschlagen. Die gesamte Test-Suite sollte erst ausgeführt werden, wenn test_request_capture_match erfolgreich abgeschlossen wurde.

Getestete APIs:

Bestanden: Die Metadatenwerte der Anfrage und der Aufnahme stimmen bei allen Aufnahmen überein.

test_sensor_events

Bei Geräten, die die Unterstützung von Sensorfusion bewerben, wird mit 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 das Display eingeschaltet ist, das Gerät sich also nicht im Stand-by-Modus befindet. Dies ist ein Fast-FAIL-Test, da er nur kurz dauert, nur minimale Einrichtung erfordert und signalisiert, dass der Sensorfusionstest nachgelagert fehlschlägt. Die sensor_fusion-Szenentests sollten nur ausgeführt werden, wenn test_sensor_events BESTANDEN oder ÜBERSPRUNGEN ist.

Getestete APIs:

Bestanden:Für jeden Sensor werden Ereignisse empfangen.

test_solid_color_test_pattern

Testet, ob einfarbige Testmuster für die Stummschaltung 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 einfarbige Testmuster nur getestet, wenn die Funktion beworben wird.

Wenn RAW-Bilder unterstützt werden, wird auch die Farbzuweisung 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 die Abweichung im Bild ist gering.

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:

  1. Nimmt Bilder für alle unterstützten Testmuster auf.
  2. 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 in YUV mit linearer Tonemap. Für diesen Test ist android.sensor.testPatternMode = 2 (COLOR_BARS) erforderlich, um ein perfektes Bildmuster für die Tonemap-Konvertierung zu generieren. Prüft, ob die Pipeline die richtigen Farbausgaben mit linearer Tonemap und idealer Bildeingabe hat (basiert auf test_test_patterns).

Getestete APIs:

Bestanden:Die YUV- und die RAW-Aufnahme sehen ähnlich aus.

test_tonemap_curve raw-Beispiel

Abbildung 3. RAW-Beispiel für test_tonemap_curve.

test_tonemap_curve YUV-Beispiel

Abbildung 4. YUV-Beispiel für test_tonemap_curve.

test_unified_timestamp

Prüft, ob Bild- und Bewegungssensorereignisse im selben Zeitbereich liegen. Dies ist ein Fast-FAIL-Test, da er in kurzer Zeit ausgeführt wird, nur minimale Einrichtung erfordert und signalisiert, dass der Sensorfusionstest nachgelagert fehlschlägt. Die Tests der Szene sensor_fusion sollten nur ausgeführt werden, wenn test_unified_timestamp mit PASS oder SKIP abgeschlossen wurde.

Getestete APIs:

Bestanden:Die Zeitstempel der Bewegung liegen zwischen den beiden Bildzeitstempeln.

test_vibration_restriction

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

Getestete APIs:

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

scene1_1

scene1 ist ein graues Diagramm. Die graue Karte muss die mittleren 30% des Sichtfelds der Kamera abdecken. Die Graukarte stellt eine mäßige Herausforderung für die 3A-Funktionen (AE, AWB und AF) dar, da der mittlere Bereich keine Merkmale aufweist. In der Aufnahmeanfrage wird jedoch die gesamte Szene angegeben, die genügend Merkmale für die Konvergenz von 3A enthält.

Kameras mit reduziertem Sichtfeld können im Testaufbau für Kameras mit weitem oder reduziertem Sichtfeld getestet werden. Wenn eine Kamera mit normalem Sichtfeld im Testaufbau für ein weites Sichtfeld getestet wird, wird das Diagramm um 2/3 skaliert, um einige Grenzen für das graue Diagramm im Sichtfeld festzulegen, damit 3A konvergieren kann. Ausführlichere Beschreibungen der Kamera-Testvorrichtungen findest du unter Camera ITS-in-a-box.

scene1 example

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

test_ae_precapture_trigger

Testet die AE-Zustandsmaschine bei Verwendung des Precapture-Triggers. Erfasst fünf manuelle Anfragen bei deaktivierter AE. Die letzte Anfrage hat einen AE-Precapture-Trigger, der ignoriert werden sollte, da AE deaktiviert ist.

Getestete APIs:

Bestanden:AE konvergiert.

test_auto_vs_manual

Tests, bei denen automatische und manuelle Aufnahmen gemacht wurden, sehen gleich aus.

Getestete APIs:

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

test_auto_vs_manual auto example

Abbildung 6. Beispiel für „test_auto_vs_manual“ mit automatischer Einstellung.

Beispiel für automatischen und manuellen Weißabgleich (test_auto_vs_manual)

Abbildung 7: Beispiel für den Weißabgleich „test_auto_vs_manual“.

Beispiel für die Transformation des manuellen Weißabgleichs in „test_auto_vs_manual“

Abbildung 8: Beispiel für die Transformation des manuellen Weißabgleichs in „test_auto_vs_manual“

test_black_white

Testet, ob das Gerät vollständige Schwarz-Weiß-Bilder erzeugt. Es werden zwei Aufnahmen gemacht: die erste mit extrem geringer Verstärkung und kurzer Belichtung, was zu einem schwarzen Foto führt, und die zweite mit extrem hoher Verstärkung und Langzeitbelichtung, was zu einem weißen Foto führt.

Getestete APIs:

Pass: Erzeugt Schwarz-Weiß-Bilder. Gesättigte Kanäle von weißen Bildern haben RGB-Werte von [255, 255, 255] mit einer Fehlerspanne von weniger als 1 %.

test_black_white, schwarzes Beispiel

Abbildung 9. test_black_white, schwarzes Beispiel.

Beispiel für die Transformation des manuellen Weißabgleichs in „test_auto_vs_manual“

Abbildung 10: test_black_white, weißes Beispiel.

test_black_white plot means example

Abbildung 11: test_black_white, Beispiel für Plot-Mittelwerte.

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:

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

test_burst_sameness_manual

Nimmt 5 Serien mit 50 Bildern mit der manuellen Aufnahmeeinstellung auf und prüft, ob sie alle identisch sind. Mit diesem Test können Sie feststellen, 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.

Fehlgeschlagen:Im RGB-Durchschnittsdiagramm ist zu Beginn jeder Burst-Aufnahme ein Anstieg oder Abfall zu sehen.

  • 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 Mittelwert von „test_burst_sameness_manual“

test_burst_sameness_manual_plot_means

Abbildung 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

Testet, ob die RAW-Streams nicht zugeschnitten werden können.

Getestete APIs:

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

test_crop_region_raw comp raw crop example

Abbildung 14: Beispiel für den Test „test_crop_region_raw“ mit RAW-Zuschnitt

test_crop_region_raw comp raw full example

Abbildung 15: Vollständiges Beispiel für „test_crop_region_raw comp raw“.

test_crop_region_raw comp YUV crop example

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

Beispiel für test_crop_region_raw_yuv_full

Abbildung 17. Vollständiges Beispiel für test_crop_region_raw YUV.

test_crop_regions

Testet, 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 dem für die fünf Regionen festgelegten Zuschnitt auf. Vergleicht die Werte des Patch- und des Crop-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 Belichtungskorrektur (EV) angewendet wird. Der Test besteht aus einem grundlegenden und einem fortgeschrittenen Abschnitt.

Im grundlegenden Abschnitt wird getestet, ob die Belichtungskorrektur mit einem Bereich angewendet wird, der mit CONTROL_AE_COMPENSATION_STEP erstellt wurde. Bei jedem Korrekturwert werden acht Frames 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 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 die gemessenen Werte nicht übereinstimmen oder wenn die Bilder innerhalb von fünf Schritten überbelichtet werden.

Getestete APIs:

Grundlegende Anforderungen erfüllt:Die Bilder zeigen eine zunehmende Belichtung, ohne dass es innerhalb von fünf Schritten zu einer Überbelichtung kommt.

test_ev_compensation_basic

Abbildung 18: test_ev_compensation_basic

Erweiterter Abschnitt – bestanden:Erfasst einen Anstieg der Luminanz, wenn die Einstellung für die Belichtungskorrektur erhöht wird. Die acht Frames, die für jede Einstellung der Belichtungskorrektur aufgenommen werden, haben stabile Luminanzwerte.

test_ev_compensation_advanced_plot_means

Abbildung 19: test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

Testet, ob eine konstante Belichtung erreicht wird, wenn ISO und Belichtungszeit variieren. Nimmt eine Reihe von Fotos auf, bei denen ISO und Belichtungszeit so gewählt werden, 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 Mittelwerte der Beispielpixel nahe beieinander liegen. Prüft, ob die Bilder nicht auf 0 oder 1 beschränkt sind (wodurch sie wie flache Linien aussehen würden). Der Test kann auch mit RAW-Bildern ausgeführt werden. Dazu muss das Flag debug in der Konfigurationsdatei festgelegt werden.

Getestete APIs:

Bestanden:Die Bilder haben dieselbe Helligkeit, werden aber mit höherem ISO-Wert verrauschter. RGB-Ebenen sind flach, wenn der Wert von ISO*Belichtung über den getesteten Verstärkungsbereich konstant ist.

Fehlermechanismus:In der folgenden Abbildung weichen die normalisierten RGB-Ebenen-Durchschnittswerte (y-Achse) mit zunehmenden Verstärkungsmultiplikatorwerten (x-Achse) von den niedrigen Verstärkungsmultiplikatorwerten ab.

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

Testet, ob die Einstellungen (Belichtung und Verstärkung) für FULL- und LEVEL_3-Kameras im richtigen Frame einrasten. Nimmt eine Reihe von Aufnahmen mit aufeinanderfolgenden Anfragen auf, wobei die Parameter der Aufnahmeanfrage zwischen den Aufnahmen variieren. Prüft, ob die Images die erwarteten Eigenschaften haben.

Getestete APIs:

Bestanden:Die Bilder [2, 3, 6, 8, 10, 12, 13] haben einen höheren ISO-Wert oder eine höhere Belichtung und werden im Diagramm in der folgenden Abbildung mit höheren RGB-Mittelwerten angezeigt.

test_latching plot means example

Abbildung 23: Beispiel für ein Diagramm mit „test_latching“.

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

Testet, ob die Geräteverarbeitung in lineare Pixel umgewandelt werden kann. Nimmt eine Reihe von Aufnahmen auf, 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.

test_linearity plot means example

Abbildung 37: Beispiel für ein Diagramm mit den Mittelwerten von „test_linearity“

test_locked_burst

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

Getestete APIs:

Bestanden: Die Aufnahmen sehen einheitlich aus.

test_locked_burst frame0 example

Abbildung 38: Beispiel für „test_locked_burst frame0“

test_locked_burst frame1 example

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 Subszene-Struktur implementiert, um die längere Dauer von scene 1 zu verkürzen.

test_param_color_correction

Testet, ob die android.colorCorrection.*-Parameter angewendet werden, wenn sie festgelegt sind. Nimmt Bilder mit unterschiedlichen Transformations- und Verstärkungswerten auf und prüft, ob sie entsprechend unterschiedlich aussehen. Die Transformation und die Verstärkungen werden so gewählt, dass die Ausgabe zunehmend rot oder blau wird. Verwendet ein lineares Tonemapping.

Tone Mapping ist eine Technik, die in der Bildverarbeitung verwendet wird, um einen Farbsatz einem anderen zuzuordnen, um das Erscheinungsbild von Bildern mit hohem Dynamikumfang in einem Medium mit einem begrenzteren Dynamikumfang anzunähern.

Getestete APIs:

Bestanden: Die R- und B-Werte werden gemäß der Transformation erhöht.

Beispiel für ein Diagramm mit Mittelwerten für „test_param_color_correction“

Abbildung 41: Beispiel für ein Diagramm mit Mittelwerten für „test_param_color_correction“

In den folgenden Abbildungen ist die x-Achse die Aufnahme-Anfragen: 0 = Unity, 1 = Red Boost und 2 = Blue Boost.

test_param_color_correction req=0 unity example

Abbildung 42. Unity-Beispiel für „test_param_color_correction req=0“.

test_param_color_correctness req=1 red boost example

Abbildung 43. Beispiel für „test_param_color_correctness req=1 red boost“.

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

Prüft, ob der Parameter android.flash.mode angewendet wird. Die Belichtung wird manuell auf die dunkle Seite eingestellt, damit klar ist, ob der Blitz ausgelöst wurde oder nicht. Außerdem wird ein lineares Tonemapping verwendet. Prüft die Mitte des Kachelbilds, um festzustellen, ob ein großer Farbverlauf erstellt wurde, um zu prüfen, ob der Blitz ausgelöst wurde.

Getestete APIs:

Bestanden:Die Mitte des Kachelbilds 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.

test_param_flash_mode 1 tile example

Abbildung 46: Beispiel für „test_param_flash_mode“ mit einer Kachel

Beispiel für test_param_flash_mode_2

Abbildung 47. Beispiel für „test_param_flash_mode 2“.

test_param_flash_mode 2 tile example

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

test_param_noise_reduction

Prüft, ob der Parameter android.noiseReduction.mode korrekt angewendet wird, wenn er festgelegt ist. Nimmt Bilder mit der Kamera bei schwachem Licht auf. Verwendet eine hohe analoge Verstärkung, um sicherzustellen, dass das aufgenommene Bild verrauscht ist. Nimmt drei Bilder auf: ohne Rauschunterdrückung, schnell und in hoher Qualität. Außerdem wird ein Bild mit niedriger Verstärkung und deaktivierter Rauschunterdrückung aufgenommen und die Varianz dieses Bildes als Baseline verwendet. Je höher das Signal-Rausch-Verhältnis (SNR), desto besser die Bildqualität.

Getestete APIs:

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

Beispiel für SNRs im Diagramm „test_param_noise_reduction“

Abbildung 49: Beispiel für SNRs im Diagramm „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 low gain example

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

test_param_shading_mode

Prüft, ob der Parameter android.shading.mode angewendet wird.

Getestete APIs:

Bestanden:Die Schattierungsmodi werden gewechselt und die Objektivschattierungskarten werden wie erwartet geändert.

test_param_shading_mode lens shading map, mode 0 loop 0 example

Abbildung 55: Beispiel für eine Lens-Shading-Karte für „test_param_shading_mode“, Modus 0, Schleife 0.

test_param_shading_mode lens shading map, mode 1 loop 0 example

Abbildung 56: Beispiel für die Objektivschattierungskarte „test_param_shading_mode“, Modus 1, Schleife 0.

test_param_shading_mode lens shading map, mode 2 loop 0 example

Abbildung 57: Beispiel für die Objektivschattierungskarte „test_param_shading_mode“, Modus 2, Schleife 0.

test_param_tonemap_mode

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

Getestete APIs:

Karte/Ticket:

  • test1: Beide Bilder haben ein lineares Tonemapping, aber n=1 hat einen steileren Gradienten. Der G-Kanal (grün) ist für das n=1-Bild heller.
  • test2: Gleiches Tonemapping, aber andere 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 Empfindlichkeitssteigerung nach der Rohdatenverarbeitung. Nimmt eine Reihe von RAW- und YUV-Bildern mit unterschiedlicher Empfindlichkeit auf, postet die Kombination aus RAW-Empfindlichkeitssteigerung und prüft, ob der Mittelwert der Ausgabepixel mit den Anfrageeinstellungen übereinstimmt.

Getestete APIs:

Bestanden:RAW-Bilder werden mit zunehmender Verstärkung dunkler, während die Helligkeit von YUV-Bildern konstant bleibt.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

Abbildung 60: Beispiel für test_post_raw_sensitivity_boost raw s=3583 boost=0100.

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

Abbildung 61: Beispiel für test_post_raw_sensitivity_boost raw s=1792 boost=0200.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

Abbildung 62: Beispiel für test_post_raw_sensitivity_boost raw s=0896 boost=0400.

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

Abbildung 63: Beispiel für test_post_raw_sensitivity_boost raw s=0448 boost=0800

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

Abbildung 64: Beispiel für „test_post_raw_sensitivity_boost“ mit „raw s=0224 boost=1600“

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

Abbildung 65: Beispiel für „test_post_raw_sensitivity_boost raw s=0112 boost=3199“

Beispiel für ein Diagramm mit Rohdatenmittelwerten für test_post_raw_sensitivity_boost

Abbildung 66: Beispiel für ein Diagramm mit Rohwerten für „test_post_raw_sensitivity_boost“.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

Abbildung 67. Beispiel für test_post_raw_sensitivity_boost YUV s=0112 boost=3199.

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

Abbildung 68: Beispiel für „test_post_raw_sensitivity_boost“ mit YUV s=0448 boost=0800.

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

Abbildung 69: Beispiel für „test_post_raw_sensitivity_boost“ mit YUV, s=0896, boost=0400.

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

Abbildung 70: Beispiel für „test_post_raw_sensitivity_boost“ mit YUV, s=1792, boost=0200.

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

Abbildung 71: Beispiel für „test_post_raw_sensitivity_boost“ mit YUV, s=3585, boost=0100.

test_post_raw_sensitivity_boost_yuv_plot_means

Abbildung 72: Beispiel für „test_post_raw_sensitivity_boost_yuv_plot_means“.

test_raw_exposure

Nimmt eine Reihe von RAW-Bildern mit zunehmender Belichtungszeit auf und misst die Pixelwerte.

Getestete APIs:

Bestanden:Durch Erhöhen des ISO-Werts (Verstärkung) werden die Pixel lichtempfindlicher, sodass sich die Darstellung nach links verschiebt.

test_raw_exposure ISO=55-Beispiel

Abbildung 73: Beispiel für test_raw_exposure ISO=55

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

test_raw_exposure ISO=132-Beispiel

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

test_raw_exposure ISO=209-Beispiel

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

test_raw_exposure ISO=286-Beispiel

Abbildung 76: Beispiel für test_raw_exposure mit ISO=286.

test_raw_exposure ISO=363-Beispiel

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

test_raw_exposure_s=440

Abbildung 78: Beispiel für test_raw_exposure ISO=440.

test_reprocess_noise_reduction

Testet, ob android.noiseReduction.mode für Wiederaufbereitungsanfragen angewendet wird. Nimmt neu verarbeitete Bilder mit schwach beleuchteter Kamera auf. Verwendet eine hohe analoge Verstärkung, um zu prüfen, ob das aufgenommene Bild verrauscht ist. Nimmt drei neu verarbeitete Bilder auf, für „Rauschunterdrückung aus“, „Schnell“ und „Hohe Qualität“. Nimmt ein neu verarbeitetes Bild mit geringer Verstärkung und deaktivierter Rauschunterdrückung auf und verwendet die Varianz dieses Bildes als Referenz.

Getestete APIs:

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

Typisches Diagramm für SNR- und NR-Modus

Abbildung 79. Beispiel für ein typisches Diagramm zum SNR- und NR-Modus.

test_tonemap_sequence

Testet eine Sequenz von Aufnahmen mit unterschiedlichen Tonemap-Kurven. Nimmt drei manuelle Aufnahmen mit einer linearen Tonwertzuordnung auf. Nimmt 3 manuelle Aufnahmen mit Standard-Tonemapping auf. Berechnet das Delta zwischen jedem aufeinanderfolgenden Frame-Paar.

Getestete APIs:

Bestanden:Es gibt drei identische Frames, gefolgt von einer anderen Gruppe von drei identischen Frames.

test_tonemap_sequence i=0 example

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-Beispiel

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.

Beispiel für test_tonemap_sequence_i=4

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

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

Getestete APIs:

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

test_yuv_jpeg_all-Beispiel

Abbildung 86. Beispiel für „test_yuv_jpeg_all“.

test_yuv_plus_dng

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

Getestete APIs:

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 Subszene-Struktur implementiert, um die längere Dauer von scene 1 zu verkürzen.

test_capture_result

Prüft, 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 Objektivschattierungskorrektur 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 RAW-Aufnahmen, die über einen Bereich von Empfindlichkeiten aufgenommen wurden, und vergleicht diese Werte mit der Varianz, die bei jeder Empfindlichkeit durch das DNG-Rauschmodell im Kamera-HAL erwartet wird (basierend auf den O,S-Parametern, die in den Aufnahmeergebnisobjekten zurückgegeben werden). Weitere Informationen zum DNG-Rauschmodell findest du im folgenden Dokument zum DNG-Rauschmodell.

Getestete APIs:

Bestanden:Die Parameter des DNG-Rohmodells sind korrekt. Die erwarteten RGB-Werte stimmen mit den tatsächlich gemessenen RGB-Werten überein.

test_dng_noise_model_plog

Abbildung 89. test_dng_noise_model_plog.

test_jpeg

Testet, ob konvertierte YUV-Bilder und JPEG-Bilder des Geräts gleich aussehen. Der Test nimmt die mittleren 10% des Bildes, berechnet den RGB-Wert und prüft, ob sie übereinstimmen.

Getestete APIs:

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

Nimmt eine Reihe von RAW-Bildern mit zunehmender Verstärkung auf und misst das Rauschen. Nimmt nur RAW-Bilder in einer Serie auf.

Getestete APIs:

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

Verwendet die Varianz der mittleren Statistikrasterzelle.

test_raw_burst_sensitivity_variance

Abbildung 92: test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Nimmt eine Reihe von RAW-Bildern mit zunehmender Empfindlichkeit auf und misst das Rauschen (Varianz) in den mittleren 10% des Bildes. Testet, ob jeder Shot mehr Rauschen enthält als der vorherige.

Getestete APIs:

Bestanden:Die Varianz nimmt mit jedem Schuss zu.

test_raw_sensitivity_variance

Abbildung 93: test_raw_sensitivity_variance

test_yuv_plus_jpeg

Testet die Aufnahme eines einzelnen Frames als YUV- und JPEG-Ausgabe. Verwendet eine manuelle Anfrage mit einer linearen Tonemap, 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 weisen einen RMS-Unterschied (Wert eines Signals) von weniger als 1% auf.

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 einzelner Frame sowohl als RAW- (10-Bit- und 12-Bit-RAW) als auch als YUV-Ausgabe erfasst wird, sofern unterstützt. Verwendet eine manuelle Anfrage mit linearer Tonemap, sodass RAW und YUV voraussichtlich identisch sind. Vergleicht die RGB-Werte der mittleren 10% der RGB-konvertierten Bilder. Protokolleandroid.shading.mode.

Getestete APIs:

Bestanden:YUV- und RAW-Bilder sind ähnlich und weisen eine Differenz von weniger als 3,5% RMS (Effektivwert eines Signals) auf.

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

Testet CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY mit verschiedenen ISO-Einstellungen, um einen Zusammenhang zwischen höheren ISO-Werten und erhöhtem Rauschen zu bestätigen.

Getestete APIs:

Bestanden:Ein höherer ISO-Wert führt zu einem höheren Rauschpegel.

Kriterien für das Überspringen von Tests

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

test_exposure_time_priority

CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY wird bei verschiedenen Belichtungszeiten getestet, um eine stabile Helligkeit in dem Bereich zu prüfen, in dem der ISO-Wert kompensieren kann.

Getestete APIs:

Bestanden:Die Helligkeit ist bei allen Belichtungszeiten stabil (innerhalb der Toleranz), wenn der ISO-Wert innerhalb des Kompensationsbereichs liegt.

Kriterien für das Überspringen von Tests

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

scene2_a

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

scene2_a example

Abbildung 98. Beispiel für scene2_a.

test_autoframing

Testet das Autoframe-Verhalten der Kamera. Führt einen starken Zoom aus, sodass keine der Gesichter in der Szene sichtbar sind, aktiviert den Autoframe-Modus, indem AUTOFRAMING in CaptureRequest auf True gesetzt wird, und prüft, ob alle Gesichter in der ursprünglichen Szene erkannt werden können, wenn der Zustand 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

Testet die Display P3-Aufnahme im JPEG-Format mit der ColorSpaceProfiles API. Es wird geprüft, ob das aufgenommene JPEG ein geeignetes ICC-Profil im Header hat und ob das Bild Farben außerhalb des sRGB-Farbraums enthält.

Getestete APIs:

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

test_effects

Nimmt Frames für unterstützte Kameraeffekte auf und prüft, ob sie korrekt generiert werden. Der Test prüft nur die Effekte OFF und MONO, speichert aber Bilder für alle unterstützten Effekte.

Getestete APIs:

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

test_effects_MONO

Abbildung 99: test_effects_MONO.

test_exposure_keys_consistent

Bei diesem Test wird die durchschnittliche Luminanz einer Aufnahme mit aktivierter automatischer Belichtung mit einer Aufnahme mit deaktivierter automatischer Belichtung verglichen, bei der die Belichtungsparameter (Empfindlichkeit, Belichtungszeit, Framedauer, Erhöhung der Empfindlichkeit nach RAW) manuell angewendet werden, die im CaptureResult der Aufnahme mit aktivierter automatischer Belichtung empfangen wurden.

Getestete APIs:

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

test_format_combos

Testet verschiedene Kombinationen von Ausgabeformaten.

Getestete APIs:

Bestanden:Alle Kombinationen wurden erfolgreich erfasst.

test_num_faces

Testet die Gesichtserkennung.

Getestete APIs:

Bestanden: Es werden drei Gesichter gefunden.

Beispiel für test_num_faces-Gesichtserkennungsmodus 1

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

test_reprocess_uv_swap

Testet, ob bei der YUV-Neuverarbeitung die U- und V-Ebenen 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 einer höheren 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 vertauscht.

test_reprocess_uv_swap

Abbildung 101: Beispiel für „test_reprocess_uv_swap“

scene2_b

scene2_b hat drei Gesichter mit grauem Hintergrund und neutraler Kleidung. Die Gesichter wurden so ausgewählt, dass sie eine breite Palette von Hauttönen abdecken. Das Diagramm muss die richtige Ausrichtung haben, damit die Gesichtserkennung optimal funktioniert.

test_preview_num_faces

Testet die 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 „test_num_faces“.

test_yuv_jpeg_capture_sameness

Nimmt zwei Bilder mit den größten gemeinsamen YUV- und JPEG-Formaten mit demselben Seitenverhältnis wie das größte JPEG-Format auf, das eine Auflösung von 1920 × 1440 nicht überschreitet. Setzt jpeg.quality auf 100 und erfasst eine Anfrage für zwei Oberflächen. Konvertiert beide Bilder in RGB-Arrays und berechnet die 3D-RMS-Differenz (Root Mean Square) zwischen den beiden Bildern.

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

Getestete APIs:

Bestanden: YUV- und JPEG-Bilder für den Anwendungsfall STILL_CAPTURE weisen eine RMS-Differenz (Effektivwert eines Signals) von weniger als 3% auf. YUV-Bilder für alle unterstützten Anwendungsfälle weisen eine CIELAB-Differenz von weniger als 4% zu YUV-Bildern mit dem Anwendungsfall STILL_CAPTURE auf.

scene2_c

test_num_faces

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

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 JPEG-Aufnahmelatenz für die Leistungsklasse S, wie in Abschnitt 2.2.7.2 „Kamera“ der CDD angegeben.

Bestanden:Die JPEG-Aufnahmelatenz von camera2 MUSS für beide Hauptkameras bei einer Auflösung von 1080p unter 1.000 ms liegen, gemessen mit dem CTS-Kamera-PerformanceTest unter ITS-Beleuchtungsbedingungen (3.000 K).

test_camera_launch_perf_class

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

Bestanden:Die camera2-Startlatenz (Öffnen der Kamera bis zum ersten Vorschau-Frame) MUSS bei beiden Hauptkameras unter 3.000 K-ITS-Beleuchtungsbedingungen weniger als 600 ms betragen, gemessen mit dem CTS-Kamera-PerformanceTest.

test_default_camera_hdr

Es wird getestet, ob die Standard-Kameraaufnahme für die Leistungsklasse 15 Ultra HDR ist, wie in Abschnitt 2.2.7.2 „Kamera“ der CDD angegeben.

Bestanden:Die Standard-Kamera-App MUSS auf einem Gerät der Leistungsklasse 15 Ultra HDR-Aufnahmen machen.

scene2_d

test_preview_num_faces

Testet die 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 VGA-Frames werden mit der ersten Einstellung der Erfassungsanfrage erfasst android.control.afMode = 4 (CONTINUOUS_PICTURE).

Getestete APIs:

Bestanden:Das 3A-System stabilisiert sich am Ende einer Aufnahme mit 50 Frames.

test_num_faces

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

Getestete APIs:

Erfolgreich:3 Gesichter gefunden.

scene2_f

scene2_f hat drei Gesichter mit weißem Hintergrund und weißer Kleidung. Die Gesichter haben eine Vielzahl von Hauttönen und einen starken 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 Szenen mit Gesichtern.

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 Vielzahl von Hauttönen und einen starken Kontrast zum Hintergrund.

scene2_g.png

Abbildung 106. Beispiel für scene2_g.

test_preview_num_faces

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

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“

scene3

scene3 verwendet das ISO12233-Diagramm und die meisten Tests verwenden eine Diagrammextraktionsmethode, um das Diagramm in der Szene zu finden. Aus diesem Grund haben die meisten gespeicherten Bilder keine Rahmen wie die Bilder für die Szenen 1, 2 oder 4, sondern nur das Diagramm. Das Diagramm muss richtig ausgerichtet sein, damit die Diagrammsuche optimal funktioniert. In Android 17 und höher verwendet scene3 ArUco-Marker für die Diagrammerkennung.

scene3_aruco_chart

Abbildung 108: Diagramm „scene3“.

test_edge_enhancement

Prüft, ob der Parameter android.edge.mode richtig angewendet wird. Nimmt für jeden Edge-Modus Bilder auf, die nicht noch einmal verarbeitet werden, und gibt die Schärfe des Ausgabebilds und die Metadaten des Aufnahmeergebnisses zurück. Verarbeitet eine Aufnahme-Anfrage mit einem bestimmten Kantenmodus, einer bestimmten Empfindlichkeit, Belichtungszeit, Fokusentfernung und einem bestimmten Ausgabeflächenparameter. In Android 17 und höher werden ArUco-Marker verwendet, um den Diagrammbereich zu definieren, der die erforderlichen scharfen Kanten enthält.

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

Getestete APIs:

Betroffene Kameraparameter:

  • EDGE_MODE

test_edge_enhancement_edge=0

Abbildung 109: Beispiel für „test_edge_enhancement“ mit „edge=0“

test_edge_enhancement edge=1 example

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

test_edge_enhancement edge=2 example

Abbildung 111: Beispiel für test_edge_enhancement edge=2 (Modus für hohe Qualität)

test_flip_mirror

Prüft, ob das Bild gemäß 7.5.2 Frontkamera in der CDD richtig ausgerichtet ist. In Android 17 und höher werden ArUco-Markierungen verwendet, um sowohl das Vorhandensein als auch die Ausrichtung des Diagramms zu prüfen. Gespiegelte, umgedrehte oder gedrehte Bilder können anhand des rautenförmigen Merkmals in der Mitte identifiziert werden.

Bestanden:Alle Markierungen werden erkannt und sind richtig ausgerichtet. Das Bild ist nicht umgedreht, gespiegelt oder gedreht.

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

Abbildung 112: Beispiel für einen Szenen-Patch „test_flip_mirror“

test_imu_drift

Prüft, ob die Trägheitsmesseinheit (Inertial Measurement Unit, IMU) 30 Sekunden lang eine stabile Ausgabe liefert, während das Gerät stillsteht und eine HD-Vorschau aufnimmt.

Getestete APIs:

Karte/Ticket:

  • Die Abweichung des Gyroskops beträgt während der Testzeit weniger als 0,01 rad.
  • Die Varianz des Gyroskop-Messwerts ist während der Testzeit kleiner als 1E-7 rad2/s2/Hz.
  • Die Abweichung des Rotationsvektors beträgt während der Testzeit weniger als 0,01 rad.
  • (Noch nicht vorgeschrieben) Die Abweichung des Gyroskops beträgt weniger als 1 Grad pro Sekunde.

Beispiel für Gyroskopdrift in test_imu_drift

Abbildung 113: Beispiel für Gyroskopdrift bei „test_imu_drift“

Beispiel für die Drift des Rotationsvektors „test_imu_drift“

Abbildung 114: Beispiel für die Drift des Rotationsvektors bei „test_imu_drift“

test_landscape_to_portrait

Prüft, ob die Überschreibung von Querformat zu Hochformat für Sensoren im Querformat ordnungsgemäß funktioniert.

Getestete APIs:

Bestanden:Der Test findet ein Diagramm mit der erwarteten Drehung (0 Grad, wenn die Überschreibung von Querformat zu Hochformat deaktiviert ist, 90 Grad, wenn sie aktiviert ist).

Beispiel für test_landscape_to_portrait

Abbildung 115. Beispiel für „test_landscape_to_portrait“.

test_lens_movement_reporting

Prüft, ob das Flag für die Objektivbewegung richtig gemeldet wird. Nimmt eine Serie von 24 Bildern auf, wobei die ersten 12 Bilder mit dem optimalen Fokusabstand (wie von 3A ermittelt) und die letzten 12 Bilder mit dem minimalen Fokusabstand aufgenommen werden. Etwa bei Frame 12 bewegt sich das Objektiv, wodurch die Schärfe abnimmt. Die Schärfe stabilisiert sich schließlich, wenn sich das Objektiv in die endgültige Position bewegt.

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 Fokusentfernung und den letzten Frames mit dem Objektiv in der minimalen Fokusentfernung liegt. Der genaue Frame, in dem sich das Objektiv bewegt, ist nicht wichtig. Wichtig ist, dass das Bewegungs-Flag gesetzt wird, wenn sich das Objektiv bewegt.

In Android 17 und höher werden bei diesem Test ArUco-Marker verwendet, um den Diagrammbereich mit den erforderlichen scharfen Kanten zu definieren. Diese Methode bietet eine stabile Erkennung für Kameras von Ultraweitwinkel- bis Teleobjektiven.

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 im Vergleich zu den ersten Frames bei optimaler Fokusentfernung oder den letzten Frames bei minimaler Fokusentfernung auf.

test_reprocess_edge_enhancement

Prüft, ob die unterstützten Methoden zur erneuten Verarbeitung für die Verbesserung des Verbindungssignals ordnungsgemäß funktionieren. Verarbeitet eine Aufnahme-Anfrage mit einem bestimmten Edge-Modus für die Nachbearbeitung und vergleicht verschiedene Modi für die Aufnahme mit deaktivierten Edge-Modi für die Nachbearbeitung.

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 ein Diagramm für „test_reprocess_edge_enhancement“

Abbildung 116: Beispiel für ein Diagramm für „test_reprocess_edge_enhancement“.

scene4

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 Verzeichnis „tools“ verwenden, um eine Prüfung der Ausrichtung des zu testenden Geräts und des Diagramms zu aktivieren.

scene4 example

Abbildung 117. Beispiel für scene4.

test_30_60fps_preview_fov_match

Es wird getestet, ob die Vorschauvideos mit 30 fps und 60 fps dasselbe Sichtfeld haben. Im 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. Es wird getestet, ob das Seitenverhältnis des Kreises konstant bleibt, der Mittelpunkt des Kreises stabil bleibt und der Radius des Kreises konstant bleibt.

Getestete APIs:

Bestanden:Die Bilder sind nicht gestreckt, die Bildmitten weichen um nicht mehr als 3 % voneinander ab und die maximale Änderung des Seitenverhältnisses zwischen Videos mit 30 fps und 60 fps beträgt nicht mehr als 7,5 %.

Fehlermechanismen:

  • Der Kreis im 30-fps-Video unterscheidet sich deutlich in der Größe vom 60-fps-Video.
  • Der Kreis im aufgenommenen Bild wird durch die Verarbeitungspipeline verzerrt.
  • Der Kreis im aufgenommenen Bild wird aufgrund einer Aufnahmeanfrage mit extremem Seitenverhältnis abgeschnitten, wodurch die Höhe oder Breite des Bildes reduziert wird.
  • Der Kreis im aufgenommenen Bild hat in der Mitte eine Reflexion und ist nicht vollständig ausgefüllt.

test_aspect_ratio_and_crop

Prüft, ob Bilder in der Bildpipeline verzerrt oder unerwartet zugeschnitten werden. Nimmt Bilder eines Kreises in allen Formaten auf. Prüft, ob der Kreis nicht verzerrt ist, sich nicht aus der Mitte des Bildes bewegt und sich die Größe bei unterschiedlichen Seitenverhältnissen oder Auflösungen nicht falsch ändert.

Getestete APIs:

Bestanden:Die Bilder sind nicht gestreckt, die Bildmitten weichen um nicht mehr als 3 % voneinander ab und das maximal mögliche Sichtfeld bleibt erhalten.

Fehlermechanismen:

  • Die Kamera ist nicht auf den Kreis ausgerichtet, der auf dem Tablet in der Mitte der aufgenommenen Szene angezeigt wird.
  • Der Kreis im aufgenommenen Bild wird durch die Verarbeitungspipeline verzerrt.
  • Das Bild mit niedrigerer Auflösung wird in der Bildpipeline doppelt zugeschnitten, wodurch sich das Sichtfeld zwischen Bildern mit hoher und niedriger Auflösung unterscheidet.
  • Der Kreis im aufgenommenen Bild wird aufgrund einer Aufnahmeanfrage mit extremem Seitenverhältnis abgeschnitten, wodurch die Höhe oder Breite des Bildes reduziert wird.
  • Der Kreis im aufgenommenen Bild hat in der Mitte eine Reflexion und ist nicht vollständig ausgefüllt.

test_multi_camera_alignment

Testet die Parameter für die Kamerakalibrierung im Zusammenhang mit der Kamerapositionierung für Systeme mit mehreren Kameras. Nimmt mit einer der physischen Kameras ein Bild auf. Findet den Kreismittelpunkt. Projiziert den Kreismittelpunkt für jede Kamera auf die Weltkoordinaten. Vergleicht die Differenz zwischen den Kreismittelpunkten der Kameras in Weltkoordinaten. Projiziert die Weltkoordinate zurück in Pixelkoordinaten und vergleicht sie mit den Originalen, um die Gültigkeit zu prüfen. Vergleicht die Kreisgrößen, um zu prüfen, ob die Brennweiten der Kameras unterschiedlich sind.

Getestete APIs:

Bestanden:Die Mittelpunkte und Größen der Kreise entsprechen den Erwartungen in projizierten Bildern im Vergleich zu aufgenommenen Bildern, wenn Kamerakalibrierungsdaten und Brennweiten verwendet werden.

Fehlermechanismen:

  • LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION und LENS_POSE_ROTATION sind Designwerte und keine tatsächlichen Kalibrierungsdaten.
  • Das Kamerasystem ist nicht für die Testeinrichtung geeignet, z. B. wenn ein Weitwinkel- und ein Ultraweitwinkel-Kamerasystem mit dem RFoV-Testaufbau getestet werden. Weitere Informationen findest du unter Camera ITS-in-a-box – Häufig gestellte Fragen, 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 nicht ändert, ob der Kreis bei den zugeschnittenen Bildern in der Mitte des Frames bleibt und ob sich die Kreisgröße bei einem konstanten Format oder bei verschiedenen Auflösungen nicht ändert (FoV-Prüfung).

Getestete APIs:

Bestanden:Die Bilder sind nicht gestreckt, die Bildmitten weichen um nicht mehr als 3 % voneinander ab und das maximal mögliche Sichtfeld bleibt erhalten.

test_preview_stabilization_fov

Prüft die unterstützten Vorschaugrößen, um sicherzustellen, dass das Sichtfeld entsprechend zugeschnitten wird. Im Test werden zwei Videos aufgenommen, eines mit der Vorschaustabilisierung ON und eines mit der Vorschaustabilisierung 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 innerhalb der Spezifikation liegen.

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

Nimmt Videos eines Kreises in einem Quadrat in allen Videoformaten auf. Extrahiert die Keyframes und prüft, ob sich das Seitenverhältnis des Kreises nicht ändert, ob der Kreis in den zugeschnittenen Bildern in der Mitte bleibt und ob sich die Kreisgröße bei einem konstanten Format oder bei einer anderen Auflösung nicht ändert (FoV-Prüfung).

Getestete APIs:

Bestanden:Die Videoframes sind nicht gestreckt, die Mitte der Frames weicht nicht um mehr als 3 % ab und das maximal mögliche Sichtfeld bleibt erhalten.

scene6

scene6 ist ein Raster aus eindeutig identifizierbaren ArUco-Markierungen. Tests in scene6 können empfindlich auf die Ausrichtung reagieren. Ab Version 15 kannst du daher check_alignment.py im Verzeichnis „tools“ verwenden, um eine Prüfung der Ausrichtung des DUT und des Diagramms zu aktivieren.

scene6

Abbildung 118: Beispiel für scene6.

test_in_sensor_zoom

Testet das Verhalten der Funktion für den Sensor-Zoom der Kamera, die zugeschnittene RAW-Bilder erzeugt.

Wenn der Stream-Anwendungsfall auf CROPPED_RAW festgelegt ist, werden im Test zwei Aufnahmen über den Zoombereich gemacht: ein RAW-Bild mit vollem Sichtfeld und ein zugeschnittenes RAW-Bild. Der Test wandelt die Bilder in RGB-Arrays um, skaliert das zugeschnittene Rohbild in voller Größe auf die von SCALER_RAW_CROP_REGION gemeldete Größe herunter und berechnet die 3D-RMS-Differenz zwischen den beiden Bildern.

Getestete APIs:

Bestanden:Die 3D-RMS-Differenz zwischen dem herunterskalierten, zugeschnittenen Rohbild und dem Rohbild mit vollem Sichtfeld ist kleiner als der im Test festgelegte Schwellenwert.

test_zoom

Testet das Zoomverhalten der Kamera vom Ultraweitwinkel- zum Weitwinkelobjektiv. Nimmt Bilder über den Zoombereich auf und prüft, ob die ArUco-Marker beim Heranzoomen größer werden. Außerdem wird geprüft, ob sich die Position der mittleren Markierung bei jeder Aufnahme vorhersehbar ändert. Der Abstand von der Mitte der mittleren Markierung zur Bildmitte kann sich entweder mit einer konstanten Rate im Verhältnis zum Zoomverhältnis bis zu einem physischen Kamerawechsel ändern oder sich monoton in Richtung der Position derselben Markierung nach einem physischen Kamerawechsel ändern. Die Jetpack Camera App (JCA) muss vor dem Testen auf dem Gerät installiert sein.

Getestete APIs:

Bestanden:Die relative Größe des erfassten ArUco-Markers entspricht dem angeforderten Zoomverhältnis, um zu bestätigen, dass die Kamera richtig zoomt. Der Abstand des Markers zur Bildmitte ändert sich gemäß den in der Testbeschreibung angegebenen Kriterien.

test_zoom, um die Kontur des ArUco-Markers zu finden, der der Mitte am nächsten ist

Abbildung 119: „test_zoom“ zum Ermitteln der Kontur des ArUco-Markers, der der Mitte am nächsten ist.

test_low_latency_zoom

Testet das Zoomverhalten der Kamera bei niedriger Latenz. Nimmt Aufnahmen über den Zoombereich mit android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) auf und prüft, ob die Markierungen in den Ausgabebildern mit den Zoomverhältnissen in den Aufnahmemetadaten übereinstimmen. Dieselbe Kameraaufnahmesitzung wird verwendet, um 3A zu konvergieren und Aufnahmen zu machen.

Getestete APIs:

Bestanden:Die relative Größe der erfassten Markierung entspricht den Metadaten des Zoomverhältnisses.

test_preview_video_zoom_match

Testet, ob während der Aufnahme und des Zoomens in der Videovorschau und der Videoausgabe dieselbe Ausgabe angezeigt und aufgezeichnet wird. Berechnet die Größe der Markierung, die der Mitte am nächsten ist, bei verschiedenen Zoomfaktoren und prüft, ob die Größe der Markierung mit zunehmendem Zoomfaktor zunimmt.

Getestete APIs:

Bestanden:Die relative Größe der erfassten Markierung entspricht dem angeforderten Zoomverhältnis im Video und in der Vorschau.

HD_1280x720_key_frame.png

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

preview_1280x720_key_frame.png

Abbildung 121: preview_1280x720_key_frame.png (vor dem Zoomen)

HD_1280x720_key_frame_zoomed.png

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

preview_1280x720_key_frame_zoomed.png

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

test_preview_zoom

Prüft, ob das Zoomverhältnis jedes Vorschauframes mit den entsprechenden Aufnahmemetadaten vom Ultraweitwinkelobjektiv zum Weitwinkelobjektiv übereinstimmt. Im Test werden Vorschaubilder über den Zoombereich hinweg aufgenommen und die ArUco-Markierung gefunden, die der Mitte am nächsten ist. Anschließend wird geprüft, ob sich die Position der mittleren Markierung bei jeder Aufnahme vorhersehbar ändert. Der Abstand von der Mitte der mittleren Markierung zur Bildmitte kann sich entweder mit einer konstanten Rate im Verhältnis zum Zoomverhältnis bis zu einem physischen Kamerawechsel ändern oder sich monoton in Richtung der Position derselben Markierung nach einem physischen Kamerawechsel ändern.

Getestete APIs:

Bestanden:Die relative Größe der ausgewählten ArUco-Markierung ist für das gemeldete Zoomverhältnis des entsprechenden Aufnahmeergebnisses für alle Vorschauframes korrekt. Die relative Entfernung der ausgewählten Markierung von der Bildmitte ist für das gemeldete Zoomverhältnis des entsprechenden Aufnahmeergebnisses aller Vorschauframes korrekt.

test_preview_zoom-Bilder, die die ausgewählte Markierung am nächsten zur Mitte zeigen

Abbildung 124: test_preview_zoom-Bilder, die die ausgewählte Markierung am nächsten zur Mitte zeigen

test_session_characteristics_zoom

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

Getestete APIs:

Bestanden:Für jede unterstützte SessionConfiguration, die in CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION aufgeführt ist, können sowohl das minimale als auch das maximale Zoomverhältnis erreicht werden.

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 Diagramm mit schrägen Kanten für Schärfeprüfungen. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um bei unterschiedlichen Zoomfaktoren genaue Koordinaten des Hauptrechteckrahmens zu erhalten.

scene7

Abbildung 125. scene7.

test_multi_camera_switch

Mit diesem Test wird geprüft, ob der Wechsel zwischen dem Ultraweitwinkel- (UW) und dem Weitwinkelobjektiv (W) bei der Vorschauaufnahme mit unterschiedlichen Zoomfaktoren zu ähnlichen RGB-Werten führt.

Im Test werden verschiedene Zoomverhältnisse innerhalb des vordefinierten Bereichs verwendet, um eine dynamische Vorschauaufnahme zu erstellen und den Punkt zu ermitteln, an dem die physische Kamera wechselt. Dieser Punkt markiert den Übergang vom Ultraweitwinkel- zum Weitwinkelobjektiv.

Die Frames, die am und vor dem Übergangspunkt 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 Luma-Änderung sowohl für Bilder mit dem Ultraweitwinkel- als auch mit dem Weitwinkelobjektiv im erwarteten Bereich liegt. Bei der AWB-Prüfung wird geprüft, ob die Verhältnisse von Rot-Grün und Blau-Grün sowohl bei UW- als auch bei W-Objektivbildern innerhalb der Schwellenwerte liegen. Bei der AF-Prüfung wird der Schätzwert für die Schärfe anhand der durchschnittlichen Gradientengröße zwischen Bildern mit Ultraweitwinkel- und Weitwinkelobjektiv bewertet.

Wenn der Moiré-Effekt die Ergebnisse bei der Ausführung dieses Tests beeinträchtigt, verwende ein Tablet mit höherer Auflösung aus der Liste der für die Kamera-ITS zugelassenen Tablets.

Getestete APIs:

Bestanden:Der Test gilt als bestanden, wenn die AE- und AWB-Prüfungen bestanden wurden. Die Ergebnisse der AF-Prüfung werden nur für Logging-Zwecke verwendet. Im Folgenden sind die Kriterien für die einzelnen Prüfungen aufgeführt:

  • AE-Prüfung: Die Änderung der Luminanz (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 der grauen Farbfelder 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 für die Aufnahme mit dem W-Objektiv muss höher sein als die Schärfe bei der UW-Aufnahme.

test_multi_camera_switch_gray_uw_y

Abbildung 126. Graues Feld, aufgenommen mit dem Ultraweitwinkelobjektiv.

test_multi_camera_switch_gray_w_y

Abbildung 127. Graues Feld, 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 (Blauton, erhöhte Belichtung, verringerte Belichtung, Gelbton). 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

Testet, ob sich die RGB- und Luma-Werte unterscheiden, wenn die Vorschau in verschiedenen AE- und AWB-Regionen aufgezeichnet wird.

Der Test zeichnet eine 8-sekündige Vorschau auf und führt für jeden Quadranten jeweils 2 Sekunden lang eine AE- und AWB-Messung durch. Der Test extrahiert dann einen Frame aus der Vorschauaufzeichnung jeder Region und führt mit den extrahierten Frames die folgenden AE- und AWB-Prüfungen durch:

  • AE-Prüfung: Es wird geprüft, ob der Frame, der die Region mit verringerter Belichtung misst, einen um mehr als 1% höheren Lumawert hat als der Frame, der die Region mit erhöhter Belichtung misst. Dadurch wird sichergestellt, dass Bilder aufgehellt werden, wenn ein dunkler Bereich 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 um mehr als 2 % höher ist als im Frame mit dem gelben Messbereich. So wird sichergestellt, dass Bilder einen ausgewogenen RGB-Wert haben, wenn ein gelber (warmer) oder blauer (kühler) Bereich gemessen wird.

Getestete APIs:

Bestanden:Die AE- und AWB-Prüfungen sind beide bestanden.

test_ae_awb_regions_dark_region

Abbildung 129: Dunkler Bereich der Belichtungsmessung mit erhöhter Belichtung.

test_ae_awb_regions_light_region

Abbildung 130. Messung des Bildausschnitts: hellerer Bereich mit verringerter Belichtung.

Fehlermechanismen:

  • Die genaue Erkennung aller vier ArUco-Marker ist für diesen Test unerlässlich. 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:

    ArUco-Marker nicht richtig ausgerichtet

    Abbildung 131. ArUco-Markierungen sind nicht richtig ausgerichtet.

test_color_correction_mode_cct

COLOR_CORRECTION_MODE wird bei verschiedenen Farbtemperaturen und Farbtönen getestet, um Änderungen der RGB-Verhältnisse im Vergleich zur Aufnahmeszene scene8 zu prüfen.

Getestete APIs:

Bestanden:Die RGB-Verhältnisse weisen die erwarteten Erhöhungen oder Verringerungen im Verhältnis zu den ausgewählten Farbtemperaturen und Farbtönen auf.

Kriterien für das Überspringen von Tests

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

scene9

scene9 besteht aus Tausenden von Kreisen in zufälligen Größen und Farben, um eine Szene mit sehr geringer Wiederholbarkeit zu erstellen, die JPEG-Komprimierungsalgorithmen stark beansprucht.

scene9 example

Abbildung 132. Beispiel für scene9.

test_jpeg_high_entropy

Testet, ob die JPEG-Komprimierung der Kamera auf scene9 mit hoher Entropie und einem JPEG-Qualitätsfaktor von 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 vom Laufwerk gelesen.

test_jpeg_quality

Testet die JPEG-Komprimierungsqualität der Kamera. Geht die JPEG-Qualitäten von android.jpeg.quality durch und prüft, ob sich die Quantisierungstabellen korrekt ändern.

Getestete APIs:

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

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

Abbildung 133. Durchschnittswerte der Luma- und Chroma-DQT-Matrix der Rückkamera des Pixel 4 im Vergleich zur JPEG-Qualität.

Beispiel für fehlgeschlagenen Test „test_jpeg_quality“

Abbildung 134. Beispiel für einen fehlgeschlagenen Test.

scene_extensions

Die scene_extensions-Tests sind für Kameraerweiterungen vorgesehen und müssen Camera ITS-in-a-Box verwenden, da sie eine genaue Kontrolle der Testumgebung erfordern. Außerdem muss jeglicher Lichteinfall kontrolliert werden. Dazu müssen möglicherweise der Testaufbau, das zu testende Gerät und das Tablet mit einem Abdecktuch abgedeckt und der Lichteinfall vom vorderen Display des zu testenden Geräts beseitigt werden.

scene_hdr

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

scene_hdr

Abbildung 135. Beispiel für scene_hdr.

test_hdr_extension

Testet die HDR-Erweiterung. Nimmt Aufnahmen mit und ohne aktivierte Erweiterung auf und prüft, ob der QR-Code durch die Erweiterung besser erkannt wird.

Getestete APIs:

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

scene_low_light

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

Beispiel für scene_low_light

Abbildung 136. Beispiel für scene_low_light.

test_night_extension

Testet die Nacht-Erweiterung. Nimmt Aufnahmen mit aktivierter Erweiterung auf und führt Folgendes aus:

  • Erkennt das Vorhandensein von 20 Quadraten
  • Berechnet die Luma-Werte, die durch die einzelnen Quadrate begrenzt werden
  • Berechnet den durchschnittlichen Lumawert der ersten 6 Quadrate gemäß der Hilbert-Kurven-Rasterausrichtung
  • Berechnet die Differenz des Lumawerts aufeinanderfolgender Quadrate (z. B. Quadrat 2 – Quadrat 1) bis zu den Quadraten 5 und 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 Aufnahme-Anfrage einen Messbereich, der dem Rechteck entspricht, das das Quadratgitter umschließt. Durch diese Ergänzung ändern sich die Kriterien für das Erreichen des Schwellenwerts.

Getestete APIs:

Karte/Ticket:

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

Das folgende Luminanzdiagramm zeigt, wie ein bestandenes Testergebnis aussieht.

Beispiel für einen bestandenen Test einer Nachtszene bei wenig Licht

Abbildung 137. Beispiel für einen bestandenen Test bei einer Nachtszene mit wenig Licht.

test_low_light_boost_extension

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

  • Erkennt das Vorhandensein von 20 Kartons
  • Berechnet die Luma-Werte, die durch die einzelnen Boxen begrenzt werden
  • Berechnet den durchschnittlichen Lumawert der ersten 6 Quadrate gemäß der Hilbert-Kurven-Rasterausrichtung
  • Berechnet die Differenz des Lumawerts aufeinanderfolgender Quadrate (z. B. Quadrat 2 – Quadrat 1) bis zu den Quadraten 5 und 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 Aufnahme-Anfrage einen Messbereich, der dem Rechteck entspricht, das das Quadratgitter umschließt. Durch diese Ergänzung ändern sich die Kriterien für das Erreichen des Schwellenwerts.

Getestete APIs:

Karte/Ticket:

  • Bei Geräten mit Android 16 oder höher muss der durchschnittliche Lumawert der ersten 6 Quadrate mindestens 54 betragen und der durchschnittliche Unterschied im Lumawert aufeinanderfolgender Quadrate bis zu den Quadraten 5 und 6 muss mindestens 17 betragen.

  • Bei Geräten mit Android 15 und niedriger muss der durchschnittliche Lumawert der ersten sechs Quadrate mindestens 70 betragen und die durchschnittliche Differenz des Lumawerts aufeinanderfolgender Quadrate bis zu den Quadraten 5 und 6 muss mindestens 18 betragen.

scene_tele

Eine wichtige Anforderung für scene_tele-Tests ist, dass der Abstand zum Testbild mindestens dem Mindestfokusabstand des Teleobjektivs entsprechen muss. Da sich dieser Mindestfokusabstand von Gerät zu Gerät unterscheiden kann, musst du deine Konfiguration an die jeweilige Telekamera anpassen.

scene_tele-Einrichtung basierend auf dem Fokusabstand der Weitwinkel- und Telekamera

Abbildung 138: scene_tele-Einrichtung basierend auf der Fokusentfernung der Weitwinkel- und Telekamera.

Weitere Informationen zur Einrichtung der Testhardware findest du unter Einrichtung des Tele-Erweiterungs-Rigs.

scene6_tele

Die scene6_tele-Szene besteht aus einem Raster von ArUco-Markierungen auf weißem Hintergrund.

Wenn scene6_tele-Aufnahmen im modularen Rig überbelichtet aussehen, entferne die Frontplatte des modularen Rigs.

Trenne die WFoV-Testvorrichtung von der Verlängerung und entferne die Smartphone-Halterung.

Trenne die WFoV-Testvorrichtung von der Verlängerung und entferne die Smartphone-Halterung.

Abbildung 139: Trenne die WFoV-Testvorrichtung von der Verlängerung und entferne die Smartphone-Halterung.

remove_front_plate

Abbildung 140: Entferne die Frontplatte.

test_zoom_tele

Testet das Zoomverhalten der Kamera vom Weitwinkel- bis 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 des aufgenommenen ArUco-Markers entspricht dem angeforderten Zoomverhältnis, um zu bestätigen, dass die Kamera richtig zoomt. Der Abstand des Markers zur Bildmitte ändert sich gemäß den in test_zoom aufgeführten Kriterien.

test_preview_zoom_tele

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

Getestete APIs:

Bestanden:Die relative Größe des erfassten ArUco-Markers entspricht dem angeforderten Zoomverhältnis, um zu bestätigen, dass die Kamera korrekt zoomt. Der Abstand des Markers zur Bildmitte ändert sich gemäß den in test_preview_zoom aufgeführten Kriterien.

scene7_tele

scene7_tele ist mit scene7 identisch, aber für das Testen von Teleobjektiven 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 Diagramm mit schrägen Kanten für Schärfeprüfungen. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um bei unterschiedlichen Zoomfaktoren genaue Koordinaten des Hauptrechteckrahmens zu erhalten.

test_multi_camera_switch_tele

Mit diesem Test wird überprüft, ob der Wechsel zwischen dem Weitwinkel- (W) und dem Teleobjektiv (Tele) bei der Vorschauaufnahme mit unterschiedlichen Zoomverhältnissen zu ähnlichen RGB-Werten führt.

Im Test werden verschiedene Zoomverhältnisse innerhalb des vordefinierten Bereichs verwendet, um eine dynamische Vorschauaufnahme zu erstellen und den Punkt zu ermitteln, an dem die physische Kamera wechselt. Dieser Punkt markiert den Übergang vom Weitwinkel- zum Teleobjektiv.

Die Frames, die am und vor dem Übergangspunkt aufgenommen wurden, werden auf AE, AWB und AF analysiert.

Bei der AE-Prüfung wird überprüft, ob die Luma-Änderung sowohl bei Bildern mit dem Weitwinkel- als auch mit dem Teleobjektiv im erwarteten Bereich liegt. Bei der AWB-Prüfung wird geprüft, ob die Verhältnisse von Rot-Grün und Blau-Grün sowohl bei Bildern mit dem Weitwinkel- als auch mit dem Teleobjektiv innerhalb der Schwellenwerte liegen. Bei der AF-Prüfung wird der Schätzwert für die Schärfe anhand der durchschnittlichen Gradientengröße zwischen Bildern mit Weitwinkel- und Teleobjektiv bewertet.

Getestete APIs:

Bestanden:Damit der Test bestanden wird, müssen die Prüfungen für AE, AWB und AF bestanden werden. Für die einzelnen Prüfungen gelten die folgenden Kriterien:

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

scene_video

scene_video ist eine Videoszene, die aus vier verschiedenfarbigen Kreisen besteht, die sich mit unterschiedlichen Framerates vor einem weißen Hintergrund hin- und herbewegen.

Abbildung 141. Beispiel für scene_video.

test_preview_frame_drop

Prüft, ob die angeforderte Vorschau-Framerate bei einer dynamischen Szene beibehalten wird. Dieser Test wird auf allen Kameras ausgeführt, die für Drittanbieter-Apps freigegeben sind.

Getestete APIs:

Bestanden:Die Framerate der Vorschau liegt am Maximum des angeforderten Frameratenbereichs und die durchschnittliche Abweichung zwischen aufeinanderfolgenden Frames ist kleiner als die im Test festgelegte relative Toleranz.

Gen2-Rig / sensor_fusion-basierte Testszenen

feature_combination

Mit den feature_combination-Tests wird geprüft, ob die Funktionen korrekt funktionieren, wenn mehrere Kamerafunktionen gleichzeitig aktiviert sind. Bei diesen Tests wird dasselbe Schachbrettbild verwendet wie in der Sensorfusionsszene.

test_feature_combination

Testet alle Kombinationen aus verschiedenen Stream-Kombinationen, Videostabilisierungsmodi, Ziel-FPS-Bereichen, 10‑Bit-HDR-Videos und Ultra HDR, die vom Kameragerät unterstützt werden.

Unter Android 16 und höher werden beim Test alle Kombinationen unterstützter Funktionen ausgeführt und die Ergebnisse in einer Proto-Datei protokolliert. Fehler-Assertions werden nur für Kombinationen von Features aufgerufen, für die isSessionConfigurationSupported den Wert True zurückgibt.

Getestete APIs:

Bestanden: Für jede unterstützte Funktionskombination:

  • Der Vorschaustream wird stabilisiert, wenn die Vorschaustabilisierung aktiviert ist.
  • Die Framerate der Vorschau liegt innerhalb des konfigurierten AE_TARGET_FPS_RANGE.
  • Der Farbraum des aufgezeichneten Vorschaustreams entspricht dem festgelegten Farbraum.
  • Die Ultra HDR-Aufnahme hat eine gültige Gain Map.

scene_flash

Für die scene_flash-Tests ist eine dunkle Szene in der Sensor-Fusion-Box erforderlich. Unter Android 17 und höher können scene_flash-Tests mit dem Gen2-Rig durchgeführt werden.

test_auto_flash

Testet, ob der automatische Blitz in einer dunklen Szene für die Rück- und Frontkamera ausgelöst wird. Bei Frontkameras wird für den automatischen Blitz das Display verwendet, um die Szene zu beleuchten, nicht ein physischer Blitz. Im Test wird geprüft, ob der automatische Blitz ausgelöst wird. Dazu wird geprüft, ob die Mitte des Kachelbilds bei aktiviertem automatischem Blitz heller ist. Damit der automatische Blitz ausgelöst wird, müssen die Lichter im Testaufbau ausgeschaltet sein. Die Lichter können automatisch mit dem Arduino-Controller ausgeschaltet werden. Die Szene muss vollständig dunkel sein, damit der Test korrekt funktioniert. Die Jetpack Camera App (JCA) muss vor dem Testen auf dem Gerät installiert sein. Der automatische Blitz für Rückkameras wird durch den AE-Status ausgelöst, der automatische Blitz für Frontkameras wird jedoch nicht durch den AE-Status ausgelöst und ist immer aktiviert.

In Android 17 und höher werden Zoomstufen ungleich 1x getestet, um die korrekte Funktion in allen unterstützten Zoombereichen zu überprüfen.

Getestete APIs:

Bestanden:Die Mitte des Kachelbilds mit aktiviertem automatischem Blitz ist bei allen Kameras heller als das Originalbild der Szene.

test_flash_strength

Prüft, ob die Steuerung der Blitzstärke im Modus SINGLE korrekt implementiert ist.

Prüft, ob sich die Blitzstärke bei verschiedenen angeforderten Stärkestufen ändert, wenn das Gerät die Steuerung der Blitzstärke während der Kameranutzung im SINGLE-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, hat die Blitzstärke Auswirkungen auf die Helligkeit. 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 Testaufbau ausgeschaltet werden. Die Lichter können automatisch mit dem Arduino-Controller ausgeschaltet werden. Die Umgebung muss vollständig dunkel sein, damit der Test richtig funktioniert.

Getestete APIs:

Karte/Ticket:

Wenn der automatische Belichtungsmodus ON oder OFF ist, erhöht sich die Helligkeit der Bildbereiche, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_SINGLE_STRENGTH_MAX_LEVEL erhöht wird. Wenn der automatische Belichtungsmodus ON_AUTO_FLASH ist, liegt der Helligkeitsunterschied der Bildbereiche innerhalb der Toleranz, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_SINGLE_STRENGTH_MAX_LEVEL erhöht wird.

test_led_snapshot

Es wird getestet, ob die LED-Snapshots das Bild übersättigen oder tönen.

Bei diesem Test wird der Sensor Fusion Box ein Beleuchtungscontroller 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 eingestellt. Während dieser Aufnahme führt der Test eine Voraufnahmesequenz aus, wobei der Trigger aePrecapture auf START gesetzt ist, und setzt die Aufnahmeabsicht auf Preview, um die Aufnahme mit Blitz zu machen.

Da die Aufnahme aufgrund des Blitzes einen markanten Hotspot hat, wird beim Test der Mittelwert des Blitzbildes der gesamten Aufnahme berechnet und geprüft, ob der Wert im Bereich (68, 102) liegt. Um zu prüfen, ob der Weißabgleich des Bildes angemessen ist, werden beim Test die Rot-Grün- und Blau-Grün-Verhältnisse berechnet und geprüft, ob die Verhältnisse zwischen 0,95 und 1,05 liegen.

Getestete APIs:

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

test_night_mode_indicator

Testet die Funktionalität der Nachtmodusanzeige, einer Funktion, die angibt, ob die Kamera bei schlechten Lichtverhältnissen betrieben wird und von einer Standbildaufnahme mit der Kameraerweiterung „Nachtmodus“ profitieren würde. 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 Nachtmodusanzeige die Lichtverhältnisse während der Kameravorschau korrekt wiedergibt. Der Test führt die folgenden Schritte aus:

  1. Initialisierung: Der Test initialisiert ein ItsSession und ruft Kameraeigenschaften ab. Außerdem wird eine Verbindung zum Beleuchtungscontroller hergestellt.
  2. Bedingungen für das Überspringen:Der Test wird übersprungen, wenn das Gerät das erforderliche API-Level oder die Nachtmodus-Anzeige nicht unterstützt.
  3. Camera2-Sitzung:
    • Der Test startet eine Vorschau-Aufnahmesitzung mit einer Camera2-Sitzung.
    • Das Licht wird eingeschaltet und ein Vorschaubild wird aufgenommen.
    • Im Test wird geprüft, ob die Anzeige für den Nachtmodus den Status OFF hat.
    • Das Licht wird ausgeschaltet und ein Vorschaubild wird aufgenommen.
    • Im Test wird geprüft, ob die Anzeige für den Nachtmodus den Status ON hat.
  4. Sitzung mit Kameraerweiterung:
    • Der Test wiederholt das gleiche Verfahren wie für die Camera2-Sitzung, verwendet jedoch eine CameraExtension-Sitzung mit der Erweiterung EXTENSION_NIGHT.
  5. Bereinigung: Der Test schließt ItsSession und gibt den Beleuchtungscontroller frei.

Getestete APIs:

Karte/Ticket:

  • Wenn das Licht eingeschaltet ist, sollte die Nachtmodusanzeige den Status OFF haben.
  • Wenn das Licht ausgeschaltet ist, sollte die Nachtmodusanzeige den Status ON haben.
  • Gilt sowohl für Camera2- als auch für CameraExtension-Sitzungen.

test_preview_min_frame_rate

Testet, ob die Framerate der Vorschau in einer dunklen Szene korrekt abnimmt. Damit dieser Test ordnungsgemäß funktioniert, müssen die Lichter im Test-Rig vom Controller oder manuell vom Testoperator ausgeschaltet werden.

Getestete APIs:

Bestanden:Die Framerate der Vorschau liegt am unteren Ende des angeforderten Frameratenbereichs und die Abweichung zwischen den Frames ist geringer als die im Test festgelegte absolute Toleranz.

test_torch_strength

Prüft, ob die Steuerung der Blitzstärke im Modus TORCH korrekt implementiert ist.

Prüft, ob sich die Blitzstärke bei verschiedenen angeforderten Stärkestufen ä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, hat die Blitzstärke Auswirkungen auf die Helligkeit. Wenn der Modus ON_AUTO_FLASH ist, hat die Blitzstärke keine Auswirkungen auf die Helligkeit. Prüft, ob die Blitzlichtstärke während der gesamten Dauer einer Bilderserie gleich bleibt, und simuliert eine Videoaufnahmesitzung. Für den Test müssen die Lichter im Testaufbau ausgeschaltet werden. Die Lichter können automatisch mit dem Arduino-Controller ausgeschaltet werden. Die Szene muss vollständig dunkel sein, damit der Test korrekt funktioniert.

Getestete APIs:

Karte/Ticket:

Wenn der automatische Belichtungsmodus ON oder OFF ist, erhöht sich die Helligkeit der Bildburst-Patches, 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 Bildbereiche innerhalb der Toleranz, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_TORCH_STRENGTH_MAX_LEVEL erhöht wird.

scene_gen2_chart

In Android 17 und höher verwendet scene_gen2_chart das Gen2-Papierdiagramm.

Diese Testkarte besteht aus Gesichtsproben, einem QR-Code, Graustufenfeldern, einem Siemensstern, einer Farbkarte und schrägen Quadraten.

test_chart_gen2

Abbildung 142. Beispiel für ein Gen2-Diagramm.

test_tonemap_sequence

In diesem Test wird die Standard-Tone-Mapping-Kurve eines Geräts mit einer linearen Kurve und zwei exponentiellen Kurven (eine mit gleichmäßigen Punkten und eine mit ungleichmäßigen Punkten) verglichen. Damit das Ergebnis als bestanden gilt, muss die Helligkeit der Standardkurve die der linearen und exponentiellen Kurven überschreiten. Außerdem muss die lineare Kurve heller als die exponentiellen Kurven sein und die beiden exponentiellen Kurven sollten ähnliche Helligkeitsstufen haben.

Außerdem wird die Genauigkeit der Standardkurve des Geräts überprüft. Dazu wird die Standardkurve extrahiert, neu eingegeben und dann die Helligkeit des resultierenden Bildes mit dem Bild der ursprünglichen Standardkurve verglichen.

Diagramm der Test-Tonemap-Sequenz

Abbildung 143. Test-Tonemap-Sequenzdiagramm.

Getestete APIs:

Bestanden:Der Helligkeitsunterschied zwischen der Standardkurve und der linearen Kurve beträgt mehr als 15%, während der Unterschied zwischen den beiden exponentiellen Kurven weniger als 8 % beträgt.

test_multi_camera_switch

Mit diesem Test wird die Farb- und Belichtungskonsistenz bei dynamischen Zoomübergängen überprüft. Es wird geprüft, ob beim Wechsel zwischen dem Ultraweitwinkel- und dem Weitwinkelobjektiv während der Vorschauaufnahme nahezu identische CIELAB-Werte beibehalten werden, um sichtbare Abweichungen in der Nutzererfahrung zu vermeiden.

Die Testausführung führt eine dynamische Vorschauaufnahme über einen vordefinierten Zoombereich aus, um den physischen „Übergangspunkt“ der Kamera auszulösen, an dem vom Ultraweitwinkelobjektiv zum Weitwinkelobjektiv gewechselt wird. Der Test identifiziert den genauen Frame, in dem der Objektivwechsel stattfindet. Die Frames unmittelbar vor und nach diesem Übergangspunkt werden erfasst und auf Stabilität bei der automatischen Belichtung (AE) und dem automatischen Weißabgleich (AWB) analysiert.

Bei der AE-Prüfung wird bestätigt, dass die Luma-Schwankungen während des Objektivwechsels innerhalb eines akzeptablen Bereichs bleiben. Bei der AWB-Prüfung wird geprüft, ob die Rot-Grün- und Blau-Grün-Verhältnisse innerhalb der definierten Schwellenwerte für Farbneutralität liegen.

Getestete APIs:

Bestanden:Damit der Test bestanden wird, müssen die folgenden AE- und AWB-Prüfungen bestanden werden:

  • AE-Prüfung: Die Änderung der Luminanz (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 der grauen Farbfelder 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.

uw_dynamic_range_patch_cell_8

Abbildung 144. Graues Feld, aufgenommen mit dem Ultraweitwinkelobjektiv.

w_dynamic_range_patch_cell_7

Abbildung 145. Graues Feld, aufgenommen mit dem Weitwinkelobjektiv.

scene_ip

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

Anforderungen an die Hardwareeinrichtung

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

  • Die Tests werden in der ITS-in-a-Box für Gen2-Kameras ausgeführt.
  • Die Beleuchtungs- und Servocontroller, die Teil des Gen2-Rigs sind, werden zur Steuerung der Testumgebung verwendet.
  • Im Gen2-Rig befindet sich ein Testdiagramm.

test_chart_gen2

Abbildung 146: Beispiel für Gen2chart_sample.

Kriterien für das Ü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 einer primären Front- und Rückkamera (z. B. ein Tablet oder Fernseher).

test_default_jca_ip

Nimmt mit der Standard-Kamera-App und der JCA unter kontrollierten Lichtbedingungen Bilder des Test-Feature-Charts auf und führt die folgenden Prüfungen durch:

  • Sichtfeld:Es wird geprüft, ob die Standard-Kamera-App und JCA-Aufnahmen dasselbe Sichtfeld haben. Bei dieser Prüfung wird die Funktion „QR-Code in der Mitte“ verwendet, die aus dem aufgenommenen Diagrammbild extrahiert wurde.

  • Helligkeit:Es wird geprüft, ob der Helligkeitsunterschied zwischen der Standard-Kamera-App und der JCA nicht mehr als 10 beträgt. Bei dieser Prüfung wird das Patch für den Dynamikbereich zur Helligkeitsmessung verwendet.

  • Weißabgleich:Es wird geprüft, ob der Unterschied beim Weißabgleich zwischen der Standard-Kamera-App und der JCA nicht größer als 4 ist. Bei dieser Prüfung wird das Patch für den Dynamikbereich zur Helligkeitsmessung verwendet.

  • Farbwiedergabe:Es wird geprüft, ob der Unterschied bei der Farbwiedergabe zwischen der Standard-Kamera-App und der JCA nicht größer als 6 ist.

Bestanden:Der Test besteht die Prüfungen für Sichtfeld, Helligkeit und Weißabgleich. Unter Android 16 ist dieser Test nicht vorgeschrieben (NOT_YET_MANDATED). Unter Android 17 und höher sind die Paritätsprüfungen für Sichtfeld, Helligkeit und Weißabgleich vorgeschrieben. Die Prüfung der Farbwiedergabe ist in Android 17 nicht vorgeschrieben (NOT_YET_MANDATED).

test_jca_jpegr_ip

Prüft, ob der Unterschied beim Weißabgleich zwischen dem JPEG_R-JCA-Vorschauschnappschuss und den aufgenommenen Bildern nicht größer als 4 ist.

Getestete APIs:

Bestanden:Der Unterschied beim Weißabgleich zwischen dem JCA-Vorschauschnappschuss und dem aufgenommenen JPEG_R-Bild liegt innerhalb des Schwellenwerts (Standardwert ist 4).

sensor_fusion

Für Sensorfusionstests sind bestimmte Smartphonebewegungen vor einem Schachbrettmuster und ArUco-Markern erforderlich. Für optimale Ergebnisse muss die Testkarte flach montiert sein. Nicht flache Diagramme wirken sich auf die Rotationsberechnungen für viele der Tests aus. Das Diagramm muss die Rückseite der Sensorfusionsbox ausfüllen. Drucken Sie es dazu im Format 17 × 17 Zoll. (43 × 43 cm). Die sensor_fusion-Tests können mit der Sensor Fusion Box automatisiert werden.

Diagramm zur Sensorfusion

Abbildung 147. Diagramm zur Sensorfusion

Diagramm zur Sensorfusion in Rig

Abbildung 148: Sensorfusionsdiagramm, das die Rückseite der Sensorfusionsbox ausfüllt.

test_lens_intrinsic_calibration

Prüft, ob sich der optische Mittelpunkt der intrinsischen Parameter des Objektivs ändert, wenn sich das Objektiv aufgrund der optischen Bildstabilisierung (OIS) bewegt. Wenn intrinsische Objektivproben unterstützt werden, wird getestet, ob sich der optische Mittelpunkt der intrinsischen Objektivproben ändert, wenn sich das Objektiv aufgrund von OIS bewegt.

Getestete APIs:

Bestanden:Das optische Zentrum der intrinsischen Parameter des Objektivs ändert sich um mindestens 1 Pixel. Wenn intrinsische Linsenproben unterstützt werden, ändern sich die optischen Zentren der intrinsischen Linsenproben um mindestens 1 Pixel.

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

test_lens_intrinsic_calibration_example.png

Abbildung 149. Beispiel für ein test_lens_intrinsic_calibration-Diagramm, das die Änderungen der Hauptpunkte in Pixeln für jeden Frame zeigt.

test_multi_camera_frame_sync

Es wird getestet, ob die Zeitstempel der von der logischen Kamera aufgenommenen Frames innerhalb von 10 ms liegen. Dazu werden die Winkel der Quadrate im Schachbrettmuster berechnet, um den Zeitstempel zu bestimmen.

Getestete APIs:

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

test_preview_distortion

Testet, ob die Verzerrung in jedem Vorschauframe korrigiert wird, der bei verschiedenen Zoomstufen aufgenommen wird. Für jeden Vorschauframe berechnet der Test ideale Punkte basierend auf den intrinsischen und extrinsischen Kameraparametern.

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 im Bild werden verwendet, um den Bereich des Verzerrungsfehlers visuell zu erkennen.

test_preview_distortion_example.jpg

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

Getestete APIs:

Bestanden:Der normalisierte Verzerrungsfehler jedes Vorschauframes ist kleiner als der im Test festgelegte Schwellenwert.

test_preview_stabilization

Tests, bei denen sich das stabilisierte Vorschauvideo weniger dreht als das Gyroskop.

Getestete APIs:

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

Hier sind Beispielvideos mit und ohne Stabilisierung:

Abbildung 151: Beispielvideo mit Stabilisierung

Abbildung 152. Beispielvideo ohne Stabilisierung.

test_sensor_fusion

Testet die Zeitstempeldifferenz zwischen der Kamera und dem Gyroskop für AR- und VR-Anwendungen. Das Smartphone wird zehnmal um 90 Grad vor dem Schachbrettmuster 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.

Der test_sensor_fusion-Test generiert eine Reihe von Diagrammen. Die beiden wichtigsten Diagramme für das Debugging sind:

  • test_sensor_fusion_gyro_events: Zeigt die Gyroskop-Ereignisse für das Smartphone während des Tests an. Bewegungen in x- und y-Richtung deuten darauf hin, dass das Smartphone nicht sicher an der Wandhalterung befestigt ist. Dadurch sinkt die Wahrscheinlichkeit, dass der Test bestanden wird. Die Anzahl der Zyklen im Diagramm hängt von der Schreibgeschwindigkeit beim Speichern von Frames ab.

    Beispiel für Gyroskope-Ereignisse in „test_sensor_fusion“

    Abbildung 153: Beispiel für Gyroskope-Ereignisse in „test_sensor_fusion“

  • test_sensor_fusion_plot_rotations: Zeigt die Ausrichtung der Gyroskop- und Kameraereignisse an. Dieses Diagramm muss eine übereinstimmende Bewegung zwischen Kamera und Gyroskop auf +/-1 ms zeigen.

    Beispiel für test_sensor_fusion-Plotrotationen

    Abbildung 154. Beispiel für Drehungen im Diagramm „test_sensor_fusion“.

Getestete APIs:

Bestanden:Der Zeitstempelversatz von Kamera und Gyroskop beträgt weniger als 1 ms, wie in 7.3.9 High Fidelity-Sensoren in der CDD beschrieben.

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 besteht, um den Test auszuführen.
  • Die Tafel ist nicht flach montiert. Das Diagramm test_sensor_fusion_plot_rotations enthält Frames, in denen die Gyroskop- und Kamerarotation erheblich variieren, wenn sich die Kamera durch die Teile des Diagramms dreht, die nicht flach sind.
  • 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 etwas aus dem Gehäuse des Smartphones herausragt. Dadurch wird das Smartphone beim Anbringen der Rückseite an der Wandhalterung geneigt.

test_video_stabilization

Eingestellt:Dieser Test wird ab Android 17 nicht mehr unterstützt. Ab Android 17 wird dieser Test durch test_video_stabilization_jca ersetzt.

Tests, bei denen sich das stabilisierte Video weniger dreht als das Gyroskop.

Getestete APIs:

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

Im Folgenden finden Sie Beispielvideos mit und ohne Stabilisierung.

Abbildung 155. Beispielvideo mit Stabilisierung

Abbildung 156: Beispielvideo ohne Stabilisierung.

test_video_stabilization_jca

Tests, bei denen Videos mit dem JCA stabilisiert wurden, drehen sich weniger als das Gyroskop. Der JCA muss vor dem Testen auf dem Gerät installiert werden.

Getestete APIs:

Bestanden:Die maximale Winkeldrehung über Frames, die aus mit der JCA aufgenommenen Videos extrahiert wurden, beträgt weniger als 70% der Gyroskopdrehungen (4).

Diffusorbasierte Testszene

scene5

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

Befestige zur Vorbereitung der Szene einen Diffusor vor der Kamera und richte die Kamera auf eine Lichtquelle mit etwa 2.000 Lux. Für scene5 aufgenommene Bilder erfordern diffuses Licht ohne erkennbare Merkmale. Hier ist ein Beispielbild:

scene5 example

Abbildung 157: Beispiel für die Aufnahme von scene5.

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

test_lens_shading_and_color_uniformity

Prüft, ob die Vignettierungskorrektur richtig angewendet wird und die Farbe einer einfarbigen Szene gleichmäßig verteilt ist. Führt diesen Test für einen YUV-Frame mit Auto-3A durch. Die Vignettierung wird anhand des Y-Kanals bewertet. Misst den durchschnittlichen y-Wert für jeden angegebenen Beispielblock und bestimmt, ob der Test bestanden wurde, indem er mit dem mittleren y-Wert verglichen wird. Der Test der Farbgleichmäßigkeit wird im Rot-Grün- und Blau-Grün-Bereich ausgewertet.

Getestete APIs:

Bestanden: Im angegebenen Radius des Bildes muss die Varianz des Rot-Grün- und Blau-Grün-Werts weniger als 20% betragen, um den Test zu bestehen.

Fehlermechanismen:

  • Übermäßige Vignettierung in Bildern
  • Artefakte mit schwarzen Rändern in Bildern

test_lens_shading_and_color_uniformity_y_plane

Abbildung 158. test_lens_shading_and_color_uniformity_y_plane.

test_lens_shading_and_color_uniformity_color_uniformity_result

Abbildung 159: test_lens_shading_and_color_uniformity_color_uniformity

test_lens_shading_and_color_uniformity_lens_shading_result

Abbildung 160: test_lens_shading_and_color_uniformity_lens_shading_result

Tablet-basierte Testszene mit großem Farbraum

scene_wide_gamut

scene_wide_gamut ist ein rechteckiger Rahmen, der in vier gleich große Quadranten unterteilt ist, die jeweils eine andere Farbe haben. Dazu muss das Tablet das Diagramm mit einem großen Farbraum anzeigen und das zu testende Gerät ein Foto des Displays mit einem großen Farbraum aufnehmen.

Mit diesen Tests wird überprüft, ob das aufgenommene Bild dem richtigen Farbprofil und Farbbereich entspricht.

test_display_p3

Testet die Display P3-Aufnahme im JPEG-Format mit der ColorSpaceProfiles API. Es wird geprüft, ob das aufgenommene JPEG-Bild ein geeignetes ICC-Profil im Header hat und ob das Bild einen bestimmten Perzentilwert von Farben außerhalb des sRGB-Farbraums enthält.

Getestete APIs:

Bestanden:Das JPEG enthält ein Display P3-ICC-Profil und mehr als 1 % der Farben liegen außerhalb des sRGB-Farbraums.

test_display_p3-Beispiel

Abbildung 161. Beispiel für test_display_p3.