Kamera-ITS-Tests

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

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

Die Tests sind nach Szenen gruppiert:

  • scene0:Metadaten, Jitter, Gyroskop, Vibration erfassen
  • scene1:Belichtung, Empfindlichkeit, EV-Kompensation, YUV im Vergleich zu JPEG/RAW
  • scene2:Gesichtserkennung, Tests, für die Farbszenen erforderlich sind
  • scene3:Kantenschärfung, Objektivbewegung
  • scene4:Seitenverhältnis, Zuschnitt, Sichtfeld
  • scene5:Linsenabbildung
  • scene6:Zoom
  • scene7:Schalter für mehrere Kameras
  • scene8:AE- und AWB-Regionsmessung
  • scene9:JPEG-Komprimierung
  • scene_extensions:Kameraerweiterungen
  • scene_tele:Umschalten zum Teleobjektiv
  • scene_flash:Automatischer Blitz, minimale Framerate
  • scene_video:Frame-Drops
  • sensor_fusion:Zeitversatz zwischen Kamera und Gyroskop
  • feature_combination:Kombinationen von Funktionen
  • scene_ip:Bildübereinstimmung zwischen der Standardkamera-App und der JCA

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

scene0

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

test_jitter

Misst das Jitter bei Kamerazeitstempeln.

Getestete APIs:

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

test_jitter_plot.png

test_jitter_plot.png (Beachten Sie den kleinen Bereich der Y-Achse. Der Jitter ist in diesem Diagramm tatsächlich gering.)

test_metadata

Prüft die Gültigkeit von Metadateneinträgen. Es werden die Aufnahmeergebnisse und die Objekte mit Kameraeigenschaften berücksichtigt. Bei diesem Test werden die Belichtungs- und Verstärkungswerte auto_capture_request verwendet, da der Bildinhalt nicht wichtig ist.

Getestete APIs:

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

test_request_capture_match

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

Getestete APIs:

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

test_sensor_events

Prüft Geräteabfragen und druckt Sensorereignisse für Geräte aus, die die Sensorfusion unterstützen. 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 Standbymodus befindet.

Getestete APIs:

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

test_solid_color_test_pattern

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

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

Getestete APIs:

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

test_test_pattern

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

  1. Erfasst Bilder für alle unterstützten Testmuster.
  2. Führt eine einfache Prüfung der Richtigkeit für ein einfarbiges Testmuster und Farbbalken durch.

Getestete APIs:

Pass:Unterstützte Testmuster werden korrekt generiert.

test_test_patterns_2

test_test_patterns_2.jpg

test_tonemap_curve

Testet die Konvertierung des Testmusters von RAW nach YUV mit linearer Tonkarte. Für diesen Test ist android.sensor.testPatternMode = 2 (COLOR_BARS) erforderlich, um ein perfektes Bildmuster für die Tonwertanpassung zu generieren. Sorgt dafür, dass die Pipeline korrekte Farbausgaben mit linearer Tonkarte und idealer Bildeingabe hat (erfordert test_test_patterns).

Getestete APIs:

Pass: YUV und RAW sehen ähnlich aus.

test_tonemap_curve_raw_2

test_tonemap_curve_raw_2.jpg

test_tonemap_curve_yuv_2.jpg

test_tonemap_curve_yuv_2.jpg

test_unified_timestamp

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

Getestete APIs:

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

test_vibration_restriction

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

Getestete APIs:

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

scene1_1

scene1 ist ein graues Diagramm. Die graue Grafik muss die mittleren 30% des Sichtfelds der Kamera abdecken. Das graue Diagramm stellt voraussichtlich nur eine mäßige Herausforderung für 3A (automatische Belichtung, automatischer Weißabgleich, automatischer Fokus) dar, da die mittlere Region keine Merkmale aufweist. In der Aufnahmeanfrage wird jedoch die gesamte Szene angegeben, die genügend Merkmale für die 3A-Konvergenz enthält.

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

scene1

scene1: Diagramm in Originalgröße (links). Diagramm mit ⅔ Skalierung (rechts)

test_ae_precapture_trigger

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

Getestete APIs:

Pass:AE konvergiert.

test_auto_vs_manual

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

Getestete APIs:

Pass:Die in den einzelnen Aufnahmeergebnissen gemeldeten manuellen Weißabgleichsverstärkungen und ‑transformationen stimmen mit dem automatischen Weißabgleich estimate aus dem 3A-Algorithmus der Kamera überein.

test_auto_vs_manual_auto

test_auto_vs_manual_auto.jpg

test_auto_vs_manual_wb

test_auto_vs_manual_wb.jpg

test_auto_vs_manual_manual_wb_tm

test_auto_vs_manual_manual_wb_tm.jpg

test_black_white

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

Getestete APIs:

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

test_black_white_black test_black_white_black
test_black_white_black.jpg test_black_white_white.jpg

test_black_white_plot_means

test_black_white_plot_means.png

test_burst_capture

Prüft, ob die gesamte Aufnahmepipeline mit der Geschwindigkeit der Vollformataufnahme und der CPU-Zeit Schritt halten kann.

Getestete APIs:

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

test_burst_sameness_manual

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

Getestete APIs:

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

Fehlgeschlagen:Zeigt einen Anstieg oder Rückgang des RGB-Durchschnittsdiagramms zu Beginn jeder Burst-Sequenz an.

  • Toleranz ist 3% für first_API_level < 30
  • Toleranz von 2% für first_API_level >= 30

test_burst_sameness_manual_mean

test_burst_sameness_manual_mean.jpg

test_burst_sameness_manual_plot_means

test_burst_sameness_manual_plot_means.png

test_crop_region_raw

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

Getestete APIs:

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

test_crop_region_raw_comp_raw_crop

test_crop_region_raw_comp_raw_crop.jpg

test_crop_region_raw_comp_raw_full

test_crop_region_raw_comp_raw_full.jpg

test_crop_region_raw_comp_yuv_crop

test_crop_region_raw_comp_yuv_crop.jpg

test_crop_region_raw_yuv_full

test_crop_region_raw_yuv_full.jpg

test_crop_regions

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

Getestete APIs:

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

test_ev_compensation

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

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

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

Getestete APIs:

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

test_ev_compensation_basic

test_ev_compensation_basic.png

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

test_ev_compensation_advanced_plot_means

test_ev_compensation_advanced_plot_means.png

test_exposure_x_iso

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

Getestete APIs:

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

Fehlermechanismus:

  • In test_exposure_plot_means.png weichen die normalisierten RGB-Ebenen-Mittelwerte (y-Achse) mit steigenden Werten des Verstärkungsmultiplikators (x-Achse) von den Werten des niedrigen Verstärkungsmultiplikators ab.

test_exposure_plot_means

test_exposure_plot_means.png

test_exposure_mult=1.00 test_exposure_mult=64.00
test_exposure_mult=1.00.jpg test_exposure_mult=64.00.jpg

test_latching

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

Getestete APIs:

Nicht bestanden:Die Bilder [2, 3, 6, 8, 10, 12, 13] haben eine höhere ISO oder Belichtung und werden auf test_latching_plot_means.png mit einem höheren RGB-Mittelwert angezeigt.

test_latching_i=00.jpg test_latching_i=01.jpg test_latching_i=02.jpg
test_latching_i=00.jpg test_latching_i=01.jpg test_latching_i=02.jpg
test_latching_i=03.jpg test_latching_i=04.jpg test_latching_i=05.jpg
test_latching_i=03.jpg test_latching_i=04.jpg test_latching_i=05.jpg
test_latching_i=06.jpg test_latching_i=07.jpg test_latching_i=08.jpg
test_latching_i=06.jpg test_latching_i=07.jpg test_latching_i=08.jpg
test_latching_i=09.jpg test_latching_i=10.jpg test_latching_i=11.jpg
test_latching_i=09.jpg test_latching_i=10.jpg test_latching_i=11.jpg
test_latching_i=12.jpg
test_latching_i=12.jpg

test_latching_plot_means

test_latching_plot_means.png

test_linearity

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

Getestete APIs:

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

test_linearity_plot_means

test_linearity_plot_means.png

test_locked_burst

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

Getestete APIs:

Pass:Die Aufnahmen sind einheitlich.

test_locked_burst_frame0

test_locked_burst_frame0.jpg

test_locked_burst_frame1

test_locked_burst_frame1.jpg

test_locked_burst_frame2

test_locked_burst_frame2.jpg

scene1_2

Szene 1_2 ist eine funktional identische Kopie von Szene 1_1. Durch die Implementierung einer Unterszene wird die längere Dauer von Szene 1 verringert.

test_param_color_correction

Prüft, ob die android.colorCorrection.*-Parameter angewendet werden, wenn sie festgelegt sind. Es werden Aufnahmen mit unterschiedlichen Transformierungs- und Verstärkungswerten aufgenommen und getestet, ob sie sich entsprechend unterscheiden. Die Transformation und die Verstärkung werden so gewählt, dass die Ausgabe immer röter oder blauer wird. Es wird eine lineare Tonkarte verwendet. Bei der Tonmapping-Technologie werden bei der Bildverarbeitung eine Reihe von Farben einer anderen zugeordnet, um das Erscheinungsbild von Bildern mit hohem Dynamikumfang in einem Medium mit begrenztem Dynamikumfang anzunähern.

Getestete APIs:

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

test_param_color_correction_plot_means

test_param_color_correction_plot_means.png

*Die X-Achse zeigt die Aufnahmeanfragen: 0 = Einheit, 1=roter Boost, 2= blauer Boost

test_param_color_correction_req=0

test_param_color_correction_req=0.jpg

test_param_color_correctness_req=1

test_param_color_correctness_req=1.jpg (R boost)

test_param_color_correction_req=2

test_param_color_correction_req=2.jpg (B boost)

test_param_flash_mode

Prüft, ob der Parameter android.flash.mode angewendet wird. Die Belichtung wird manuell auf die dunkle Seite gesetzt, damit klar ist, ob der Blitz ausgelöst wurde oder nicht. Außerdem wird eine lineare Tonkarte verwendet. Prüft die Mitte des Kachelbilds, um festzustellen, ob ein großer Farbverlauf entsteht, der darauf hinweist, dass der Blitz ausgelöst wurde.

Getestete APIs:

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

test_param_flash_mode_1

test_param_flash_mode_1.jpg

test_param_flash_mode_1_tile

test_param_flash_mode_1_tile.jpg

test_param_flash_mode_2

test_param_flash_mode_2.jpg

test_param_flash_mode_2_tile

test_param_flash_mode_2_tile.jpg

test_param_noise_reduction

Prüft, ob der Parameter android.noiseReduction.mode nach der Festlegung korrekt angewendet wird. Bilder werden bei gedimmtem Licht aufgenommen. Verwendet einen hohen analogen Verstärkungsfaktor, um dafür zu sorgen, dass das aufgenommene Bild rauschig ist. Es werden drei Bilder aufgenommen: mit deaktivierter Rauschminderung, „Schnell“ und „Hohe Qualität“. Es wird auch ein Bild mit niedriger Verstärkung und deaktivierter Rauschunterdrückung aufgenommen und die Abweichung davon als Baseline verwendet. Je höher das SNR (Signal-Rausch-Verhältnis), desto besser die Bildqualität.

Getestete APIs:

Pass:Der SNR variiert mit den verschiedenen Geräuschunterdrückungsmodi und verhält sich ähnlich wie im Diagramm unten.

test_param_noise_reduction_plot_SNRs

test_param_noise_reduction_plot_SNRs.png

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

test_param_noise_reduction_high_gain_nr=0

test_param_noise_reduction_high_gain_nr=0.jpg

test_param_noise_reduction_high_gain_nr=1

test_param_noise_reduction_high_gain_nr=1.jpg

test_param_noise_reduction_high_gain_nr=2

test_param_noise_reduction_high_gain_nr=2.jpg

test_param_noise_reduction_high_gain_nr=3

test_param_noise_reduction_high_gain_nr=3.jpg

test_param_noise_reduction_low_gain

test_param_noise_reduction_low_gain.jpg

test_param_shading_mode

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

Getestete APIs:

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

test_param_shading_mode_ls_maps_mode_0_loop_0

test_param_shading_mode_ls_maps_mode_0_loop_0.png

test_param_shading_mode_ls_maps_mode_1_loop_0

test_param_shading_mode_ls_maps_mode_1_loop_0.png

test_param_shading_mode_ls_maps_mode_2_loop_0

test_param_shading_mode_ls_maps_mode_2_loop_0.png

test_param_tonemap_mode

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

Getestete APIs:

Karte/Ticket:

  • test1: Beide Bilder haben eine lineare Tonkarte, aber n=1 hat einen steileren Farbverlauf. Der G‑Kanal (grün) ist für das Bild mit n=1 heller.
  • test2: Dieselbe Tonkarte, aber unterschiedliche Länge. Mehrere identische Bilder.
test_param_tonemap_mode_n=0.jpg test_param_tonemap_mode_n=1.jpg
test_param_tonemap_mode_n=0.jpg test_param_tonemap_mode_n=1.jpg

test_post_raw_sensitivity_boost

Prüft die RAW-Empfindlichkeit nach der Steigerung. Es werden eine Reihe von RAW- und YUV-Bildern mit unterschiedlicher Empfindlichkeit aufgenommen, eine Kombination aus RAW-Empfindlichkeitssteigerungen gepostet und geprüft, ob der Mittelwert der Ausgabepixel mit den Anfrageeinstellungen übereinstimmt.

Getestete APIs:

Pass:RAW-Bilder werden dunkler, wenn der Boost erhöht wird, während YUV-Bilder gleichbleibend hell bleiben.

test_post_raw_sensitivity_boost_raw_s=3583_boost=0100

test_post_raw_sensitivity_boost_raw_s=3583_boost=0100.jpg

test_post_raw_sensitivity_boost_raw_s=1792_boost=0200

test_post_raw_sensitivity_boost_raw_s=1792_boost=0200.jpg

test_post_raw_sensitivity_boost_raw_s=0896_boost=0400

test_post_raw_sensitivity_boost_raw_s=0896_boost=0400.jpg

test_post_raw_sensitivity_boost_raw_s=0448_boost=0800

test_post_raw_sensitivity_boost_raw_s=0448_boost=0800.jpg

test_post_raw_sensitivity_boost_raw_s=0224_boost=1600

test_post_raw_sensitivity_boost_raw_s=0224_boost=1600.jpg

test_post_raw_sensitivity_boost_raw_s=0112_boost=3199

test_post_raw_sensitivity_boost_raw_s=0112_boost=3199.jpg

test_post_raw_sensitivity_boost_raw_plot_means

test_post_raw_sensitivity_boost_raw_plot_means.png

test_post_raw_sensitivity_boost_yuv_s=0112_boost=3199

test_post_raw_sensitivity_boost_yuv_s=0112_boost=3199.jpg

test_post_raw_sensitivity_boost_yuv_s=0448_boost=0800

test_post_raw_sensitivity_boost_yuv_s=0448_boost=0800.jpg

test_post_raw_sensitivity_boost_yuv_s=0896_boost=0400

test_post_raw_sensitivity_boost_yuv_s=0896_boost=0400.jpg

test_post_raw_sensitivity_boost_yuv_s=1792_boost=0200

test_post_raw_sensitivity_boost_yuv_s=1792_boost=0200.jpg

test_post_raw_sensitivity_boost_yuv_s=3585_boost=0100

test_post_raw_sensitivity_boost_yuv_s=3585_boost=0100.jpg

test_post_raw_sensitivity_boost_yuv_plot_means

test_post_raw_sensitivity_boost_yuv_plot_means.png

test_raw_exposure

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

Getestete APIs:

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

test_raw_exposure_s=55

test_raw_exposure_s=55.png

(10⁰ = 1 ms, 10¹ = 10 ms, 10⁻¹ = 0,1 ms)

test_raw_exposure_s=132

test_raw_exposure_s=132.png

test_raw_exposure_s=209

test_raw_exposure_s=209.png

test_raw_exposure_s=286

test_raw_exposure_s=286.png

test_raw_exposure_s=363

test_raw_exposure_s=363.png

test_raw_exposure_s=440

test_raw_exposure_s=440.png

test_reprocess_noise_reduction

Tests, bei denen android.noiseReduction.mode für die erneute Verarbeitung von Anfragen angewendet wird. Hier werden Bilder aufgenommen, die mit der Kamera bei gedimmtem Licht neu verarbeitet wurden. Verwendet einen hohen analogen Verstärkungsgrad, um dafür zu sorgen, dass das aufgenommene Bild rauschig ist. Es werden drei neu verarbeitete Bilder aufgenommen: für NR-Aus, „Schnell“ und „Hohe Qualität“. Es wird ein neu verarbeitetes Bild mit niedrigem Gewinn und deaktivierter Rauschunterdrückung aufgenommen und die Abweichung davon als Baseline verwendet.

Getestete APIs:

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

Typische Darstellung von SNR im Vergleich zu NR_MODE

Typische Darstellung von SNR im Vergleich zu NR_MODE

test_tonemap_sequence

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

Getestete APIs:

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

test_tonemap_sequence_i=0

test_tonemap_sequence_i=0.jpg

test_tonemap_sequence_i=1

test_tonemap_sequence_i=1.jpg

test_tonemap_sequence_i=2

test_tonemap_sequence_i=2.jpg

test_tonemap_sequence_i=3

test_tonemap_sequence_i=3.jpg

test_tonemap_sequence_i=4

test_tonemap_sequence_i=4.jpg

test_tonemap_sequence_i=5

test_tonemap_sequence_i=5.jpg

test_yuv_jpeg_all

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

Getestete APIs:

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

test_yuv_jpeg_all

test_yuv_jpeg_all.png

test_yuv_plus_dng

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

Getestete APIs:

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

test_yuv_plus_dng

test_yuv_plus_dng.jpg

scene1_3

Szene 1_3 ist eine funktional identische Kopie von Szene 1_1. Durch die Implementierung einer untergeordneten Szene wird die längere Dauer von Szene 1 verringert.

test_capture_result

Prüft, ob gültige Daten in CaptureResult-Objekten zurückgegeben werden. Ermöglicht eine automatische, manuelle und automatische Aufnahme.

Getestete APIs:

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

test_capture_result_plot_lsc_auto_ch0

test_capture_result_plot_lsc_auto_ch0.png

test_dng_noise_model

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

Getestete APIs:

Pass:Die DNG-Raw-Modellparameter sind korrekt. Die erwarteten RGB-Werte stimmen mit den tatsächlich gemessenen RGB-Werten überein.

test_dng_noise_model_plog

test_dng_noise_model_plog.png

test_jpeg

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

Getestete APIs:

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

test_jpeg_fmt=jpg.jpg test_jpeg=fmt=yuv.jpg
test_jpeg_fmt=jpg.jpg test_jpeg=fmt=yuv.jpg

test_raw_burst_sensitivity

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

Getestete APIs:

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

Die Abweichung der Rasterzelle mit den Mittelungsstatistiken wird verwendet.

test_raw_burst_sensitivity_variance

test_raw_burst_sensitivity_variance.png

test_raw_sensitivity

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

Getestete APIs:

Pass:Die Varianz steigt mit jedem Schuss.

test_raw_sensitivity_variance

test_raw_sensitivity_variance.png

test_yuv_plus_jpeg

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

Getestete APIs:

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

test_yuv_plus_jpg_jpg.jpg test_yuv_plus_jpeg_yuv.jpg
test_yuv_plus_jpg_jpg.jpg test_yuv_plus_jpeg_yuv.jpg

test_yuv_plus_raw

Hier wird getestet, ob ein einzelner Frame sowohl als RAW/RAW10/RAW12 als auch als YUV-Ausgabe erfasst werden kann. Es wird eine manuelle Anfrage mit linearer Tonkarte verwendet, sodass Raw und YUV voraussichtlich identisch sind. Vergleicht die RGB-Werte von 10% der Bildmitte der in RGB konvertierten Bilder. Protokolleandroid.shading.mode

Getestete APIs:

Pass: YUV- und Rohbilder sind ähnlich und haben eine RMS-Differenz (Root Mean Square, Wurzel der mittleren Fehlerquadratsumme) von weniger als 3,5 %.

test_yuv_plus_raw_shading=1_raw.jpg test_yuv_plus_raw_shading=1_yuv.jpg
test_yuv_plus_raw_shading=1_raw.jpg test_yuv_plus_raw_shading=1_yuv.jpg

test_sensitivity_priority

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

Getestete APIs:

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

Testkriterien für das Überspringen

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

test_exposure_time_priority

Der CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY wird mit verschiedenen Belichtungszeiten getestet, um eine stabile Helligkeit im Bereich zu ermitteln, in dem die ISO-Empfindlichkeit kompensieren kann.

Getestete APIs:

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

Testkriterien für das Überspringen

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

scene2_a

scene2_a zeigt drei Gesichter vor einem grauen Hintergrund und in neutraler Kleidung. Die Gesichter haben unterschiedliche Hauttöne. Das Diagramm muss richtig ausgerichtet sein, damit die Gesichtserkennung optimal funktioniert.

scene2_a

scene2_a

test_autoframing

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

Getestete APIs:

Pass:Alle drei Gesichter werden erkannt.

test_display_p3

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

Getestete APIs:

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

test_effects

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

Getestete APIs:

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

test_effects_MONO

test_effects_MONO.jpg

test_exposure_keys_consistent

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

Getestete APIs:

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

test_format_combos

Hier werden verschiedene Kombinationen von Ausgabeformaten getestet.

Getestete APIs:

Pass:Alle Kombinationen wurden erfasst.

test_num_faces

Hier wird die Gesichtserkennung getestet.

Getestete APIs:

Pass:Es werden drei Gesichter gefunden.

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_reprocess_uv_swap

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

Getestete APIs:

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

test_reprocess_uv_swap

test_reprocess_uv_swap.png

scene2_b

test_preview_num_faces

Tests der Gesichtserkennung in der Vorschau mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_yuv_jpeg_capture_sameness

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

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

Getestete APIs:

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

scene2_c

test_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden drei Gesichter gefunden.

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_jpeg_capture_perf_class

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

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

test_camera_launch_perf_class

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

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

test_default_camera_hdr

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

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

scene2_d

test_preview_num_faces

Tests der Gesichtserkennung in der Vorschau mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

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

scene2_e

test_continuous_picture

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

Getestete APIs:

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

test_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden drei Gesichter gefunden.

scene2_f

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

scene2_f.png

scene2_f

test_preview_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

scene2_g

scene2_g enthält drei Profilansichten mit weißem Hintergrund und weißer Kleidung. Die Gesichter haben eine Vielzahl von Hauttönen und einen hohen Kontrast zum Hintergrund.

scene2_g.png

scene2_g

test_preview_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

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

test_preview_num_faces

test_preview_num_faces

scene3

In Scene3 wird das ISO12233-Diagramm verwendet und in den meisten Tests wird eine Diagramm-Extraktionsmethode verwendet, um das Diagramm in der Szene zu finden. Aus diesem Grund haben die meisten gespeicherten Bilder keine Rahmen wie die Bilder für Szene 1, 2 oder 4, sondern nur das Diagramm. Das Diagramm muss richtig ausgerichtet sein, damit die Diagrammsuche optimal funktioniert.

test_edge_enhancement

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

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

Getestete APIs:

Betroffene Kameraparameter:

  • EDGE_MODE

test_edge_enhancement_edge=0

test_edge_enhancement_edge=0.jpg

test_edge_enhancement_edge=1

test_edge_enhancement_edge=1.jpg (Schnellmodus)

test_edge_enhancement_edge=2

test_edge_enhancement_edge=2.jpg (Modus „Hohe Qualität“)

test_flip_mirror

Prüft, ob das Bild gemäß CDD-Abschnitt 7.5.2 Frontkamera [C-1-5] richtig ausgerichtet ist.

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

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

test_flip_mirror_scene_patch

test_flip_mirror_scene_patch.jpg

test_imu_drift

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

Getestete APIs:

Karte/Ticket:

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

test_imu_drift_gyro_drift.png

test_imu_drift_gyro_drift.png

test_imu_drift_rotation_vector_drift.png

test_imu_drift_rotation_vector_drift.png

test_landscape_to_portrait

Prüft, ob die Umstellung von Quer- auf Hochformat für horizontal ausgerichtete Sensoren richtig funktioniert.

Getestete APIs:

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

test_landscape_to_portrait

test_landscape_to_portrait.png

test_lens_movement_reporting

Prüft, ob das Flag für die Objektivbewegung korrekt gemeldet wird. Es werden 24 Bilder aufgenommen, wobei die ersten 12 Frames auf die optimale Fokusdistanz (wie von 3A ermittelt) und die letzten 12 Frames auf die minimale Fokusdistanz eingestellt sind. Etwa bei Frame 12 bewegt sich das Objektiv, wodurch die Schärfe nachlässt. Die Schärfe stabilisiert sich schließlich, wenn sich das Objektiv in der Endposition befindet. Das Flag für die Objektivbewegung sollte in allen Frames gesetzt werden, in denen die Schärfe mittel bis scharf ist. Das gilt für die ersten Frames, in denen das Objektiv bei der optimalen Brennweite steht, und für die letzten Frames, in denen das Objektiv bei der minimalen Brennweite steht. Der genaue Frame, in dem sich das Objektiv bewegt, ist nicht wichtig. Es wird nur geprüft, ob das Bewegungsflag gesetzt wird, wenn sich das Objektiv bewegt.

Getestete APIs:

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

Fehlermechanismen:

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

test_reprocess_edge_enhancement

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

Getestete APIs:

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

test_reprocess_edge_enhancement_plot

test_reprocess_edge_enhancement_plot.png

scene4

Szene 4 besteht aus einem schwarzen Kreis auf weißem Hintergrund in einem Quadrat. Tests in scene4 können empfindlich auf die Ausrichtung reagieren. Ab Version 15 können Sie im Tools-Verzeichnis check_alignment.py verwenden, um eine Prüfung der DUT und der Diagrammausrichtung zu aktivieren.

scene4

scene4

test_30_60fps_preview_fov_match

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

Getestete APIs:

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

Fehlermechanismen:

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

test_aspect_ratio_and_crop

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

Getestete APIs:

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

Fehlermechanismen:

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

test_multi_camera_alignment

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

Getestete APIs:

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

Fehlermechanismen:

  • LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION oder LENS_POSE_ROTATION sind Designwerte und keine tatsächlichen Kalibrierungsdaten.
  • Das Kamerasystem ist für die Testeinrichtung nicht geeignet. Beispielsweise können Sie ein Weitwinkel- und ein Ultraweitwinkel-Kamerasystem mit dem RFoV-Testgestell testen. Weitere Informationen finden Sie unter Camera ITS-in-a-box FAQ1.

test_preview_aspect_ratio_and_crop

Ähnlich wie beim Test test_aspect_ratio_and_crop für Standbilder werden hier 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 nicht ändert, der Kreis bei den zugeschnittenen Bildern in der Mitte des Frames bleibt und die Kreisgröße sich bei einem konstanten Format oder bei verschiedenen Auflösungen nicht ändert (Feldblickprüfung).

Getestete APIs:

Bestanden:Die Bilder sind nicht gestreckt, die Mitte der Bilder unterscheidet sich nicht um mehr als 3 % und das maximale Sichtfeld wird beibehalten.

test_preview_stabilization_fov

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

Getestete APIs:

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

test_video_aspect_ratio_and_crop

Ermöglicht die Aufnahme von Videos eines Kreises in einem Quadrat in allen Videoformaten. Die Keyframes werden extrahiert und es wird geprüft, ob sich das Seitenverhältnis des Kreises nicht ändert, ob der Kreis in den zugeschnittenen Bildern zentriert ist und ob sich die Kreisgröße bei einem konstanten Format oder bei einer anderen Auflösung nicht ändert (FOV-Prüfung).

Getestete APIs:

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

scene5

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

Zur Vorbereitung der Szene befestigen Sie einen Diffusor vor der Kamera und richten Sie die Kamera auf eine Lichtquelle mit etwa 2.000 Lux. Für Szene 5 aufgenommene Bilder erfordern diffuses Licht ohne erkennbare Merkmale. Hier ein Beispielbild:

scene5

scene5 capture

test_lens_shading_and_color_uniformity

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

Getestete APIs:

Erfolgreich:Im angegebenen Radius des Bildes muss die Abweichung der Werte R/G und B/G unter 20% liegen, damit der Test bestanden wird.

scene6

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

scene6

scene6

test_in_sensor_zoom

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

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

Getestete APIs:

Erfolgreich:Der 3D-RMS-Unterschied (Root Mean Square) zwischen dem herunterskalierten zugeschnittenen RAW-Bild und dem RAW-Bild mit vollem Sichtfeld liegt unter dem im Test festgelegten Grenzwert.

test_zoom

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

Getestete APIs:

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

test_zoom

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

test_low_latency_zoom

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

Getestete APIs:

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

test_preview_video_zoom_match

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

Getestete APIs:

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

HD_1280x720_key_frame.png

HD_1280x720_key_frame.png (vor dem Zoomen)

preview_1280x720_key_frame.png

preview_1280x720_key_frame.png (vor dem Zoomen)

HD_1280x720_key_frame_zoomed.png

HD_1280x720_key_frame.png (nach dem Zoomen)

preview_1280x720_key_frame_zoomed.png

preview_1280x720_key_frame.png (nach dem Zoomen)

test_preview_zoom

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

Getestete APIs:

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

test_zoom

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

test_session_characteristics_zoom

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

Getestete APIs:

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

scene7

Scene7 ist ein rechteckiger Frame, der in vier gleich große Quadranten unterteilt ist, die jeweils mit einer anderen Farbe gefüllt sind. In der Mitte des Rechtecks befindet sich ein Diagramm mit schrägen Linien zur Schärfeprüfung. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um bei unterschiedlichen Zoomfaktoren genaue Koordinaten des Hauptrechtecks zu erhalten.

scene7

scene7

test_multi_camera_switch

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

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

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

Die AE-Prüfung sorgt dafür, dass die Helligkeitsänderung sowohl bei Bildern mit Weitwinkel- als auch mit Ultraweitwinkelobjektiv im erwarteten Bereich liegt. Bei der AWB-Prüfung wird überprüft, ob die R/G- und B/G-Verhältnisse sowohl bei Bildern mit Weitwinkel- als auch mit Ultraweitwinkelobjektiv innerhalb der Grenzwerte liegen. Bei der AF-Prüfung wird der Schärfewert anhand der durchschnittlichen Gradientenstärke zwischen UW- und Weitwinkelaufnahmen bewertet.

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

Getestete APIs:

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

  • AE-Prüfung: Die Luminanzänderung (Y-Wert) zwischen den Bildern des Weitwinkel- und des Weitwinkelobjektivs muss für alle Farbfelder unter 4% liegen, wenn das Gerät sowohl ae_regions als auch awb_regions unterstützt. Wenn nur ae_regions unterstützt wird, müssen nur die Werte für den grauen Farbfleck die Kriterien erfüllen.
  • AWB-Prüfung: Der Unterschied zwischen den R/G- und B/G-Werten für die Bilder mit Weitwinkel- und Weitwinkelobjektiv muss für den grauen Farbfleck unter 3% und für andere Farbflecke unter 10% liegen, wenn das Gerät sowohl ae_regions als auch awb_regions unterstützt.
  • AF-Prüfung: Die Bildschärfe der Aufnahme mit dem Weitwinkelobjektiv muss höher sein als die der Aufnahme mit dem Ultraweitwinkelobjektiv.

test_multi_camera_switch_gray_uw_y

Grauer Fleck, aufgenommen mit Weitwinkelobjektiv

test_multi_camera_switch_gray_w_y

Grauer Fleck, aufgenommen mit Weitwinkelobjektiv

scene8

Scene8 ist ein rechteckiger Frame, 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-Markierungen werden an den vier äußeren Ecken des Rechtecks ausgerichtet, um genaue Koordinaten des Hauptrechtecks zu erhalten.

scene8

scene8

test_ae_awb_regions

Prüft, ob sich die RGB- und Luminanzwerte bei der Vorschauaufnahme mit unterschiedlichen Bereichen für die automatische Belichtung (AE) und den automatischen Weißabgleich (AWB) unterscheiden.

Dabei wird eine achtsekündige Vorschauaufnahme erstellt, bei der die AE- und AWB-Messung jeweils zwei Sekunden lang für jeden Quadranten durchgeführt wird. Im Test wird dann ein Frame aus der Vorschauaufnahme jeder Region extrahiert und mit den extrahierten Frames werden die folgenden AE- und AWB-Prüfungen durchgeführt:

  • AE-Prüfung: Prüft, ob der Luma-Wert des Frames, in dem die Region mit verringerter Belichtung gemessen wird, um mehr als 1% höher ist als der Luma-Wert des Frames, in dem die Region mit erhöhter Belichtung gemessen wird. So wird überprüft, ob Bilder bei der Belichtung einer dunklen Region aufgehellt werden.
  • AWB-Prüfung: Prüft, ob das Verhältnis von Rot zu Blau (der durchschnittlichen RGB-Werte des Bilds) im Frame mit dem blauen Messbereich um mehr als 2 % höher ist als im Frame mit dem gelben Messbereich. So wird sichergestellt, dass Bilder einen ausgewogenen RGB-Wert haben, wenn eine gelbe (warme) oder blaue (kalte) Region gemessen wird.

Getestete APIs:

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

test_ae_awb_regions_dark_region

Belichtung eines dunklen Bereichs im Frame mit erhöhter Belichtung

test_ae_awb_regions_light_region

Belichtungsmessung für hellere Bereiche mit verringerter Belichtung

Fehlermechanismen:

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

    Falsch ausgerichtete ArUco-Markierungen

test_color_correction_mode_cct

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

Getestete APIs:

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

Testkriterien für das Überspringen

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

scene9

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

scene9

scene9

test_jpeg_high_entropy

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

Getestete APIs:

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

test_jpeg_quality

Hier wird die JPEG-Komprimierungsqualität der Kamera getestet. Ändern Sie die JPEG-Qualität über android.jpeg.quality und achten Sie darauf, dass sich die Quantisierungstabellen richtig ändern.

Getestete APIs:

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

test_jpeg_quality

DQT-Matrix-Mittelwerte für Luminanz/Chromatik der Rückkamera von Google Pixel 4 im Vergleich zur JPEG-Qualität

test_jpeg_quality fehlgeschlagen

Beispiel für einen fehlgeschlagenen Test

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

scene_video

Die Szene scene_video ist eine Video-Szene. Es besteht aus vier unterschiedlich farbigen Kreisen, die sich vor einem weißen Hintergrund mit unterschiedlichen Frameraten vor- und zurückbewegen.

scene_video

test_preview_frame_drop

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

Getestete APIs:

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

scene_extensions

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

scene_hdr

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

scene_hdr

scene_hdr

test_hdr_extension

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

Getestete APIs:

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

scene_low_light

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

scene_low_light

scene_low_light

test_night_extension

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

  • Erkennt 20 Quadrate
  • Berechnet die Luminanz, die von jedem Quadrat begrenzt ist.
  • Berechnet den durchschnittlichen Luminanzwert der ersten 6 Quadrate gemäß der Ausrichtung des Hilbert-Kurven-Rasters.
  • Berechnet die Differenz des Luminanzwerts aufeinanderfolgender Quadrate (z. B. Quadrat 2 – Quadrat 1) bis zu den Quadraten 5 und 6 (Quadrat 6 – Quadrat 5) und ermittelt den Durchschnitt der fünf berechneten Differenzen.

Bei Geräten mit Android 16 oder höher enthält der Aufnahmeantrag einen Messbereich, der dem Rechteck entspricht, das das Quadratraster umschließt. Durch diese Ergänzung ändern sich die Kriterien für die Grenzwerte.

Getestete APIs:

Karte/Ticket:

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

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

scene_low_light_night_pass

test_low_light_boost_extension

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

  • Erkennt die Anwesenheit von 20 Boxen
  • Berechnet die von jedem Feld begrenzte Luminanz.
  • Berechnet den durchschnittlichen Luminanzwert der ersten 6 Quadrate gemäß der Ausrichtung des Hilbert-Kurven-Rasters.
  • Berechnet die Differenz des Luminanzwerts aufeinanderfolgender Quadrate (z. B. Quadrat 2 – Quadrat 1) bis zu den Quadraten 5 und 6 (Quadrat 6 – Quadrat 5) und ermittelt den Durchschnitt der fünf berechneten Differenzen.

Bei Geräten mit Android 16 oder höher enthält der Aufnahmeantrag einen Messbereich, der dem Rechteck entspricht, das das Quadratraster umschließt. Durch diese Ergänzung ändern sich die Kriterien für die Grenzwerte.

Getestete APIs:

Karte/Ticket:

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

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

scene_tele

Eine wichtige Anforderung für scene_tele-Tests ist, dass der Abstand zum Diagramm mindestens der Mindestfokusdistanz des Teleobjektivs entspricht. Da sich dieser Mindestfokusabstand von Gerät zu Gerät unterscheiden kann, müssen Sie Ihre Einrichtung an die jeweilige Teleobjektivkamera anpassen.

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

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

scene6_tele

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

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

remove_phone_mount

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

remove_front_plate

Entfernen Sie die Abdeckung.

test_zoom_tele

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

Getestete APIs:

Erfolgreich:Die relative Größe der erfassten ArUco-Markierung stimmt mit dem angeforderten Zoomverhältnis überein, damit die Kamera richtig heranzoomt. Die Entfernung der Markierung zum Bildmittelpunkt ändert sich gemäß den in test_zoom aufgeführten Kriterien.

test_preview_zoom_tele

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

Getestete APIs:

Erfolgreich:Die relative Größe der erfassten ArUco-Markierung stimmt mit dem angeforderten Zoomverhältnis überein, damit die Kamera richtig heranzoomt. Die Entfernung der Markierung zum Bildmittelpunkt ändert sich gemäß den in test_preview_zoom aufgeführten Kriterien.

scene7_tele

„scene7_tele“ ist mit scene7 identisch, aber für Tests mit Teleobjektiven eingerichtet. Es ist ein rechteckiger Frame, der in vier gleich große Quadranten unterteilt ist, die jeweils mit einer anderen Farbe gefüllt sind. In der Mitte des Rechtecks befindet sich ein Diagramm mit schrägen Linien zur Schärfeprüfung. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet, um bei unterschiedlichen Zoomfaktoren genaue Koordinaten des Hauptrechtecks zu erhalten.

test_multi_camera_switch_tele

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

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

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

Die AE-Prüfung sorgt dafür, dass die Helligkeitsänderung sowohl bei Weitwinkel- als auch bei Teleobjektiven im erwarteten Bereich liegt. Bei der AWB-Prüfung wird überprüft, ob die R/G- und B/G-Verhältnisse sowohl bei Weitwinkel- als auch bei Teleobjektiven innerhalb der Grenzwerte liegen. Bei der AF-Prüfung wird der Schärfeschätzwert anhand der durchschnittlichen Steigungsmagnitude zwischen Weitwinkel- und Teleobjektivbildern bewertet.

Getestete APIs:

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

  • AE-Prüfung: Die Helligkeitsänderung zwischen den Bildern mit Weitwinkel- und Teleobjektiv darf maximal 4 % betragen.
  • AWB-Prüfung: Im LAB-Farbraum darf der Delta-C-Wert zwischen R/G und B/G für Weitwinkel- und Teleobjektiv nicht über 10 liegen.
  • AF-Prüfung: Die Bildschärfe des Teleobjektivs muss höher sein als die des Weitwinkelobjektivs.

scene_flash

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

test_auto_flash

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

Getestete APIs:

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

test_flash_strength

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

Prüft, ob das Gerät die Kontrolle der Blitzstärke bei der Verwendung der Kamera im Modus SINGLE unterstützt und ob sich die Blitzstärke bei verschiedenen angeforderten Stärken ändert. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der Modus der automatischen Belichtung beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Bei ON_AUTO_FLASH hat sie dagegen keine Auswirkungen. Zum Ausführen des Tests müssen die Lampen im Testgestell ausgeschaltet werden. Sie können mit dem Arduino-Controller automatisch ausgeschaltet werden. Die Szene muss vollständig dunkel sein, damit der Test richtig funktioniert.

Getestete APIs:

Karte/Ticket:

Wenn der Modus für die automatische Belichtung ON oder OFF ist, erhöht sich die Helligkeit der Bildbereiche, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_SINGLE_STRENGTH_MAX_LEVEL erhöht wird. Wenn der Modus „Automatische Belichtung“ auf ON_AUTO_FLASH eingestellt ist, liegt die Helligkeitsdifferenz der Bildflecke innerhalb der Toleranz, wenn die Blitzstärke von „Kein Blitz“ auf FLASH_SINGLE_STRENGTH_MAX_LEVEL erhöht wird.

test_led_snapshot

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

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

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

Getestete APIs:

Gültig:Die R/G- und B/G-Verhältnisse liegen zwischen 0,95 und 1,05. Der Mittelwert des Blitzbilds liegt im Bereich (68, 102).

test_night_mode_indicator

Hier wird die Funktion der Nachtmodus-Anzeige getestet. Diese Funktion gibt an, ob die Kamera bei schlechten Lichtverhältnissen arbeitet und von einer Aufnahme mit der Kameraerweiterung „Nachtmodus“ profitieren würde. Diese Funktion ist nur auf Geräten verfügbar, die Kameraerweiterungen für den Nachtmodus unterstützen.

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

Getestete APIs:

Karte/Ticket:

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

test_preview_min_frame_rate

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

Getestete APIs:

Erfolgreich:Die Framerate der Vorschau liegt im Mindestwert des angeforderten Frameratenbereichs und die Abweichung zwischen den Frames ist kleiner als die im Test festgelegte absolute Toleranz.

test_torch_strength

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

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

Getestete APIs:

Karte/Ticket:

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

sensor_fusion

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

Diagramm für Sensorfusion

Diagramm für Sensorfusion

Diagramm zur Sensorfusion in Rig

Sensorfusionsdiagramm, das die Rückseite des Sensorfusionsfelds ausfüllt

test_lens_intrinsic_calibration

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

Getestete APIs:

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

test_lens_intrinsic_calibration_example.png

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

test_multi_camera_frame_sync

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

Getestete APIs:

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

test_preview_distortion

Prüft, ob die Verzerrung in jedem Vorschauframe korrigiert wird, der bei verschiedenen Zoomstufen aufgenommen wurde. Für jeden Vorschauframe werden im Test anhand der intrinsischen und extrinsischen Kameraparameter ideale Punkte berechnet. Im Beispielbild sind die idealen Punkte grün und die tatsächlichen Punkte rot dargestellt. Der Verzerrungsfehler wird anhand der Wurzel der mittleren quadratischen Pixeldistanz (Root Mean Square, RMS) zwischen den tatsächlichen Punkten und den idealen Punkten berechnet. Die grünen und roten Markierungen auf dem Bild dienen dazu, den Bereich mit dem Verzerrungsfehler visuell zu erkennen.

test_preview_distortion_example.jpg

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

Getestete APIs:

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

test_preview_stabilization

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

Getestete APIs:

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

Unten findest du Beispielvideos mit und ohne Stabilisierung.

  • Beispielvideo mit Stabilisierung

  • Beispielvideo ohne Stabilisierung

test_sensor_fusion

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

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

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

    test_sensor_fusion_gyro_events.png

    test_sensor_fusion_gyro_events

  • test_sensor_fusion_plot_rotations: Zeigt die Ausrichtung des Gyroskops und Kameraereignisse an. Dieser Plot muss eine übereinstimmende Bewegung zwischen Kamera und Gyroskop mit einer Abweichung von +/- 1 ms zeigen.

    test_sensor_fusion_plot_rotations.png

    test_sensor_fusion_plot_rotations

Getestete APIs:

Pass:Die Zeitstempel von Kamera und Gyroskop weichen gemäß Abschnitt 7.3.9 „High Fidelity Sensors“ [C-2-14] des CDD um weniger als 1 ms voneinander ab.

Fehlermechanismen:

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

test_video_stabilization

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

Getestete APIs:

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

Unten findest du Beispielvideos mit und ohne Stabilisierung.

  • Beispielvideo mit Stabilisierung

  • Beispielvideo ohne Stabilisierung

test_video_stabilization_jca

Tests haben gezeigt, dass Videos, die mit der Jetpack Camera App (JCA) stabilisiert wurden, weniger rotieren als mit dem Gyroskop. Die JCA muss vor dem Testen auf dem Gerät installiert sein.

Getestete APIs:

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

feature_combination

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

test_feature_combination

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

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

Getestete APIs:

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

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

scene_ip

(Verfügbar ab Android 16) Mit „scene_ip“ können Bildparitätsprüfungen zwischen der Standardkamera-App und der Jetpack-Kamera-App (JCA) durchgeführt werden, um große Unterschiede zwischen aufgenommenen Bildern zu erkennen. Die JCA repliziert die Aufnahmen der Social-Media-App und stellt ein Baseline-Image bereit, das von den Social-Media-Apps verarbeitet und optimiert wird.

Anforderungen an die Hardwareeinrichtung

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

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

test_chart_gen2

Gen2chart_sample.png

Testkriterien für das Überspringen

Die Tests für „scene_ip“ werden übersprungen, wenn eines der folgenden Kriterien erfüllt ist:

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

test_default_jca_ip

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

  • Bildwinkel:Prüft, ob die Standardkamera-App und die JCA-Aufnahmen denselben Bildwinkel haben. Bei dieser Prüfung wird die Funktion „Mittlerer QR-Code“ verwendet, die aus dem erfassten Diagrammbild extrahiert wird.

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

  • Weißabgleich:Prüft, ob die Weißabgleichsdifferenz zwischen der Standardkamera-App und JCA 4 nicht überschreitet. Bei dieser Prüfung wird der Patch für den dynamischen Bereich für die Helligkeitsmessung verwendet.

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