Kamera-ITS-Tests

Auf dieser Seite finden Sie eine umfassende Liste der Tests der Camera Image Test Suite (ITS), die Teil des Verifiers der Android Compatibility Test Suite (CTS) 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:

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 Millisekunden.

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- und frameDuration-Tags, timestampSource, croppingType, blackLevelPattern, pixel_pitch, Blickwinkel 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:

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 geprüft. 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 Tonmap-Konvertierung 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

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 ⅔ der 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-Ausfälle 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 von 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_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_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_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_ev_compensation_advanced

Prüft, ob die Belichtungskorrektur angewendet wird. Dabei 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 EV-Kompensation 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:

Pass:Die Bilder zeigen eine zunehmende Belichtung ohne Überbelichtung in fünf Schritten.

test_ev_compensation_advanced_plot_means

test_ev_compensation_advanced_plot_means.png

test_ev_compensation_basic

Hier wird getestet, ob die Belichtungskorrektur mit einem Bereich angewendet wird, der mit CONTROL_AE_COMPENSATION_STEP erstellt wurde. Bei jedem Wert für die Belichtungskorrektur werden acht Frames erfasst.

Getestete APIs:

Pass:Die Luminanz wird bei erhöhter Belichtungseinstellung erhöht. Die acht Frames, die für jede Belichtungseinstellung erfasst werden, haben stabile Luminanzwerte.

test_ev_compensation_basic

test_ev_compensation_basic.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 ausgewä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 lassen würde. 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_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_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:

Genehmigt: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

Hier werden die 3A-Sperre und der YUV-Burst (mit automatischer Einstellung) getestet. 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

test_param_color_correction

Prüft, ob die android.colorCorrection.*-Parameter angewendet werden, wenn sie festgelegt sind. Es werden Aufnahmen mit verschiedenen 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=Rotverstärkung, 2= Blauverstärkung

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: „Rauschminderung deaktiviert“, „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_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_exposure

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

Getestete APIs:

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

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

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

scene2_a

scene2_a zeigt drei Gesichter vor grauem 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 für die 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:

Pass:Hier wird das Bild der Szene mit den Effekten OFF und ein Schwarzweißbild mit den Effekten MONO aufgenommen.

test_effects_MONO

test_effects_MONO.jpg

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:

Überspringen: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_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_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 von camera2 für 1080p-Auflösung muss unter ITS-Beleuchtungsbedingungen (3.000 K) für beide Hauptkameras unter 1.000 ms liegen, wie im CTS-Kamera-Leistungstest gemessen.

test_camera_launch_perf_class

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

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

test_default_camera_hdr

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

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

scene2_d

test_num_faces

Tests der Gesichtserkennung mit mehr Hauttonvielfalt in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden drei Gesichter gefunden.

scene2_e

test_continuous_picture

Mit der ersten Einstellung der Aufnahmeanfrage werden 50 Frames mit 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_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

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 Ränder wie die Bilder für Szene 1, 2 oder 4, sondern nur das Diagramm. Das Diagramm muss richtig ausgerichtet sein, damit die Diagrammsuche optimal funktioniert.

test_edge_enhancement

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

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

Getestete APIs:

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 Funktion zum Überschreiben des Querformats in ein Hochformat für horizontal ausgerichtete Sensoren ordnungsgemäß 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 von 3A ermittelte optimale Fokusdistanz und die letzten 12 Frames auf die minimale Fokusdistanz eingestellt sind. Etwa bei Frame 12 bewegt sich das Objektiv, wodurch die Schärfe nachlässt. Die Schärfe stabilisiert sich schließlich, wenn sich das Objektiv in die endgültige Position bewegt. 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 die Taste check_alignment.py verwenden, um die Ausrichtung des DUT und des Diagramms zu prüfen.

scene4

scene4

test_30_60fps_preview_fov_match

Prüft, ob die Vorschauvideos mit 30 fps und 60 fps dasselbe Sichtfeld haben. Im Test werden zwei Videos aufgenommen, eines mit 30 fps und eines mit 60 fps. Aus jedem Video wird ein repräsentativer Frame ausgewählt und analysiert, um 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 unterscheidet sich nicht um mehr als 3 % und die maximale Seitenverhältnisänderung zwischen Videos mit 30 fps und 60 fps beträgt nicht mehr als 7,5 %.

Fehlermechanismen:

  • Der Kreis im Video mit 30 fps ist deutlich kleiner als 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 projizierten Bildern wie erwartet, verglichen mit 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. Beispiel: Testen eines Weitwinkel- und eines Ultraweitwinkel-Kamerasystems mit dem RFoV-Testgestell. 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 unterschiedlichen 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 maximal mögliche 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 überprüft, ob sich das Seitenverhältnis des Kreises nicht ändert, der Kreis in den zugeschnittenen Bildern in der Mitte bleibt und die Kreisgröße sich bei einem konstanten Format oder bei einer anderen Auflösung nicht ändert (Fokusbereichsprü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 bewertet.

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 kleinen Kreisen mit einem Quadrat in einer Ecke, das die Ausrichtung angibt. Die kleinen Kreise sind erforderlich, um die Zoomfunktion über einen großen Bereich zu testen. 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-Abweichung (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 getestet. Es werden Aufnahmen im gesamten Zoombereich gemacht und geprüft, ob die Kreise beim Heranzoomen der Kamera größer werden. Für jedes Format (YUV, JPEG) wird dieselbe Kameraaufnahmesitzung verwendet, um 3A zu konvergieren und Aufnahmen zu machen.

Getestete APIs:

Pass:Die relative Größe des aufgenommenen Kreises stimmt mit dem angeforderten Zoomverhältnis überein, damit die Kamera richtig heranzoomt.

test_zoom

„test_zoom“, um die Kontur des Kreises zu finden, der der Mitte am nächsten ist.

test_low_latency_zoom

Hier wird das Zoomverhalten der Kamera mit niedriger Latenz getestet. Erfasst mit android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) Aufnahmen im gesamten Zoombereich und prüft, ob die Kreise 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:

Pass:Die relative Größe des erfassten Kreises 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. Hier wird die Größe des Kreises berechnet, der dem Zentrum am nächsten ist, bei verschiedenen Zoomfaktoren. Außerdem wird geprüft, ob die Größe des Kreises mit steigendem Zoomfaktor zunimmt.

Getestete APIs:

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

VGA_640x480_key_frame.png

VGA_640x480_key_frame.png (vor dem Zoomen)

preview_640x480_key_frame.png

preview_640x480_key_frame.png (vor dem Zoomen)

VGA_640x480_key_frame_zoomed.png

VGA_640x480_key_frame.png (nach dem Zoomen)

preview_640x480_key_frame_zoomed.png

preview_640x480_key_frame.png (nach dem Heranzoomen)

test_preview_zoom

Prüft, ob das Zoomverhältnis jedes Vorschauframes mit den entsprechenden Aufnahmemetadaten übereinstimmt. Beim Test werden Vorschauframes über den Zoombereich aufgenommen und die Kontur des Kreises ermittelt, der sich am nächsten am Mittelpunkt befindet. Im Test wird dann geprüft, ob der ausgewählte Kreis größer wird und sich der Mittelpunkt des Kreises von der Mitte des Bildes entfernt, wenn die Kamera heranzoomt.

Getestete APIs:

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

test_zoom

test_preview_zoom-Bilder, in denen der ausgewählte Kreis am nächsten an der 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 Kamera-ITS-Abteilung zugelassenen Tablets.

Getestete APIs:

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

  • AE-Prüfung: Die Luminanzänderung zwischen den Bildern mit dem Ultraweitwinkel- und dem Weitwinkelobjektiv darf 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.

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 eines dunklen Bereichs heller 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.

Fehlermechanismen:

  • Für diesen Test ist eine 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

scene9

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

scene9

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 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 gedacht und müssen Camera ITS-in-a-Box verwenden, da sie eine genaue Kontrolle der Testumgebung erfordern. Außerdem muss jeglicher Lichtaustritt kontrolliert werden. Dazu müssen Sie möglicherweise den Testaufbau, das DUT und das Tablet mit einer Abdeckplane abdecken und Lichtlecks am 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 umgeben. Die Quadrate sind in einer Hilbert-Kurven-Orientierung angeordnet.

scene_low_light

scene_low_light

test_night_extension

Hier wird die Nachterweiterung getestet. 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.

Getestete APIs:

Bestanden:Der durchschnittliche Luminanzwert der ersten 6 Quadrate muss 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.

Getestete APIs:

Gültig:Der durchschnittliche Luminanzwert der ersten 6 Quadrate muss mindestens 70 betragen und der durchschnittliche Unterschied im Luminanzwert aufeinanderfolgender Quadrate bis zu den Quadraten 5 und 6 muss mindestens 17 betragen.

scene_flash

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

test_auto_flash

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

Getestete APIs:

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

test_flash_strength

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

Prüft, ob das Gerät die Kontrolle der Blitzstärke bei der Verwendung der Kamera im Modus SINGLE unterstützt und ob sich die Blitzstärke bei verschiedenen angeforderten Stärken ändert. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn der Modus der automatischen Belichtung beispielsweise ON oder OFF ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Bei ON_AUTO_FLASH hat sie dagegen keine Auswirkungen. Für den Test 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 für die automatische Belichtung ON_AUTO_FLASH 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:

Pass: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_preview_min_frame_rate

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

Getestete APIs:

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

test_torch_strength

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

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

Getestete APIs:

Karte/Ticket:

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

sensor_fusion

Für Sensorfusionstests ist eine bestimmte Bewegung des Smartphones vor einem Schachbrettmuster und ArUco-Markierungen erforderlich. Für optimale Ergebnisse muss das Testdiagramm flach montiert sein. Nicht flache Diagramme wirken sich auf die Drehungsberechnungen für viele der Tests aus. Das Diagramm muss die Rückseite des Sensorfusions-Gerätekartons ausfüllen und muss im Format 43 × 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 bestimmen.

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 sehen Sie Beispiele für Videos 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 an der Wandhalterung angebracht ist. Die Wahrscheinlichkeit, dass der Test bestanden wird, ist dann geringer. Die Anzahl der Zyklen im Diagramm hängt von der Schreibgeschwindigkeit für das 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 der Kamera und des Gyroskops 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. Dieser Fehler 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 Befestigung 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 sehen Sie Beispiele für Videos mit und ohne Stabilisierung.

  • Beispielvideo mit Stabilisierung

  • Beispielvideo ohne Stabilisierung

feature_combination

Bei den feature_combination-Tests wird überprüft, ob Funktionen richtig 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, Vorschaustabilisierung, Ziel-FPS-Bereich, 10-Bit-HDR-Video und Ultra-HDR getestet, die vom Kameragerät unterstützt werden. Dieser Test ist sehr speicherintensiv. Wir empfehlen daher einen Host mit mindestens 128 GB RAM.

Bei Android 15 und höher enthält die Konfigurationsdatei ein Feld log_feature_combo_support, dessen Standardwert False ist. Wenn das Feld log_feature_combo_support auf True festgelegt ist, werden alle Kombinationen der unterstützten Funktionen ausgeführt und die Ergebnisse in einer Proto-Datei protokolliert, ohne dass der Test fehlschlägt. Für Compliance-Tests muss das Feld log_feature_combo_support auf False gesetzt sein.

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.