ITS-Tests der Kamera

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 die Bildqualität nicht gemessen wird, aber 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.

ITS-Gatter-Tests der Kamera richten sich nach den erforderlichen Kameraeigenschaften, dem API-Level und der MPC-Ebene (Media Performance Class). 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 das Testen des Gyroskops und der Vibration muss das Smartphone jedoch unbeweglich sein.

test_jitter

Misst das Jitter bei Kamerazeitstempeln.

Getestete APIs:

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

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. Für diesen Test werden die Belichtungs- und Verstärkungswerte von 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 bei eingeschaltetem Bildschirm, d. h., das Gerät befindet sich nicht im Stand-by-Modus.

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_Testmuster

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 Richtigkeitsprüfung für einfarbiges Testmuster und -farbbalken durch.

Getestete APIs:

Pass:Unterstützte Testmuster werden korrekt generiert.

test_test_muster_2

test_test_patterns_2.jpg

test_tonemap_curve

Testet die Umwandlung des Testmusters von RAW in YUV mit einer linearen Tonemap. 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 Bild- und Bewegungssensorereignisse im selben Zeitbereich liegen.

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:

Erfolgreich:Das Gerät vibriert nicht, wenn es durch die Camera Audio Einschränkungs API stummgeschaltet wird.

scene1

Scene1 ist ein graues Diagramm. Das graue Diagramm 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. Die Erfassungsanfrage gibt jedoch die gesamte Szene an, die genügend Merkmale enthält, damit 3A konvergieren kann.

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 Camera ITS-in-a-box.

scene1

Szene1: Diagramm in Originalgröße (links). 2⁄3 skaliertes Diagramm (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

Testet, ob das Gerät vollständige Schwarz-Weiß-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:

Ticket:Erzeugt 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

Überprüft, ob die gesamte Erfassungspipeline mit der Geschwindigkeit der Fullsize-Aufnahme 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 5 Stichlichtaufnahmen mit 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_burs_sameness_manual_mean.jpg

test_burst_gleichheit_manueller_plot_means

test_burst_sameness_manual_plot_means.png

test_capture_result

Prüft, ob gültige Daten in CaptureResult-Objekten zurückgegeben werden. Es gibt automatische, manuelle und automatische Aufnahmen.

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 Flecken aus fünf verschiedenen Bereichen (Ecken und Mitte) werden erstellt. Es werden Bilder mit einem Zuschnitt für die 5 Regionen aufgenommen. Vergleicht die Werte für Patch und Bild zum Zuschneiden.

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:

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

test_dng_noise_model_plog

test_dng_noise_model_plog.png

test_ev_compensation_advanced

Prüft, ob die Belichtungskorrektur angewendet wird. Der Test erhöht die Belichtung in acht Schritten und vergleicht die gemessene Helligkeit mit der erwarteten Helligkeit. 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 Messwerte nicht übereinstimmen oder Bilder innerhalb von fünf Schritten überbelichtet werden.

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 einer höheren Einstellung der Belichtungskorrektur erhöht. Die acht Frames, die für jede Belichtungskorrektureinstellung 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. Nimmt eine Reihe von Aufnahmen auf, bei denen ISO und Belichtungszeit ausgewählt sind, um ein ausgewogenes Verhältnis zu erreichen. 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, sind aber bei höherem ISO-Wert rauschiger. RGB-Ebenen sind flach, wenn der Wert von ISO*Belichtung im gesamten getesteten Verstärkungsbereich konstant ist.

Fail-Mechanismus:

  • 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-Differenz 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:

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

Testlinearität

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:

Erfolgreich:Aufnahmen sehen einheitlich aus.

test_locked_burst_frame0

test_locked_burst_frame0.jpg

test_locked_burst_frame1

test_locked_burs_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 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. Tone Mapping ist ein Verfahren, das in der Bildverarbeitung verwendet wird, um einen Satz von Farben einer anderen Gruppe zuzuordnen, um die Darstellung von Bildern aus hohem Dynamikumfang in einem Medium mit eingeschränktem dynamischen Bereich 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:Der mittlere Bereich 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. Es wird eine hohe analoge Verstärkung verwendet, um sicherzustellen, dass das aufgenommene Bild verrauscht ist. Es werden drei Bilder aufgenommen: „Rauschminderung aus“, „Schnell“ und „Hohe Qualität“. Erfasst außerdem ein Bild mit niedriger Verstärkung und niedriger NR-Rate und verwendet die Varianz davon als Referenz. Je höher der SNR-Wert (Signal-Rausch-Verhältnis), desto besser ist 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 (Testparameter-Shading-Modus)

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

Getestete APIs:

Überspringen: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 (Testparameter-Shading-Modus_ls_Kartenmodus_1_Schleife_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 (Testparameter-Tonzuordnungsmodus)

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: Gleiche Tonkarte, aber unterschiedliche Länge. Die Bilder sind identisch.
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. Erfasst eine Reihe von RAW- und YUV-Bildern mit unterschiedlicher Empfindlichkeit, sendet die Kombination zur Steigerung der RAW-Empfindlichkeit und prüft, ob der Mittelwert des Ausgabepixels 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:Bei jeder Aufnahme ist mehr Rauschen zu sehen, da der Gewinn erhöht wird.

Die Varianz der Rasterzelle mit den Mittelungsstatistiken wird verwendet.

test_roh_burst_sensitivity_varianz

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:

Durchlassen: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_Rohempfindlichkeit

Es werden eine Reihe von Rohbildern mit steigender Empfindlichkeit aufgenommen und der Rauschenpegel (die Abweichung) in den mittleren 10% des Bildes gemessen. Testet, dass jede Aufnahme rauschender ist als die vorherige.

Getestete APIs:

Pass:Die Varianz steigt mit jedem Schuss.

test_roh_empfindlichkeit_varianz

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. Es wird eine hohe analoge Verstärkung verwendet, um sicherzustellen, dass das Aufnahmebild Rauschrauschen hat. Es werden drei neu verarbeitete Bilder aufgenommen: „Rauschminderung 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:

Erfolgreich: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 Framepaar.

Getestete APIs:

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

test_tonemap_sequenz_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_sequenz_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. Verwendet eine manuelle Anfrage mit einer linearen Tonemap, sodass die YUV- und JPEG-Dateien bei der Konvertierung durch das Modul image_processing_utils 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 eine maximale RMS-Differenz (Quadratwurzel aus dem Mittelquadratwert eines Signals) in RGB-konvertierten Bildern mit 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 RGB-Werte von konvertierten Bildern mit 10% mittleren RGB-Werten. Protokolleandroid.shading.mode

Getestete APIs:

Erfolgreich:YUV- und Rohbilder sind ähnlich und haben eine RMS-Unterschiede von unter 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 die richtige Ausrichtung haben, damit die Gesichtserkennung optimal funktioniert.

scene2_a

scene2_a

test_autoframing

Testet das Verhalten des Kamerageräts für den automatischen Bildausschnitt. 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 die aufgenommene JPEG-Datei ein geeignetes ICC-Profil im Header hat und ob das Bild Farben außerhalb des sRGB-Gamuts 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:

Erfolgreich:Das Szenenbild wird mit den Effekten OFF und einem monochromen Bild mit Effekten auf 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.

Testnummer_Gesichter

Testet die Gesichtserkennung.

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

Szene2_b

test_num_faces

Testet die Gesichtswiedererkennung mit erhöhter Vielfalt der Hauttöne 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 im größten gängigen YUV- und JPEG-Format mit demselben Seitenverhältnis wie das größte JPEG-Format mit einer Auflösung von maximal 1920 × 1440 aufgenommen. Legt jpeg.quality auf 100 fest und erfasst eine Anfrage für eine Doppelfläche. Wandelt beide Bilder in RGB-Arrays um und berechnet die 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

Testet die Gesichtswiedererkennung mit erhöhter Vielfalt der Hauttöne 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: MÜSSEN eine JPEG-Aufnahmelatenz von „cam2“ unter 1.000 ms für eine Auflösung von 1080p gemäß Messung bei einem Leistungstest der CTS-Kamera unter ITS-Beleuchtungsbedingungen (3.000 K) für beide primären Kameras haben.

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 des CDD angegeben.

Erfolgreich:Für ein Gerät der Leistungsklasse 15 MUSS die Standardaufnahme des Kamerapakets Ultra HDR sein.

scene2_d

test_num_faces

Testet die Gesichtswiedererkennung mit erhöhter Vielfalt der Hauttöne in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden drei Gesichter gefunden.

scene2_e

test_continuous_picture

Mit der Einstellung „Erste Aufnahmeanfrage zuerst“ 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

Testet die Gesichtswiedererkennung mit erhöhter Vielfalt der Hauttöne in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden drei Gesichter gefunden.

Szene2_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

Testet die Gesichtswiedererkennung mit erhöhter Vielfalt der Hauttöne in Gesichtsszenen.

Getestete APIs:

Erfolgreich:Es werden drei Gesichter gefunden.

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

scene3

Scene3 verwendet das ISO12233-Diagramm und die meisten Tests verwenden eine Diagrammextraktormethode, 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

Testet, 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 bestimmten 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 umgedreht, gespiegelt 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:

Erfolgreich:

  • 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_vektor_drift.png

Test_Querformat_nach_Hochformat

Prüft, ob die Funktion zum Überschreiben des Querformats in ein Hochformat bei Querformatsensoren 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 Bilder auf die von 3A ermittelte optimale Fokusdistanz und die letzten 12 Bilder auf die minimale Fokusdistanz fokussiert werden. 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 angegeben werden, in denen die Schärfe in den ersten Frames mit der Schärfe in den ersten paar Frames unverändert ist, wobei die Linse in der optimalen Brennweite steht und in den letzten Frames, in denen das Objektiv in 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 bestätigt, 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 – Test

Prüft, ob unterstützte Methoden zur Nachbearbeitung für die Kantenschärfung ordnungsgemäß funktionieren. Verarbeitet eine Erfassungsanfrage mit einem bestimmten Edge-Neuverarbeitungsmodus und vergleicht verschiedene Erfassungsmodi mit deaktivierten Edge-Neuverarbeitungsmodi.

Getestete APIs:

Pass: Die Schärfe der verschiedenen Kantenmodi ist korrekt. HQ (Modus 2) ist kleiner als OFF (Modus 0) und die Verbesserung zwischen 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. Die Tests in Scene4 können anfällig für die Ausrichtung sein. Daher können Sie ab 15 mit check_alignment.py im Tools-Verzeichnis eine Prüfung der DUT und der Diagrammausrichtung ermöglichen.

scene4

scene4

test_30_60fps_preview_fov_match

Prüft, ob Vorschauvideos mit 30 fps und 60 fps dasselbe Sichtfeld haben. Beim Test werden zwei Videos aufgenommen, eines mit 30 fps und eines mit 60 fps. Aus jedem Video wird ein repräsentativer Frame ausgewählt und analysiert, um sicherzustellen, dass die Änderungen des FoV 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 Spiegelung 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 Bilder 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 auf den Kreis ausgerichtet, der auf dem Tablet in der Mitte der aufgenommenen Szene angezeigt wird.
  • Der Kreis im aufgenommenen Bild wird durch die Verarbeitungspipeline verzerrt.
  • Das Bild mit niedrigerer Auflösung wird in der Bildpipeline doppelt zugeschnitten, wodurch sich das Sichtfeld zwischen Bildern mit hoher und niedriger Auflösung unterscheidet.
  • Der Kreis im aufgenommenen Bild 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 in der Mitte eine Spiegelung und ist nicht vollständig ausgefüllt.

test_multi_kamera_ausrichtung

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. Beispiel: Testen eines Weitwinkel- und eines Ultraweitwinkel-Kamerasystems mit dem RFoV-Testgestell. Weitere Informationen finden Sie unter FAQs zu ITS-in-a-box-Kamerafunktionen1.

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:

Erfolgreich:Bilder werden nicht gestreckt, die Bildmitte 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 erfasst, eines mit der Stabilisierungsstabilisierung für die Vorschau ON und eines mit der Stabilisierung für die Vorschau 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_verhältnis_und_zuschnitt

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

Getestete APIs:

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

scene5

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 bringen Sie einen Diffusor vor der Kamera an und richten Sie die Kamera auf eine Lichtquelle mit etwa 2.000 Lux. Für Sce55 aufgenommene Bilder erfordern ein diffuses Licht ohne erkennbare Merkmale. Hier sehen Sie ein Beispielbild:

scene5

Bildaufnahme 5

test_objektiv_schatten_und_farbe_einheitlich

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. Misst den durchschnittlichen y-Wert für jeden angegebenen Stichprobenblock und ermittelt durch einen Vergleich mit dem mittleren y-Wert, ob die Prüfung bestanden wurde oder nicht. Der Test für die Farbuniformität wird im r/g- und b/g-Farbraum bewertet.

Getestete APIs:

Erfolgreich:Im angegebenen Radius des Bildes darf die Abweichung der Werte R/G und B/G nicht mehr als 20% betragen, damit der Test bestanden wird.

scene6

Szene 6 ist ein Raster kleiner Kreise mit einem Quadrat in einer Ecke, das die Ausrichtung angibt. Die kleinen Kreise werden benötigt, um die Zoomfunktion in einem großen Bereich zu testen. Die Tests in Scene6 können anfällig für die Ausrichtung sein. Daher können Sie ab 15 im Tools-Verzeichnis check_alignment.py verwenden, um die DUT- und Diagrammausrichtung zu prüfen.

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 gesetzt ist, werden für den Test zwei Aufnahmen über den Zoombereich, ein RAW-Bild des gesamten Sichtfelds (FoV) und ein zugeschnittenes RAW-Bild vorgenommen. 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 Kamerazoomverhalten getestet. Es werden Aufnahmen im gesamten Zoombereich gemacht und geprüft, ob sich die Kreise beim Heranzoomen der Kamera vergrößern. Für jedes Format (YUV, JPEG) wird dieselbe Kameraaufnahmesitzung verwendet, um 3A zu konvergieren und Aufnahmen zu machen.

Getestete APIs:

Richtig:Die relative Größe des erfassten Kreises entspricht genau dem angeforderten Zoomverhältnis, damit die Kamera korrekt zoomt.

test_zoom

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

test_low_latency_zoom

Testet das Zoomverhalten der Kamera mit niedriger Latenz. 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 Zoomen)

test_preview_zoom

Prüft, ob das Zoomverhältnis jedes Vorschauframes mit den entsprechenden Aufnahmemetadaten übereinstimmt. Für den Test werden Vorschauframes über den Zoombereich übernommen und die Kontur des Kreises ermittelt, der dem Mittelpunkt am nächsten ist. Der Test prüft dann, ob der ausgewählte Kreis größer wird und ob sich der Mittelpunkt des Kreises vom Bildmittelpunkt wegbewegt, 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

Testet den Zoomverhältnisbereich für alle unterstützten Sitzungskonfigurationen, 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 abgeschrägtes Kantendiagramm zur Schärfeprüfung. Vier ArUco-Markierungen sind an den vier äußeren Ecken des Rechtecks ausgerichtet. So lassen sich genaue Koordinaten des Hauptrechtecks bei verschiedenen Zoomverhältnissen ermitteln.

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 Ultraweitwinkelobjektiv (UW) und dem Weitwinkelobjektiv (W) zu ähnlichen RGB-Werten führt.

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

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

Bei der AE-Prüfung wird sichergestellt, dass die Änderung der Lichtquelle sowohl für UW- als auch für W-Objektivaufnahmen 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.

Getestete APIs:

Bestanden:Damit der Test bestanden wird, müssen die AE-, AWB- und AF-Prüfungen bestanden werden. Für jede Prüfung müssen folgende Kriterien erfüllt sein:

  • AE-Prüfung: Die Leuchtdichteänderung zwischen den Bildern mit dem Weitwinkel- und dem Ultraweitwinkelobjektiv darf weniger als 0,5 % betragen.
  • AWB-Prüfung: Der Unterschied zwischen den R/G- und B/G-Werten für die Bilder mit Weitwinkel- und Ultraweitwinkelobjektiv darf nicht mehr als 0,5 % betragen.
  • AF-Prüfung: Die Änderung der Bildschärfe zwischen den Bildern mit dem UW- und dem W-Objektiv muss kleiner als 2 % sein.

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.

Szene 8

scene8

test_ae_awb_regions

Hier wird getestet, 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 Frame, der den Bereich mit geringerer Belichtung misst, einen höheren Luma-Wert von mehr als 1% hat als der Frame, der den Bereich mit erhöhter Belichtung misst. 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.

Szene 9

Scene9 besteht aus Tausenden von zufällig großen und farbigen Kreisen, um eine Szene mit sehr geringer Wiederholbarkeit zu erstellen, um die 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 dargestellte Szene das Sichtfeld der Kamera ausfüllt.

Getestete APIs:

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

JPEG-Qualität testen

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

Testet, ob die angeforderte Framerate für die Vorschau mit 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.

szenenerweiterungen

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 Frontdisplay des DUT beseitigen.

scene_hdr

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

Szene_HD

Szene_HD

test_hdr_extension

Hier wird die HDR-Erweiterung getestet. Nimmt mit und ohne aktivierte Erweiterung Aufnahmen auf und prüft, ob die Erweiterung den QR-Code besser erkennbar macht.

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 Szene scene_low_light besteht aus einem Raster von Quadraten verschiedener Grautöne vor einem schwarzen Hintergrund und das Quadratraster ist durch einen roten Umriss begrenzt. Die Quadrate sind in einer Hilbert-Kurvenausrichtung angeordnet.

scene_low_light

scene_low_light

test_night_verlängerung

Hier wird die Nachterweiterung getestet. Er führt Aufnahmen mit aktivierter Erweiterung aus und führt Folgendes aus:

  • Erkennt 20 Quadrate
  • Berechnet die Luminanz, die von jedem Quadrat begrenzt ist.
  • Berechnet den durchschnittlichen Luminanzwert der ersten 6 Quadrate gemäß der Orientierung des Hilbert-Kurven-Rasters.
  • Berechnet die Differenz in Luma-Werten von aufeinanderfolgenden Quadraten (z. B. Quadrat2 – Quadrat1) bis zu den Quadraten 5 und 6 (Quadrat6 – Quadrat5) 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

Testet den AE-Modus für wenig Lichtverstärker. 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 für den AE-Modus die Optimierung bei wenig Licht verwendet, ein Frame aus der Vorschau wird verwendet und es werden folgende Schritte 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 in Luma-Werten von aufeinanderfolgenden Quadraten (z. B. Quadrat2 – Quadrat1) bis zu den Quadraten 5 und 6 (Quadrat6 – Quadrat5) 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 ein dunkler Bereich in der Sensorfusionsbox erforderlich.

test_auto_flash

Es wird geprüft, 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. Um den automatischen Blitz auszulösen, müssen die Lichter im Test-Rig ausgeschaltet werden. Die Lichter können automatisch mit dem Arduino-Controller ausgeschaltet werden. 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. Bei Kameras auf der Rückseite muss der automatische Blitz aktiviert werden. Bei Frontkameras hingegen wird der automatische Blitz nicht ausgelöst, sondern nur der AE-Status.

Getestete APIs:

Erfolgreich:Die Mitte des Kachelbilds mit aktiviertem automatischem Blitz ist bei allen Kameras heller als das Originalszenenbild.

test_flash_strength

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

Prüft, ob sich die Blitzstärke bei der Verwendung der Kamera im Modus SINGLE ändert, wenn das Gerät die Blitzstärkeregelung unterstützt. Prüft, ob die Steuerung der Blitzstärke mit verschiedenen AE_MODES funktioniert. Wenn für die automatische Belichtung beispielsweise ON oder OFF festgelegt ist, wirkt sich die Blitzstärke auf die Helligkeit aus. Ist der Modus ON_AUTO_FLASH, hat die Blitzstärke keine Auswirkung auf die Helligkeit. 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 auf ON oder OFF eingestellt ist, erhöht sich die Helligkeit der Bildfelder mit der Stärke des Blitzlichts von „Kein Blitz“ auf FLASH_SINGLE_STRENGTH_MAX_LEVEL. 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 Lichter auf OFF eingestellt sind, wird mit dem Test eine Aufnahme mit dem Modus AUTO_FLASH aufgenommen, der auf ON eingestellt ist. Während dieser Erfassung wird im Test eine Vorerfassungssequenz ausgeführt, bei der der aePrecapture-Trigger auf START gesetzt ist. Außerdem wird der Erfassungs-Intent auf Preview gesetzt, um die Aufnahme mit Blitz aufzunehmen.

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 einen angemessenen Weißabgleich aufweist, berechnet der Test die R/G- und B/G-Verhältnisse und prüft, ob die Verhältnisse zwischen 0,95 und 1,05 liegen.

Getestete APIs:

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

Testet, ob die Framerate der Vorschau in einer dunklen Szene korrekt abnimmt. 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 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. Überprüft, ob die Taschenlampenstärke während der gesamten Dauer einer Burst-Funktion gleich bleibt, und simuliert so eine Videoaufnahmesitzung. 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 auf ON_AUTO_FLASH gesetzt ist, liegt der Unterschied in der Helligkeit der Bild-Burst-Patches innerhalb eines Toleranzbereichs, da die Blitzstärke von „Kein Blitz“ auf FLASH_TORCH_STRENGTH_MAX_LEVEL ansteigt.

Sensorfusion

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.

Sensorfusionsdiagramm

Diagramm für die Sensorfusion

Sensorfusionsdiagramm im Rig

Sensor Fusion-Diagramm, das die Rückseite der Sensor Fusion Box füllt

test_lens_intrinsic_calibration

Testet, ob sich der optische Mittelpunkt der Linse ändert, wenn sich die Linse 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_objektiv_kalibrierung_beispiel.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 Millisekunden 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

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

test_preview_distortion_example.jpg

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

Getestete APIs:

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

test_preview_stabilization

Tests, bei denen das Vorschauvideo stabilisiert wurde, drehen sich weniger als das Gyroskop.

Getestete APIs:

Pass:Die maximale Drehung des Winkels ü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

Testet den Zeitstempelunterschied zwischen Kamera und Gyroskop für AR- und VR-Anwendungen. 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. Eine Bewegung in x- und y-Richtung deutet darauf hin, dass das Smartphone nicht sicher auf der Wandhalterung montiert ist. Dadurch sinkt die Wahrscheinlichkeit, dass der Test bestanden wird. 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 der Gyroskop- und Kamera-Ereignisse 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:

  • Offsetfehler: Der Offset des Kamera-Gyroskops ist nicht korrekt auf +/-1 ms kalibriert.
  • Frame Drops: Die Pipeline ist nicht schnell genug, um 200 Frames nacheinander zu erfassen.
  • Socket-Fehler: adb kann keine zuverlässige Verbindung zum DUT lange genug 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, bei denen Videos bei stabilisierten Videos weniger gedreht werden als mit Gyroskopen.

Getestete APIs:

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

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 ordnungsgemäß funktionieren, wenn mehrere Kamerafunktionen gleichzeitig aktiviert sind. Für diese Tests wird dasselbe Schachbrettbild wie in der Sensorfusionsszene verwendet.

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 das Feld log_feature_combo_support, das standardmäßig auf False festgelegt 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 Protodatei protokolliert, ohne dass der Test fehlschlägt. Für Compliance-Tests muss das Feld log_feature_combo_support auf False gesetzt sein.

Getestete APIs:

Erfolgreich:Für jede unterstützte Funktionskombination:

  • 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 entspricht der festgelegten Einstellung.
  • Für die Ultra HDR-Aufnahme ist eine gültige Verstärkungskarte vorhanden.