Camera ITS – Übersicht

Die Camera Image Test Suite (ITS) ist ein Framework zum Ausführen von Tests für Bilder, die mit einer Android-Kamera aufgenommen wurden. Das allgemeine Ziel jedes Tests in ITS ist es, die Kamera auf eine bestimmte Weise zu konfigurieren, ein oder mehrere Fotos aufzunehmen und die Fotos zu prüfen, 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 in der CTS Verifier-Testumgebung 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
  • Ein Hostcomputer (z. B. ein Linux-Desktop oder -Laptop)
  • Eine Szene, die von der Kamera fotografiert wird

Einrichtung des zu testenden Geräts

So richten Sie ein zu testendes Gerät ein:

  1. Verbinden Sie das zu testende Gerät über USB mit einem Hostcomputer.
  2. Gewähren Sie dem Host Berechtigungen für den Zugriff auf das zu testende Gerät über ADB.

  3. 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

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

Host einrichten

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

Achten Sie darauf, dass die folgende Software auf Ihrem Hostcomputer installiert ist.

Android SDK-Plattformtools

Die Android SDK-Plattformtools müssen installiert sein und ADB muss sich im ausführbaren Pfad der Shell oder des Terminals befinden, die auf dem Hostcomputer ausgeführt werden. Die öffentlich veröffentlichte 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 zu den Python- und Paketversionen, die für einen bestimmten Release installiert werden müssen, finden Sie in den Versionshinweisen zu Camera ITS für den entsprechenden Release.

Mobly

Installieren Sie für Android 12 und höher das Mobly-Testframework. Mit Mobly können Sie ein zu testendes Gerät und ein Testbild-Tablet in der Klasse its_base_test einrichten. Führen Sie Folgendes aus, um das Mobly-Testframework zu installieren:

pip install mobly

Umgebung einrichten

Führen Sie Folgendes 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 Module utils/*.py ausgeführt. Wenn im Terminal keine Fehler ausgegeben werden, ist die Umgebung bereit für die Ausführung der ITS-Tests.

Szene einrichten

Für die Einrichtung der Szenen empfehlen wir die Verwendung des Camera ITS-in-a-box-Setups, um die Automatisierung, Zuverlässigkeit und Effizienz beim Testen zu verbessern. Die ITS-in-a-box-Testaufbauten unterstützen alle Anforderungen an Beleuchtung, Zentrierung und Testbildwechsel 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 zu testende Gerät befindet sich auf einem Stativ.
  • Das zu testende Gerät ist für jeden Test auf die richtige Szene gerichtet. (Das ITS-Testskript enthält Aufforderungen, die Szene vor dem Starten von Tests in einer neuen Szene zu ändern.)
  • Das zu testende Gerät ist über USB mit dem Hostcomputer verbunden.
  • Das zu testende Gerät bewegt sich während des Testlaufs nicht.
  • Die Szene wird mit einer gleichmäßigen, nicht flackernden Lichtquelle beleuchtet. (Verwenden Sie keine Leuchtstofflampe, da diese zu Flimmern führt.)

Das ITS-Testskript fordert den Nutzer auf, die Szene vor dem Starten von Tests in einer neuen Szene zu ändern.

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

Konfigurationsdateien

Mit dem Mobly-Framework müssen Sie eine config.yml-Konfigurationsdatei erstellen, um die Mobly-Testumgebung 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 Namen der Testumgebung enthalten sein. Während der Initialisierung initialisiert der Mobly-Testrunner 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 keine Befehlszeilenwerte für Kameras oder Szenen angegeben sind, wird der Test mit den Werten aus der Datei config.yml ausgeführt. Wenn Befehlszeilenwerte für Kameras oder Szenen vorhanden sind, überschreiben diese die Werte im Abschnitt TestParams der Datei config.yml. 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 Testbildskalierung für Geräte mit Telekamera und einem größeren Sichtfeld. So wird verhindert, dass Szenen zugeschnitten werden, und der Fokus des Geräts wird während des Tests richtig eingestellt.

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

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

Hier sehen Sie ein Beispiel für eine config.yml-Datei 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

Auf Testseite sind Anpassungen erforderlich, um die Funktionen zur Testbildskalierung von Camera ITS zu aktivieren. Wenn ein von Ihnen verwendeter Test dies nicht unterstützt, melden Sie einen Fehler.

Hier sehen Sie ein Beispiel für eine Änderung auf 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)

config.yml-Datei für die Szene „sensor_fusion“

Im Folgenden finden Sie ein Beispiel für eine config_yml-Datei für sensor_fusion-Tests. Für sensor_fusion-Tests muss das Keyword SENSOR_FUSION im Namen der Testumgebung enthalten sein. Android 13 und höher unterstützen aufgrund von Tests zur Vorschau und Videostabilisierung nur den Arduino-Controller für die Sensorfusion. 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

Führen Sie Folgendes aus, um sensor_fusion Tests mit der Sensorfusionsbox auszuführen:

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

config.yml-Datei für mehrere Testumgebungen

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei mit mehreren Testumgebungen, einer Tablet-Testumgebung und einer sensor_fusion-Testumgebung. Die richtige Testumgebung 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

config.yml-Datei für manuelle Tests

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei für manuelle Tests. Android 14 und höher unterstützt manuelle Tests für alle Tests mit Ausnahme der scene_extensions Tests. Für manuelle Tests muss das Keyword MANUAL im Namen der Testumgebung enthalten sein. Außerdem darf der Abschnitt AndroidDevice keinen Abschnitt für die Seriennummer oder das Label eines Tablets 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 Tests mit dem Gen2-Testaufbau

Im Folgenden finden Sie ein Beispiel für eine config.yml-Datei einer TEST_BED_GEN2-Testumgebung. Diese Testumgebung wird für scene_ip-Tests verwendet, bei denen ein Gen2-Testaufbau verwendet wird. Im folgenden Beispiel werden die Parameter der Testumgebung angezeigt, wenn der Gen2-Testaufbau 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

Im folgenden Beispiel werden die Parameter der Testumgebung angezeigt, wenn der Gen2-Testaufbau 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 scene_ip-Test 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 wurden, 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 aus. In 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 die ITS-Tests auf dem Hostcomputer aus dem Verzeichnis CameraITS/ aus. Führen Sie beispielsweise für ein Gerät mit Front- und Rückkamera den folgenden Befehl aus:

    python tools/run_all_tests.py

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

    Bei manuellen 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 Ablauf wird wiederholt, bis der Nutzer bestätigt, dass das Bild in Ordnung ist. Im Folgenden finden Sie die Meldungen in diesem Ablauf.

    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* bedeutet, 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 wird, nicht beworben hat. Wenn ein Gerät beispielsweise über die Kameraschnittstellen nicht bewirbt, dass es DNG unterstützt, werden Tests zur 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üllt haben. Der Eintrag Camera ITS Test im Menü „Tests“ von CTS Verifier wird dann grün und zeigt an, dass das Smartphone den Camera ITS-Test bestanden hat.

Parallele Tests auf zu testenden Geräten

Geräte mit Android 14 oder höher unterstützen parallele Tests auf zu testenden Geräten. So können Sie zu testende Geräte parallel mit mehreren Testaufbauten testen, um die Gesamttestzeit zu verkürzen. Bei parallelen Tests können Sie beispielsweise Kamera 0 in einem Testaufbau und Kamera 1 in einem anderen Testaufbau gleichzeitig testen. In Android 17 und höher sind die Camera ITS-Tests in zwei Aktivitäten unterteilt. So können Sie sensor_fusion- und feature_combination-Tests auf einem zu testenden Gerät und andere Tests parallel auf einem anderen zu testenden Gerät ausführen. Alle Tests für parallele Testsitzungen werden in der CTS Verifier-Sitzung auf dem Referenzgerät zusammengefasst. Sie müssen parallele Tests mit der Arduino-Lichtsteuerung ausführen, da die manuelle Lichtsteuerung bei parallelen Tests nicht unterstützt wird. Achten Sie darauf, dass die Beleuchtung für jeden Testaufbau über einen anderen Kanal auf demselben Arduino-Controller gesteuert wird.

Hier sehen Sie ein Beispiel für eine config.yml-Datei, in der drei Testumgebungen 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 Testumgebungen 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 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, die alle genau denselben Build-Fingerabdruck haben.
  2. CTS Verifier installieren:Installieren Sie die neueste CTS Verifier APK, die Sie über den bereitgestellten Build-Explorer erhalten.

  3. Tests parallel ausführen :

    1. Bringen Sie die zu testenden Geräte in separaten Testaufbauten an.
    2. Führen Sie verschiedene Camera ITS-Szenen gleichzeitig auf jedem Gerät aus.
    3. Sammlung „Berichte“:Rufen Sie nach jeder Ausführung den CTS Verifier-Bericht ab. Dazu gehören auch Berichte, bei denen Szenen fehlgeschlagen sind. Führen Sie die fehlgeschlagenen Szenen nur bei nachfolgenden Ausführungen noch einmal aus.

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

  5. Ergebnisse prüfen:Nachdem die Berichte hochgeladen wurden, prüfen Sie die aggregierten Ergebnisse:

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

    • Nicht ausgeführte oder fehlgeschlagene Szenen werden im Abschnitt Fehlgeschlagen aufgeführt.

      result-aggregation-image-1

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

    • Bestandene Szenen werden im Abschnitt Aggregiert bestanden aufgeführt.

      result-aggregation-image-2

      Abbildung 2 : Szenen, die als „Aggregiert bestanden“ kategorisiert wurden

Freigabestatus des Builds

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

DNG-Rauschmodell

Geräte, die die Möglichkeit zur Aufnahme von RAW- oder DNG-Dateien bewerben, müssen in den Metadaten der Aufnahmeergebnisse 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 beansprucht, in die Kamera-HAL eingebettet sein.

Implementierung des Rauschmodells

Führen Sie die folgenden Schritte aus, um ein Rauschmodell zu implementieren, ein Rauschmodell zu generieren und das Modell in die Kamera-HAL einzubetten.

  1. Führen Sie das dng_noise_model.py Skript im tools Verzeichnis aus, um ein Rauschmodell für jede Kamera zu generieren. 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. Schneiden Sie das C-Code-Snippet aus und fügen Sie es in die Kamera-HAL ein, um das Rauschmodell für das Gerät zu implementieren.

Validierung des Rauschmodells

Der tests/scene1_1/test_dng_noise_model.py automatisierte ITS-Test validiert das Rauschmodell, indem er prüft, ob die Rauschwerte für die Aufnahmebelichtung und -verstärkung, die in den Kameradaten angegeben sind, korrekt sind.

Tests, die knapp bestanden wurden (Teststatus „PASS*“)

In Android 17 und höher bedeutet ein knapp bestanden (PASS*), dass ein Test bestanden wurde, die Leistungsmesswerte jedoch sehr nahe am vordefinierten Schwellenwert für das Bestehen liegen. Obwohl der Test die Kriterien für das Bestehen technisch erfüllt, deutet die Nähe zur Grenze für das Scheitern darauf hin, dass eine genauere Prüfung erforderlich ist.

Vorteile von „knapp bestanden“

Der Status PASS* bietet mehrere Vorteile:

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

  • Proaktive Optimierung: Teams werden aufgefordert, Tests und Code zu optimieren, die am unteren Ende des akzeptablen Bereichs liegen, um die Gesamtstabilität zu verbessern.

  • Verbesserte Qualität: Ein höherer Qualitätsstandard wird beibehalten, indem Bereiche gekennzeichnet werden, die bei geringfügigen Codeänderungen anfällig für zukünftige Regressionen sein könnten.

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

Details zu „PASS*“

Der Status PASS* umfasst Folgendes:

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

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

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

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

  • Monitoring: Für Tests, die auf einem Gerät knapp bestanden wurden, werden Leistungsdaten erfasst. So können zukünftige Kameraverbesserungen von OEMs beobachtet werden, wenn diese Tests den Status PASS erreichen.

Hier sehen 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 aufgefordert, Folgendes zu tun:

  • PASS*-Benachrichtigungen beobachten
  • Die Ursache von PASS*-Tests untersuchen
  • Tests und Code, die als PASS* identifiziert wurden, proaktiv optimieren

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