Camera ITS – Übersicht

Die Camera Image Test Suite (ITS) ist ein Framework zum Ausführen von Tests für Bilder, die von einer Android-Kamera aufgenommen wurden. Das allgemeine Ziel jedes Tests in ITS besteht darin, die Kamera auf eine bestimmte Weise zu konfigurieren, ein oder mehrere Bilder aufzunehmen und die Bilder zu untersuchen, um festzustellen, ob sie die erwarteten Bilddaten enthalten. Bei vielen Tests muss die Kamera auf ein bestimmtes Testbild gerichtet oder mit einer bestimmten Intensität beleuchtet werden.

ITS befindet sich im CTS Verifier-Test-Harness unter cts/apps/CameraITS. Geräte müssen die ITS-Tests bestehen, die den unterstützten Funktionen entsprechen, die vom Kamera-Framework für Drittanbieter-Apps als Teilmenge von CTS beworben werden.

Einrichtung

Für die Ausführung von ITS-Tests muss Folgendes eingerichtet sein:

  • Ein zu testendes Gerät (Device Under Test, DUT)
  • Ein Hostcomputer (z. B. ein Linux-Desktop oder ‑Laptop)
  • Eine Szene, die von der Kamera fotografiert wird

Einrichtung des zu testenden Geräts (DUT)

So richten Sie ein Testgerät ein:

  1. Verbinden Sie das zu testende Gerät über USB mit einem Hostcomputer.
  2. Konfigurieren Sie die Entwickleroptionen auf dem Testgerät:
    • Aktiviere Display aktiv lassen und USB-Debugging.
    • Deaktiviere Automatische Systemupdates und Über USB installierte Apps prüfen.
  3. Gewähren Sie dem Host Berechtigungen für den Zugriff auf das DUT über ADB.

  4. Installieren Sie die CTS Verifier App (CtsVerifier.apk) auf dem Gerät. Weitere Informationen finden Sie unter CTS Verifier verwenden.

    extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip
cd android-cts-verifier
adb install -r -g CtsVerifier.apk

  5. Starten Sie auf dem DUT die Standardkamera-App und schließen Sie alle Fenster, die beim Start angezeigt werden, um Störungen während des Tests zu vermeiden.

Host-Einrichtung

Für ITS muss der Hostcomputer über USB mit dem zu testenden Gerät verbunden sein, ADB zur Gerätesteuerung und ‑kommunikation verwenden können und die erforderliche Software installiert haben.

Prüfen Sie, ob auf Ihrem Hostcomputer die folgende Software installiert ist.

Android SDK Platform Tools

Die Android SDK-Plattformtools müssen installiert sein und ADB muss sich im Ausführungspfad der Shell oder des Terminals befinden, die auf dem Hostrechner ausgeführt werden. Informationen zur öffentlich veröffentlichten Version der Android SDK-Plattformtools finden Sie in den Versionshinweisen zu den SDK-Plattformtools.

Python

Python muss auf dem Hostcomputer installiert sein. Wir empfehlen, eine gebündelte Python-Distribution zu verwenden, um die Unterstützung für kompatible Versionen zu gewährleisten. Details dazu, welche Python- und Paketversionen für ein bestimmtes Release installiert werden müssen, finden Sie in den Versionshinweisen für das entsprechende Release von Camera ITS.

Mobly

Installieren Sie für Android 12 und höher das Mobly-Testframework. Mit Mobly können Sie ein DUT und ein Chart-Tablet in der Klasse its_base_test einrichten. Führen Sie Folgendes aus, um das Mobly-Test-Framework zu installieren:

pip install mobly

Umgebung einrichten

Führen Sie den folgenden Befehl aus, um die Testumgebung einzurichten:

cd CameraITS
source build/envsetup.sh

Mit diesem Befehl wird die Python-Installation geprüft, die Umgebungsvariable PYTHONPATH eingerichtet und Einheitentests für die utils/*.py-Module ausgeführt. Wenn im Terminal keine Fehler ausgegeben werden, ist die Umgebung bereit für die Ausführung der ITS-Tests.

Szeneneinrichtung

Für die Einrichtung der Szenen empfehlen wir die Verwendung der Camera ITS-in-a-box-Einrichtung, da sie die Automatisierung, Zuverlässigkeit und Effizienz beim Testen erleichtert. Die ITS-in-a-box-Prüfstände unterstützen alle Anforderungen an Beleuchtung, Zentrierung und Diagrammwechsel für ITS. Außerdem ist ITS-in-a-box für das Testen von Kameraerweiterungen erforderlich.

Achten Sie bei manuellen Tests auf Folgendes:

  • Das Prüfgerät befindet sich auf einem Stativ.
  • Das zu prüfende Gerät ist für jeden Test auf die richtige Szene ausgerichtet. Die ITS-Testanleitung enthält Aufforderungen, die Szene einzurichten, bevor Tests in einer neuen Szene gestartet werden.
  • Das DUT ist über USB mit dem Hostcomputer verbunden.
  • Das zu testende Gerät bewegt sich während des Tests nicht.
  • Die Szene wird von einer gleichmäßigen, nicht flackernden Lichtquelle beleuchtet. Verwenden Sie keine Leuchtstoffröhre, da diese flackert.

Im ITS-Testskript wird der Nutzer aufgefordert, die Szene einzurichten, bevor er Tests in einer neuen Szene startet.

Die Ausrichtung des Smartphones muss so eingestellt sein, dass die Kamera Bilder ohne Drehung aufnimmt. Am einfachsten lässt sich das mit den Gesichtsszenen in scene2 überprüfen. Bei den meisten Smartphones wird das Smartphone im Querformat gehalten. Für die Rückkamera wird es gegen den Uhrzeigersinn und für die Frontkamera im Uhrzeigersinn gedreht.

Führen Sie tools/check_alignment.py aus, um die Ausrichtung von DUT und Testbild zu prüfen. Dadurch werden die x- und y-Koordinaten für die Mitte des Testbilds im Vergleich zur Mitte des Bilds ausgegeben. Annotieren Sie ein aufgenommenes Bild mit den beiden Mittelpunkten, um eine optimale Ausrichtung zu erzielen.

Konfigurationsdateien

Mit dem Mobly-Framework müssen Sie eine config.yml-Konfigurationsdatei erstellen, um das Mobly-Testbed zu definieren. Im Folgenden finden Sie Beispiele für verschiedene Anwendungsfälle.

config.yml-Datei für tabletbasierte Szenen

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei für tabletbasierte Szenen. Für tabletbasierte Tests muss das Keyword TABLET im Testbed-Namen enthalten sein. Bei der Initialisierung initialisiert der Mobly-Test-Runner die Parameter in der Datei und übergibt sie an die einzelnen Tests.

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"  # "True" or "False"; quotes needed
      lighting_cntl: <controller-type>  # "arduino" or "None"; quotes needed
      lighting_ch: <controller-channel>
      camera: 0
      foldable_device: "False". # set "True" if testing foldable
      scene: <scene-name>  # if <scene-name> runs all scenes

Führen Sie tools/run_all_tests.py aus, um die Testumgebung aufzurufen. Wenn in der Befehlszeile keine Werte für Kameras oder Szenen angegeben sind, wird der Test mit den Werten aus der Datei config.yml ausgeführt. Wenn es Befehlszeilenwerte für Kameras oder Szenen gibt, werden die Werte im Abschnitt TestParams der Datei config.yml überschrieben. 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=0 scenes=scene_tele
python tools/run_all_tests.py camera=0.4 scenes=4,scene6_tele

Parameter „chart_scaling“

In Android 17 und höher ist der Parameter chart_scaling in config.yml für TEST_BED_TABLET_SCENES enthalten. Dieser Parameter behebt Probleme mit der Diagrammskalierung für Geräte mit Telekamera mit einem breiteren Sichtfeld (Field of View, FoV). So wird verhindert, dass die Szene beschnitten wird, und während des Tests wird der Fokus des Geräts richtig eingestellt.

Unterstützte Werte für chart_scaling sind 1, 0.33, 0.5 oder 0.67. Die Standardeinstellung ist None. Mit diesem Ansatz können Geräte einen optimalen Skalierungsfaktor verwenden, der auf ihre spezifischen Anforderungen zugeschnitten ist. Gleichzeitig werden Funktionstests auf allen Geräten durchgeführt.

Wenn chart_scaling auf None festgelegt ist, wird der Skalierungsfaktor automatisch anhand von chart_scaling_logic ermittelt. Andernfalls wird der in config.yml angegebene Wert verwendet oder es wird ein Fehler gemeldet, wenn die Skalierung nicht verfügbar ist.

Im Folgenden sehen Sie ein Beispiel für config.yml mit dem Parameter chart_scaling.

TestBeds:
  -   Name: TEST_BED_TABLET_SCENES  # Need 'tablet' in name for tablet scenes
    # Use TEST_BED_MANUAL for manual testing and remove below lines:
    #     - serial <tablet_id>
    #       label: tablet
    # Test configuration for scenes[0:4, 6]
    Controllers:
        AndroidDevice:
          -   serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
          -   serial: <tablet-id>  # quotes needed if serial id entirely numeric
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # quotes needed
      lighting_cntl: <controller-type>  # can be arduino or "None"
      lighting_ch: <controller-channel>
      camera: <camera-id>
      scene: <scene-name>  # if <scene-name> runs all scenes
      foldable_device: "False"  # "True" if testing foldable device
      chart_scaling: "None"  # use the values available for scene to be tested
      resultstore_upload: "False"  # "True" if results should be uploaded to ResultStore

Für die Skalierung von Camera ITS-Diagrammen sind Anpassungen auf der Testseite erforderlich. Wenn ein Test, den Sie verwenden, dies nicht unterstützt, melden Sie einen Fehler.

Im Folgenden finden Sie ein Beispiel für eine Änderung auf der Testseite mit dem Parameter chart_scaling.

# load chart for scene
      its_session_utils.load_scene(
          cam, props, self.scene, self.tablet, self.chart_distance,
          chart_scaling=self.chart_scaling)

sensor_fusion-Szenenkonfigurationsdatei „config.yml“

Hier sehen Sie eine config_yml-Beispieldatei für sensor_fusion-Tests. Für sensor_fusion-Tests muss das Keyword SENSOR_FUSION im Namen des Testbeds enthalten sein. Unter Android 13 und höher wird für Sensorfusion nur der Arduino-Controller unterstützt, da Tests für Vorschau und Videostabilisierung durchgeführt werden. Android 12 unterstützt Arduino- und Canakit-Controller.

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
      rotator_ch: 1
      camera: 0

So führen Sie sensor_fusion-Tests mit der Sensor-Fusion-Box aus:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
python tools/run_all_tests.py scenes=scene_flash,feature_combination
python tools/run_all_tests.py scenes=checkerboard camera=1

Mehrere testbeds-config.yml-Dateien

Das Folgende ist ein Beispiel für eine config.yml-Datei mit mehreren Testbeds, einem Tablet-Testbed und einem sensor_fusion-Testbed. Das richtige Testbed wird durch die getesteten Szenen bestimmt.

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 der Datei „config.yml“

Hier sehen Sie eine config.yml-Beispieldatei für manuelle Tests. Unter Android 14 und höher werden manuelle Tests für alle Tests mit Ausnahme der scene_extensions-Tests unterstützt. Für manuelle Tests muss das Keyword MANUAL im Namen des Testgeräts enthalten sein. Außerdem darf der Abschnitt AndroidDevice keinen Serien- oder Labelabschnitt für ein Tablet enthalten.

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

    TestParams:
      debug_mode: "False"
      camera: 0
      scene: 1

config.yml-Datei für Gen2-Rig-Tests

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei eines TEST_BED_GEN2-Testbeds. Verwenden Sie dieses Testbed für scene_ip-Tests, bei denen ein Gen2-Rig verwendet wird. Das folgende Beispiel zeigt die Testumgebungsparameter, wenn das Gen2-Rig verfügbar ist und die scene_ip-Tests nicht übersprungen werden.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: gen2_rotator   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: 0
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: gen2_lights  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: 1
      scene: scene_ip

Das folgende Beispiel zeigt Testbed-Parameter, wenn das Gen2-Rig nicht verfügbar ist und die scene_ip-Tests übersprungen werden.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: "None"   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: <controller-channel>
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: "None"  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: <controller-channel>
      scene: scene_ip

Verwenden Sie einen der folgenden Befehle, um den Test „scene_ip“ auszuführen:

python tests/scene_ip/test_default_jca_ip.py -c config.yml
python tools/run_all_tests.py camera=<camera-id> scenes=scene_ip

ITS-Tests ausführen

In diesem Abschnitt wird beschrieben, wie Sie ITS-Tests ausführen.

Tests aufrufen

Nachdem das Gerät, der Hostcomputer (einschließlich Umgebung) und die physische Szene eingerichtet sind, führen Sie die ITS-Tests mit dem folgenden Verfahren aus.

  1. Öffnen Sie die CTS Verifier App. Wählen Sie im Menü „Tests“ die Option Camera ITS Test (ITS-Kameratest) aus. Unter Android 17 und höher befinden sich die Tests sensor_fusion und feature_combination in einer zusätzlichen Aktivität namens Camera ITS Sensor Fusion Rig Test.

  2. Führen Sie auf dem Hostcomputer die ITS-Tests aus dem Verzeichnis CameraITS/ aus. Führen Sie für ein Gerät mit Front- und Rückkamera beispielsweise den folgenden Befehl aus:

    python tools/run_all_tests.py

    Das Script durchläuft Kameras und Testszenen basierend auf der Datei config.yml. Für das Debugging von Setups empfehlen wir, eine der scene2-Szenen mit einem einzelnen Test auszuführen, um die schnellste Bearbeitungszeit zu erzielen.

    Für manuelle Tests wird vor dem Ausführen der ITS-Tests für jede Szene ein Bild der aktuellen Szene aufgenommen, als JPEG gespeichert, der Pfad zum JPEG in der Konsole ausgegeben und der Nutzer aufgefordert, zu bestätigen, ob das Bild in Ordnung ist. Dieser Erfassungs- und Bestätigungsablauf wird wiederholt, bis der Nutzer bestätigt, dass das Bild in Ordnung ist. Im Folgenden sind die Meldungen in diesem Ablauf aufgeführt.

    Preparing to run ITS on camera 0
Start running ITS on camera:  0
Press Enter after placing camera 0 to frame the test scene:
scene1_1
The scene setup should be: A grey card covering at least the   middle 30% of the scene
Running vendor 3A on device
Capture an image to check the test scene
Capturing 1 frame with 1 format [yuv]
Please check scene setup in /tmp/tmpwBOA7g/0/scene1_1.jpg
Is the image okay for ITS scene1_1? (Y/N)

    Bei jeder Ausführung des Skripts wird ein Log ausgegeben, in dem für jeden ITS-Test entweder PASS, FAIL, FAIL* oder SKIP angezeigt wird. FAIL* gibt an, dass der Test fehlgeschlagen ist. Da der Test jedoch noch nicht vorgeschrieben ist, wird er in CtsVerifier als PASS gemeldet. SKIP bedeutet, dass der Test bestanden wurde, weil das Gerät die zugrunde liegende Funktion, die getestet wurde, nicht beworben hat. Wenn ein Gerät beispielsweise über die Kameraschnittstellen nicht angibt, dass es DNG unterstützt, werden Tests im Zusammenhang mit der Aufnahme von DNG-Dateien übersprungen und als PASS gezählt.

  3. Tippen Sie auf die Schaltfläche mit dem grünen Häkchen, um zu bestätigen, dass die Tests die Testanforderungen erfüllen. Der Eintrag Camera ITS Test im CTS Verifier-Menü wird dann grün und signalisiert, dass das Smartphone die Camera ITS-Tests bestanden hat.

Paralleles Testen von Geräten

Geräte mit Android 14 oder höher unterstützen parallele DUT-Tests. So können Sie DUTs parallel mit mehreren Rigs testen und die Gesamttestzeit verkürzen. Beim Paralleltest können Sie beispielsweise Kamera 0 in einem Rig und Kamera 1 in einem anderen Rig gleichzeitig testen. Bei Android 17 und höher können Sie die Tests sensor_fusion und feature_combination auf einem DUT und andere Tests parallel auf einem anderen DUT ausführen, da die Camera ITS-Tests in zwei Aktivitäten unterteilt sind. Alle Tests für parallele Testsitzungen werden in der CTS Verifier-Sitzung auf dem Referenz-DUT zusammengefasst. Sie müssen parallele Tests mit der Arduino-Beleuchtungssteuerung durchführen, da die manuelle Beleuchtungssteuerung bei parallelen Tests nicht unterstützt wird. Achten Sie darauf, dass die Beleuchtung für jede Anlage über einen anderen Kanal auf demselben Arduino-Controller gesteuert wird.

Im Folgenden sehen Sie eine config.yml-Beispieldatei, in der drei Testbeds definiert sind, die parallel ausgeführt werden sollen.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES_INDEX_0
    Controllers:
        AndroidDevice:
          - serial: <device-id-0>
            label: dut
          - serial: <tablet-id-0>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-0>
      camera: 0
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  - Name: TEST_BED_TABLET_SCENES_INDEX_1
    Controllers:
        AndroidDevice:
          - serial: <device-id-1>
            label: dut
          - serial: <tablet-id-1>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-1>
      camera: 1
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  # TEST_BED_SENSOR_FUSION represents testbed index 2
  # Parallel sensor_fusion is currently unsupported due to Arduino requirements
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion
    Controllers:
        AndroidDevice:
          - serial: <device-id>
            label: dut
    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: "arduino"
      rotator_ch: <controller-channel-2>
      camera: <camera-id>
      foldable_device: "False"
      tablet_device: "False"
      lighting_cntl: "None"
      lighting_ch: <controller-channel>
      scene: "sensor_fusion"

Verwenden Sie den folgenden Befehl, um die Testbeds parallel auszuführen:

for i in 0 1 2; do python3 tools/run_all_tests.py testbed_index=$i num_testbeds=3 & done; wait

Aggregierte Testergebnisse einreichen

In Android 17 und höher können Sie aggregierte Camera ITS-Testergebnisse zur Build-Genehmigung einreichen. Mit dem CTS Verifier können Sie mehrere Szenen gleichzeitig auf mehreren Geräten testen und Testergebnisse aus mehreren CTS Verifier-Berichten (aus verschiedenen Testläufen oder Geräten) in einer einzigen, einheitlichen Einreichung zusammenfassen.

Einreichungsverfahren

So reichen Sie aggregierte Camera ITS-Ergebnisse zur Build-Genehmigung ein:

  1. Geräte vorbereiten:Sammeln Sie zwei bis drei zu testende Geräte (DUTs), die alle denselben Build-Fingerabdruck haben.
  2. CTS Verifier installieren:Installieren Sie das aktuelle CTS Verifier-APK, das Sie über den bereitgestellten Build-Explorer erhalten.

  3. Tests parallel ausführen:

    1. Bringen Sie die Testgeräte in separaten Vorrichtungen an.
    2. Führen Sie auf jedem Gerät gleichzeitig verschiedene ITS-Kameraszenen aus.
    3. Berichtserstellung:Rufen Sie den CTS Verifier-Bericht nach jedem Lauf ab. Dazu gehören auch Berichte, in denen Szenen fehlgeschlagen sind. Bei nachfolgenden Läufen werden nur die fehlgeschlagenen Szenen noch einmal ausgeführt.

  4. Berichte einreichen:Laden Sie mehrere CTS Verifier-Berichte hoch, die von allen Geräten erfasst wurden.

  5. Ergebnisse ansehen:Nachdem die Berichte hochgeladen wurden, können Sie sich die zusammengefassten Ergebnisse ansehen:

    • Im Bereich Testanalyse finden Sie eine vollständige Liste aller ausgeführten Szenen.

    • Nicht ausgeführte oder fehlgeschlagene Szenen werden im Bereich Fehler aufgeführt.

      result-aggregation-image-1

      Abbildung 1. Dokumentation von Szenen, die nicht ausgeführt wurden oder fehlgeschlagen sind.

    • Die Übergangsszenen werden im Bereich Aggregated Pass (Zusammengefasster Durchgang) aufgeführt.

      result-aggregation-image-2

      Abbildung 2: Szenen, die als „Aggregated Pass“ kategorisiert sind

Freigabestatus des Builds

Die Build-Genehmigung wird erteilt, sobald alle erforderlichen Szenen in den zusammengefassten Berichten erfolgreich abgeschlossen wurden.

DNG-Rauschmodell

Geräte, die mit der Möglichkeit werben, RAW- oder DNG-Bilder aufzunehmen, müssen in den Metadaten des Aufnahmeergebnisses jeder RAW-Aufnahme ein Rauschmodell bereitstellen. Dieses Rauschmodell muss für jede Kamera (z. B. Front- und Rückkamera) auf dem Gerät, das Unterstützung bietet, in die Kamera-HAL eingebettet werden.

Implementierung des Rauschmodells

So implementieren Sie ein Rauschmodell:

  1. Führen Sie das Skript dng_noise_model.py im Verzeichnis tools aus, um ein Rauschmodell für jede Kamera zu erstellen. Dadurch wird ein C-Code-Snippet ausgegeben. Weitere Informationen zum Einrichten der Kamera und der Aufnahmeumgebung finden Sie im Dokument DngNoiseModel.pdf im Verzeichnis tools.

  2. Um das Rauschmodell für das Gerät zu implementieren, kopieren Sie den C-Code-Snippet und fügen Sie ihn in die Kamera-HAL ein.

Validierung des Rauschmodells

Beim automatisierten ITS-Test tests/scene1_1/test_dng_noise_model.py> wird das Rauschmodell validiert, indem geprüft wird, ob die in den Kameradaten angegebenen Rauschwerte für die Aufnahmebelichtung und die Verstärkung korrekt sind.

Tests mit knapp bestandenem Ergebnis (Teststatus „PASS*“)

In Android 17 und höher weist das Ergebnis Marginal Pass (PASS*) darauf hin, dass ein Test bestanden wurde, die Leistungsmesswerte jedoch sehr nahe am vordefinierten Grenzwert für das Bestehen liegen. Der Test erfüllt zwar technisch die Kriterien für das Bestehen, die Nähe zur Fehlergrenze deutet jedoch darauf hin, dass eine genauere Untersuchung erforderlich ist.

Vorteile von Grenzübertragungen

Der Status PASS* bietet mehrere Vorteile:

  • Frühwarnsystem: Identifiziert Tests, die kurz vor dem Fehlschlagen stehen, sodass Teams Probleme beheben können, bevor sie zu einem vollständigen Fehlschlagen führen.

  • Proaktive Optimierung: Teams werden dazu angehalten, Tests und Code zu optimieren, die im unteren Bereich des akzeptablen Bereichs liegen, um die Gesamtstabilität zu verbessern.

  • Höhere Qualität: Durch das Markieren von Bereichen, die bei geringfügigen Codeänderungen anfällig für zukünftige Regressionen sein könnten, wird ein höherer Qualitätsstandard aufrechterhalten.

  • Weniger Zeit für das Debugging: Wenn PASS*-Tests frühzeitig erkannt werden, kann der Zeit- und Arbeitsaufwand für das Debugging vollständiger Fehler in Zukunft erheblich reduziert werden.

Details zu PASS*

Der Status PASS* umfasst Folgendes:

  • Grenzwerte definieren: Für jeden relevanten Test in Camera ITS werden spezifische Grenzwerte für „bestanden“ definiert.

  • Automatisierte Erkennung: Das Testautomatisierungssystem erkennt und kategorisiert Tests als PASS* basierend auf den definierten Grenzwerten.

  • Benachrichtigungsmechanismus: Teams erhalten automatische Benachrichtigungen für alle Tests, die als PASS* gekennzeichnet sind. Sie werden aufgefordert, den jeweiligen Test und seine Messwerte zu untersuchen.

  • Berichterstellung: Grenzfälle werden in Testberichten und Dashboards zur besseren Sichtbarkeit als PASS* im Bericht ItsTestSummary angegeben, ähnlich wie Fail* für not_yet_mandated-Tests. Der Test behält den grünen Status bei, da er weiterhin innerhalb der festgelegten Grenzwerte liegt, um weitere Verwirrung zu vermeiden. Der Status PASS* gilt nur für eine Testklasse, nicht für die gesamte Szene. Scene_0 kann beispielsweise als PASS betrachtet werden, auch wenn test_jitter und test_metadata PASS* sind.

  • Monitoring: Leistungsdaten werden für Tests erhoben, die auf einem Gerät nur knapp bestanden wurden. So können zukünftige Kameraverbesserungen von OEMs überwacht werden, wenn diese Tests in den Status PASS übergehen.

Im Folgenden finden Sie ein Beispiel für Testergebnisse mit PASS*:

INFO:root:Reporting camera 1 ITS results to CtsVerifier
INFO:root:ITS results to CtsVerifier: {'scene0': {'result': 'PASS', 'TEST_STATUS': [{'test': 'test_jitter', 'status': 'PASS*'}, {'test': 'test_metadata', **'status': 'PASS*'**}, {'test': 'test_request_capture_match', 'status': 'PASS'}, {'test': 'test_sensor_events', 'status': 'PASS'}, {'test': 'test_solid_color_test_pattern', 'status': 'PASS'}, {'test': 'test_test_patterns', 'status': 'SKIP'}, {'test': 'test_tonemap_curve', 'status': 'SKIP'}, {'test': 'test_unified_timestamps', 'status': 'PASS'}, {'test': 'test_vibration_restriction', 'status': 'PASS'}], 'mpc_metrics': [], 'performance_metrics': [], 'feature_query_proto': [], 'feature_query_proto_path': [], 'summary': '/tmp/CameraITS_zojk4sdr/cam_id_1/scene0/scene_test_summary.txt', 'start': 1754330630345, 'end': 1754330764534}, 'scene1_1': {'result': 'NOT_EXECUTED'}, 'scene1_2': {'result': 'NOT_EXECUTED'}, 'scene1_3': {'result': 'NOT_EXECUTED'}, 'scene2_a': {'result': 'NOT_EXECUTED'}, 'scene2_b': {'result': 'NOT_EXECUTED'}, 'scene2_c': {'result': 'NOT_EXECUTED'}, 'scene2_d': {'result': 'NOT_EXECUTED'}, 'scene2_e': {'result': 'NOT_EXECUTED'}, 'scene2_f': {'result': 'NOT_EXECUTED'}, 'scene2_g': {'result': 'NOT_EXECUTED'}, 'scene3': {'result': 'NOT_EXECUTED'}, 'scene4': {'result': 'NOT_EXECUTED'}, 'scene6': {'result': 'NOT_EXECUTED'}, 'scene7': {'result': 'NOT_EXECUTED'}, 'scene8': {'result': 'NOT_EXECUTED'}, 'scene9': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_hdr': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_low_light': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene6_tele': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene7_tele': {'result': 'NOT_EXECUTED'}, 'scene_video': {'result': 'NOT_EXECUTED'}, 'scene5': {'result': 'NOT_EXECUTED'}, 'sensor_fusion': {'result': 'NOT_EXECUTED'}, 'feature_combination': {'result': 'NOT_EXECUTED'}, 'scene_flash': {'result': 'NOT_EXECUTED'}, 'scene_ip': {'result': 'NOT_EXECUTED'}}

Partner werden dazu angehalten,

  • PASS*-Benachrichtigungen im Blick behalten
  • Ursache von PASS* Tests untersuchen
  • Proaktive Optimierung von Tests und Code, die als PASS* gekennzeichnet sind

Der Status PASS* soll die Robustheit und Zuverlässigkeit von Camera ITS-Tests verbessern und zu einem stabilen und hochwertigen Produkt führen.