Versionshinweise zur Android 12 Camera Image Test Suite

In der Android 12-Version sind eine Reihe von Camera ITS- Änderungen enthalten. Auf dieser Seite werden die Änderungen zusammengefasst, die in vier große Kategorien unterteilt sind:

Refaktorierung auf Python 3

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

Der Haupttest-Launcher tools/run_all_tests.py bleibt derselbe wie bei den Versionen Android 11 oder niedriger und wurde auf Python 3 umgestaltet.

Alle einzelnen Tests werden umgestaltet und verwenden die neue Test-Setup-Klasse, 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 erhöht, 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

Einführung 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 (Device Under Test, DUT) und ein Diagrammtablett 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 Prüfstände konfiguriert werden, beispielsweise ein Tablet und ein Sensorfusionsprüfstand. Im Controller-Abschnitt jedes Testbeds können Sie device_ids angeben, um dem Testläufer die entsprechenden Android-Geräte 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 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)

Tabletbasiertes Testen

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

Im Folgenden finden Sie eine Beispieldatei config.yml 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 ausgeführt. 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

Sensorfusionstests

Für Sensorfusionstests muss der Testbed-Name das Schlüsselwort SENSOR_FUSION enthalten. Die richtige Testumgebung 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 Beispieldatei config.yml 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 Prüfstände

In der Konfigurationsdatei können mehrere Testbeds enthalten sein. Die gebräuchlichste Kombination besteht darin, sowohl einen Tablet-Prüfstand als auch einen Sensorfusions-Prüfstand zu haben.

Im Folgenden finden Sie eine Beispieldatei config.yml mit Tablet- und Sensorfusionstestumgebungen.

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

Manuelle Tests werden in Android 12 weiterhin unterstützt. Allerdings muss das Testbed Tests als solche mit dem Schlüsselwort MANUAL im Testbed-Namen identifizieren. Darüber hinaus darf das Testbed keine Tablet-ID enthalten.

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

Testszenen ohne Tablets

Tests für Szene 0 und Szene 5 können mit TEST_BED_TABLET_SCENES oder mit TEST_BED_MANUAL durchgeführt werden. Wenn der Test jedoch mit TEST_BED_TABLET_SCENES durchgeführt wird, muss das Tablet angeschlossen sein und die Seriennummer des Tablets muss gültig sein, auch wenn das Tablet nicht verwendet wird, da das Testklassen-Setup den Wert der Seriennummer für das Tablet zuweist.

Führen Sie individuelle Tests durch

Einzelne Tests können nur zu Debugzwecken ausgeführt werden, da ihre Ergebnisse nicht an CTS Verifier gemeldet werden. Da die config.yml Dateien nicht in der Befehlszeile für camera und scene überschrieben werden können, müssen diese Parameter in der config.yml Datei für den einzelnen betreffenden Test korrekt sein. Wenn die Konfigurationsdatei mehr als ein Testbed enthält, müssen Sie außerdem das Testbed 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

Testartefakte

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

  • Im Testartefakt-Verzeichnis /tmp ist der 8-stelligen Zufallszeichenfolge aus Gründen der Übersichtlichkeit CameraITS_ vorangestellt.
  • Testausgaben und Fehler werden für jeden Test in test_log.DEBUG anstelle von 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 das Debuggen vereinfacht, da alle zum Debuggen von 3A-Problemen erforderlichen Informationen protokolliert werden.

Testen Sie Änderungen

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 korrekt anzeigen.

scene0/test_jitter.py

Der test_jitter Test läuft auf physischen versteckten Kameras in Android 12.

scene1_1/test_black_white.py

Für Android 12 verfügt test_black_white über die Funktionalität von test_black_white und 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 geringer Verstärkung ~[0, 0, 0]
Langzeitbelichtung, RGB-Werte mit hoher Verstärkung ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 Reduzierte Toleranz für [255, 255, 255]-Unterschiede, um Farbstiche in weißen Bildern zu beseitigen.

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 geringer 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 vermeiden.

scene1_1/test_burst_sameness_manual.py

Der test_burst_sameness_manual Test läuft auf physischen versteckten Kameras in Android 12.

scene1_2/test_tonemap_sequence.py

Der test_tonemap_sequence -Test läuft auf LIMITED-Kameras in Android 12.

scene1_2/test_yuv_plus_raw.py

Der test_yuv_plus_raw Test läuft auf physischen versteckten Kameras in Android 12.

scene2_a/test_format_combos.py

Der test_format_combos -Test läuft auf LIMITED-Kameras in Android 12.

scene3/test_flip_mirror.py

Der test_flip_mirror -Test läuft auf LIMITED-Kameras in Android 12.

scene4/test_aspect_ratio_and_crop.py

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

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 gesucht wurde. Android 12 verwendet eine Methode, bei der alle Konturen gesucht und dann gefiltert werden, indem die kreisförmigsten Merkmale ermittelt werden. Um störende Kreise auf dem Display auszublenden, ist eine Mindestkonturfläche erforderlich und die Kontur des Kreises muss schwarz sein.

Die Konturen und ihre Auswahlkriterien sind im folgenden Bild dargestellt.

Konzeptionelles Zeichnen von Konturen und Auswahlkriterien

Abbildung 1. Konzeptionelle Zeichnung von Konturen und Auswahlkriterien

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

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

In der folgenden Tabelle sind die Behauptungen für test_aspect_ratio_and_crop.py aufgeführt, 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 umgestaltet, um das Zuschneiden auf Sensoren, die nicht zum Seitenverhältnis der Aufnahme passen, 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 zur Erkennung von Merkmalen in Bildern hinzugefügt.

In Versionen vor Android 12 wird das gesamte Bild verwendet, um die besten 240 Features zu finden, die dann auf 20 % in der Mitte maskiert werden, um Rolling-Shutter-Effekte zu vermeiden, wobei die Mindestanforderung an 30 Features liegt.

Wenn die mit dieser Methode gefundenen Funktionen nicht ausreichen, maskiert Android 12 den Feature-Erkennungsbereich zunächst um 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. Eine Anhebung des Mindestschwellenwerts für die Merkmalsanforderung führt zur Erkennung von Merkmalen schlechter Qualität und wirkt sich negativ auf die 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 Tests

scene0/test_solid_color_test_pattern.py

Für Android 12 ist ein neuer Test, test_solid_color_test_pattern , 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 Ausgabe von Vollfarbbildern und die Programmierbarkeit von Bildfarben.

Zur Unterstützung des Kamera-Privatsphärenmodus müssen einfarbige Testmuster aktiviert sein. Der test_solid_color_test_pattern -Test bestätigt die Ausgabe von einfarbigen YUV-Bildern mit der durch das ausgewählte Muster definierten Farbe und ändert die Bildfarbe gemäß der Spezifikation.

Parameter

  • cameraPrivacyModeSupport : Bestimmt, 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- und G-Testmusterwerte für den Testmustermodus fest.

Eine Beschreibung des Vollton-Testmusters finden Sie unter SENSOR_TEST_PATTERN_MODE_SOLID_COLOR .

Methode

Für die eingestellten Parameter werden YUV-Frames 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 einzelner YUV-Frame erfasst. Wenn PER_FRAME_CONTROL nicht unterstützt wird, werden vier Frames erfasst, wobei nur das letzte Frame analysiert wird, um die Testabdeckung in LIMITED Kameras zu maximieren.

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

Farbe testPatternData (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

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

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

Leistungsklassentests

scene2_c/test_camera_launch_perf_class.py

Überprüft, ob der Kamerastart sowohl für die vordere als auch für die hintere Hauptkamera mit der Gesichtsszene „scene2_c“ weniger als 500 ms dauert.

scene2_c/test_jpeg_capture_perf_class.py

Stellt sicher, dass die 1080p-JPEG-Aufnahmelatenz sowohl für die vordere als auch für die hintere Hauptkamera mit der Gesichtsszene scene2_c weniger als 1 Sekunde beträgt.