Kamera-ITS-Tests

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

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

Tests werden nach Szene gruppiert:

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

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

scene0

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

test_jitter

Misst Jitter in Kamerazeitstempeln.

Getestete APIs:

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

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

test_jitter-Diagramm

Abbildung 1. test_jitter-Diagramm.

test_metadata

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

Getestete APIs:

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

test_request_capture_match

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

Getestete APIs:

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

test_sensor_events

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

Getestete APIs:

Bestanden:Ereignisse für jeden Sensor werden empfangen.

test_solid_color_test_pattern

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

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

Getestete APIs:

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

test_test_pattern

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

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

Getestete APIs:

Bestanden:Unterstützte Testmuster werden korrekt generiert.

Beispiel für test_test_patterns

Abbildung 2. Beispiel für test_test_patterns.

test_tonemap_curve

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

Getestete APIs:

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

test_tonemap_curve – Rohbeispiel

Abbildung 3. Rohbeispiel für „test_tonemap_curve“.

test_tonemap_curve-YUV-Beispiel

Abbildung 4: test_tonemap_curve – YUV-Beispiel.

test_unified_timestamp

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

Getestete APIs:

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

test_vibration_restriction

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

Getestete APIs:

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

scene1_1

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

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

scene1 example

Abbildung 5: Diagramm in voller Größe (links), Diagramm im Maßstab 2/3 (rechts)

test_ae_precapture_trigger

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

Getestete APIs:

Bestanden:Die AE konvergiert.

test_auto_vs_manual

Tests mit automatischen und manuellen Aufnahmen sehen gleich aus.

Getestete APIs:

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

Beispiel für den automatischen und manuellen Test von test_auto_vs_manual

Abbildung 6. test_auto_vs_manual auto example.

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

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

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

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

test_black_white

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

Getestete APIs:

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

test_black_white, schwarzes Beispiel

Abbildung 9: „test_black_white“, schwarzes Beispiel.

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

Abbildung 10: test_black_white, weißes Beispiel.

Beispiel für ein Diagramm mit Testwerten für Schwarzweiß

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

test_burst_capture

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

Getestete APIs:

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

test_burst_sameness_manual

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

Getestete APIs:

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

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

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

test_burst_sameness_manual_mean

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

test_burst_sameness_manual_plot_means

Abbildung 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

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

Getestete APIs:

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

test_crop_region_raw comp raw crop example

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

test_crop_region_raw comp raw full example

Abbildung 15: test_crop_region_raw comp raw full example.

test_crop_region_raw comp YUV crop example

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

test_crop_region_raw_yuv_full-Beispiel

Abbildung 17: test_crop_region_raw – YUV-Vollbeispiel.

test_crop_regions

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

Getestete APIs:

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

test_ev_compensation

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

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

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

Getestete APIs:

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

test_ev_compensation_basic

Abbildung 18: test_ev_compensation_basic.

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

test_ev_compensation_advanced_plot_means

Abbildung 19. test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

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

Getestete APIs:

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

Fehlermechanismus:In der folgenden Abbildung weichen die durchschnittlichen normalisierten RGB-Ebenenwerte (y-Achse) mit zunehmenden Werten des Verstärkungsmultiplikators (x-Achse) von den niedrigen Werten des 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

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

Getestete APIs:

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

Beispiel für das Diagramm „test_latching“

Abbildung 23: Beispiel für die Bedeutung von test_latching-Diagrammen.

test_latching i=00

Abbildung 24. test_latching i=00.

test_latching i=01

Abbildung 25. test_latching i=01.

test_latching i=02

Abbildung 26. test_latching i=02.

test_latching i=03

Abbildung 27. test_latching i=03.

test_latching i=04

Abbildung 28. test_latching i=04.

test_latching i=05

Abbildung 29. test_latching i=05.

test_latching i=06

Abbildung 30. test_latching i=06.

test_latching i=07

Abbildung 31. test_latching i=07.

test_latching i=08

Abbildung 32. test_latching i=08.

test_latching i=09

Abbildung 33. test_latching i=09.

test_latching i=10

Abbildung 34. test_latching i=10.

test_latching i=11

Abbildung 35. test_latching i=11.

test_latching i=12

Abbildung 36. test_latching i=12.

test_linearity

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

Getestete APIs:

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

Beispiel für ein Diagramm mit Testmittelwerten für Linearität

Abbildung 37: Beispiel für ein Diagramm für den Linearitätstest.

test_locked_burst

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

Getestete APIs:

Bestanden:Die Aufnahmen sehen konsistent aus.

Beispiel für test_locked_burst frame0

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

Beispiel für test_locked_burst frame1

Abbildung 39. Beispiel für test_locked_burst frame1.

test_locked_burst_frame2

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

scene1_2

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

test_param_color_correction

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

Die Tonzuordnung ist eine Technik, die in der Bildverarbeitung verwendet wird, um eine Reihe von Farben einer anderen zuzuordnen, um das Erscheinungsbild von Bildern mit hohem Dynamikumfang in einem Medium mit einem begrenzten Dynamikumfang zu simulieren.

Getestete APIs:

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

Beispiel für das Diagramm „test_param_color_correction“

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

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

test_param_color_correction req=0 unity example

Abbildung 42. test_param_color_correction req=0 Unity-Beispiel.

test_param_color_correctness req=1 red boost example

Abbildung 43. test_param_color_correctness req=1 red boost example.

test_param_color_correction req=2 blue boost example

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

test_param_flash_mode

Testet, ob der Parameter android.flash.mode angewendet wird. Legt die Belichtung manuell auf der dunklen Seite fest, damit deutlich wird, ob der Blitz ausgelöst wurde oder nicht, und verwendet ein lineares Ton-Mapping. Prüft den Mittelpunkt des Kachelbilds, um festzustellen, ob ein großer Farbverlauf vorhanden ist, der darauf hinweist, dass der Blitz ausgelöst wurde.

Getestete APIs:

Bestanden:Das Zentrum des Kachelbilds hat einen großen Farbverlauf, was bedeutet, dass der Blitz ausgelöst wurde.

Beispiel für „test_param_flash_mode 1“

Abbildung 45. Beispiel für test_param_flash_mode 1.

Beispiel für Kachel 1 für „test_param_flash_mode“

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 Kachel „test_param_flash_mode 2“

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

test_param_noise_reduction

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

Getestete APIs:

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

test_param_noise_reduction-Diagramm mit SNR-Beispiel

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

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

test_param_noise_reduction high gain nr=0 example

Abbildung 50. test_param_noise_reduction high gain nr=0 example.

test_param_noise_reduction high gain nr=1 example

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

test_param_noise_reduction high gain nr=2 example

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

test_param_noise_reduction high gain nr=3 example

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

test_param_noise_reduction – Beispiel für niedrige Verstärkung

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

test_param_shading_mode

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

Getestete APIs:

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

test_param_shading_mode lens shading map, mode 0 loop 0 example

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

test_param_shading_mode lens shading map, mode 1 loop 0 example

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

test_param_shading_mode lens shading map, mode 2 loop 0 example

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

test_param_tonemap_mode

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

Getestete APIs:

Bestanden:

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

test_param_tonemap_mode mit n=0

Abbildung 58: test_param_tonemap_mode mit n=0.

test_param_tonemap_mode mit n=1

Abbildung 59: test_param_tonemap_mode mit n=1.

test_post_raw_sensitivity_boost

Prüft die Empfindlichkeitssteigerung nach der Rohbearbeitung. Erfasst eine Reihe von RAW- und YUV-Bildern mit unterschiedlicher Empfindlichkeit, sendet eine Kombination aus RAW-Empfindlichkeitssteigerung und prüft, ob der mittlere Ausgabepixelwert mit den Anforderungseinstellungen übereinstimmt.

Getestete APIs:

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

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

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

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

Abbildung 61: test_post_raw_sensitivity_boost raw s=1792 boost=0200 example.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

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

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

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

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

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

test_post_raw_sensitivity_boost raw s=0112 boost=3199 example

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

test_post_raw_sensitivity_boost – Beispiel für Rohdatenplot

Abbildung 66: Beispiel für den Rohplot für den Sensitivitäts-Boost von test_post_raw.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

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

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

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

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

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

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

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

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

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

test_post_raw_sensitivity_boost_yuv_plot_means

Abbildung 72. test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

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

Getestete APIs:

Bestanden:Durch Erhöhen des ISO-Werts (Verstärkung) werden die Pixel empfindlicher gegenüber Licht, sodass sich die Kurve 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¹ entspricht 10 ms und 10⁻¹ entspricht 0, 1 ms.

test_raw_exposure ISO=132 example

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

Beispiel für „test_raw_exposure ISO=209“

Abbildung 75: Beispiel für „test_raw_exposure“ mit ISO 209.

Beispiel für „test_raw_exposure ISO=286“

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

Beispiel für „test_raw_exposure ISO=363“

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

test_raw_exposure_s=440

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

test_reprocess_noise_reduction

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

Getestete APIs:

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

Typisches Diagramm für SNR im Vergleich zum NR-Modus

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

test_tonemap_sequence

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

Getestete APIs:

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

Beispiel für „test_tonemap_sequence i=0“

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

test_tonemap_sequence i=1 example

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

test_tonemap_sequence i=2 example

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

test_tonemap_sequence i=3 example

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

test_tonemap_sequence_i=4 example

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

test_tonemap_sequence i=5 example

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

test_yuv_jpeg_all

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

Getestete APIs:

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

test_yuv_jpeg_all example

Abbildung 86: Beispiel für test_yuv_jpeg_all.

test_yuv_plus_dng

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

Getestete APIs:

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

Beispiel für test_yuv_plus_dng

Abbildung 87. Beispiel für test_yuv_plus_dng.

scene1_3

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

test_capture_result

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

Getestete APIs:

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

test_capture_result_plot_lsc_auto_ch0

Abbildung 88. test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

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

Getestete APIs:

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

test_dng_noise_model_plog

Abbildung 89. test_dng_noise_model_plog.

test_jpeg

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

Getestete APIs:

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

test_jpeg_fmt=jpg.jpg

Abbildung 90. test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

Abbildung 91: test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

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

Getestete APIs:

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

Verwendet die Varianz der Statistiken der Mittelpunkt-Rasterzelle.

test_raw_burst_sensitivity_variance

Abbildung 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

Es wird eine Reihe von Rohbildern mit zunehmender Empfindlichkeit aufgenommen und das Rauschen (die Varianz) in den mittleren 10% des Bildes gemessen. Tests, bei denen jede Aufnahme mehr Rauschen aufweist als die vorherige.

Getestete APIs:

Pass (Pass): Die Varianz nimmt mit jedem Schuss zu.

test_raw_sensitivity_variance

Abbildung 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

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

Getestete APIs:

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

test_yuv_plus_jpeg mit JPEG-Format

Abbildung 94. test_yuv_plus_jpeg mit JPEG-Format.

test_yuv_plus_jpeg mit YUV-Format

Abbildung 95: test_yuv_plus_jpeg mit YUV-Format.

test_yuv_plus_raw

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

Getestete APIs:

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

test_yuv_plus_raw_shading=1_raw.jpg

Abbildung 96. test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

Abbildung 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

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

Getestete APIs:

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

Kriterien zum Überspringen von Tests

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

test_exposure_time_priority

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

Getestete APIs:

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

Kriterien zum Überspringen von Tests

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

scene2_a

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

Beispiel für scene2_a

Abbildung 98: Beispiel für „scene2_a“.

test_autoframing

Testet das Autoframing-Verhalten des Kamerageräts. Führt einen großen Zoom aus, sodass keines der Gesichter in der Szene sichtbar ist, aktiviert den Autoframing-Modus, indem AUTOFRAMING in CaptureRequest auf True gesetzt wird, und prüft, ob alle Gesichter in der ursprünglichen Szene erkannt werden können, wenn der Status konvergiert (d. h. wenn AUTOFRAMING_STATE in CaptureResult auf AUTOFRAMING_STATE_CONVERGED gesetzt ist).

Getestete APIs:

Bestanden:Alle drei Gesichter werden erkannt.

test_display_p3

Tests P3-Anzeige Erfassung im JPEG-Format mit der ColorSpaceProfiles API. Prüft, ob das aufgenommene JPEG ein geeignetes ICC-Profil im Header hat und ob das Bild Farben außerhalb des sRGB-Gamuts enthält.

Getestete APIs:

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

test_effects

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

Getestete APIs:

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

test_effects_MONO

Abbildung 99. test_effects_MONO.

test_exposure_keys_consistent

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

Getestete APIs:

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

test_format_combos

Es werden verschiedene Kombinationen von Ausgabeformaten getestet.

Getestete APIs:

Bestanden:Alle Kombinationen wurden erfolgreich erfasst.

test_num_faces

Testet die Gesichtserkennung.

Getestete APIs:

Bestanden:Es werden drei Gesichter gefunden.

test_num_faces face detection mode 1 example

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

test_reprocess_uv_swap

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

Getestete APIs:

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

test_reprocess_uv_swap

Abbildung 101: Beispiel für „test_reprocess_uv_swap“.

scene2_b

test_preview_num_faces

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

Getestete APIs:

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

test_num_faces_fd_mode_1

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

test_yuv_jpeg_capture_sameness

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

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

Getestete APIs:

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

scene2_c

test_num_faces

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

Getestete APIs:

Bestanden:Es werden drei Gesichter gefunden.

test_num_faces_fd_mode_1

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

test_jpeg_capture_perf_class

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

Bestanden:Die Latenz für die JPEG-Aufnahme mit camera2 MUSS bei einer Auflösung von 1080p weniger als 1.000 ms betragen, gemessen mit dem CTS-Kameraleistungstest unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Primärkameras.

test_camera_launch_perf_class

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

Bestanden:Die Startlatenz von Camera2 (Öffnen der Kamera bis zum ersten Vorschaubild) MUSS für beide primären Kameras unter ITS-Beleuchtungsbedingungen (3.000 K) gemäß dem CTS-Kamera-PerformanceTest < 600 ms betragen.

test_default_camera_hdr

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

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

scene2_d

test_preview_num_faces

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

Getestete APIs:

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

scene2_e

test_continuous_picture

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

Getestete APIs:

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

test_num_faces

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

Getestete APIs:

Erfolgreich:Es werden 3 Gesichter gefunden.

scene2_f

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

scene2_f example

Abbildung 104. Beispiel für scene2_f.

test_preview_num_faces

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

Getestete APIs:

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

test_num_faces_fd_mode_1

Abbildung 105. Beispiel für test_num_faces_fd_mode_1.

scene2_g

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

scene2_g.png

Abbildung 106. Beispiel für scene2_g.

test_preview_num_faces

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

Getestete APIs:

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

test_preview_num_faces

Abbildung 107. Beispiel für „test_preview_num_faces“.

scene3

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

test_edge_enhancement

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

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

Getestete APIs:

Betroffene Kameraparameter:

  • EDGE_MODE

test_edge_enhancement_edge=0

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

test_edge_enhancement edge=1 example

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

test_edge_enhancement edge=2 example

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

test_flip_mirror

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

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

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

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

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

test_imu_drift

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

Getestete APIs:

Bestanden:

  • Die Drift des Gyroskops beträgt über den Testzeitraum weniger als 0,01 rad.
  • Die Varianz des Gyroskopsignals beträgt über den Testzeitraum weniger als 1E-7 rad2/s2/Hz.
  • Die Abweichung des Rotationsvektors beträgt über den Testzeitraum weniger als 0,01 rad.
  • (Noch nicht vorgeschrieben) Die Drift des Gyroskops beträgt weniger als 1 Grad pro Sekunde.

test_imu_drift – Beispiel für Gyroskopdrift

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

test_imu_drift-Beispiel für Drift des Rotationsvektors

Abbildung 113. Beispiel für die Drift des Rotationsvektors bei test_imu_drift.

test_landscape_to_portrait

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

Getestete APIs:

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

Beispiel für test_landscape_to_portrait

Abbildung 114. Beispiel für test_landscape_to_portrait.

test_lens_movement_reporting

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

Das Flag für die Objektivbewegung sollte in allen Frames gesetzt werden, in denen die Schärfe zwischen der Schärfe in den ersten Frames mit dem Objektiv in der optimalen Brennweite und der Schärfe in den letzten Frames mit dem Objektiv in der minimalen Brennweite liegt. Das 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:

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

Fehlermechanismen:

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

test_reprocess_edge_enhancement

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

Getestete APIs:

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

Beispiel für das Diagramm „test_reprocess_edge_enhancement“

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

Szene 4

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

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

scene4 example

Abbildung 116. Beispiel für scene4.

test_30_60fps_preview_fov_match

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

Getestete APIs:

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

Fehlermechanismen:

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

test_aspect_ratio_and_crop

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

Getestete APIs:

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

Fehlermechanismen:

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

test_multi_camera_alignment

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

Getestete APIs:

Bestanden:Die Kreismittelpunkte und -größen sind in den projizierten Bildern im Vergleich zu den mit Kamerakalibrierungsdaten und Brennweiten aufgenommenen Bildern wie erwartet.

Fehlermechanismen:

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

test_preview_aspect_ratio_and_crop

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

Getestete APIs:

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

test_preview_stabilization_fov

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

Getestete APIs:

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

test_video_aspect_ratio_and_crop

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

Getestete APIs:

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

scene5

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

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

scene5-Beispiel

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

test_lens_shading_and_color_uniformity

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

Getestete APIs:

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

scene6

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

scene6

Abbildung 118. Beispiel für scene6.

test_in_sensor_zoom

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

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

Getestete APIs:

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

test_zoom

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

Getestete APIs:

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

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

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

test_low_latency_zoom

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

Getestete APIs:

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

test_preview_video_zoom_match

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

Getestete APIs:

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

HD_1280x720_key_frame.png

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

preview_1280x720_key_frame.png

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

HD_1280x720_key_frame_zoomed.png

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

preview_1280x720_key_frame_zoomed.png

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

test_preview_zoom

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

Getestete APIs:

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

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

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

test_session_characteristics_zoom

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

Getestete APIs:

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

scene7

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

scene7

Abbildung 125. scene7.

test_multi_camera_switch

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

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

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

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

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

Getestete APIs:

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

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

test_multi_camera_switch_gray_uw_y

Abbildung 126. Graues Feld, aufgenommen mit dem Ultraweitwinkelobjektiv.

test_multi_camera_switch_gray_w_y

Abbildung 127. Grauer Fleck, aufgenommen mit dem Weitwinkelobjektiv.

Szene 8

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

scene8 example

Abbildung 128. Beispiel für scene8.

test_ae_awb_regions

Tests, ob sich die RGB- und Luma-Werte unterscheiden, wenn die Vorschauaufzeichnung in verschiedenen AE- und AWB-Regionen erfolgt.

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

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

Getestete APIs:

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

test_ae_awb_regions_dark_region

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

test_ae_awb_regions_light_region

Abbildung 130. Heller Bereich mit verringerter Belichtung.

Fehlermechanismen:

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

    Falsche Ausrichtung von ArUco-Markierungen

    Abbildung 131. ArUco-Markierungen sind nicht richtig ausgerichtet.

test_color_correction_mode_cct

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

Getestete APIs:

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

Kriterien zum Überspringen von Tests

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

scene9

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

scene9-Beispiel

Abbildung 132. Beispiel für scene9.

test_jpeg_high_entropy

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

Getestete APIs:

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

test_jpeg_quality

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

Getestete APIs:

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

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

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

Beispiel für einen fehlgeschlagenen test_jpeg_quality-Test

Abbildung 134. Beispiel für einen fehlgeschlagenen Test.

scene_video

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

Abbildung 135. Beispiel für „scene_video“.

test_preview_frame_drop

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

Getestete APIs:

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

scene_extensions

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

scene_hdr

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

scene_hdr

Abbildung 136. Beispiel für scene_hdr.

test_hdr_extension

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

Getestete APIs:

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

scene_low_light

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

scene_low_light-Beispiel

Abbildung 137. Beispiel für „scene_low_light“.

test_night_extension

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

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

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

Getestete APIs:

Bestanden:

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

Das folgende Luminanzdiagramm zeigt, wie ein bestandener Test aussieht.

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

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

test_low_light_boost_extension

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

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

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

Getestete APIs:

Bestanden:

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

  • Bei Geräten mit Android 15 und niedriger muss der durchschnittliche Helligkeitswert der ersten sechs Quadrate mindestens 70 betragen und der durchschnittliche Unterschied im Helligkeitswert aufeinanderfolgender Quadrate bis zu Quadrat 5 und 6 muss mindestens 18 betragen.

scene_tele

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

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

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

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

scene6_tele

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

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

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

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

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

remove_front_plate

Abbildung 141. Entferne die Frontplatte.

test_zoom_tele

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

Getestete APIs:

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

test_preview_zoom_tele

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

Getestete APIs:

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

scene7_tele

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

test_multi_camera_switch_tele

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

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

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

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

Getestete APIs:

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

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

scene_flash

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

test_auto_flash

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

Getestete APIs:

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

test_flash_strength

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

Prüft, ob die Blitzstärke bei Verwendung der Kamera im SINGLE-Modus geändert wird, wenn verschiedene Stärken angefordert werden. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der Modus für die automatische Belichtung beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Wenn der Modus ON_AUTO_FLASH ist, hat die Blitzstärke keine Auswirkungen auf die Helligkeit.

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

Getestete APIs:

Bestanden:

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

test_led_snapshot

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

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

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

Getestete APIs:

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

test_night_mode_indicator

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

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

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

Getestete APIs:

Bestanden:

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

test_preview_min_frame_rate

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

Getestete APIs:

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

test_torch_strength

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

Prüft, ob die Blitzstärke während der Kameranutzung im TORCH-Modus angepasst wird, wenn unterschiedliche Stärken angefordert werden. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der Modus für die automatische Belichtung beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Wenn der Modus ON_AUTO_FLASH ist, hat die Blitzstärke keine Auswirkungen auf die Helligkeit. Prüft, ob die Helligkeit der Taschenlampe während eines Burst-Modus gleich bleibt, um eine Videoaufnahme zu simulieren. Für den Test müssen die Lichter im Prüfstand ausgeschaltet sein. Das kann automatisch über den Arduino-Controller erfolgen. Die Szene muss für den Test vollständig dunkel sein.

Getestete APIs:

Bestanden:

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

sensor_fusion

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

Diagramm zur Sensorfusion

Abbildung 142. Diagramm zur Sensorfusion

Diagramm zur Sensorfusion im Rig

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

test_lens_intrinsic_calibration

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

Getestete APIs:

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

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

test_lens_intrinsic_calibration_example.png

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

test_multi_camera_frame_sync

Tests, bei denen die von der logischen Kamera erfassten Frame-Zeitstempel innerhalb von 10 ms liegen, indem die Winkel von Quadraten innerhalb des Schachbrettmusters berechnet werden, um den Zeitstempel zu bestimmen.

Getestete APIs:

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

test_preview_distortion

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

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

test_preview_distortion_example.jpg

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

Getestete APIs:

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

test_preview_stabilization

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

Getestete APIs:

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

Hier sind Beispielvideos mit und ohne Stabilisierung:

Abbildung 146. Beispielvideo mit Stabilisierung.

Abbildung 147. Beispielvideo ohne Stabilisierung.

test_sensor_fusion

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

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

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

    Beispiel für test_sensor_fusion-Gyroskopereignisse

    Abbildung 148: Beispiel für test_sensor_fusion-Gyroskopereignisse.

  • test_sensor_fusion_plot_rotations: Zeigt die Ausrichtung der Gyroskop- und Kameraereignisse an. In diesem Diagramm muss die Bewegung zwischen Kamera und Gyroskop innerhalb von +/-1 ms übereinstimmen.

    Beispiel für test_sensor_fusion-Diagrammdrehungen

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

Getestete APIs:

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

Fehlermechanismen:

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

test_video_stabilization

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

Getestete APIs:

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

Hier sind Beispielvideos mit und ohne Stabilisierung.

Abbildung 150. Beispielvideo mit Stabilisierung.

Abbildung 151. Beispielvideo ohne Stabilisierung.

test_video_stabilization_jca

Bei Tests, bei denen mit der JCA aufgenommene Videos stabilisiert wurden, wird weniger gedreht als beim Gyroskop. Die JCA muss vor dem Testen auf dem Gerät installiert werden.

Getestete APIs:

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

feature_combination

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

test_feature_combination

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

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

Getestete APIs:

Bestanden:Für jede unterstützte Funktionskombination:

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

scene_ip

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

Anforderungen an die Hardwareeinrichtung

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

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

test_chart_gen2

Abbildung 152. Beispiel für Gen2chart_sample

Kriterien zum Überspringen von Tests

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

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

test_default_jca_ip

Erstellt Aufnahmen des Testfunktionsdiagramms unter kontrollierten Lichtverhältnissen mit der Standardkamera-App und dem JCA und führt die folgenden Prüfungen durch:

  • FoV:Prüft, ob die Standardkamera-App und JCA-Aufnahmen dasselbe Sichtfeld (Field of View, FoV) haben. Bei dieser Prüfung wird der mittlere QR-Code verwendet, der aus dem Bild des Erfassungsdiagramms extrahiert wurde.

  • Helligkeit:Prüft, ob die zwischen der Standardkamera-App und JCA gemessene Helligkeitsdifferenz 10 nicht überschreitet. Bei dieser Prüfung wird der Patch für den dynamischen Bereich für die Helligkeitsmessung verwendet.

  • Weißabgleich:Prüft, ob die Differenz beim Weißabgleich zwischen der Standardkamera-App und JCA nicht mehr als 4 beträgt. Bei dieser Prüfung wird der Patch für den dynamischen Bereich für die Helligkeitsmessung verwendet.

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