Versionshinweise zur Android 12 Camera Image Test Suite

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

Eine Reihe von Kamera-ITS- Änderungen sind in der Android 12-Version enthalten. Diese Seite fasst die Änderungen zusammen, die in vier große Kategorien fallen:

Refactoring auf Python 3

Aufgrund der Einstellung von Python 2.7 im Januar 2020 wurde die gesamte Kamera-ITS-Codebasis auf Python 3 umgestaltet. Die folgenden Python-Versionen und -Bibliotheken sind in Android 12 erforderlich:

Der Hauptteststarter, tools/run_all_tests.py , bleibt derselbe wie die Versionen Android 11 oder niedriger und wird auf Python 3 umgestaltet.

Alle einzelnen Tests werden umgestaltet und verwenden die neue Testaufbauklasse, die in tests/its_base_test.py definiert ist. Die meisten Testnamen und Funktionen bleiben gleich. In Android 12 laden nun alle Einzeltests ihre Szenen. Während das Laden von Szenen für jeden Test die Gesamttestzeit verlängert, ermöglicht es das Debuggen einzelner Tests.

Weitere Informationen zu einzelnen Teständerungen finden Sie unter Teständerungen .

Die folgenden Python-Module werden mit einer Namensänderung umgestaltet:

  • pymodules/its/caps.pyutils/camera_properties_utils.py
  • pymodules/its/cv2image.pyutils/opencv_processing_utils.py
  • pymodules/its/device.pyutils/its_session_utils.py
  • pymodules/its/error.pyutils/error_util.py
  • pymodules/its/image.pyutils/image_processing_utils.py
  • pymodules/its/objects.pyutils/capture_request_utils.py
  • pymodules/its/target.pyutils/target_exposure_utils.py
  • tools/hw.pyutils/sensor_fusion_utils.py

Übernahme des Mobly-Testframeworks

Mobly ist ein Python-basiertes Testframework, das Testfälle unterstützt, die mehrere Geräte mit benutzerdefinierten Hardware-Setups erfordern. Camera ITS nutzt die Testinfrastruktur von Mobly, um eine bessere Kontrolle und Protokollierung der Tests zu ermöglichen.

Camera ITS nutzt die Testinfrastruktur von Mobly, um eine bessere Kontrolle und Protokollierung der Tests zu ermöglichen. Mobly ist ein Python-basiertes Testframework, das Testfälle unterstützt, die mehrere Geräte mit benutzerdefinierten Hardware-Setups erfordern. Weitere Informationen zu Mobly finden Sie unter google/mobly .

config.yml-Dateien

Mit dem Mobly-Framework können Sie ein zu testendes Gerät (DUT) und ein Diagrammtablett in der Klasse its_base_test . Eine config.yml (YAML)-Datei wird verwendet, um ein Mobly-Testbed zu erstellen. In dieser Konfigurationsdatei können mehrere Testbeds konfiguriert werden, beispielsweise ein Tablet und ein Sensorfusionstestbed. Innerhalb des Controller-Abschnitts jedes Testbeds können Sie device_ids angeben, um die entsprechenden Android-Geräte für den Testläufer zu identifizieren. Zusätzlich zu den Geräte-IDs werden in der Testklasse weitere Parameter wie Tablet brightness , chart_distance , debug_mode , camera_id und scene_id übergeben. Übliche Testparameterwerte sind:

brightness: 192  (all tablets except Pixel C)
chart_distance: 31.0  (rev1/rev1a box for FoV < 90° cameras)
chart_distance: 22.0 (rev2 test rig for FoV > 90° cameras)

Tablet-basierte Tests

Für Tablet-basierte Tests muss das Schlüsselwort TABLET im Testbed-Namen vorhanden sein. Während der Initialisierung initialisiert der Mobly- TestParams und übergibt sie an die einzelnen Tests.

Das Folgende ist ein Beispiel für eine config.yml -Datei für Tablet-basierte Ausführungen.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

Das Testbed kann mit tools/run_all_tests.py aufgerufen werden. Wenn keine Befehlszeilenwerte vorhanden sind, werden die Tests mit den Werten der Datei config.yml . Darüber hinaus können Sie die Werte der camera und scene in der Befehlszeile mit Befehlen überschreiben, die denen von Android 11 oder niedriger ähneln.

Zum Beispiel:

python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=1 scenes=2,1,0

Sensorfusionstest

Für Sensorfusionstests muss der Testumgebungsname das Schlüsselwort SENSOR_FUSION . Das richtige Testbed wird durch die getesteten Szenen bestimmt. Android 12 unterstützt sowohl Arduino- als auch Canakit- Controller für die Sensorfusion .

Das Folgende ist ein Beispiel für eine config.yml -Datei für Sensorfusionsläufe.

Testbeds
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Um Sensorfusionstests mit dem Sensorfusionsprüfstand durchzuführen , verwenden Sie:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0

Mehrere Testumgebungen

In der Konfigurationsdatei können mehrere Testumgebungen enthalten sein. Die häufigste Kombination besteht darin, sowohl ein Tablet-Testbed als auch ein Sensor-Fusion-Testbed zu haben.

Das Folgende ist ein Beispiel für eine config.yml -Datei mit Tablet- und Sensor-Fusion-Testbeds.

Testbeds
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Manuelles Testen

Manuelles Testen wird in Android 12 weiterhin unterstützt. Allerdings muss das Testbed das Testen als solches mit dem Schlüsselwort MANUAL im Namen des Testbeds kennzeichnen. Darüber hinaus kann das Testbed keine Tablet-ID enthalten.

Das Folgende ist ein Beispiel für eine config.yml -Datei zum manuellen Testen.

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      chart_distance: 31.0
      camera: 0
      scene: scene1

Testen von Szenen ohne Tablets

Das Testen für Szene 0 und Szene 5 kann mit TEST_BED_TABLET_SCENES oder mit TEST_BED_MANUAL . Wenn der Test jedoch mit TEST_BED_TABLET_SCENES wird, muss das Tablet verbunden sein und die Seriennummer des Tablets muss gültig sein, auch wenn das Tablet nicht verwendet wird, da das Setup der Testklasse den Wert der Seriennummer für das Tablet zuweist.

Individuelle Tests durchführen

Einzelne Tests können nur zu Debug-Zwecken ausgeführt werden, da ihre Ergebnisse nicht an CTS Verifier gemeldet werden. Da die config.yml Dateien nicht auf der Kommandozeile für camera und scene überschrieben werden können, müssen diese Parameter in der config.yml -Datei für den betreffenden individuellen Test korrekt sein. Wenn die Konfigurationsdatei mehr als ein Testbed enthält, müssen Sie das Testbed außerdem mit dem Flag --test_bed angeben. Zum Beispiel:

python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES

Artefakte testen

In Android 12 werden Testartefakte für Kamera-ITS ähnlich wie in Android 11 oder niedriger gespeichert, jedoch mit den folgenden Änderungen:

  • Dem Testartefakt-Verzeichnis /tmp ist aus Gründen der Übersichtlichkeit CameraITS_ der 8-stelligen Zufallszeichenfolge vorangestellt.
  • Testausgaben und Fehler werden für jeden Test in test_log.DEBUG statt in test_name_stdout.txt und test_name_stderr.txt .
  • Die DUT- und Tablet-Logcats von jedem einzelnen Test werden im /tmp/CameraITS_######## gespeichert, wodurch das Debuggen vereinfacht wird, da alle zum Debuggen von 3A-Problemen erforderlichen Informationen protokolliert werden.

Änderungen testen

In Android 12 sind die Tablet-Szenen PNG-Dateien und keine PDF-Dateien. Durch die Verwendung von PNG-Dateien können mehr Tablet-Modelle die Szenen richtig anzeigen.

scene0/test_jitter.py

Der test_jitter -Test wird auf physischen versteckten Kameras in Android 12 ausgeführt.

scene1_1/test_black_white.py

Für Android 12 hat test_black_white die Funktionalität von sowohl test_black_white als test_channel_saturation .

Die folgende Tabelle beschreibt die beiden Einzeltests in Android 11.

Testname Erste API-Ebene Behauptungen
scene1_1/test_black_white.py ALLE Kurze Belichtung, RGB-Werte mit niedriger Verstärkung ~[0, 0, 0]
Langzeitbelichtung, RGB-Werte mit hoher Verstärkung ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Reduzierte Toleranz bei [255, 255, 255]-Unterschieden, um Farbstiche in weißen Bildern zu eliminieren.

Die folgende Tabelle beschreibt den zusammengeführten Test, scene1_1/test_black_white.py, in Android 12.

Testname Erste API-Ebene Behauptungen
scene1_1/test_black_white.py ALLE Kurze Belichtung, RGB-Werte mit niedriger Verstärkung ~[0, 0, 0]
Langzeitbelichtung, RGB-Werte mit hoher Verstärkung ~[255, 255, 255] und reduzierte Toleranz zwischen den Werten, um Farbstiche in weißen Bildern zu eliminieren.

scene1_1/test_burst_sameness_manual.py

Der Test test_burst_sameness_manual wird auf physischen versteckten Kameras in Android 12 ausgeführt.

scene1_2/test_tonemap_sequence.py

Der test_tonemap_sequence -Test wird auf BEGRENZTEN Kameras in Android 12 ausgeführt.

scene1_2/test_yuv_plus_raw.py

Der test_yuv_plus_raw -Test wird auf physischen versteckten Kameras in Android 12 ausgeführt.

scene2_a/test_format_combos.py

Der test_format_combos -Test wird auf LIMITED Kameras in Android 12 ausgeführt.

scene3/test_flip_mirror.py

Der test_flip_mirror -Test wird auf BEGRENZTEN Kameras in Android 12 ausgeführt.

scene4/test_aspect_ratio_and_crop.py

Das Finden von Kreisen in scene4/test_aspect_ratio_and_crop.py wurde in Android 12 umgestaltet.

Frühere Android-Versionen verwendeten eine Methode, bei der eine untergeordnete Kontur (der Kreis) innerhalb der übergeordneten Kontur (das Quadrat) mit Filtern für Größe und Farbe gefunden wurde. Android 12 verwendet eine Methode, bei der alle Konturen gefunden und dann gefiltert werden, indem Merkmale gefunden werden, die am kreisrundsten sind. Um störende Kreise auf der Anzeige auszublenden, ist ein minimaler Konturbereich erforderlich, und die Kontur des Kreises muss schwarz sein.

Die Konturen und ihre Auswahlkriterien sind in der folgenden Abbildung dargestellt.

Konzeptionelles Zeichnen von Konturen und Auswahlkriterien

Abbildung 1. Konzeptzeichnung von Konturen und Auswahlkriterien

Die Android 12-Methode ist einfacher und löst das Problem mit dem Beschneiden des Begrenzungsrahmens in einigen Display-Tablets. Alle Kreiskandidaten werden zu Debugging-Zwecken protokolliert.

In Android 12 wird der Crop-Test für FULL und LEVEL3 Geräte ausgeführt. Android 11 oder niedrigere Versionen überspringen die Crop-Test-Assertionen für FULL Geräte.

Die folgende Tabelle listet die Zusicherungen für test_aspect_ratio_and_crop.py auf, die einer bestimmten Geräteebene und ersten API-Ebene entsprechen.

Geräteebene Erste API-Ebene Behauptungen
BEGRENZT ALLE Seitenverhältnis
FoV für die Formate 4:3, 16:9, 2:1
VOLL < 31 Seitenverhältnis
FoV für die Formate 4:3, 16:9, 2:1
VOLL ≥ 31 Ernte
Seitenverhältnis
FoV für die Formate 4:3, 16:9, 2:1
STUFE 3 ALLE Ernte
Seitenverhältnis
FoV für die Formate 4:3, 16:9, 2:1

scene4/test_multi_camera_alignment.py

Die Methode undo_zoom() für YUV-Aufnahmen in scene4/test_multi_camera_alignment.py wurde überarbeitet, um das Zuschneiden auf Sensoren, die nicht dem Seitenverhältnis der Aufnahme entsprechen, genauer zu berücksichtigen.

Android 11 Python 2-Code

zoom_ratio = min(1.0 * yuv_w / cr_w, 1.0 * yuv_h / cr_h)
circle[i]['x'] = cr['left'] + circle[i]['x'] / zoom_ratio
circle[i]['y'] = cr['top'] + circle[i]['y'] / zoom_ratio
circle[i]['r'] = circle[i]['r'] / zoom_ratio

Android 12 Python 3-Code

yuv_aspect = yuv_w / yuv_h
relative_aspect = yuv_aspect / (cr_w/cr_h)
if relative_aspect > 1:
  zoom_ratio = yuv_w / cr_w
  yuv_x = 0
  yuv_y = (cr_h - cr_w / yuv_aspect) / 2
else:
  zoom_ratio = yuv_h / cr_h
  yuv_x = (cr_w - cr_h * yuv_aspect) / 2
  yuv_y = 0
circle['x'] = cr['left'] + yuv_x + circle['x'] / zoom_ratio
circle['y'] = cr['top'] + yuv_y + circle['y'] / zoom_ratio
circle['r'] = circle['r'] / zoom_ratio

sensor_fusion/test_sensor_fusion.py

In Android 12 wird für den Sensorfusionstest eine Methode zum Erkennen von Merkmalen in Bildern hinzugefügt.

In Versionen unter Android 12 wird das gesamte Bild verwendet, um die besten 240 Funktionen zu finden, die dann auf die mittleren 20 % maskiert werden, um Rolling-Shutter-Effekte zu vermeiden, wobei die Mindestfunktionsanforderung 30 Funktionen beträgt.

Wenn die von dieser Methode gefundenen Features nicht ausreichen, maskiert Android 12 den Feature-Erkennungsbereich zuerst auf 20 % in der Mitte und begrenzt die maximalen Features auf das Zweifache der minimalen Feature-Anforderung.

Das folgende Bild zeigt den Unterschied zwischen der Funktionserkennung von Android 11 und Android 12. Das Erhöhen des Schwellenwerts für die minimale Merkmalsanforderung führt zur Erkennung von Merkmalen schlechter Qualität und wirkt sich negativ auf Messungen aus.

Unterschied in der Funktionserkennung zwischen Android 11 und Android 12 sensor_fusion Funktionserkennung

Abbildung 2. Unterschied in der Funktionserkennung zwischen Android 11 und Android 12

Neue Prüfungen

scene0/test_solid_color_test_pattern.py

Ein neuer Test, test_solid_color_test_pattern , ist für Android 12 aktiviert. Dieser Test ist für alle Kameras aktiviert und wird in der folgenden Tabelle beschrieben.

Szene Testname Erste API-Ebene Beschreibung
0 test_solid_color_test_pattern 31 Bestätigt die Vollfarbbildausgabe und die Programmierbarkeit der Bildfarbe.

Einfarbige Testmuster müssen aktiviert werden, um den Datenschutzmodus der Kamera zu unterstützen. Der Test test_solid_color_test_pattern bestätigt die YUV-Bildausgabe in Volltonfarbe mit der durch das ausgewählte Muster definierten Farbe, und die Bildfarbe ändert sich gemäß der Spezifikation.

Parameter

  • cameraPrivacyModeSupport : Legt fest, ob die Kamera den Datenschutzmodus unterstützt.
  • android.sensor.testPatternMode : Legt den Testmustermodus fest. Dieser Test verwendet SOLID_COLOR .
  • android.sensor.testPatternData : Legt die R-, Gr-, Gb-, G-Testmusterwerte für den Testmustermodus fest.

Eine Beschreibung des einfarbigen Testmusters finden Sie unter SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .

Methode

YUV-Frames werden für die eingestellten Parameter erfasst und der Bildinhalt validiert. Das Testmuster wird direkt vom Bildsensor ausgegeben, sodass keine bestimmte Szene erforderlich ist. Wenn PER_FRAME_CONTROL unterstützt wird, wird für jede getestete Einstellung ein einzelnes YUV-Frame erfasst. Wenn PER_FRAME_CONTROL nicht unterstützt wird, werden vier Bilder erfasst, wobei nur das letzte Bild analysiert wird, um die Testabdeckung in LIMITED -Kameras zu maximieren.

YUV-Aufnahmen sind auf vollständig gesättigte BLACK , WHITE , RED , GREEN und BLUE -Testmuster eingestellt. Da die Testmusterdefinition dem Sensor-Bayer-Muster entspricht, müssen die Farbkanäle für jede Farbe wie in der folgenden Tabelle gezeigt eingestellt werden.

Farbe Testmusterdaten (RGGB)
SCHWARZ (0, 0, 0, 0)
WEISS (1, 1, 1, 1)
ROT (1, 0, 0, 0)
GRÜN (0, 1, 1, 0)
BLAU (0, 0, 0, 1)

Behauptungstabelle

Die folgende Tabelle beschreibt die Testzusicherungen für test_solid_color_test_pattern.py .

Kamera
Erste API-Ebene
Kameratyp Farben behauptet
31 Bayer SCHWARZ, WEISS, ROT, GRÜN, BLAU
31 MONO SCHWARZ-WEISS
< 31 Bayer/MONO SCHWARZ

Leistungsklassenprüfungen

scene2_c/test_camera_launch_perf_class.py

Überprüft, dass der Kamerastart sowohl für die vordere als auch für die hintere Primärkamera mit der Szene „scene2_c face“ weniger als 500 ms dauert.

scene2_c/test_jpeg_capture_perf_class.py

Verifiziert, dass die 1080p-JPEG-Erfassungslatenz weniger als 1 Sekunde für die vordere und hintere Primärkamera mit der Scene2_c-Gesichtsszene beträgt.