Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Versionshinweise für die Android 12 Camera Image Test Suite

In der Android 12-Version sind einige Änderungen an Camera ITS enthalten. Auf dieser Seite werden die Änderungen zusammengefasst, die in vier Kategorien fallen:

Refactoring zu Python 3
Einführung des Mobly-Test-Frameworks
Änderungen testen
Neue Tests

Zu Python 3 umgestalten

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

Der Haupt-Test-Launcher, tools/run_all_tests.py, ist derselbe wie bei Android 11 oder niedriger und wurde in Python 3 umgestaltet.

Alle einzelnen Tests wurden umgestaltet und verwenden die neue Testeinrichtungsklasse, die in tests/its_base_test.py definiert ist. Die meisten Testnamen und ‑funktionen bleiben gleich. In Android 12 laden alle einzelnen Tests jetzt ihre Szenen. Das Laden der Szene für jeden Test verlängert zwar die Gesamttestzeit, ermöglicht aber das Debuggen einzelner Tests.

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

Die folgenden Python-Module wurden umbenannt:

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

Mobly-Testframework

Mobly ist ein Python-basiertes Test-Framework, das Testläufe unterstützt, für die mehrere Geräte mit benutzerdefinierten Hardwarekonfigurationen erforderlich sind. Camera ITS verwendet die Mobly-Testinfrastruktur, um eine bessere Steuerung und Protokollierung der Tests zu ermöglichen.

Camera ITS verwendet die Mobly-Testinfrastruktur, um eine bessere Steuerung und Protokollierung der Tests zu ermöglichen. Mobly ist ein Python-basiertes Test-Framework, das Testläufe 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 zu testendes Gerät (DUT) und ein Chart-Tablet in der Klasse its_base_test einrichten. Eine config.yml-Datei (YAML) wird verwendet, um ein Mobly-Testbed zu erstellen. In dieser Konfigurationsdatei können mehrere Testumgebungen konfiguriert werden, z. B. eine Tablet- und eine Sensor-Fusion-Testumgebung. Im Controller-Abschnitt jedes Testbeds 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 auch andere Parameter wie Tablet-brightness, chart_distance, debug_mode, camera_id und scene_id übergeben. Häufige 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)

Tests auf Tablets

Für tabletbasierte 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.

Im Folgenden finden Sie eine Beispiel-config.yml-Datei für tabletbasierte Läufe.

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 Datei config.yml ausgeführt. Außerdem können Sie die Werte der Konfigurationsdateien camera und scene in der Befehlszeile mit Befehlen überschreiben, die denen von Android 11 oder niedriger ähneln.

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 Sensor-Fusionstests muss der Testumgebungsname das Keyword SENSOR_FUSION enthalten. Das richtige Testbed wird durch die getesteten Szenen bestimmt. Android 12 unterstützt sowohl Arduino- als auch Canakit-Controller für die Sensorfusion.

Im Folgenden finden Sie eine config.yml-Beispieldatei für Sensorfusion-Ausführungen.

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 Sensorfusion-Prüfstand aus:

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

Mehrere Testumgebungen

Die Konfigurationsdatei kann mehrere Testbeds enthalten. Die häufigste Kombination ist ein Tablet-Testgerät und ein Sensor-Fusion-Testgerät.

Im Folgenden finden Sie eine Beispiel-config.yml-Datei mit Testumgebungen für Tablets und Sensor-Fusion.

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. Im Namen des Testbeds muss jedoch das Keyword MANUAL enthalten sein, um es als Test zu kennzeichnen. Außerdem darf die Prüfumgebung keine Tablet-ID enthalten.

Im Folgenden finden Sie eine Beispiel-config.yml-Datei 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

Tests für Szene 0 und Szene 5 können mit TEST_BED_TABLET_SCENES oder mit TEST_BED_MANUAL durchgeführt werden. Wenn die Tests jedoch mit TEST_BED_TABLET_SCENES durchgeführt werden, muss das Tablet verbunden sein und die Serien-ID des Tablets muss gültig sein, auch wenn das Tablet nicht verwendet wird, da in der Einrichtung der Testklasse der Serien-ID-Wert für das Tablet zugewiesen wird.

Einzelne Tests ausführen

Einzelne Tests können nur zu Debugging-Zwecken ausgeführt werden, da ihre Ergebnisse nicht an CTS Verifier gemeldet 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 in der Konfigurationsdatei mehr als ein Testbed vorhanden ist, müssen Sie das Testbed 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

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

Dem Testartefaktverzeichnis /tmp wird zur besseren Übersichtlichkeit CameraITS_ vorangestellt.
Die 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 Logcats des DUT und des Tablets aus jedem einzelnen Test werden im Verzeichnis /tmp/CameraITS_######## gespeichert, was die Fehlersuche vereinfacht, da alle Informationen, die zur Behebung von 3A-Problemen erforderlich sind, 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 darstellen.

scene0/test_jitter.py

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

scene1_1/test_black_white.py

Unter Android 12 bietet test_black_white die Funktionen von test_black_white und 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, RGB-Werte mit geringer Verstärkung ~[0, 0, 0] Lange Belichtung, RGB-Werte mit hoher Verstärkung ~[255, 255, 255]
scene1_1/test_channel_saturation.py	29	Die Toleranz für Unterschiede bei [255, 255, 255] wurde reduziert, um Farbstiche in weißen Bildern zu vermeiden.

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, RGB-Werte mit geringer Verstärkung ~[0, 0, 0] Lange Belichtung, RGB-Werte mit hoher Verstärkung ~[255, 255, 255] und geringere Toleranz zwischen den Werten, um Farbstiche in weißen Bildern zu vermeiden.

scene1_1/test_burst_sameness_manual.py

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

scene1_2/test_tonemap_sequence.py

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

scene1_2/test_yuv_plus_raw.py

Der test_yuv_plus_raw-Test wird auf physischen, verborgenen 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 LIMITED-Kameras in Android 12 ausgeführt.

scene4/test_aspect_ratio_and_crop.py

Die Suche nach Kreisen in scene4/test_aspect_ratio_and_crop.py wurde in Android 12 überarbeitet.

In früheren Android-Versionen wurde eine Methode verwendet, bei der eine untergeordnete Kontur (der Kreis) innerhalb der übergeordneten Kontur (dem Quadrat) mit Filtern für Größe und Farbe gesucht wurde. Bei Android 12 werden alle Konturen ermittelt und dann nach Merkmalen gefiltert, die am kreisförmigsten sind. Um unerwünschte Kreise auf dem Display zu vermeiden, ist eine Mindestkonturfläche erforderlich und die Kontur des Kreises muss schwarz sein.

Die Konturen und ihre Auswahlkriterien sind im folgenden Bild dargestellt.

Konzeptionelle Zeichnung von Konturen und Auswahlkriterien

Abbildung 1: Konzeptionelle Zeichnung von Konturen und Auswahlkriterien

Die Android 12-Methode ist einfacher und behebt das Problem mit dem Beschneiden von Begrenzungsrahmen auf einigen Display-Tablets. Alle infrage kommenden Kreise werden zu Debugging-Zwecken protokolliert.

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

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

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

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-Code für Python 3

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 wurde für den Sensor-Fusion-Test eine Methode zum Erkennen von Merkmalen in Bildern hinzugefügt.

In Versionen unter Android 12 wird das gesamte Bild verwendet, um die 240 besten Merkmale zu finden. Diese werden dann auf die mittleren 20% maskiert, um Rolling-Shutter-Effekte zu vermeiden. Die Mindestanforderung liegt bei 30 Merkmalen.

Wenn die mit dieser Methode gefundenen Funktionen nicht ausreichen, wird der Bereich für die Funktionserkennung in Android 12 zuerst auf die mittleren 20% beschränkt und die maximale Anzahl der Funktionen auf das Doppelte der Mindestanforderung für Funktionen begrenzt.

Das folgende Bild zeigt den Unterschied zwischen der Funktionserkennung in Android 11 und Android 12. Wenn Sie den Mindestschwellenwert für die Funktion anheben, werden Funktionen von schlechter Qualität erkannt und die Messungen werden negativ beeinflusst.

Unterschiede bei der Feature-Erkennung zwischen Android 11 und Android 12
sensor_fusion-Feature-Erkennung

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

Neue Tests

scene0/test_solid_color_test_pattern.py

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

Szene	Test name	Erstes API-Level	Beschreibung
0	test_solid_color_test_pattern	31	Bestätigt die Ausgabe von Bildern mit Volltonfarben und die Programmierbarkeit von Bildfarben.

Testmuster mit einheitlicher Farbe müssen aktiviert sein, damit der Vertraulichkeitsmodus der Kamera unterstützt wird. Der test_solid_color_test_pattern-Test bestätigt die Ausgabe von YUV-Bildern in Volltonfarbe mit der durch das ausgewählte Muster definierten Farbe sowie Farbänderungen des Bildes gemäß Spezifikation.

Parameter

cameraPrivacyModeSupport: Gibt an, ob die Kamera den Datenschutzmodus unterstützt.
android.sensor.testPatternMode: Legt den Testbildmodus fest. In diesem Test wird SOLID_COLOR verwendet.
android.sensor.testPatternData: Legt die Testmusterwerte für R, Gr, Gb und G für den Testmuster-Modus fest.

Eine Beschreibung des Testbilds mit Volltonfarbe finden Sie unter SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.

Methode

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 aufgenommen und nur der letzte Frame analysiert, um die Testabdeckung bei LIMITED-Kameras zu maximieren.

YUV-Aufnahmen werden auf vollständig gesättigte BLACK-, WHITE-, RED-, GREEN- und BLUE-Testmuster eingestellt. Da die Definition des Testmusters 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)`

Assertion-Tabelle

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

Kamera Erstes API-Level	Kameratyp	Angegebene Farben
31	Bayer	SCHWARZ, WEISS, ROT, GRÜN, BLAU
31	MONO	SCHWARZ, WEISS
< 31	Bayer/MONO	SCHWARZ

Tests der Leistungsklasse

scene2_c/test_camera_launch_perf_class.py

Prüft, ob das Starten der Kamera sowohl für die primäre Front- als auch für die primäre Rückkamera weniger als 500 ms dauert, wenn die Gesichtsszene „scene2_c“ verwendet wird.

scene2_c/test_jpeg_capture_perf_class.py

Überprüft, ob die Latenz bei der Aufnahme von 1080p-JPEGs mit der Gesichtsszene „scene2_c“ für die primären Front- und Rückkameras weniger als 1 Sekunde beträgt.