Eine Reihe von Kamera-ITS- Änderungen sind in der Android 12-Version enthalten. Diese Seite fasst die Änderungen zusammen, die in vier große Kategorien fallen:
Refactoring auf Python 3
Aufgrund der Einstellung von Python 2.7 im Januar 2020 wurde die gesamte Kamera-ITS-Codebasis auf Python 3 umgestaltet. Die folgenden Python-Versionen und -Bibliotheken sind in Android 12 erforderlich:
- Python 3.7.9 oder Python 3.7.10
- OpenCV 3.4.2
- Numpy 1.19.2
- Matplotlib 3.3.2
- Scipy 1.5.2
- pySerial 3.5
- Kissen 8.1.0
- PyYAML 5.3.1
Der Hauptteststarter, tools/run_all_tests.py
, bleibt derselbe wie die Versionen Android 11 oder niedriger und wird auf Python 3 umgestaltet.
Alle einzelnen Tests werden umgestaltet und verwenden die neue Testaufbauklasse, 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 verlängert, 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.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
Übernahme 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 (DUT) und ein Diagrammtablett in der Klasse its_base_test
. Eine config.yml
(YAML)-Datei wird verwendet, um ein Mobly-Testbed zu erstellen. In dieser Konfigurationsdatei können mehrere Testbeds konfiguriert werden, beispielsweise ein Tablet und ein Sensorfusionstestbed. Innerhalb des Controller-Abschnitts jedes Testbeds können Sie device_ids
angeben, um die entsprechenden Android-Geräte für den Testläufer 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. Übliche 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)
Tablet-basierte Tests
Für Tablet-basierte Tests muss das Schlüsselwort TABLET
im Testbed-Namen vorhanden sein. Während der Initialisierung initialisiert der Mobly- TestParams
und übergibt sie an die einzelnen Tests.
Das Folgende ist ein Beispiel für 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
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
. 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
Sensorfusionstest
Für Sensorfusionstests muss der Testumgebungsname das Schlüsselwort SENSOR_FUSION
. Das richtige Testbed wird durch die getesteten Szenen bestimmt. Android 12 unterstützt sowohl Arduino- als auch Canakit- Controller für die Sensorfusion .
Das Folgende ist ein Beispiel für eine 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
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 Testumgebungen
In der Konfigurationsdatei können mehrere Testumgebungen enthalten sein. Die häufigste Kombination besteht darin, sowohl ein Tablet-Testbed als auch ein Sensor-Fusion-Testbed zu haben.
Das Folgende ist ein Beispiel für 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
Manuelles Testen
Manuelles Testen wird in Android 12 weiterhin unterstützt. Allerdings muss das Testbed das Testen als solches mit dem Schlüsselwort MANUAL
im Namen des Testbeds kennzeichnen. Darüber hinaus kann das Testbed keine Tablet-ID enthalten.
Das Folgende ist ein Beispiel für eine config.yml
-Datei 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
Testen von Szenen ohne Tablets
Das Testen für Szene 0 und Szene 5 kann mit TEST_BED_TABLET_SCENES
oder mit TEST_BED_MANUAL
. Wenn der Test jedoch mit TEST_BED_TABLET_SCENES
wird, muss das Tablet verbunden sein und die Seriennummer des Tablets muss gültig sein, auch wenn das Tablet nicht verwendet wird, da das Setup der Testklasse den Wert der Seriennummer für das Tablet zuweist.
Individuelle Tests durchführen
Einzelne Tests können nur zu Debug-Zwecken ausgeführt werden, da ihre Ergebnisse nicht an CTS Verifier gemeldet werden. Da die config.yml
Dateien nicht auf der Kommandozeile für camera
und scene
überschrieben werden können, müssen diese Parameter in der config.yml
-Datei für den betreffenden individuellen 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. Zum Beispiel:
python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES
Artefakte testen
In Android 12 werden Testartefakte für Kamera-ITS ähnlich wie in Android 11 oder niedriger gespeichert, jedoch mit den folgenden Änderungen:
- Dem Testartefakt-Verzeichnis
/tmp
ist aus Gründen der ÜbersichtlichkeitCameraITS_
der 8-stelligen Zufallszeichenfolge vorangestellt. - Testausgaben und Fehler werden für jeden Test in
test_log.DEBUG
statt intest_name_stdout.txt
undtest_name_stderr.txt
. - Die DUT- und Tablet-Logcats von jedem einzelnen Test werden im
/tmp/CameraITS_########
gespeichert, wodurch das Debuggen vereinfacht wird, da alle zum Debuggen von 3A-Problemen erforderlichen Informationen 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 anzeigen.
scene0/test_jitter.py
Der test_jitter
-Test wird auf physischen versteckten Kameras in Android 12 ausgeführt.
scene1_1/test_black_white.py
Für Android 12 hat test_black_white
die Funktionalität von sowohl test_black_white
als 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 niedriger Verstärkung ~[0, 0, 0] Langzeitbelichtung, RGB-Werte mit hoher Verstärkung ~[255, 255, 255] |
scene1_1/test_channel_saturation.py | 29 | Reduzierte Toleranz bei [255, 255, 255]-Unterschieden, um Farbstiche in weißen Bildern zu eliminieren. |
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 niedriger 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 eliminieren. |
scene1_1/test_burst_sameness_manual.py
Der Test test_burst_sameness_manual
wird auf physischen versteckten Kameras in Android 12 ausgeführt.
scene1_2/test_tonemap_sequence.py
Der test_tonemap_sequence
-Test wird auf BEGRENZTEN 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 auf LIMITED Kameras in Android 12 ausgeführt.
scene3/test_flip_mirror.py
Der test_flip_mirror
-Test wird auf BEGRENZTEN Kameras in Android 12 ausgeführt.
scene4/test_aspect_ratio_and_crop.py
Das Finden von Kreisen in scene4/test_aspect_ratio_and_crop.py
wurde in Android 12 umgestaltet.
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 gefunden wurde. Android 12 verwendet eine Methode, bei der alle Konturen gefunden und dann gefiltert werden, indem Merkmale gefunden werden, die am kreisrundsten sind. Um störende Kreise auf der Anzeige auszublenden, ist ein minimaler Konturbereich erforderlich, und die Kontur des Kreises muss schwarz sein.
Die Konturen und ihre Auswahlkriterien sind in der folgenden Abbildung dargestellt.
Abbildung 1. Konzeptzeichnung von Konturen und Auswahlkriterien
Die Android 12-Methode ist einfacher und löst das Problem mit dem Beschneiden des Begrenzungsrahmens in einigen Display-Tablets. Alle Kreiskandidaten werden zu Debugging-Zwecken protokolliert.
In Android 12 wird der Crop-Test für FULL
und LEVEL3
Geräte ausgeführt. Android 11 oder niedrigere Versionen überspringen die Crop-Test-Assertionen für FULL
Geräte.
Die folgende Tabelle listet die Zusicherungen für test_aspect_ratio_and_crop.py
auf, 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 ü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 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 zum Erkennen von Merkmalen in Bildern hinzugefügt.
In Versionen unter Android 12 wird das gesamte Bild verwendet, um die besten 240 Funktionen zu finden, die dann auf die mittleren 20 % maskiert werden, um Rolling-Shutter-Effekte zu vermeiden, wobei die Mindestfunktionsanforderung 30 Funktionen beträgt.
Wenn die von dieser Methode gefundenen Features nicht ausreichen, maskiert Android 12 den Feature-Erkennungsbereich zuerst auf 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. Das Erhöhen des Schwellenwerts für die minimale Merkmalsanforderung führt zur Erkennung von Merkmalen schlechter Qualität und wirkt sich negativ auf Messungen aus.
Abbildung 2. Unterschied in der Funktionserkennung zwischen Android 11 und Android 12
Neue Prüfungen
scene0/test_solid_color_test_pattern.py
Ein neuer 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 | Testname | Erste API-Ebene | Beschreibung |
---|---|---|---|
0 | test_solid_color_test_pattern | 31 | Bestätigt die Vollfarbbildausgabe und die Programmierbarkeit der Bildfarbe. |
Einfarbige Testmuster müssen aktiviert werden, um den Datenschutzmodus der Kamera zu unterstützen. Der Test test_solid_color_test_pattern
bestätigt die YUV-Bildausgabe in Volltonfarbe mit der durch das ausgewählte Muster definierten Farbe, und die Bildfarbe ändert sich gemäß der Spezifikation.
Parameter
-
cameraPrivacyModeSupport
: Legt fest, ob die Kamera den Datenschutzmodus unterstützt. -
android.sensor.testPatternMode
: Legt den Testmustermodus fest. Dieser Test verwendetSOLID_COLOR
. -
android.sensor.testPatternData
: Legt die R-, Gr-, Gb-, G-Testmusterwerte für den Testmustermodus fest.
Eine Beschreibung des einfarbigen Testmusters finden Sie unter SENSOR_TEST_PATTERN_MODE_SOLID_COLOR
.
Methode
YUV-Frames werden für die eingestellten Parameter 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 einzelnes YUV-Frame erfasst. Wenn PER_FRAME_CONTROL
nicht unterstützt wird, werden vier Bilder erfasst, wobei nur das letzte Bild analysiert wird, um die Testabdeckung in LIMITED
-Kameras zu maximieren.
YUV-Aufnahmen sind auf vollständig gesättigte BLACK
, WHITE
, RED
, GREEN
und BLUE
-Testmuster eingestellt. Da die Testmusterdefinition dem Sensor-Bayer-Muster entspricht, müssen die Farbkanäle für jede Farbe wie in der folgenden Tabelle gezeigt eingestellt werden.
Farbe | Testmusterdaten (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
Die folgende Tabelle beschreibt die Testzusicherungen für test_solid_color_test_pattern.py
.
Kamera Erste API-Ebene | Kameratyp | Farben behauptet |
---|---|---|
31 | Bayer | SCHWARZ, WEISS, ROT, GRÜN, BLAU |
31 | MONO | SCHWARZ-WEISS |
< 31 | Bayer/MONO | SCHWARZ |
Leistungsklassenprüfungen
scene2_c/test_camera_launch_perf_class.py
Überprüft, dass der Kamerastart sowohl für die vordere als auch für die hintere Primärkamera mit der Szene „scene2_c face“ weniger als 500 ms dauert.
scene2_c/test_jpeg_capture_perf_class.py
Verifiziert, dass die 1080p-JPEG-Erfassungslatenz weniger als 1 Sekunde für die vordere und hintere Primärkamera mit der Scene2_c-Gesichtsszene beträgt.