Versionshinweise für die Android 12 Camera Image Test Suite

Im Android 12-Release sind einige Änderungen an der Kamera-ITS enthalten. Auf dieser Seite werden die Änderungen zusammengefasst, die in vier große Kategorien unterteilt werden:

Zu Python 3 umstellen

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

Der Hauptteststarter tools/run_all_tests.py ist der gleiche wie unter Android 11 oder niedriger und wurde auf Python 3 refaktoriert.

Alle einzelnen Tests werden neu strukturiert und verwenden die neue Testeinrichtungsklasse, die in tests/its_base_test.py definiert ist. Die meisten Testnamen und Funktionen bleiben gleich. In Android 12 werden jetzt alle einzelnen Tests geladen. Das Laden von Szenen für jeden Test erhöht zwar die Gesamttestzeit, ermöglicht aber die Fehlerbehebung für einzelne Tests.

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

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

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

Einführung des Mobly-Test-Frameworks

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

Camera ITS nutzt die Mobly-Testinfrastruktur, um eine bessere Kontrolle und Protokollierung der Tests zu ermöglichen. Mobly ist ein Python-basiertes Test-Framework, das Testfälle unterstützt, für die mehrere Geräte mit benutzerdefinierten Hardwarekonfigurationen erforderlich sind. Weitere Informationen zu Mobly finden Sie unter google/mobly.

config.yml-Dateien

Mit dem Mobly-Framework können Sie ein Testgerät und ein Diagrammtablet in der Klasse its_base_test einrichten. Eine config.yml-Datei (YAML) wird zum Erstellen eines Mobly-Testbeds verwendet. In dieser Konfigurationsdatei können mehrere Testbeds konfiguriert werden, z. B. ein Tablet und ein Sensorfusions-Testbed. Innerhalb des Controller-Abschnitts jedes testbed-Moduls können Sie device_ids angeben, um die entsprechenden Android-Geräte für den Test-Runner 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. Gängige Werte für Testparameter 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)

Tabletbasierte Tests

Bei tabletbasierten Tests muss das Keyword TABLET im Namen des Testbeds enthalten sein. Während der Initialisierung initialisiert der Mobly-Test-Runner TestParams und übergibt sie an die einzelnen Tests.

Das folgende Beispiel zeigt 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

Der Testbed kann mit tools/run_all_tests.py aufgerufen werden. Wenn keine Befehlszeilenwerte vorhanden sind, werden die Tests mit den Werten aus der config.yml-Datei ausgeführt. Außerdem können Sie die Werte der Konfigurationsdateien camera und scene in der Befehlszeile mit Befehlen wie Android 11 oder niedriger überschreiben.

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

Sensorfusionstests

Für Sensorfusionstests muss der Testbed-Name das Keyword SENSOR_FUSION enthalten. Das richtige Testsystem wird anhand der getesteten Szenen bestimmt. Android 12 unterstützt sowohl Arduino- als auch Canakit-Controller für die Sensorfusion.

Im Folgenden finden Sie eine Beispiel-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

So führen Sie Sensorfusionstests mit dem Sensorfusionstestgerät aus:

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

Mehrere Prüfplätze

In der Konfigurationsdatei können mehrere Testbeds enthalten sein. Die gängigste Kombination ist ein Tablet-Testfeld und ein Sensorfusions-Testfeld.

Das folgende Beispiel zeigt 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

Manuelle Tests

Manuelle Tests werden in Android 12 weiterhin unterstützt. Das testbed muss die Tests jedoch als solche mit dem Schlüsselwort MANUAL im Namen des Testbedürfnisses identifizieren. Außerdem darf testbed keine Tablet-ID enthalten.

Im Folgenden finden Sie eine Beispieldatei config.yml für manuelle Tests.

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

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

Szenen ohne Tablets testen

Sie können Szene 0 und 5 mit TEST_BED_TABLET_SCENES oder TEST_BED_MANUAL testen. Wenn die Tests jedoch mit TEST_BED_TABLET_SCENES durchgeführt werden, muss das Tablet angeschlossen und die Seriennummer des Tablets gültig sein, auch wenn das Tablet nicht verwendet wird, da die Seriennummer in der Testklasseneinrichtung dem Tablet zugewiesen wird.

Einzelne Tests ausführen

Einzelne Tests können nur zu Debugzwecken ausgeführt werden, da ihre Ergebnisse nicht an den CTS Verifier gesendet werden. Da die config.yml-Dateien für camera und scene nicht in der Befehlszeile überschrieben werden können, müssen diese Parameter in der config.yml-Datei für den jeweiligen 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. Beispiel:

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

Testartefakte

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

  • Im Verzeichnis /tmp des Testartefakts wurde CameraITS_ dem achtstelligen zufälligen String der Übersichtlichkeit vorangestellt.
  • Testausgabe und -fehler werden für jeden Test in test_log.DEBUG anstatt in test_name_stdout.txt und test_name_stderr.txt gespeichert.
  • Die DUT- und Tablet-Logcats von jedem einzelnen Test werden im Verzeichnis /tmp/CameraITS_######## gespeichert, was die Fehlerbehebung vereinfacht, da alle Informationen, die zur Behebung von 3A-Problemen erforderlich sind, protokolliert werden.

Änderungen testen

Unter Android 12 sind die Tablet-Szenen PNG-Dateien und keine PDF-Dateien. Durch die Verwendung von PNG-Dateien können die Szenen auf mehr Tablet-Modellen korrekt angezeigt werden.

scene0/test_jitter.py

Der test_jitter-Test wird unter Android 12 für physische versteckte Kameras ausgeführt.

scene1_1/test_black_white.py

Unter Android 12 hat test_black_white sowohl die Funktionalität von test_black_white als auch von test_channel_saturation.

In der folgenden Tabelle werden die beiden einzelnen Tests in Android 11 beschrieben.

Test name Erstes API-Level Behauptungen
scene1_1/test_black_white.py ALLE Kurze Belichtung, geringe Verstärkung: RGB-Werte etwa [0, 0, 0]
Lange Belichtung, hohe Verstärkung: RGB-Werte etwa [255, 255, 255]
scene1_1/test_channel_saturation.py 29 Die Toleranz bei Abweichungen von [255, 255, 255] wurde reduziert, um Farbstiche in weißen Bildern zu entfernen.

In der folgenden Tabelle wird der zusammengeführte Test „scene1_1/test_black_white.py“ in Android 12 beschrieben.

Test name Erstes API-Level Behauptungen
scene1_1/test_black_white.py ALLE Kurze Belichtung, niedrige RGB-Werte mit hoher Verstärkung (ca. [0, 0, 0])
Lange Belichtung, hohe RGB-Werte mit hoher Verstärkung (ca. [255, 255, 255]) und reduzierte Toleranz zwischen den Werten, um Farbton in weißen Bildern zu vermeiden.

Szene1_1/test_first_sameness_manual.py

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

scene1_2/test_tonemap_sequence.py

Der test_tonemap_sequence-Test wird NUR auf bestimmten 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 für LIMITED Kameras in Android 12 ausgeführt.

scene3/test_flip_mirror.py

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

szene4/test_seitenverhältnis_und_crop.py

Die Suche nach Gruppen in scene4/test_aspect_ratio_and_crop.py wurde in Android 12 neu strukturiert.

Bei früheren Android-Versionen wurde eine Methode verwendet, bei der eine untergeordnete Kontur (der Kreis) innerhalb der übergeordneten Kontur (das Quadrat) mithilfe von Filtern für Größe und Farbe gefunden wurde. Android 12 verwendet eine Methode, bei der alle Konturen ermittelt und dann nach den Elementen gefiltert werden, die am kreisförmigsten sind. Um unerwünschte Kreise auf dem Display herauszufiltern, ist ein Mindestkonturbereich erforderlich und die Kontur des Kreises muss schwarz sein.

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

Konzeptionelle Zeichnung von Konturen und Auswahlkriterien

Abbildung 1. Konzeptionelle Zeichnung von Konturen und Auswahlkriterien

Die Methode für Android 12 ist einfacher und behebt das Problem mit dem Zuschneiden des Begrenzungsrahmens auf einigen Display-Tablets. Alle Kreiskandidaten werden zu Debugging-Zwecken protokolliert.

In Android 12 wird der Zuschneidetest für FULL- und LEVEL3-Geräte ausgeführt. Bei Android 11 oder niedriger werden die Testaussagen für den Zuschnitt für FULL-Geräte übersprungen.

In der folgenden Tabelle sind die Behauptungen für test_aspect_ratio_and_crop.py aufgeführt, die einer bestimmten Geräteebene und der ersten API-Ebene entsprechen.

Geräteebene Erste API-Ebene Behauptungen
EINGESCHRÄNKT ALLE Seitenverhältnis
Bildwinkel für 4:3-, 16:9- und 2:1-Formate
VOLLSTÄNDIG Unter 31 Seitenverhältnis
Bildwinkel für 4:3-, 16:9- und 2:1-Formate
VOLLSTÄNDIG ≥ 31 Zuschneiden
Seitenverhältnis
Bildwinkel für 4:3-, 16:9- und 2:1-Formate
LEVEL3 ALLE Zuschneiden
Seitenverhältnis
Sichtfeld für die Formate 4:3, 16:9 und 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.

Python 2-Code für Android 11

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

Python 3-Code für Android 12

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?hl=de

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

In Versionen vor Android 12 wird das gesamte Bild verwendet, um die besten 240 Elemente zu finden. Diese werden dann in der Mitte 20% maskiert, um rollende Effekte zu vermeiden, wobei mindestens 30 Elemente erforderlich sind.

Wenn die mit dieser Methode gefundenen Merkmale nicht ausreichen, maskiert Android 12 den Feature-Erkennungsbereich zuerst in der Mitte 20% und beschränkt die maximale Anzahl von Features auf das Zweifache der Mindestfunktionsanforderung.

Die folgende Abbildung zeigt den Unterschied zwischen der Funktionserkennung von Android 11 und Android 12. Das Erhöhen des Grenzwerts der Mindestfunktionsanforderung führt zur Erkennung von Features mit schlechter Qualität und wirkt sich negativ auf die Messungen aus.

Unterschied bei der Feature-Erkennung zwischen Android 11 und Android 12 Sensorfusion

Abbildung 2: Unterschied bei der Funktionserkennung zwischen Android 11 und Android 12

Neue Tests

scene0/test_solid_color_test_pattern.py

Der neue 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 Test name Erste API-Ebene Beschreibung
0 test_solid_color_test_pattern 31 Bestätigt die Ausgabe von Volltonbildern und die Programmierbarkeit von Bildfarben.

Testmuster mit durchgehender Farbe müssen aktiviert sein, damit der Vertraulichkeitsmodus der Kamera unterstützt wird. Beim test_solid_color_test_pattern-Test wird die YUV-Bildausgabe mit durch das ausgewählte Muster definierte Farbe bestätigt und die Bildfarbe ändert sich gemäß der Spezifikation.

Parameter

  • cameraPrivacyModeSupport: Gibt an, ob die Kamera den Datenschutzmodus unterstützt.
  • android.sensor.testPatternMode: Legt den Modus für das Testmuster fest. Für diesen Test wird SOLID_COLOR verwendet.
  • android.sensor.testPatternData: Legt die Testmusterwerte für R, Gr, Gb und G für den Testmustermodus fest.

Eine Beschreibung des Testmusters mit durchgehender Farbe finden Sie unter SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Method

YUV-Frames werden für die festgelegten Parameter erfasst und der Bildinhalt wird 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 einzelner YUV-Frame erfasst. Wenn PER_FRAME_CONTROL nicht unterstützt wird, werden vier Frames erfasst, wobei nur der letzte Frame analysiert wird, um die Testabdeckung bei LIMITED-Kameras zu maximieren.

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

Farbe testPatternData (RGGB)
SCHWARZ (0, 0, 0, 0)
WEIẞ (1, 1, 1, 1)
Richtlinie 2014/53/EU (1, 0, 0, 0)
GRÜN (0, 1, 1, 0)
BLAU (0, 0, 0, 1)

Tabelle mit Behauptungen

In der folgenden Tabelle werden die Testaussagen für test_solid_color_test_pattern.py beschrieben.

Kamera
Erste API-Ebene		 Kameratyp Angewendete Farben
31 Bayer SCHWARZ, WEISS, ROT, GRÜN, BLAU
31 Mono SCHWARZ, WEISS
Unter 31 Bayer/MONO SCHWARZ

Leistungstests für Klassen

scene2_c/test_camera_launch_perf_class.py

Prüft, ob das Starten der Kamera sowohl für die primäre Front- als auch Rückkamera weniger als 500 ms dauert, wenn sich die Szene „scene2_c“ (Gesicht) auf dem Display befindet.

Szene2_c/test_jpeg_capture_perf_class.py

Prüft, ob die Latenz bei der Aufnahme von 1080p-JPEG-Bildern sowohl mit der primären Front- als auch der primären Rückkamera unter 1 Sekunde liegt. Dabei wird die Szene „scene2_c“ verwendet.