Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Kamera-ITS-Tests

Auf dieser Seite finden Sie eine umfassende Liste der Tests der Camera Image Test Suite (ITS), die Teil des CTS Verifier (Android Compatibility Test Suite) ist. ITS-Tests sind Funktionstests. Das bedeutet, dass nicht die Bildqualität gemessen wird, sondern ob alle beworbenen Kamerafunktionen wie erwartet funktionieren. In diesem Dokument erfahren Entwickler und Tester, welche Funktion die einzelnen Tests haben und wie sie Fehler beheben können.

Kamera-ITS-Gatter führen Tests nach erforderlichen Kameraeigenschaften, API-Ebene und MPC-Ebene (Media Performance Class) durch. Für die API-Ebene verwendet ITS ro.product.first_api_level, um Tests zu steuern, die in einer bestimmten API-Ebene hinzugefügt wurden und die auf negative Nutzererfahrungen bei Funktionen in niedrigeren API-Ebenen prüfen. ITS verwendet ro.vendor.api_level, um Tests für Funktionen zu steuern, die in einer bestimmten API-Ebene hinzugefügt wurden und neue Hardwarefunktionen erfordern. Wenn ro.odm.build.media_performance_class für ein Gerät definiert ist, müssen je nach MPC-Ebene bestimmte Tests ausgeführt werden.

Die Tests sind nach Szenen gruppiert:

scene0:Metadaten, Jitter, Gyroskop, Vibration erfassen
scene1: Belichtung, Empfindlichkeit, Belichtungsmesswert (EV)-Kompensation, YUV im Vergleich zu JPEG und RAW
scene2:Gesichtserkennung, Tests, für die Farbszenen erforderlich sind
scene3:Kantenschärfung, Objektivbewegung
scene4: Seitenverhältnis, Zuschnitt, Sichtfeld
scene5:Tönung der Linse
scene6:Zoom
scene7: Schalter für mehrere Kameras
scene8:Messung der Belichtungs- und Weißabgleichsregion
scene9: JPEG-Komprimierung
scene_extensions:Kameraerweiterungen
scene_tele:Umschalten zum Teleobjektiv
scene_flash:Automatischer Blitz, minimale Framerate
scene_video: Frame-Drops
sensor_fusion:Zeitversatz zwischen Kamera und Gyroskop
feature_combination:Kombinationen von Funktionen
scene_ip: Bildparität zwischen der Standardkamera-App und der Jetpack Camera App (JCA)

In den einzelnen Abschnitten finden Sie eine Beschreibung der einzelnen Szenen.

scene0

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

test_jitter

Misst das Jitter bei Kamerazeitstempeln.

Getestete APIs:

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

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

Prüft die Gültigkeit von Metadateneinträgen anhand der Aufnahmeergebnisse und der Kameraeigenschaften. Bei diesem Test werden die Werte für Belichtung und Verstärkung verwendet, da der Bildinhalt nicht wichtig ist.auto_capture_request

Getestete APIs:

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

test_request_capture_match

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

Getestete APIs:

Pass:Die angeforderten und erfassten Metadatenwerte stimmen für alle Aufnahmen überein.

test_sensor_events

Bei Geräten, die die Sensorfusion unterstützen, 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, also sich das Gerät nicht im Standbymodus befindet.

Getestete APIs:

Überspringen:Es werden Ereignisse für jeden Sensor empfangen.

test_solid_color_test_pattern

Prüft, ob Testmuster mit durchgehender Farbe für die Stummschaltung der Kamera richtig generiert werden. Wenn die Kamera stummgeschaltet werden kann, müssen auch Testmuster mit einfarbigen Hintergründen unterstützt werden. Wenn die Stummschaltung der Kamera nicht unterstützt wird, werden Testmuster mit durchgehender Farbe nur getestet, wenn die Funktion beworben wird.

Wenn Rohbilder 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 es gibt nur geringe Abweichungen im Bild.

test_test_pattern

Hier wird der Parameter android.sensor.testPatternMode getestet, um Frames für jedes gültige Testmuster zu erfassen. Außerdem wird geprüft, ob die Frames für Volltonfarben und Farbbalken korrekt generiert werden. Dieser Test umfasst die folgenden Schritte:

Erfasst Bilder für alle unterstützten Testmuster.
Führt eine Richtigkeitsprüfung für ein Testmuster mit durchgehender Farbe und Farbbalken durch.

Getestete APIs:

Pass: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 Umwandlung des Testmusters von RAW in YUV mit linearer Tonkarte. Für diesen Test ist android.sensor.testPatternMode = 2 (COLOR_BARS) erforderlich, um ein perfektes Bildmuster für die Tonwertkorrektur zu generieren. Prüft, ob die Pipeline korrekte Farbausgaben mit linearer Tonkarte und idealer Bildeingabe hat (erfordert test_test_patterns).

Getestete APIs:

Pass: YUV und RAW sehen ähnlich aus.

test_tonemap_curve – Beispiel für ein Rohbild

Abbildung 3: Rohbeispiel für „test_tonemap_curve“.

YUV-Beispiel für test_tonemap_curve

Abbildung 4: YUV-Beispiel für „test_tonemap_curve“.

test_unified_timestamp

Prüft, ob sich Bild- und Bewegungssensorereignisse in derselben Zeitdomäne befinden.

Getestete APIs:

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

test_vibration_restriction

Hier wird getestet, ob die Vibration des Geräts wie erwartet funktioniert.

Getestete APIs:

Nicht bestanden:Das Gerät vibriert nicht, wenn es durch die API zur Einschränkung der Kameraaudioausgabe stummgeschaltet wurde.

scene1_1

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

RFoV-Kameras können im WFoV- oder RFoV-Testgestell getestet werden. Wenn eine RFoV-Kamera im WFoV-Testgestell getestet wird, wird das Diagramm um 2/3 skaliert, um einige Grenzen für das graue Diagramm im FoV anzugeben, damit 3A konvergiert. Ausführlichere Beschreibungen der Kameratestvorrichtungen finden Sie unter Kamera ITS-in-a-Box.

Beispiel für Szene 1

Abbildung 5: Vollständiges Diagramm für Szene 1 (links), Diagramm mit 2/3 der Größe (rechts)

test_ae_precapture_trigger

Hier wird der AE-Zustandsautomat bei Verwendung des Pre-Capture-Triggers getestet. Es werden fünf manuelle Anfragen erfasst, bei denen AE deaktiviert ist. Die letzte Anfrage enthält einen AE-Trigger vor der Aufnahme, der ignoriert werden sollte, da die AE deaktiviert ist.

Getestete APIs:

Pass:AE konvergiert.

test_auto_vs_manual

Tests, bei denen automatisch und manuell aufgenommene Fotos verglichen wurden, sehen identisch aus.

Getestete APIs:

Pass:Die für jede Aufnahme gemeldeten manuellen Weißabgleichsverstärkungen und ‑transformationen stimmen mit dem automatischen Weißabgleich estimate aus dem 3A-Algorithmus der Kamera überein.

Beispiel für den automatischen Test „test_auto_vs_manual“

Abbildung 6: Beispiel für den automatischen Test „test_auto_vs_manual“.

Beispiel für den Weißabgleich „test_auto_vs_manual“

Abbildung 7: Beispiel für den Weißabgleich mit test_auto_vs_manual

Beispiel für die manuelle Weißabgleichstransformation „test_auto_vs_manual“

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

test_black_white

Prüft, ob das Gerät vollständig schwarze und weiße Bilder erzeugt. Es werden zwei Aufnahmen gemacht, die erste mit extrem niedrigem Verstärkungsgrad und kurzer Belichtungszeit, was zu einem schwarzen Foto führt, und die zweite mit extrem hohem Verstärkungsgrad und langer Belichtungszeit, was zu einem weißen Foto führt.

Getestete APIs:

Karte/Ticket:Erstellt Schwarz-Weiß-Bilder. Die gesättigten Kanäle weißer Bilder haben RGB-Werte von [255, 255, 255] mit einer Fehlertoleranz von weniger als 1 %.

test_black_white, black example

Abbildung 9: test_black_white, Beispiel für Schwarz

Beispiel für die manuelle Weißabgleichstransformation „test_auto_vs_manual“

Abbildung 10: test_black_white, weißes Beispiel

test_black_white plot means example

Abbildung 11: test_black_white, plot means example.

test_burst_capture

Prüft, ob die gesamte Aufnahmepipeline mit der Geschwindigkeit der Aufnahme in voller Größe und der CPU-Zeit Schritt halten kann.

Getestete APIs:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_BURST_CAPTURE

Überspringen:Erfasst eine Burst-Aufnahme von Bildern in voller Größe und prüft auf Frame-Aussetzer und Bildhelligkeit.

test_burst_sameness_manual

Nimmt fünf Serien mit jeweils 50 Bildern mit der Einstellung „Manuelle Aufnahme“ auf und prüft, ob sie alle identisch sind. Mit diesem Test kannst du feststellen, ob es vereinzelte Frames gibt, die anders verarbeitet werden oder Artefakte aufweisen.

Getestete APIs:

Karte/Ticket:Die Bilder sind optisch und in den RGB-Werten identisch.

Fehlgeschlagen:Zeigt einen Anstieg oder Rückgang des RGB-Durchschnittsdiagramms zu Beginn jedes Bursts an.

Toleranz ist 3% für first_API_level < 30
Toleranz von 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

Prüft, ob die RAW-Streams nicht zugeschnitten werden können.

Getestete APIs:

Überspringen:YUV-Bilder werden zentriert zugeschnitten, RAW-Bilder jedoch nicht.

test_crop_region_raw comp raw crop example

Abbildung 14: Beispiel für einen Rohausschnitt mit dem Tool „test_crop_region_raw“

test_crop_region_raw comp raw full example

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

Beispiel für die YUV-Zuschneidung von test_crop_region_raw comp

Abbildung 16: Beispiel für die Funktion „test_crop_region_raw“ mit YUV-Zuschnitt

Beispiel für test_crop_region_raw_yuv_full

Abbildung 17: Vollständiges Beispiel für test_crop_region_raw in YUV

test_crop_regions

Teste, ob die zugeschnittenen Bereiche funktionieren. Es wird ein vollständiges Bild aufgenommen und es werden Patches aus fünf verschiedenen Regionen (Ecken und Mitte) erstellt. Es werden Bilder mit Zuschnitt für die fünf Regionen aufgenommen. Vergleicht die Werte des Patches und des zugeschnittenen Bilds.

Getestete APIs:

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

test_ev_compensation

Prüft, ob die Belichtungskorrektur angewendet wird. Der Test besteht aus einem einfachen und einem fortgeschrittenen Abschnitt.

Im einfachen Abschnitt wird getestet, ob die Belichtungskorrektur mit einem mit CONTROL_AE_COMPENSATION_STEP erstellten Bereich angewendet wird. Bei jedem Wert für die Belichtungskorrektur werden acht Frames erfasst.

Im Bereich „Erweitert“ wird die Belichtung in acht Schritten erhöht und die gemessene Helligkeit mit der erwarteten Helligkeit verglichen. Die erwarteten Werte werden anhand der Bildhelligkeit des Bilds ohne Belichtungskorrektur berechnet. Der erwartete Wert wird übersättigt, wenn die berechneten Werte den tatsächlichen Bereich der Bildwerte überschreiten. Der Test schlägt fehl, wenn die erwarteten Werte und die gemessenen Werte nicht übereinstimmen oder die Bilder innerhalb von fünf Schritten überbelichtet sind.

Getestete APIs:

Grundlegender Abschnitt:Die Bilder zeigen eine zunehmende Belichtung innerhalb von fünf Schritten, ohne dass sie überbelichtet werden.

test_ev_compensation_basic

Abbildung 18: test_ev_compensation_basic

Erweiterter Abschnittspass:Erfasst eine Erhöhung der Luminanz, wenn die Einstellung für die Belichtungskorrektur erhöht wird. Die acht Frames, die für jede Belichtungskorrektureinstellung erfasst werden, haben stabile Luminanzwerte.

test_ev_compensation_advanced_plot_means

Abbildung 19: test_ev_compensation_advanced_plot_means

test_exposure_x_iso

Hier wird getestet, ob eine konstante Belichtung erreicht wird, wenn ISO und Belichtungszeit variieren. Es werden mehrere Aufnahmen gemacht, bei denen ISO und Belichtungszeit so gewählt sind, dass sie sich gegenseitig ausgleichen. Die Ergebnisse sollten dieselbe Helligkeit haben, aber im Laufe der Sequenz sollte das Bild immer unruhiger werden. Prüft, ob die Mittelwerte der Stichprobenpixel nahe beieinander liegen. Prüfen Sie, ob die Bilder nicht auf 0 oder 1 begrenzt sind, da sie sonst wie flache Linien aussehen würden. Der Test kann auch mit RAW-Bildern ausgeführt werden. Legen Sie dazu das Flag debug in Ihrer Konfigurationsdatei fest.

Getestete APIs:

Ausreichend:Die Bilder haben dieselbe Helligkeit, werden aber bei höherem ISO-Wert rauschiger. RGB-Ebenen sind flach, wenn der Wert von ISO*Belichtung im gesamten getesteten Verstärkungsbereich konstant ist.

Ausfallmechanismus:In der folgenden Abbildung weichen die normalisierten RGB-Ebenen-Mittelwerte (y-Achse) mit steigenden Werten des Verstärkungsmultiplikators (x-Achse) von den Werten des niedrigen Verstärkungsmultiplikators 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

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

Getestete APIs:

android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL

Nicht bestanden:Die Bilder [2, 3, 6, 8, 10, 12, 13] haben eine höhere ISO oder Belichtung und sind in der folgenden Abbildung mit höheren RGB-Mittelwerten zu sehen.

Beispiel für die Mittelung von „test_latching“

Abbildung 23: Beispiel für Mittelwertdiagramme für „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

Hier wird getestet, ob die Geräteverarbeitung in lineare Pixel umgewandelt werden kann. Erfasst eine Abfolge von Aufnahmen, bei denen das Gerät auf ein einheitliches Ziel gerichtet ist.

Getestete APIs:

Pass: Die Werte für R, G und B müssen mit zunehmender Empfindlichkeit linear ansteigen.

Beispiel für die Mittelung von Test_Linearity-Plots

Abbildung 37: Beispiel für ein Mittelwertdiagramm für „test_linearity“.

test_locked_burst

Testet die 3A-Sperre und den YUV-Burst (mit automatischer Einstellung). Dieser Test sollte auch auf eingeschränkten Geräten ohne MANUAL_SENSOR oder PER_FRAME_CONTROLS bestehen. Bei diesem Test wird die YUV-Bildkonsistenz geprüft, während die Framerate-Prüfung im CTS erfolgt.

Getestete APIs:

Pass:Die Aufnahmen sind einheitlich.

Beispiel für test_locked_burst frame0

Abbildung 38: Beispiel für test_locked_burst frame0

Beispiel für test_locked_burst frame1

Abbildung 39: Beispiel für test_locked_burst frame1

test_locked_burst_frame2

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

scene1_2

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

test_param_color_correction

Prüft, ob die android.colorCorrection.*-Parameter angewendet werden, wenn sie festgelegt sind. Es werden Aufnahmen mit unterschiedlichen Transformierungs- und Verstärkungswerten aufgenommen und getestet, ob sie sich entsprechend unterscheiden. Die Transformation und die Verstärkung werden so gewählt, dass die Ausgabe immer röter oder blauer wird. Es wird eine lineare Tonkarte verwendet.

Bei der Tonmapping-Technologie werden bei der Bildverarbeitung eine Reihe von Farben einer anderen Reihe zugeordnet, um das Erscheinungsbild von Bildern mit hohem Dynamikumfang in einem Medium mit begrenztem Dynamikumfang anzunähern.

Getestete APIs:

Übergeben:R- und B-Werte werden gemäß der Transformation verstärkt.

Beispiel für Mittelwertdiagramm für „test_param_color_correction“

Abbildung 41: Beispiel für den Mittelwert des Diagramms „test_param_color_correction“

In den folgenden Abbildungen steht die X-Achse für die Aufnahmeanfragen: 0 = Einheit, 1 = roter Boost und 2 = blauer Boost.

test_param_color_correction req=0 unity example

Abbildung 42: test_param_color_correction req=0 unity example

test_param_color_correctness req=1 roter Boost – Beispiel

Abbildung 43: Beispiel für einen Rot-Boost mit test_param_color_correctness req=1

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 gesetzt, damit klar ist, ob der Blitz ausgelöst wurde oder nicht. Außerdem wird eine lineare Tonkarte verwendet. Prüft die Mitte des Kachelbilds, um festzustellen, ob ein großer Farbverlauf entsteht, der darauf hinweist, dass der Blitz ausgelöst wurde.

Getestete APIs:

Nicht bestanden:Die Mitte des Kachelnbilds weist einen großen Farbverlauf auf. Das bedeutet, dass der Blitz ausgelöst wurde.

test_param_flash_mode 1 example

Abbildung 45: Beispiel für „test_param_flash_mode 1“

Beispiel für die Kachel „test_param_flash_mode 1“

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

Beispiel für test_param_flash_mode_2

Abbildung 47: Beispiel für „test_param_flash_mode 2“

Beispiel für die Kachel „test_param_flash_mode 2“

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

test_param_noise_reduction

Prüft, ob der Parameter android.noiseReduction.mode nach der Festlegung korrekt angewendet wird. Bilder werden bei gedimmtem Licht aufgenommen. Verwendet einen hohen analogen Verstärkungsgrad, um zu verhindern, dass das aufgenommene Bild verrauscht. Nimmt drei Bilder auf: ohne Rauschunterdrückung, schnell und in hoher Qualität. Es wird auch ein Bild mit niedriger Verstärkung und deaktivierter Rauschunterdrückung aufgenommen und die Abweichung davon als Baseline verwendet. Je höher das Signal-Rausch-Verhältnis (SNR), desto besser die Bildqualität.

Getestete APIs:

android.hardware.camera2.CaptureRequest#NOISE_REDUCTION_MODE

Pass:Der SNR variiert mit den verschiedenen Geräuschunterdrückungsmodi und verhält sich ähnlich wie in der folgenden Grafik:

Beispiel für die Darstellung von SNRs mit test_param_noise_reduction

Abbildung 49: Beispiel für ein SNR-Diagramm mit 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 high gain nr=0“.

test_param_noise_reduction high gain nr=1 example

Abbildung 51: Beispiel für „test_param_noise_reduction high gain nr=1“.

test_param_noise_reduction high gain nr=2 example

Abbildung 52: Beispiel für „test_param_noise_reduction high gain nr=2“.

test_param_noise_reduction high gain nr=3 example

Abbildung 53: Beispiel für test_param_noise_reduction mit hoher Verstärkung (nr=3)

Beispiel für niedrige Verstärkung bei „test_param_noise_reduction“

Abbildung 54: Beispiel für einen niedrigen Wert für „test_param_noise_reduction“

test_param_shading_mode

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

Getestete APIs:

Übergang:Die Schattierungsmodi werden umgeschaltet und die Objektivschattierungskarten werden wie erwartet geändert.

test_param_shading_mode-Objektivschattenkarte, Modus 0, Schleife 0, Beispiel

Abbildung 55: Test_param_shading_mode-Objektivschattenkarte, Modus 0, Schleife 0, Beispiel.

test_param_shading_mode-Objektivschattenkarte, Modus 1, Schleife 0, Beispiel

Abbildung 56: Beispiel für eine Blendenblendenabbildung für den Testparameter „test_param_shading_mode“, Modus 1, Schleife 0

test_param_shading_mode – Blendungskarte für Objektiv, Modus 2, Schleife 0 – Beispiel

Abbildung 57: Beispiel für eine Blendenkarte für den Testparameter „test_param_shading_mode“, Modus 2, Schleifennummer 0.

test_param_tonemap_mode

Prüft, ob der Parameter android.tonemap.mode angewendet wird. Wendet unterschiedliche Tonwertkurven auf die einzelnen R-, G- und B-Kanäle 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 eine lineare Tonkarte, aber n=1 hat einen steileren Farbverlauf. Der G‑Kanal (grün) ist für das Bild n=1 heller.
test2: Dieselbe Tonkarte, aber unterschiedliche Länge. Mehrere identische Bilder.

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 Rohempfindlichkeit nach der Steigerung. Erfasst eine Reihe von RAW- und YUV-Bildern mit unterschiedlicher Empfindlichkeit, sendet eine Kombination aus RAW-Empfindlichkeitssteigerungen und prüft, ob der Mittelwert der Ausgabepixel mit den Anfrageeinstellungen übereinstimmt.

Getestete APIs:

Pass:Rohbilder werden dunkler, wenn der Boost erhöht wird, 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 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 Mittelung der Rohdaten im Diagramm „test_post_raw_sensitivity_boost“

Abbildung 66: Beispiel für den Mittelwert eines Rohdiagramms für „test_post_raw_sensitivity_boost“

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 Beispiel

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 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 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 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 YUV s=3585 boost=0100“.

test_post_raw_sensitivity_boost_yuv_plot_means

Abbildung 72: test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

Es werden eine Reihe von Rohbildern mit zunehmender Belichtungszeit aufgenommen und die Pixelwerte gemessen.

Getestete APIs:

Durchlassen:Wenn Sie den ISO-Wert (Verstärkung) erhöhen, werden die Pixel lichtempfindlicher, sodass sich der Plot nach links verschiebt.

Beispiel für test_raw_exposure ISO=55

Abbildung 73: Beispiel für test_raw_exposure ISO=55

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

Beispiel für „test_raw_exposure ISO=132“

Abbildung 74: Beispiel für test_raw_exposure ISO=132

Beispiel für test_raw_exposure ISO=209

Abbildung 75: Beispiel für test_raw_exposure ISO=209

Beispiel für „test_raw_exposure ISO=286“

Abbildung 76: Beispiel für test_raw_exposure ISOs=286

Beispiel für test_raw_exposure ISO=363

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

test_raw_exposure_s=440

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

test_reprocess_noise_reduction

Tests, bei denen android.noiseReduction.mode für die erneute Verarbeitung von Anfragen angewendet wird. Hier werden Bilder aufgenommen, die mit der Kamera bei gedimmtem Licht neu verarbeitet wurden. Verwendet einen hohen analogen Gewinn, um zu prüfen, ob das aufgenommene Bild verrauscht ist. Es werden drei neu verarbeitete Bilder aufgenommen: ohne Rauschunterdrückung, schnell und in hoher Qualität. Es wird ein neu verarbeitetes Bild mit niedrigem Gewinn und deaktivierter Rauschunterdrückung aufgenommen und die Abweichung davon als Baseline verwendet.

Getestete APIs:

android.hardware.camera2.CaptureResult#NOISE_REDUCTION_MODE

Überspringen:SCHNELL >= AUS, HQ >= SCHNELL und HQ >> AUS

Typische Darstellung des SNR im Vergleich zum NR-Modus

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

test_tonemap_sequence

Hier wird eine Sequenz von Aufnahmen mit verschiedenen Tonwertkurven getestet. Erfasst drei manuelle Aufnahmen mit einer linearen Tonkarte. Nimmt drei manuelle Aufnahmen mit der Standardtonkarte auf. Berechnet das Delta zwischen jedem aufeinanderfolgenden Frame-Paar.

Getestete APIs:

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

Beispiel für test_tonemap_sequence i=0

Abbildung 80: Beispiel für test_tonemap_sequence i=0

test_tonemap_sequence i=1 example

Abbildung 81: Beispiel für test_tonemap_sequence i=1

Beispiel für test_tonemap_sequence i=2

Abbildung 82: Beispiel für test_tonemap_sequence i=2

Beispiel für test_tonemap_sequence i=3

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

Beispiel für test_tonemap_sequence i=5

Abbildung 85: Beispiel für test_tonemap_sequence i=5

test_yuv_jpeg_all

Prüft, ob alle angegebenen Größen und Formate für die Bildaufnahme funktionieren. Es wird eine manuelle Anfrage mit einer linearen Tonkarte verwendet, damit YUV und JPEG bei der Umwandlung durch das image_processing_utils-Modul gleich aussehen. Bilder werden standardmäßig nicht gespeichert. Sie können sie jedoch speichern, indem Sie debug_mode aktivieren.

Getestete APIs:

Pass:Alle Bildzentren haben in RGB-konvertierten Bildern eine maximale RMS-Differenz (Wert eines Signals) von 3% der höchsten YUV-Auflösung.

Beispiel für test_yuv_jpeg_all

Abbildung 86: Beispiel für test_yuv_jpeg_all

test_yuv_plus_dng

Hier wird getestet, ob die angegebenen Größen und Formate für die Bildaufnahme funktionieren.

Getestete APIs:

android.hardware.camera2.CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_RAW

Erfolgreich: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 mit einer Unterszenenstruktur, um die lange 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:

Überspringen:Die Metadaten gelten für alle Aufnahmen und die manuellen Einstellungen wirken sich nicht auf die zweite automatische Aufnahme aus. Die Korrektur der Objektivschatten für die Aufnahmen wird dargestellt.

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-Raw-Modellparameter korrekt sind. Die Grafik zeigt die gemessene Abweichung eines mittleren Bereichs der Graukarte in Rohaufnahmen, die bei verschiedenen Empfindlichkeiten aufgenommen wurden. Diese Werte werden mit der Abweichung verglichen, die bei jeder Empfindlichkeit vom DNG-Rauschmodell in der HAL der Kamera erwartet wird (basierend auf den O,S-Parametern, die in den Aufnahmeergebnisobjekten zurückgegeben werden). Weitere Informationen zum DNG-Rauschmodell finden Sie im Dokument DNG-Rauschmodell.

Getestete APIs:

Pass:Die DNG-Raw-Modellparameter 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

In Tests sahen konvertierte YUV-Bilder und JPEG-Bilder von Geräten identisch aus. Dabei werden die RGB-Werte der Mitte von 10% des Bildes berechnet und verglichen.

Getestete APIs:

android.graphics.ImageFormat#JPEG

Bestanden:Die durchschnittliche RGB-Unterschied 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

Erfasst eine Reihe von Rohbildern mit steigender Verstärkung und misst das Rauschen. Nimmt nur Raw-Aufnahmen in einem Burst auf.

Getestete APIs:

Pass:Jede Aufnahme ist rauschiger als die vorherige, da der Gewinn erhöht wird.

Die Abweichung der Rasterzelle mit den Mittelungsstatistiken wird verwendet.

test_raw_burst_sensitivity_variance

Abbildung 92: test_raw_burst_sensitivity_variance

test_raw_sensitivity

Es werden eine Reihe von Rohbildern mit steigender Empfindlichkeit aufgenommen und der Rauschenpegel (die Abweichung) in den mittleren 10% des Bildes gemessen. Prüft, ob jeder Aufnahme mehr Rauschen zu sehen ist als der vorherigen.

Getestete APIs:

Pass:Die Varianz steigt mit jedem Schuss.

test_raw_sensitivity_variance

Abbildung 93: test_raw_sensitivity_variance

test_yuv_plus_jpeg

Hier wird getestet, ob ein einzelner Frame sowohl als YUV- als auch als JPEG-Ausgabe erfasst wird. Es wird eine manuelle Anfrage mit einer linearen Tonkarte verwendet, damit YUV und JPEG bei der Umwandlung durch das image_processing_utils-Modul gleich aussehen.

Getestete APIs:

Pass: YUV- und JPEG-Bilder sind ähnlich und haben eine RMS-Abweichung (Wert eines Signals) von weniger als 1 %.

test_yuv_plus_jpeg im JPEG-Format

Abbildung 94: test_yuv_plus_jpeg im JPEG-Format

test_yuv_plus_jpeg im YUV-Format

Abbildung 95: test_yuv_plus_jpeg im YUV-Format

test_yuv_plus_raw

Hier wird getestet, ob ein einzelner Frame sowohl als Raw-Datei (10-Bit- und 12-Bit-Raw) als auch als YUV-Ausgabe erfasst werden kann, sofern unterstützt. Es wird eine manuelle Anfrage mit linearer Tonkarte verwendet, sodass Raw und YUV voraussichtlich identisch sind. Vergleicht die RGB-Werte von 10% der Pixel im Zentrum der konvertierten RGB-Bilder. Protokolleandroid.shading.mode

Getestete APIs:

Pass: YUV- und Rohbilder sind ähnlich und haben eine RMS-Differenz (Quadratwurzel der Mittelquadratsumme eines Signals) von weniger als 3,5 %.

test_yuv_plus_raw_shading=1_raw.jpg

Abbildung 96: test_yuv_plus_raw_shading=1_raw.jpg

test_yuv_plus_raw_shading=1_yuv.jpg

Abbildung 97: test_yuv_plus_raw_shading=1_yuv.jpg

test_sensitivity_priority

Tests CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY mit verschiedenen ISO-Einstellungen, um eine Korrelation zwischen höherem ISO und erhöhtem Rauschen nachzuweisen.

Getestete APIs:

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

Testkriterien für das Überspringen

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

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

test_exposure_time_priority

Tests CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY mit verschiedenen Belichtungszeiten, um eine stabile Helligkeit im Bereich zu prüfen, in dem ISO kompensieren kann.

Getestete APIs:

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

Testkriterien für das Überspringen

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

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

scene2_a

scene2_a hat drei Gesichter mit grauem Hintergrund und neutraler Kleidung. Die Gesichter haben unterschiedliche Hauttöne. Das Diagramm muss richtig ausgerichtet sein, damit die Gesichtserkennung optimal funktioniert.

scene2_a example

Abbildung 98: Beispiel für „scene2_a“.

test_autoframing

Hier wird das automatische Bildausschnitt-Verhalten des Kamerageräts getestet. Es wird stark herangezoomt, sodass keine Gesichter in der Szene zu sehen sind. Der Modus „Automatische Bildausrichtung“ wird aktiviert, indem AUTOFRAMING in CaptureRequest auf True gesetzt wird. Es wird geprüft, ob alle Gesichter in der ursprünglichen Szene erkannt werden können, wenn der Status konvergiert, d. h. wenn AUTOFRAMING_STATE in CaptureResult auf AUTOFRAMING_STATE_CONVERGED gesetzt ist.

Getestete APIs:

Pass:Alle drei Gesichter werden erkannt.

test_display_p3

Tests der Display P3-Aufnahme in JPEG mit der ColorSpaceProfiles API. Prüft, ob das aufgenommene JPEG-Bild in der Kopfzeile ein geeignetes ICC-Profil hat und ob das Bild Farben außerhalb des sRGB-Farbraums enthält.

Getestete APIs:

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

test_effects

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

Getestete APIs:

Überspringen:Hier wird das Bild mit den Effekten OFF und ein Schwarzweißbild mit den Effekten MONO aufgenommen.

test_effects_MONO

Abbildung 99: test_effects_MONO

test_exposure_keys_consistent

In diesem Test wird die durchschnittliche Luminanz einer Aufnahme mit aktivierter AE mit einer Aufnahme verglichen, bei der die Belichtungsparameter (Empfindlichkeit, Belichtungszeit, Framedauer, Post-Raw-Empfindlichkeitssteigerung) manuell angewendet werden, die in der CaptureResult der Aufnahme mit aktivierter AE empfangen wurden.

Getestete APIs:

Pass:Die relative Differenz bei der Luminanz zwischen den beiden Aufnahmen beträgt weniger als 4 Prozent.

test_format_combos

Hier werden verschiedene Kombinationen von Ausgabeformaten getestet.

Getestete APIs:

Pass:Alle Kombinationen wurden erfasst.

test_num_faces

Hier wird die Gesichtserkennung getestet.

Getestete APIs:

Pass:Es werden drei Gesichter gefunden.

Beispiel für den Modus „test_num_faces“ der Gesichtserkennung 1

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

test_reprocess_uv_swap

Prüft, ob bei der YUV-Neuverarbeitung die U- und V-Ebenen nicht vertauscht werden. Dazu wird die Summe der absoluten Differenzen (SAD) zwischen dem neu verarbeiteten Bild und einer nicht neu verarbeiteten Aufnahme berechnet. Wenn das Ersetzen der U- und V-Ebenen der Ausgabe der neu verarbeiteten Aufnahme zu einer erhöhten SAD führt, wird davon ausgegangen, dass die Ausgabe die richtigen U- und V-Ebenen hat.

Getestete APIs:

Überspringen:Die U- und V-Ebenen werden nicht vertauscht.

test_reprocess_uv_swap

Abbildung 101: Beispiel für „test_reprocess_uv_swap“.

scene2_b

test_preview_num_faces

Die Gesichtserkennung wird in der Vorabversion mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen getestet.

Getestete APIs:

Pass:Es werden drei Gesichter mit Gesichtsmarkierungen in den Begrenzungsrahmen für Gesichter gefunden.

test_num_faces_fd_mode_1

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

test_yuv_jpeg_capture_sameness

Es werden zwei Bilder mit den größten gemeinsamen YUV- und JPEG-Formaten mit demselben Seitenverhältnis wie das größte JPEG-Format aufgenommen, wobei die Auflösung 1920 x 1440 nicht überschreitet. Legt jpeg.quality auf 100 fest 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 überprüft, ob die YUV-Ausgaben für alle unterstützten Stream-Anwendungsfälle dem YUV-Wert mit dem Anwendungsfall STILL_CAPTURE in etwa entsprechen.

Getestete APIs:

Erfolgreich:YUV- und JPEG-Bilder für den Anwendungsfall STILL_CAPTURE unterscheiden sich um weniger als 3% RMS (Quadratwurzel aus dem Mittelquadratwert eines Signals). YUV-Bilder für alle unterstützten Anwendungsfälle unterscheiden sich um weniger als 10% RMS von YUV-Bildern für den Anwendungsfall STILL_CAPTURE.

scene2_c

test_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

Pass:Es werden drei Gesichter gefunden.

test_num_faces_fd_mode_1

Abbildung 103: Beispiel für den Modus „test_num_faces“ der Gesichtserkennung.

test_jpeg_capture_perf_class

Hier wird die JPEG-Aufnahmelatenz für die Leistungsklasse S gemäß Abschnitt 2.2.7.2 Kamera im CDD getestet.

Bestanden:Die Latenz der JPEG-Aufnahme von camera2 für 1080p-Auflösung muss unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Hauptkameras unter 1.000 ms liegen, wie im CTS-Kamera-Leistungstest gemessen.

test_camera_launch_perf_class

Hier wird die Latenz beim Starten der Kamera für die S‑Leistungsklasse gemäß Abschnitt 2.2.7.2 Kamera im CDD getestet.

Bestanden:Die Kamera 2-Startlatenz (Öffnen der Kamera bis zum ersten Vorschauframe) muss unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Hauptkameras unter 600 ms liegen, wie im CTS-Kamera-Leistungstest gemessen.

test_default_camera_hdr

Prüft, ob die Standardkameraaufnahme für die Leistungsklasse 15 Ultra HDR ist, wie in Abschnitt 2.2.7.2 Kamera des CDD angegeben.

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

scene2_d

test_preview_num_faces

Die Gesichtserkennung wird in der Vorabversion mit einer größeren Vielfalt an Hauttönen in Gesichtsszenen getestet.

Getestete APIs:

Pass:Es werden drei Gesichter mit Gesichtsmarkierungen in den Begrenzungsrahmen für Gesichter gefunden.

scene2_e

test_continuous_picture

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

Getestete APIs:

Pass: Das 3A-System stabilisiert sich bis zum Ende einer Aufnahme mit 50 Frames.

test_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden drei Gesichter gefunden.

scene2_f

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

scene2_f example

Abbildung 104: Beispiel für „scene2_f“.

test_preview_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

Pass:Es werden drei Gesichter mit Gesichtsmarkierungen 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 Profilansichten mit weißem Hintergrund und weißer Kleidung. Die Gesichter haben eine große Bandbreite an Hauttönen und einen hohen Kontrast zum Hintergrund.

Abbildung 106: Beispiel für „scene2_g“.

test_preview_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

Pass:Es werden drei Gesichter mit Gesichtsmarkierungen 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 Diagramm-Extraktionsmethode, um das Diagramm in der Szene zu finden. Aus diesem Grund haben die meisten gespeicherten Bilder keine Rahmen wie die Bilder für Szene 1, 2 oder 4, sondern nur das Diagramm. Das Diagramm muss richtig ausgerichtet sein, damit die Diagrammsuche optimal funktioniert.

test_edge_enhancement

Prüft, ob der Parameter android.edge.mode richtig angewendet wird. Erfasst Bilder, die nicht noch einmal verarbeitet werden müssen, für jeden Randmodus und gibt die Schärfe des Ausgabebilds und die Metadaten des Aufnahmeergebnisses zurück. Verarbeitet eine Aufnahmeanfrage mit einem bestimmten Randmodus, einer bestimmten Empfindlichkeit, Belichtungszeit, Fokusdistanz und einem Parameter für die Ausgabefläche.

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

Getestete APIs:

android.hardware.camera2.CaptureRequest#EDGE_MODE

Betroffene Kameraparameter:

EDGE_MODE

test_edge_enhancement_edge=0

Abbildung 108: Beispiel für test_edge_enhancement edge=0

Beispiel für test_edge_enhancement edge=1

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

Beispiel für test_edge_enhancement edge=2

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

test_flip_mirror

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

Gespiegelte, gedrehte oder gekippte Bilder sind an dem Rautensymbol in der Mitte zu erkennen.

Pass:Das Bild ist nicht umgedreht, gespiegelt oder gedreht.

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

Abbildung 111: Beispiel für einen Szenen-Patch vom Typ „test_flip_mirror“.

test_imu_drift

Prüft, ob die IMU (Inertial Measurement Unit) 30 Sekunden lang eine stabile Ausgabe hat, während sich das Gerät nicht bewegt und eine HD-Vorschau aufnimmt.

Getestete APIs:

Karte/Ticket:

Die Abweichung des Gyroskops beträgt während des Tests weniger als 0,01 Rad.
Die Abweichung der Gyroskopmessung beträgt während des Tests weniger als 1E-7 rad²/s²/Hz.
Die Abweichung des Drehvektors beträgt während des Tests weniger als 0,01 Rad.
(Noch nicht vorgeschrieben) Die Abweichung des Gyroskops beträgt weniger als 1 Grad pro Sekunde.

Beispiel für die Gyroskopabweichung von test_imu_drift

Abbildung 112: Beispiel für die Gyroschiefe von „test_imu_drift“.

Beispiel für den Drehvektor-Abweichungstest

Abbildung 113: Beispiel für die Abweichung des Drehvektors von test_imu_drift.

test_landscape_to_portrait

Prüft, ob die Überschreibung von Quer- in Hochformat für horizontal ausgerichtete Sensoren richtig funktioniert.

Getestete APIs:

Erfolgreich:Der Test findet ein Diagramm mit der erwarteten Drehung (0 Grad, wenn die Überschreibung von Quer- in Hochformat deaktiviert ist, 90 Grad, wenn sie aktiviert ist).

Beispiel für test_landscape_to_portrait

Abbildung 114: Beispiel für „test_landscape_to_portrait“

test_lens_movement_reporting

Prüft, ob das Flag für die Objektivbewegung korrekt gemeldet wird. Es werden 24 Bilder aufgenommen, wobei die ersten 12 Frames auf die von 3A ermittelte optimale Fokusdistanz und die letzten 12 Frames auf die minimale Fokusdistanz eingestellt sind. Etwa bei Frame 12 bewegt sich das Objektiv, wodurch die Schärfe nachlässt. Die Schärfe stabilisiert sich schließlich, wenn sich das Objektiv in der Endposition befindet.

Das Flag für die Objektivbewegung sollte in allen Frames gesetzt werden, in denen die Schärfe in den ersten Frames mittelmäßig bis scharf ist, wobei sich das Objektiv bei der optimalen Brennweite nicht bewegt, und in den letzten Frames, in denen sich das Objektiv bei der minimalen Brennweite nicht bewegt. Der genaue Frame, in dem sich das Objektiv bewegt, ist nicht wichtig. Wichtig ist, dass das Bewegungsflag gesetzt wird, wenn sich das Objektiv bewegt.

Getestete APIs:

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

Fehlermechanismen:

lens_moving: True (android.hardware.camera2.CaptureResult#LENS_STATE = 1) in test_log.DEBUG wird nur in Frames beansprucht, in denen sich die Schärfe nicht ändert.
Bei Frames mit lens_moving: False (android.hardware.camera2.CaptureResult#LENS_STATE = 0) in test_log.DEBUG ist die Schärfe im Vergleich zu den ersten Frames bei optimaler Brennweite oder den letzten Frames bei minimaler Brennweite unterschiedlich.

test_reprocess_edge_enhancement

Prüft, ob unterstützte Methoden zur Nachbearbeitung für die Kantenschärfung ordnungsgemäß funktionieren. Verarbeitet eine Aufnahmeanfrage mit einem bestimmten Modus für die Nachbearbeitung von Kanten und vergleicht verschiedene Modi für die Aufnahme mit deaktivierten Modi für die Nachbearbeitung von Kanten.

Getestete APIs:

Pass: Die Schärfe der verschiedenen Kantenmodi ist korrekt. HQ (Modus 2) ist schärfer als OFF (Modus 0) und die Verbesserung zwischen den verschiedenen Modi ist ähnlich.

Beispiel für ein Diagramm für test_reprocess_edge_enhancement

Abbildung 115: 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 mit check_alignment.py im Tools-Verzeichnis eine Prüfung der DUT und der Diagrammausrichtung aktivieren.

Beispiel für Szene 4

Abbildung 116: Beispiel für „scene4“.

test_30_60fps_preview_fov_match

Prüft, ob 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. Prüft, ob das Seitenverhältnis des Kreises konstant bleibt, der Mittelpunkt des Kreises stabil bleibt und der Radius des Kreises konstant bleibt.

Getestete APIs:

Bestanden:Bilder werden nicht gedehnt, die Mitte der Bilder unterscheidet sich nicht um mehr als 3 % und die maximale Seitenverhältnisänderung zwischen Videos mit 30 fps und 60 fps beträgt nicht mehr als 7,5 %.

Fehlermechanismen:

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

test_aspect_ratio_and_crop

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

Getestete APIs:

Pass:Bilder werden nicht gestreckt, die Mitte der Bilder unterscheidet sich nicht um mehr als 3 % und das maximal mögliche Sichtfeld wird beibehalten.

Fehlermechanismen:

Die Kamera ist nicht mit dem 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 ist aufgrund einer Aufnahmeanfrage mit extremem Seitenverhältnis zugeschnitten, wodurch die Höhe oder Breite des Bildes reduziert wird.
Der Kreis im aufgenommenen Bild hat eine Reflexion in der Mitte und ist nicht vollständig ausgefüllt.

test_multi_camera_alignment

Hier werden die Kamerakalibrierungsparameter für die Kamerapositionierung bei Mehrkamerasystemen getestet. Mit den physischen Unterkameras der Multi-Kamera wird ein Foto mit einer der physischen Kameras aufgenommen. Damit wird der Mittelpunkt des Kreises ermittelt. Projektiert den Mittelpunkt des Kreises auf die Weltkoordinaten für jede Kamera. Vergleicht den Unterschied zwischen den Kreiszentren der Kameras in Weltkoordinaten. Die Weltkoordinaten werden in Pixelkoordinaten zurückprojiziert und mit den Originalen verglichen, um ihre Gültigkeit zu prüfen. Vergleicht die Kreisgrößen und prüft, ob sich die Brennweiten der Kameras unterscheiden.

Getestete APIs:

Pass:Die Mittelpunkte und Größen der Kreise sind in den projizierten Bildern wie erwartet, verglichen mit den aufgenommenen Bildern mit Kamerakalibrierungsdaten und Brennweiten.

Fehlermechanismen:

LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION und LENS_POSE_ROTATION sind Designwerte und keine tatsächlichen Kalibrierungsdaten.
Das Kamerasystem ist für die Testeinrichtung nicht geeignet, z. B. wenn ein Weitwinkel- und ein Ultraweitwinkelkamerasystem mit dem RFoV-Testgestell getestet werden soll. Weitere Informationen finden Sie unter Camera ITS-in-a-box FAQ Q1.

test_preview_aspect_ratio_and_crop

Ähnlich wie beim test_aspect_ratio_and_crop-Test für Standbilder wird bei den unterstützten Vorschauformaten geprüft, ob die Vorschauframes nicht unangemessen gestreckt oder zugeschnitten sind. Prüft, ob sich das Seitenverhältnis des Kreises nicht ändert, der Kreis bei den zugeschnittenen Bildern in der Mitte des Frames bleibt und die Kreisgröße sich bei einem konstanten Format oder bei verschiedenen Auflösungen nicht ändert (FoV-Prüfung).

Getestete APIs:

Pass:Bilder werden nicht gestreckt, die Mitte der Bilder unterscheidet sich nicht um mehr als 3 % und das maximal mögliche Sichtfeld wird beibehalten.

test_preview_stabilization_fov

Prüft die unterstützten Vorschaugrößen, um sicherzustellen, dass das Sichtfeld richtig zugeschnitten wird. Im Test werden zwei Videos aufgenommen, eines mit VorschaustabilisierungON und eines mit VorschaustabilisierungOFF. Aus jedem Video wird ein repräsentativer Frame ausgewählt und analysiert, um zu prüfen, ob die Änderungen des Sichtfelds in den beiden Videos den Spezifikationen entsprechen.

Getestete APIs:

Pass:Das Seitenverhältnis des Kreises bleibt ungefähr gleich, die Mitte des Kreises bleibt stabil und die Größe des Kreises ändert sich um nicht mehr als 20%.

test_video_aspect_ratio_and_crop

Ermöglicht die Aufnahme von Videos eines Kreises in einem Quadrat in allen Videoformaten. Die Keyframes werden extrahiert und es wird geprü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:

Pass:Videoframes werden nicht gedehnt, die Mitte der Frames unterscheidet sich nicht um mehr als 3 % und das maximal mögliche Sichtfeld wird beibehalten.

scene5

scene5 erfordert eine gleichmäßig beleuchtete graue Szene. Dazu wird ein Diffusor über das Kameraobjektiv gelegt. Wir empfehlen den folgenden Diffusor: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

Zur Vorbereitung der Szene befestigen Sie einen Diffusor vor der Kamera und richten Sie die Kamera auf eine Lichtquelle mit etwa 2.000 Lux. Für scene5 aufgenommene Bilder benötigen Sie diffuses Licht, ohne dass Details zu sehen sind. Hier ist ein Beispielbild:

Beispiel für Szene 5

Abbildung 117: Beispiel für eine Szene 5-Aufnahme

test_lens_shading_and_color_uniformity

Prüft, ob die Korrektur der Objektivschatten korrekt angewendet wird und die Farbe einer monochromen, einheitlichen Szene gleichmäßig verteilt ist. Führt diesen Test an einem YUV-Frame mit automatischer 3A-Funktion aus. Die Objektivabschattung wird anhand des Y-Kanals bewertet. Der durchschnittliche y-Wert für jeden angegebenen Beispielblock wird gemessen und durch Vergleich mit dem mittleren y-Wert wird „Pass“ oder „Fail“ ermittelt. Der Test für die Farbuniformität wird im Rot-Grün- und Blau-Grün-Farbraum durchgeführt.

Getestete APIs:

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

scene6

scene6 ist ein Raster mit eindeutig identifizierbaren ArUco-Markierungen. Tests in scene6 können empfindlich auf die Ausrichtung reagieren. Ab Version 15 können Sie check_alignment.py im Tools-Verzeichnis verwenden, um eine Prüfung der DUT und der Diagrammausrichtung zu aktivieren.

scene6

Abbildung 118: Beispiel für scene6

test_in_sensor_zoom

Hier wird das Verhalten der Zoomfunktion des Kamerasensors getestet, die zu zugeschnittenen Rohbildern führt.

Wenn der Stream-Anwendungsfall auf CROPPED_RAW festgelegt ist, werden beim Test zwei Aufnahmen im Zoombereich gemacht: ein Rohbild mit vollem Sichtfeld und ein zugeschnittenes Rohbild. Dabei werden die Bilder in RGB-Arrays umgewandelt, das zugeschnittene Rohbild in Originalgröße wird auf die von SCALER_RAW_CROP_REGION angegebene Größe herunterskaliert und der 3D-RMS-Unterschied zwischen den beiden Bildern wird berechnet.

Getestete APIs:

Erfolgreich:Der 3D-RMS-Unterschied zwischen dem herunterskalierten zugeschnittenen Rohbild und dem Rohbild mit vollem Sichtfeld liegt unter dem im Test festgelegten Grenzwert.

test_zoom

Hier wird das Zoomverhalten der Kamera vom Ultraweitwinkel- zum Weitwinkelobjektiv getestet. Es werden Aufnahmen im gesamten Zoombereich gemacht und geprüft, ob die ArUco-Markierungen größer werden, wenn die Kamera heranzoomt. Außerdem wird geprüft, ob sich die Position der Mittelmarkierung bei jeder Aufnahme vorhersehbar ändert. Der Abstand zwischen dem Mittelpunkt der Mittelmarkierung und dem Bildmittelpunkt kann sich entweder mit konstanter Geschwindigkeit in Bezug auf das Zoomverhältnis ändern, bis die Kamera physisch gewechselt wird, oder sich nach einem physischen Kamerawechsel monoton in Richtung der Position derselben Markierung ändern. Die Jetpack Camera App (JCA) muss vor dem Test auf dem Gerät installiert sein.

Getestete APIs:

Erfolgreich:Die relative Größe der aufgenommenen ArUco-Markierung stimmt mit dem angeforderten Zoomverhältnis überein, um zu prüfen, ob die Kamera richtig heranzoomt. Außerdem ändert sich der Abstand der Markierung zur Bildmitte gemäß den in der Testbeschreibung angegebenen Kriterien.

„test_zoom“, um die Kontur der ArUco-Markierung zu finden, die sich am nächsten am Zentrum befindet

Abbildung 119: „test_zoom“, um die Kontur der ArUco-Markierung zu finden, die dem Zentrum am nächsten ist.

test_low_latency_zoom

Hier wird das Zoomverhalten der Kamera mit niedriger Latenz getestet. Er nimmt mit android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) Aufnahmen im gesamten Zoombereich auf und prüft, ob die Markierungen in den Ausgabebildern mit den Zoomfaktoren in den Aufnahmemetadaten übereinstimmen. Die gleiche Kameraaufnahmesitzung wird verwendet, um 3A zu konvergieren und Aufnahmen zu machen.

Getestete APIs:

Passiert:Die relative Größe der erfassten Markierung stimmt mit den Metadaten des Zoomfaktors überein.

test_preview_video_zoom_match

Tests, bei denen während der Aufnahme und des Zoomens die Videovorschau und die Videoausgabe dieselbe Ausgabe anzeigen und aufzeichnen. Die Größe der Markierung, die dem Zentrum am nächsten ist, wird bei verschiedenen Zoomfaktoren berechnet und geprüft, ob die Größe der Markierung mit steigendem Zoomfaktor zunimmt.

Getestete APIs:

Pass:Die relative Größe der aufgenommenen Markierung stimmt mit dem angeforderten Zoomverhältnis in Video und Vorschau überein.

Abbildung 120 HD_1280x720_key_frame.png (vor dem Zoomen).

Abbildung 121: preview_1280x720_key_frame.png (vor dem Zoomen)

Abbildung 122. HD_1280x720_key_frame.png (nach dem Zoomen)

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

test_preview_zoom

Es wird geprüft, ob das Zoomverhältnis jedes Vorschauframes mit den entsprechenden Aufnahmemetadaten vom Ultraweitwinkelobjektiv zum Weitwinkelobjektiv übereinstimmt. Beim Test werden Vorschauframes über den Zoombereich aufgenommen und die ArUco-Markierung ermittelt, die sich am nächsten am Mittelpunkt befindet. Im Test wird dann geprüft, ob sich die Position der Mittelmarkierung bei jeder Aufnahme vorhersehbar ändert. Der Abstand zwischen dem Mittelpunkt der Mittelmarkierung und dem Bildmittelpunkt kann sich entweder mit konstanter Geschwindigkeit in Bezug auf das Zoomverhältnis ändern, bis die Kamera physisch gewechselt wird, oder sich nach einem physischen Kamerawechsel monoton in Richtung der Position derselben Markierung ändern.

Getestete APIs:

Pass:Die relative Größe der ausgewählten ArUco-Markierung stimmt für das angegebene Zoomverhältnis des entsprechenden Aufnahmeergebnisses für alle Vorschauframes überein. Der relative Abstand der ausgewählten Markierung vom Bildmittelpunkt ist für das angegebene Zoomverhältnis des entsprechenden Aufnahmeergebnisses aller Vorschauframes korrekt.

test_preview_zoom-Bilder, in denen die ausgewählte Markierung am nächsten zur Mitte ist

Abbildung 124: test_preview_zoom-Bilder, die die ausgewählte Markierung zeigen, die dem Zentrum am nächsten ist

test_session_characteristics_zoom

Der Zoomverhältnisbereich wird für alle unterstützten Sitzungskonfigurationen getestet, die in CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION aufgeführt sind. Wenn für jede dieser Konfigurationen true von CameraDeviceSetup#isSessionConfigurationSupported zurückgegeben wird, wird im Test geprüft, ob der in CameraDeviceSetup#getSessionCharacteristics zurückgegebene Bereich des Zoomfaktors erreicht werden kann.

Getestete APIs:

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

scene7

scene7 ist ein rechteckiger Frame, 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 abgeschrägten Rändern für die Schärfeprüfung. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um bei unterschiedlichen Zoomfaktoren genaue Koordinaten des Hauptrechtecks zu erhalten.

scene7

Abbildung 125: scene7.

test_multi_camera_switch

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

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

Die Frames, die am und vor dem Übergangspunkt aufgenommen wurden, werden hinsichtlich automatischer Belichtung (AE), automatischer Weißabgleich (AWB) und Autofokus (AF) analysiert.

Bei der AE-Prüfung wird überprüft, ob sich die Helligkeitsänderung sowohl bei Bildern mit Weitwinkel- als auch mit Ultraweitwinkelobjektiv im erwarteten Bereich befindet. Bei der AWB-Prüfung wird überprüft, ob die Rot-Grün- und Blau-Grün-Verhältnisse sowohl bei Bildern mit Weitwinkel- als auch mit Ultraweitwinkelobjektiv innerhalb der Grenzwerte liegen. Bei der AF-Prüfung wird der Schärfewert anhand der durchschnittlichen Gradientenstärke zwischen UW- und Weitwinkelaufnahmen berechnet.

Wenn der Moiré-Effekt die Ergebnisse beeinträchtigt, verwenden Sie bei diesem Test ein Tablet mit höherer Auflösung aus der Liste der von der Kamera-ITS-Abteilung zugelassenen Tablets.

Getestete APIs:

Bestanden:Damit der Test bestanden wird, müssen die AE- und AWB-Prüfungen bestanden werden. Die Ergebnisse der AF-Prüfung werden nur zu Protokollierungszwecken verwendet. Für jede Prüfung gelten die folgenden Kriterien:

AE-Prüfung: Die Luminanzänderung (Y-Wert) zwischen den Bildern des Weitwinkel- und des Weitwinkelobjektivs muss für alle Farbfelder unter 4% liegen, 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 mit dem Ultraweitwinkel- und Weitwinkelobjektiv muss für den grauen Farbfleck unter 3% und für andere Farbflecke unter 10% liegen, wenn das Gerät sowohl ae_regions als auch awb_regions unterstützt.
AF-Prüfung: Die Bildschärfe der Aufnahme mit dem Weitwinkelobjektiv muss höher sein als die der Aufnahme mit dem Ultraweitwinkelobjektiv.

test_multi_camera_switch_gray_uw_y

Abbildung 126 Grauer Fleck, aufgenommen mit einem Ultraweitwinkelobjektiv

test_multi_camera_switch_gray_w_y

Abbildung 127 Grauer Fleck, aufgenommen mit Weitwinkelobjektiv

scene8

scene8 ist ein rechteckiger Frame, der in vier gleiche Bereiche unterteilt ist, die jeweils ein Porträt enthalten, das mit einer anderen Belichtung aufgenommen oder mit einem anderen Farbton überlagert wurde (blauer Farbton, erhöhte Belichtung, verringerte Belichtung, gelber Farbton). Vier ArUco-Markierungen werden an den vier äußeren Ecken des Rechtecks ausgerichtet, um genaue Koordinaten des Hauptrechtecks zu erhalten.

Beispiel für Szene 8

Abbildung 128: Beispiel für scene8

test_ae_awb_regions

Prüft, ob sich die RGB- und Luminanzwerte bei der Vorschauaufzeichnung in verschiedenen AE- und AWB-Regionen unterscheiden.

Dabei wird eine 8 Sekunden lange Vorschauaufnahme erstellt, bei der die AE- und AWB-Messung jeweils 2 Sekunden lang in jedem Quadranten durchgeführt wird. Im Test wird dann ein Frame aus der Vorschauaufnahme jeder Region extrahiert und mit den extrahierten Frames werden die folgenden AE- und AWB-Prüfungen durchgeführt:

AE-Prüfung: Prüft, ob der Luma-Wert des Frames, in dem die Region mit verringerter Belichtung gemessen wird, um mehr als 1% höher ist als der des Frames, in dem die Region mit erhöhter Belichtung gemessen wird. So wird überprüft, ob Bilder bei der Belichtung einer dunklen Region aufgehellt werden.
AWB-Prüfung: Prüft, ob das Verhältnis von Rot zu Blau (der durchschnittlichen RGB-Werte des Bilds) 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 eine gelbe (warme) oder blaue (kalte) Region gemessen wird.

Getestete APIs:

Pass:Die AE- und AWB-Prüfungen haben beide bestanden.

test_ae_awb_regions_dark_region

Abbildung 129. Belichtungsmessung des dunklen Bereichs des Frames mit erhöhter Belichtung.

test_ae_awb_regions_light_region

Abbildung 130 Belichtung des Frames in hellerer Region mit verringerter Belichtung.

Fehlermechanismen:

Für diesen Test ist die genaue Erkennung aller vier ArUco-Markierungen unerlässlich. Wenn die anfängliche Erkennung fehlschlägt, versucht das System einen zweiten Erkennungsdurchlauf mit einer Schwarz-Weiß-Version des Bildes. Das folgende Graustufenbild stellt den sekundären Verarbeitungsschritt dar:

Abbildung 131 Die ArUco-Markierungen sind nicht richtig ausgerichtet.

test_color_correction_mode_cct

Tests COLOR_CORRECTION_MODE mit verschiedenen Farbtemperaturen und Farbtönen, Überprüfung von Änderungen der RGB-Verhältnisse im Vergleich zur Aufnahmeszene scene8.

Getestete APIs:

Pass:Die RGB-Verhältnisse zeigen die erwarteten Erhöhungen oder Verringerungen im Vergleich zu den ausgewählten Farbtemperaturen und Farbtönen.

Testkriterien für das Überspringen

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

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

scene9

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

scene9 example

Abbildung 132: Beispiel für scene9

test_jpeg_high_entropy

Prüft, ob die JPEG-Komprimierung der Kamera bei scene9 mit hoher Entropie und einem JPEG-Qualitätsfaktor von 100 % funktioniert. Der Zoomfaktor wird erhöht, um sicherzustellen, dass die auf dem Tablet angezeigte Szene das Sichtfeld der Kamera ausfüllt.

Getestete APIs:

Pass:Die JPEG-Datei wird korrekt komprimiert, auf die Festplatte geschrieben und wieder daraus gelesen.

test_jpeg_quality

Hier wird die JPEG-Komprimierungsqualität der Kamera getestet. Die JPEG-Qualitäten werden mit android.jpeg.quality durchgegangen und es wird überprüft, ob sich die Quantisierungstabellen richtig ändern.

Getestete APIs:

Übergeben:Die Quantisierungsmatrix wird mit steigender Qualität kleiner. (Die Matrix stellt den Divisionsfaktor dar.)

Durchschnittliche DQT-Matrixwerte für Luminanz und Chroma der Rückkamera von Google Pixel 4 im Vergleich zur JPEG-Qualität

Abbildung 133 Durchschnittliche DQT-Matrixwerte für Luminanz und Chroma der Rückkamera von Google Pixel 4 im Vergleich zur JPEG-Qualität

Beispiel für einen fehlgeschlagenen Test für „test_jpeg_quality“

Abbildung 134 Beispiel für einen fehlgeschlagenen Test

scene_video

scene_video ist eine Videoszene mit vier unterschiedlich farbigen Kreisen, die sich vor einem weißen Hintergrund mit unterschiedlichen Frameraten vor und zurück bewegen.

Abbildung 135: Beispiel für „scene_video“.

test_preview_frame_drop

Hier wird getestet, 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:

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

scene_extensions

Die scene_extensions-Tests sind für Kameraerweiterungen gedacht und müssen Camera ITS-in-a-Box verwenden, da sie eine genaue Kontrolle der Testumgebung erfordern. Außerdem muss jeglicher Lichtaustritt kontrolliert werden. Dazu müssen Sie möglicherweise den Testaufbau, das DUT und das Tablet mit einer Abdeckplane abdecken und Lichtlecks am Frontdisplay des DUT beseitigen.

scene_hdr

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

scene_hdr

Abbildung 136: Beispiel für „scene_hdr“.

test_hdr_extension

Hier wird die HDR-Erweiterung getestet. Es werden Aufnahmen mit und ohne aktivierte Erweiterung gemacht und geprüft, ob der QR-Code durch die Erweiterung besser erkannt werden kann.

Getestete APIs:

Karte/Ticket:Mit der HDR-Erweiterung wird die Anzahl der Kontraständerungen reduziert, die zum Erkennen des QR-Codes erforderlich sind, oder der Farbverlauf im QR-Code wird reduziert.

scene_low_light

Die scene_low_light-Szene besteht aus einem Quadratraster in verschiedenen Grautönen vor einem schwarzen Hintergrund. Das Quadratraster ist von einem roten Umriss begrenzt. Die Quadrate sind in einer Hilbert-Kurve angeordnet.

Beispiel für „scene_low_light“

Abbildung 137: Beispiel für „scene_low_light“

test_night_extension

Testet die Nachtzeiterweiterung. Er führt Aufnahmen mit aktivierter Erweiterung aus und führt dabei folgende Aktionen aus:

Erkennt 20 Quadrate
Berechnet die Luminanz, die von jedem Quadrat begrenzt ist.
Berechnet den durchschnittlichen Luminanzwert der ersten 6 Quadrate gemäß der Ausrichtung des Hilbert-Kurven-Rasters.
Berechnet die Differenz des Luminanzwerts 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 der Aufnahmeantrag einen Messbereich, der dem Rechteck entspricht, das das Quadratraster umschließt. Durch diese Ergänzung ändern sich die Kriterien für die Grenzwerte.

Getestete APIs:

Karte/Ticket:

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

Das folgende Diagramm zur Leuchtkraft zeigt, wie ein bestandener Test aussieht.

Beispiel für einen bestandenen Test bei Nachtszenen bei wenig Licht

Abbildung 138 Beispiel für einen bestandenen Test bei Nachtszenen bei wenig Licht

test_low_light_boost_extension

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

Erkennt die Anwesenheit von 20 Boxen
Berechnet die Luminanz, die von jedem Feld begrenzt ist.
Berechnet den durchschnittlichen Luminanzwert der ersten 6 Quadrate gemäß der Ausrichtung des Hilbert-Kurven-Rasters.
Berechnet die Differenz des Luminanzwerts 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.

Getestete APIs:

Karte/Ticket:

Bei Geräten mit Android 16 oder höher muss der durchschnittliche Luminanzwert der ersten sechs Quadrate mindestens 54 betragen und der durchschnittliche Unterschied im Luminanzwert aufeinanderfolgender Quadrate bis zu den Quadraten 5 und 6 muss mindestens 17 betragen.
Bei Geräten mit Android 15 oder niedriger muss der durchschnittliche Luminanzwert der ersten sechs Quadrate mindestens 70 betragen und die durchschnittliche Differenz des Luminanzwerts 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 Diagramm mindestens der Mindestfokusdistanz des Teleobjektivs entspricht. Da sich dieser Mindestfokusabstand von Gerät zu Gerät unterscheiden kann, müssen Sie Ihre Einrichtung an die jeweilige Teleobjektivkamera anpassen.

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

Abbildung 139: Einstellung von „scene_tele“ basierend auf der Fokusdistanz der Weitwinkel- und Telekamera.

Weitere Informationen zur Einrichtung der Testhardware finden Sie unter Teleskopaufsatz einrichten.

scene6_tele

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

Wenn Aufnahmen von scene6_tele im modularen Rig überbelichtet erscheinen, entfernen Sie die Frontplatte des modularen Rigs.

Trennen Sie das WFoV-Testgestell von der Verlängerung und entfernen Sie die Smartphonehalterung.

Abbildung 140 Trennen Sie das WFoV-Testgestell von der Verlängerung und entfernen Sie die Smartphonehalterung.

remove_front_plate

Abbildung 141 Entfernen Sie die Abdeckung.

test_zoom_tele

Hier wird das Zoomverhalten der Kamera vom Weitwinkel- zum Teleobjektiv getestet. Der Test ist mit test_zoom identisch, aber es wird das Zoomverhalten der Kamera vom Weitwinkel- zum Teleobjektiv getestet.

Getestete APIs:

Pass: Die relative Größe der erfassten ArUco-Markierung stimmt mit dem angeforderten Zoomverhältnis überein, um zu prüfen, ob die Kamera richtig heranzoomt. Außerdem ändert sich der Abstand der Markierung zur Bildmitte gemäß den in test_zoom aufgeführten Kriterien.

test_preview_zoom_tele

Hier wird das Kamerazoomverhalten für Vorschauframes vom Weitwinkelobjektiv zum Teleobjektiv getestet. Der Test ist mit test_preview_zoom identisch, aber es wird das Kamerazoomverhalten für Vorschauframes vom Weitwinkelobjektiv zum Teleobjektiv getestet.

Getestete APIs:

scene7_tele

scene7_tele ist mit scene7 identisch, aber für Tests mit Teleobjektiven eingerichtet. Es ist ein rechteckiger Frame, 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 abgeschrägten Rändern für die Schärfeprüfung. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um bei unterschiedlichen Zoomfaktoren genaue Koordinaten des Hauptrechtecks zu erhalten.

test_multi_camera_switch_tele

Bei diesem Test wird überprüft, ob bei der Aufzeichnung der Vorschau bei unterschiedlichen Zoomfaktoren der Wechsel zwischen dem Weitwinkel- (W) und dem Teleobjektiv (tele) zu ähnlichen RGB-Werten führt.

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

Bei der AE-Prüfung wird überprüft, ob die Helligkeitsänderung sowohl bei Weitwinkel- als auch bei Teleobjektiven im erwarteten Bereich liegt. Bei der AWB-Prüfung wird überprüft, ob die Rot-Grün- und Blau-Grün-Verhältnisse sowohl bei Weitwinkel- als auch bei Teleobjektiven innerhalb der Grenzwerte liegen. Bei der AF-Prüfung wird der Schärfewert anhand der durchschnittlichen Steigungsgröße zwischen Weitwinkel- und Teleobjektivbildern bewertet.

Getestete APIs:

Bestanden:Damit der Test bestanden wird, müssen alle AE-, AWB- und AF-Prüfungen bestanden werden. Die folgenden Kriterien gelten für jede Prüfung:

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

scene_flash

Für die scene_flash-Tests ist eine dunkle Szene im Sensorfusionsfeld erforderlich.

test_auto_flash

Es wird getestet, ob der automatische Blitz bei dunklen Szenen für die Rück- und Frontkamera ausgelöst wird. Bei Frontkameras wird der Auto-Blitz nicht durch eine physische Blitzeinheit, sondern durch den Bildschirm ausgelöst. Beim Test wird überprüft, ob der automatische Blitz ausgelöst wird. Dazu wird geprüft, ob die Mitte des Kachelbilds bei aktiviertem automatischen Blitz heller ist. Damit der automatische Blitz ausgelöst wird, müssen die Lampen im Testgestell ausgeschaltet sein. Das kann automatisch mit dem Arduino-Controller erfolgen. Die Szene muss vollständig dunkel sein, damit der Test richtig funktioniert. Die Jetpack Camera App (JCA) muss vor dem Test auf dem Gerät installiert sein. Der automatische Blitz für Rückkameras hängt vom AE-Status ab, der automatische Blitz für Frontkameras jedoch nicht und wird immer ausgelöst.

Getestete APIs:

Nicht bestanden:Der Mittelpunkt des Kachelbilds mit aktiviertem automatischen Blitz ist bei allen Kameras heller als das ursprüngliche Szenenbild.

test_flash_strength

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

Prüft, ob das Gerät die Kontrolle der Blitzstärke bei der Verwendung der Kamera im Modus SINGLE unterstützt und ob sich die Blitzstärke bei verschiedenen angeforderten Stärken ändert. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der Modus der automatischen Belichtung beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Bei ON_AUTO_FLASH hat sie dagegen keine Auswirkungen.

Zum Ausführen des Tests müssen die Lampen im Testgestell ausgeschaltet werden. Sie können mit dem Arduino-Controller automatisch ausgeschaltet werden. Die Szene muss vollständig dunkel sein, damit der Test richtig funktioniert.

Getestete APIs:

Karte/Ticket:

Wenn der Modus für die automatische Belichtung 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 Modus „Automatische Belichtung“ auf ON_AUTO_FLASH eingestellt ist, liegt die Helligkeitsdifferenz der Bildflecke innerhalb der Toleranz, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_SINGLE_STRENGTH_MAX_LEVEL erhöht wird.

test_led_snapshot

Prüft, ob die LED-Snapshots das Bild nicht übersättigen oder färben.

In diesem Test wird der Sensor Fusion Box ein Beleuchtungscontroller hinzugefügt, um die Lampen zu steuern. Wenn die Lampen auf OFF eingestellt sind, wird beim Test eine Aufnahme mit dem Modus AUTO_FLASH = ON erstellt. Während dieser Aufnahme wird im Test eine Sequenz vor der Aufnahme mit dem aePrecapture-Trigger START ausgeführt und die Aufnahmeabsicht auf Preview gesetzt, um die Aufnahme mit Blitz auszuführen.

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

Getestete APIs:

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

test_night_mode_indicator

Hier wird die Funktion der Nachtmodus-Anzeige getestet. Diese Funktion gibt an, ob die Kamera bei schlechten Lichtverhältnissen arbeitet und von einer Aufnahme 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 der Indikator für den Nachtmodus die Lichtverhältnisse während der Kameravorschau korrekt widerspiegelt. Der Test führt die folgenden Schritte aus:

Initialisierung:Im Test wird eine ItsSession initialisiert und Kameraeigenschaften abgerufen. Außerdem stellt er eine Verbindung zum Beleuchtungscontroller her.
Überspringbedingungen:Der Test wird übersprungen, wenn das Gerät die erforderliche API-Ebene oder die Funktion für die Nachtmodus-Anzeige nicht unterstützt.
Camera2-Sitzung:
- Der Test startet eine Vorschauaufnahmesitzung mit einer Camera2-Sitzung.
- Das Licht wird eingeschaltet und ein Vorschauframe wird aufgenommen.
- Beim Test wird überprüft, ob die Anzeige für den Nachtmodus den Status OFF hat.
- Die LED wird ausgeschaltet und ein Vorschauframe wird aufgenommen.
- Beim Test wird überprüft, ob die Anzeige für den Nachtmodus den Status ON hat.
Kameraerweiterungssitzung:
- Dabei wird derselbe Vorgang wie bei der Camera2-Sitzung wiederholt, jedoch mit einer CameraExtension-Sitzung mit der EXTENSION_NIGHT-Erweiterung.
Bereinigung:Der Test schließt ItsSession und gibt den Beleuchtungscontroller frei.

Getestete APIs:

android.extension.nightModeIndicator

Karte/Ticket:

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

test_preview_min_frame_rate

Hier wird getestet, ob die Framerate der Vorschau in einer dunklen Szene korrekt sinkt. Damit dieser Test ordnungsgemäß funktioniert, müssen die Lampen im Testgestell vom Controller oder manuell vom Testoperator ausgeschaltet werden.

Getestete APIs:

Erfolgreich:Die Framerate der Vorschau liegt im Mindestwert des angeforderten Framerate-Bereichs und die Abweichung zwischen den Frames ist kleiner 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 das Gerät die Kontrolle der Blitzstärke bei der Verwendung der Kamera im Modus TORCH unterstützt und ob sich die Taschenlampenstärke bei verschiedenen angeforderten Stärken ändert. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der Modus der automatischen Belichtung beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Bei ON_AUTO_FLASH hat sie dagegen keine Auswirkungen. Prüft, ob die Taschenlampenleistung während der Dauer einer Aufnahme unverändert bleibt, um eine Videoaufnahme zu simulieren. Für den Test müssen die Lampen im Testgestell ausgeschaltet sein. Das kann automatisch mit dem Arduino-Controller erfolgen. Die Szene muss vollständig dunkel sein, damit der Test richtig funktioniert.

Getestete APIs:

Karte/Ticket:

Wenn der Modus für die automatische Belichtung ON oder OFF ist, erhöht sich die Helligkeit der Bildsequenz-Patches, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_TORCH_STRENGTH_MAX_LEVEL erhöht wird. Wenn der Modus für die automatische Belichtung ON_AUTO_FLASH ist, liegt die Differenz in der Helligkeit der Patches der Bildserie innerhalb der Toleranz, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_TORCH_STRENGTH_MAX_LEVEL erhöht wird.

sensor_fusion

Für Sensorfusionstests ist eine bestimmte Bewegung des Smartphones vor einem Schachbrettmuster und ArUco-Markierungen erforderlich. Für optimale Ergebnisse muss das Testdiagramm flach montiert sein. Nicht flache Diagramme wirken sich auf die Drehungsberechnungen für viele der Tests aus. Das Diagramm muss die Rückseite des Sensorfusions-Gerätekartons ausfüllen und muss im Format 43,2 × 43,2 cm gedruckt werden. (43 × 43 cm). Die sensor_fusion-Tests können mit der Sensor Fusion Box automatisiert werden.

Diagramm für Sensorfusion

Abbildung 142 Diagramm zur Sensorfusion

Diagramm zur Sensorfusion in Rig

Abbildung 143 Sensorfusionsdiagramm, das die Rückseite des Sensorfusionsfelds ausfüllt.

test_lens_intrinsic_calibration

Prüft, ob sich der optische Mittelpunkt des Objektivs ändert, wenn sich das Objektiv aufgrund der optischen Bildstabilisierung (OIS) bewegt. Wenn linsenspezifische Muster unterstützt werden, wird geprüft, ob sich der optische Mittelpunkt der linsenspezifischen Muster ändert, wenn sich das Objektiv aufgrund der optischen Bildstabilisierung bewegt.

Getestete APIs:

Abweichung:Die optische Mitte des Objektivs ändert sich um mindestens 1 Pixel. Wenn linsenspezifische Muster unterstützt werden, ändern sich die optischen Mittelpunkte der linsenspezifischen Muster um mindestens ein Pixel.

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

Abbildung 144 Beispiel für ein Diagramm vom Typ „test_lens_intrinsic_calibration“, das die Änderungen der Hauptpunkte in Pixeln für jeden Frame zeigt

test_multi_camera_frame_sync

Prüft, ob die von der logischen Kamera erfassten Frame-Zeitstempel innerhalb von 10 ms liegen, indem die Winkel der Quadrate im Schachbrettmuster berechnet werden, um den Zeitstempel zu ermitteln.

Getestete APIs:

Pass:Der Winkel zwischen den Bildern der einzelnen Kameras ändert sich beim Drehen des Smartphones kaum.

test_preview_distortion

Prüft, ob die Verzerrung in jedem Vorschauframe korrigiert wird, der bei verschiedenen Zoomstufen aufgenommen wurde. Für jeden Vorschauframe werden im Test anhand der intrinsischen und extrinsischen Kameraparameter ideale Punkte berechnet.

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

Abbildung 145 Bild eines Schachbretts mit idealen Punkten in grün und tatsächlichen Punkten in rot

Getestete APIs:

Erfolgreich:Der normalisierte Verzerrungsfehler jedes Vorschauframes ist kleiner als der im Test festgelegte Grenzwert.

test_preview_stabilization

Tests haben gezeigt, dass sich die stabilisierte Videovorschau weniger als der Gyroskop dreht.

Getestete APIs:

Pass:Die maximale Drehwinkeländerung über mehrere Frames liegt unter 70% der Drehung des Gyroskops.

Hier siehst du Beispiele für Videos mit und ohne Stabilisierung:

Abbildung 146 Beispielvideo mit Stabilisierung

Abbildung 147 Beispielvideo ohne Stabilisierung

test_sensor_fusion

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

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

test_sensor_fusion_gyro_events: Zeigt die Gyroskopereignisse für das Smartphone während des Tests an. Bewegungen in X- und Y-Richtung deuten darauf hin, dass das Smartphone nicht sicher auf der Halterung montiert ist. Die Wahrscheinlichkeit, dass der Test bestanden wird, ist dann geringer. Die Anzahl der Zyklen im Diagramm hängt von der Schreibgeschwindigkeit zum Speichern von Frames ab.

Abbildung 148: Beispiel für Gyroskopiereignisse vom Typ „test_sensor_fusion“
test_sensor_fusion_plot_rotations: Zeigt die Ausrichtung des Gyroskops und Kameraereignisse an. Dieser Plot muss eine übereinstimmende Bewegung zwischen Kamera und Gyroskop mit einer Abweichung von +/- 1 ms zeigen.

Abbildung 149: Beispiel für Plotdrehungen mit test_sensor_fusion

Getestete APIs:

Pass: Die Zeitstempel von Kamera und Gyroskop weichen gemäß 7.3.9 High Fidelity-Sensoren im CDD um weniger als 1 ms voneinander ab.

Fehlermechanismen:

Offset-Fehler: Der Offset des Kameragyroskops ist nicht richtig kalibriert (+/- 1 ms).
Frame-Drops: Die Pipeline ist nicht schnell genug, um 200 Frames nacheinander zu erfassen.
Socket-Fehler: adb kann nicht zuverlässig und lange genug eine Verbindung zur DUT herstellen, um den Test auszuführen.
Das Diagramm ist nicht flach montiert. Der Plot test_sensor_fusion_plot_rotations enthält Frames, in denen sich die Gyroskop- und Kameradrehung erheblich unterscheidet, da sich die Kamera durch die nicht flachen Teile des Diagramms dreht.
Die Kamera ist nicht bündig montiert. Das Diagramm test_sensor_fusion_gyro_events zeigt Bewegungen in der X‑ und Y‑Ebene. Dieses Problem tritt häufiger bei Frontkameras auf, da die Rückkamera oft eine Erhöhung im Vergleich zum Rest des Smartphone-Gehäuses aufweist, was bei der Montage der Rückseite des Smartphones an der Halterung zu einer Neigung führt.

test_video_stabilization

Tests haben gezeigt, dass stabilisierte Videos weniger als der Gyroskop rotieren.

Getestete APIs:

Pass:Die maximale Drehwinkeländerung über mehrere Frames liegt unter 60% der Drehung des Gyroskops.

Unten findest du Beispielvideos mit und ohne Stabilisierung.

Abbildung 150 Beispielvideo mit Stabilisierung

Abbildung 151 Beispielvideo ohne Stabilisierung

test_video_stabilization_jca

Tests, bei denen festgestellt wurde, dass mit der JCA aufgenommene stabilisierte Videos weniger rotieren als mit dem Gyroskop. Die JCA muss vor dem Testen auf dem Gerät installiert sein.

Getestete APIs:

Pass:Die maximale Drehung des Winkels über Frames, die aus Videos extrahiert wurden, die mit der JCA aufgenommen wurden, beträgt weniger als 70% der Drehung des Gyroskops.

feature_combination

Bei den feature_combination-Tests wird überprüft, ob Funktionen ordnungsgemäß funktionieren, wenn mehrere Kamerafunktionen gleichzeitig aktiviert sind. Für diese Tests wird dasselbe Schachbrettmuster verwendet, das auch in der Szene für die Sensorfusion verwendet wird.

test_feature_combination

Hier werden alle Kombinationen verschiedener Streamkombinationen, Videostabilisierungsmodi, Ziel-FPS-Bereiche, 10-Bit-HDR-Videos und Ultra-HDR-Videos getestet, die vom Kameragerät unterstützt werden.

Bei Android 16 und höher werden alle Kombinationen der unterstützten Funktionen ausgeführt und die Ergebnisse in einer Proto-Datei protokolliert. Fehleraussagen werden nur für Kombinationen von Funktionen aufgerufen, für die isSessionConfigurationSupported den Wert True zurückgibt.

Getestete APIs:

Übergeben:Für jede unterstützte Kombination von Funktionen:

Der Vorschaustream wird stabilisiert, wenn die Stabilisierung der Vorschau aktiviert ist.
Die Framerate der Vorschau liegt innerhalb der konfigurierten AE_TARGET_FPS_RANGE.
Der Farbraum des aufgezeichneten Vorschaustreams stimmt mit den Einstellungen überein.
Die Ultra-HDR-Aufnahme hat eine gültige Verstärkungskarte.

scene_ip

Unter Android 16 und höher ermöglicht die Szene scene_ip Bildparitätsprüfungen zwischen der Standardkamera-App und der Jetpack Camera App (JCA), um große Unterschiede zwischen aufgenommenen Bildern zu erkennen. Die JCA repliziert die Aufnahmen von Social-Media-Apps und stellt ein Baseline-Image bereit, das von den Social-Media-Apps verarbeitet und optimiert wird.

Anforderungen an die Hardwareeinrichtung

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

Die Tests werden im ITS-in-a-Box für die Gen 2-Kamera ausgeführt.
Mit den Beleuchtungs- und Servocontrollern, die zum Gen 2-Rig gehören, wird die Testumgebung gesteuert.
Ein Testfunktionsdiagramm wird in das Gen 2-Rig platziert.

test_chart_gen2

Abbildung 152 Gen2chart_sample-Beispiel

Testkriterien für das Überspringen

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

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

test_default_jca_ip

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

Bildwinkel:Prüft, ob die Standardkamera-App und die JCA-Aufnahmen denselben Bildwinkel haben. Bei dieser Prüfung wird die Funktion „Mittlerer QR-Code“ verwendet, die aus dem erfassten Diagrammbild extrahiert wird.
Helligkeit:Prüft, ob die gemessene Helligkeitsdifferenz zwischen der Standardkamera-App und JCA 10 nicht überschreitet. Bei dieser Prüfung wird der Patch für den dynamischen Bereich für die Helligkeitsmessung verwendet.
Weißabgleich:Prüft, ob die Weißabgleichsdifferenz zwischen der Standardkamera-App und JCA 4 nicht überschreitet. Bei dieser Prüfung wird der Patch für den dynamischen Bereich für die Helligkeitsmessung verwendet.

Grundlegender Abschnitt bestanden:Der Test hat die Prüfungen für den Sichtbereich, die Helligkeit und den Weißabgleich bestanden. In Android 16 ist dieser Test nicht obligatorisch (NOT_YET_MANDATED).

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

scene0

test_jitter

test_metadata

test_request_capture_match

test_sensor_events

test_solid_color_test_pattern

test_test_pattern

test_tonemap_curve

test_unified_timestamp

test_vibration_restriction

scene1_1

test_ae_precapture_trigger

test_auto_vs_manual

test_black_white

test_burst_capture

test_burst_sameness_manual

test_crop_region_raw

test_crop_regions

test_ev_compensation

test_exposure_x_iso

test_latching

test_linearity

test_locked_burst

scene1_2

test_param_color_correction

test_param_flash_mode

test_param_noise_reduction

test_param_shading_mode

test_param_tonemap_mode

test_post_raw_sensitivity_boost

test_raw_exposure

test_reprocess_noise_reduction

test_tonemap_sequence

test_yuv_jpeg_all

test_yuv_plus_dng

scene1_3

test_capture_result

test_dng_noise_model

test_jpeg

test_raw_burst_sensitivity

test_raw_sensitivity

test_yuv_plus_jpeg

test_yuv_plus_raw

test_sensitivity_priority

test_exposure_time_priority

scene2_a

test_autoframing

test_display_p3

test_effects

test_exposure_keys_consistent

test_format_combos

test_num_faces

test_reprocess_uv_swap

scene2_b

test_preview_num_faces

test_yuv_jpeg_capture_sameness

scene2_c

test_num_faces

test_jpeg_capture_perf_class

test_camera_launch_perf_class

test_default_camera_hdr

scene2_d

test_preview_num_faces

scene2_e

test_continuous_picture

test_num_faces

scene2_f

test_preview_num_faces

scene2_g

test_preview_num_faces

scene3

test_edge_enhancement

test_flip_mirror

test_imu_drift

test_landscape_to_portrait

test_lens_movement_reporting

test_reprocess_edge_enhancement

scene4

test_30_60fps_preview_fov_match

Kamera-ITS-Tests