Versionshinweise für die Android 11 Camera Image Test Suite

Auf dieser Seite werden die Änderungen an der Camera Image Test Suite (ITS) in Android 11 zusammengefasst. Die Änderungen lassen sich in die folgenden Kategorien einteilen:

• Hardwareänderungen
• ERSTE API-EBENE: ERFORDERLICHE TESTS
• Beleuchtung getestet
• Änderungen bei Szenennamen
• Änderungen und Ergänzungen testen
• Mehr LIMITED-Kameratests

Hardwareänderungen

In Android 11 wurden mehrere Hardwareänderungen eingeführt, um die Kosten zu senken und die Verfügbarkeit zu erhöhen. Diese Änderungen lassen sich in folgende Kategorien einteilen:

• Zusätzlicher Hersteller
• Einheitliche Fertigungsmethoden
• Mehr Tablet-Optionen
• Reduziertes Öffnen des Tablets
• Neuer Controller für die Sensorfusion

Zusätzlicher Hersteller

Rahi Systems ist neben unserem bestehenden Lieferanten MYWAY Design für die Herstellung von ITS-Testgehäusen qualifiziert. Die Unternehmensinformationen für qualifizierte Anbieter sind wie folgt:

• Rahi Systems Inc.
  48303 Fremont Blvd, Fremont, CA 94538, USA
  rahisystems.com/products/android-device-testing-equipment/
  androidpartner@rahisystems.com
  +1-510-319-3802

• MYWAY-Design
  4. Etage, No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Einheitliche Fertigungsmethoden

Das ITS-in-a-box-Testgehäuse mit normalem Sichtfeld (Regular Field-of-View, RFoV) – Revision 1 wurde neu gestaltet und verwendet nun die Fertigungsmethoden, die auch für die Box mit weitem Sichtfeld (Wide Field-of-View, WFoV)> und das Sensor-Fusion-Testgehäuse verwendet werden. Die Funktionalität ist identisch. Der Einfachheit halber wird das Design als rev1a bezeichnet. Durch die Neugestaltung können Hersteller nur einen Kunststofftyp für die Herstellung aller Testgehäuse vorrätig halten. Außerdem wurden die Tablet-Halterung und die Lichthalterungen neu gestaltet, um eine größere Vielfalt an Tablets und LED-Lichtleisten aufnehmen zu können.

Die neuesten Beschreibungen und mechanischen Zeichnungen finden Sie unter RFoV-Box (Rev. 1a) und WFoV-Box (Rev. 2.9).

Mehr Tablet-Optionen

Die Liste der empfohlenen Tablets wurde um Tablets wie das Samsung Galaxy Tab A 10.1 und das Chuwi Hi9 Air 10.1 erweitert. Das Tablet darf keine Pulsweitenmodulation (PWM) zur Anpassung der Bildschirmhelligkeit haben, damit es nicht zu Streifenbildung auf aufgenommenen Bildern kommt.

Aktuelle Informationen zu empfohlenen Tablets finden Sie unter Tablet-Anforderungen.

Weniger Öffnungen von Tablets

Damit das Galaxy Tab A 10.1 verwendet werden kann, wurde die Höhe der Tablet-Öffnung sowohl für das RFoV- (rev1a) als auch das WFoV-Testgehäuse (rev2) leicht verringert. Die Revisionen, in denen diese Änderungen berücksichtigt werden, sind rev1a.1 und rev2.9. Die entsprechenden Zeichnungen finden Sie unter RFoV-Box (Rev. 1a) und WFoV-Box (Rev. 2.9).

Neuer Sensor-Fusion-Controller

Die Hardware für den Sensor-Fusion-Controller wurde neu gestaltet, um die Fertigung zu verbessern. Der neue Controller basiert auf Arduino und hat ein benutzerdefiniertes Routing-Board-Shield, das auf dem Arduino montiert wird. Abbildung 1 zeigt die Abschirmung und Abbildung 2 die mechanische Zeichnung für das Gehäuse. Der neue Controller wird über eine einzelne 5‑V-Stromversorgung betrieben, die den Motor direkt mit Strom versorgt. Die Elektronik wird vollständig über den USB-Anschluss gesteuert. Die separate Stromversorgung ermöglicht eine vollständige Trennung zwischen der Steuerungselektronik und dem Servomotor. Außerdem kann ein einzelner Controller bis zu sechs Servomotoren steuern.

Abbildung 1: Draufsicht auf ein Arduino-Shield

Abbildung 2: Gehäusedesign

Android 11 ist abwärtskompatibel mit vorhandenen Controllern. So rufen Sie Tests mit dem Arduino-basierten Controller auf:

python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion

Erstes API-Level

In Android 10 werden ITS-Tests als MANDATED und NOT_YET_MANDATED bezeichnet. Wenn Sie ein Gerät mit Android 10 auf den Markt bringen möchten, müssen alle MANDATED-Tests bestanden werden. Die NOT_YET_MANDATED-Tests können fehlschlagen, werden aber für die CTS-Verifier-Berichterstellung als PASS tabellarisch dargestellt. Die Anforderung für MANDATED-Tests gilt auch für Geräte, die aktualisiert wurden. Diese Anforderung, dass aktualisierte Geräte alle MANDATED-Tests bestehen müssen, führte dazu, dass Tests erst später zu MANDATED-Tests wurden, da auch ältere Geräte die Tests bestehen müssen.

In Android 11 werden MANDATED-Tests durch das erste API-Level-Flag aus den Smartphone-Eigenschaften eingeschränkt. Bei Geräten, die auf Android 11 aktualisiert werden, werden Tests als NOT_YET_MANDATED-Tests ausgeführt. Das bedeutet, dass ein Test fehlschlagen, aber in CtsVerifier.apk als PASS aufgeführt werden kann.

Beispiel:

• In Android 11 ist der test_channel_saturation-Test MANDATED für Geräte mit einem ersten API-Level über 29.
• In Android 10 ist der test_channel_saturation-Test für alle Geräte MANDATED.

Szenenbeleuchtung validieren

In Android 11 wird die Beleuchtung der Szene durch Analyse der Helligkeit in den Ecken der Szene validiert. Alle manuellen Szenen werden auf die Beleuchtung hin validiert. Tablet-basierte Szenen werden für RFoV-Kameras im RFoV-Prüfstand und für WFoV-Kameras im WFoV-Prüfstand validiert. Wenn die Beleuchtung nicht ausreicht, wird ein Fehler gemeldet und der Test schlägt fehl.

Änderungen an Szenennamen

In Android 10 macht Szene 1 den Großteil der Tests und einen großen Prozentsatz der gesamten Testzeit aus. Wenn ein Test in Szene 1 fehlschlägt, muss die gesamte Szene noch einmal ausgeführt werden. Wenn die gesamte Szene noch einmal ausgeführt wird, werden weniger Grenztests bestanden. In Android 11 werden die Wiederholungszeiten reduziert, indem Szene 1 in zwei Szenen aufgeteilt wird: scene1_1 und scene1_2.

In der folgenden Tabelle sind die Testzeiten für die Rückkamera des Pixel 4 für verschiedene Szenen aufgeführt. Die Anzahl der Tests wird aufgeteilt, um die Testzeit auszugleichen, nicht die Anzahl der Tests.

Außerdem werden Namen bereinigt. Szene 2 ist mit Buchstaben unterteilt, Szene 1 mit Zahlen. Die Nomenklatur für die verschiedenen Erweiterungen lautet:

• Szenen mit demselben Diagramm, aber unterschiedlichen Tests: *_1,2,3
• Szenen mit unterschiedlichen Diagrammen, aber denselben Tests: *_a,b,c

Änderungen testen

Tests wurden aktualisiert, um das erste API-Level zu verwenden

In Android 11 werden die Tests in der folgenden Tabelle aktualisiert, um das erste API-Level-Flag zu verwenden. Bei allen diesen Tests wird als erster API-Level 29 verwendet, mit Ausnahme des test_tonemap_curve-Tests, bei dem als erster API-Level 30 verwendet wird.

Tests mit Änderungen

Die Tests in der folgenden Tabelle wurden in Android 11 aktualisiert. Die Änderungen werden in der Spalte Beschreibung der Änderungen beschrieben.

Neue Tests

Die Tests in der folgenden Tabelle sind in Android 11 aktiviert. Die Tests sind in der Tabelle zusammengefasst und in den folgenden Abschnitten detailliert beschrieben.

scene0/test_vibration_restriction

Für diesen Test ist keine bestimmte Szene erforderlich, das zu prüfende Gerät muss jedoch auf einer harten Oberfläche platziert oder an einer harten Oberfläche befestigt werden. Dazu gehört auch die Montage in den ITS-in-a-box-Testgehäusen.

Asserts

• Keine Vibrationen bei Verwendung der Kamera

scene2_a/test_jpeg_quality

Methode

Verschiedene Teile der JPEG-Datei werden durch 2‑Byte-Markierungen definiert. Weitere Informationen finden Sie unter JPEG.

Beim Test werden die Quantisierungsmatrizen aus der JPEG-Aufnahme extrahiert. Die Markierung für die Quantisierungsmatrizen in der JPEG-Aufnahme ist die Sequenz [255, 219]. Wenn die Markierung gefunden wird, sind die nächsten beiden Listenelemente die Größe. Die JPEG-DQT-Größenmarkierung ist normalerweise [0, 132] = 256*0+132 = 132, was der Größe der DQT-Daten im JPEG-Bild entspricht. Die eingebetteten Daten haben das folgende Format: [255, 219, 0, 132, 0 (Luminanzmarkierung), 8x8-Luminanzmatrix, 1 (Chrominanzmarkierung), 8x8-Chrominanzmatrix].

Die 0 für die Luma-Matrix-Markierung und die 1 für die Chroma-Markierung sind für eine Reihe von Geräten, einschließlich Smartphones, die die beiden Matrizen in separate DQT-Abschnitte in der JPEG-Datei aufteilen, konsistent. Luma-Matrizen haben in der Regel eine größere Vielfalt an Werten als Chroma-Matrizen, da das menschliche Auge empfindlicher auf Luma als auf Chroma reagiert. JPEG-Bilder berücksichtigen dies.

Unten sehen Sie Beispiele für extrahierte Luma- und Chroma-Matrizen für die Qualitätsfaktoren 85 und 25 für die Rückkamera des Pixel 4, mit der Szene2_a mit dem ITS-Prüfstand aufgenommen wurde. Die Matrixwerte steigen (was auf eine stärkere Komprimierung hindeutet) bei der Einstellung für niedrige Qualität erheblich an. Diese Matrizen werden nur mit dem Skript ausgegeben, wenn das Flag debug=True angewendet wird. Beachten Sie die größere Variation bei den Einträgen in den Luma-Matrixen im Vergleich zu den Chroma-Matrixen.

    luma matrix (quality = 85)    chroma matrix (quality = 85)

    [[ 5  3  4  4  4  3  5  4]    [[ 5  5  5  7  6  7 14  8]
     [ 4  4  5  5  5  6  7 12]     [ 8 14 30 20 17 20 30 30]
     [ 8  7  7  7  7 15 11 11]     [30 30 30 30 30 30 30 30]
     [ 9 12 17 15 18 18 17 15]     [30 30 30 30 30 30 30 30]
     [17 17 19 22 28 23 19 20]     [30 30 30 30 30 30 30 30]
     [26 21 17 17 24 33 24 26]     [30 30 30 30 30 30 30 30]
     [29 29 31 31 31 19 23 34]     [30 30 30 30 30 30 30 30]
     [36 34 30 36 28 30 31 30]]     [30 30 30 30 30 30 30 30]]

    luma matrix (quality = 25)            chroma matrix (quality = 25)

    [[ 32  22  24  28  24  20  32  28]    [[ 34  36  36  48  42  48  94  52]
     [ 26  28  36  34  32  38  48  80]     [ 52  94 198 132 112 132 198 198]
     [ 52  48  44  44  48  98  70  74]     [198 198 198 198 198 198 198 198]
     [ 58  80 116 102 122 120 114 102]     [198 198 198 198 198 198 198 198]
     [112 110 128 144 184 156 128 136]     [198 198 198 198 198 198 198 198]
     [174 138 110 112 160 218 162 174]     [198 198 198 198 198 198 198 198]
     [190 196 206 208 206 124 154 226]     [198 198 198 198 198 198 198 198]
     [242 224 200 240 184 202 206 198]]     [198 198 198 198 198 198 198 198]]

Abbildung 3 zeigt die durchschnittlichen Matrixwerte für die Rückkamera des Pixel 4 im Vergleich zur JPEG-Qualität. Mit zunehmender JPEG-Qualität sinkt der Grad der Komprimierung (Durchschnitt der Luma-/Chroma-DQT-Matrix).

Abbildung 3: Durchschnittliche Luma-/Chroma-DQT-Matrix der Pixel 4-Rückkamera im Vergleich zur JPEG-Qualität

Asserts

• Bei [25, 45, 65, 86] führt eine Steigerung der Qualität um 20 zu einer durchschnittlichen Reduzierung der Quantisierungsmatrix um 20 %.
• DQT-Matrix-Nutzlasten sind Quadratzahlen.

Abbildung 4 zeigt ein Beispiel für ein Smartphone, das den Test nicht besteht. Bei Bildern mit sehr niedriger Qualität (jpeg.quality < 50) wird die Komprimierung in der Quantisierungsmatrix nicht erhöht.

Abbildung 4: Beispiel für fehlgeschlagenen Test

scene2_d/e test_num_faces

Es wurden zwei neue Szenen für die Gesichtserkennung hinzugefügt, um die Vielfalt der Gesichter bei den Prüfungen des Gesichtserkennungsalgorithmus zu erhöhen. Bei wiederholten Tests einer Reihe von Kameras wird erwartet, dass das schwierigste Gesicht das ganz links in scene2_d ist. Das Modell trägt sowohl einen Hut als auch einen Bart, was in den Gesichtsszenen neu ist. Die neuen Szenen sind in Abbildung 5 und 6 zu sehen.

Abbildung 5. scene2_d

Abbildung 6. scene2_e

Asserts

• num_faces == 3

scene2_e/test_continuous_picture

Methode

Beim test_continuous_picture-Test wird „scene2_e“ verwendet. Er kann aber mit jeder der Gesichterszenen aktiviert werden. Bei diesem Test werden 50 Frames mit VGA-Auflösung aufgenommen. In der Aufnahmeanfrage wird zuerst android.control.afMode = 4 (CONTINUOUS_PICTURE) festgelegt.

Das 3A-System sollte sich am Ende einer Aufnahme mit 50 Frames stabilisiert haben.

Asserts

• 3A befindet sich am Ende der Aufnahme im konvergierten Zustand.

scene_change/test_scene_change

Methode

Es wurde ein neuer Test aktiviert, um zu prüfen, ob das Flag android.control.afSceneChange bei einem Szenenwechsel gesetzt wird. Beim Szenenwechsel wird auf dem Tablet ein Gesicht angezeigt. Dann wird das Tablet ein- und ausgeschaltet, um einen Szenenwechsel zu erzeugen. In dieser Szene wird „scene2_e“ wiederverwendet, sie ist aber eine separate Szene, da die Steuerung über das Tablet erforderlich ist.

Bei manuellen Tests kann der Szenenwechsel auch durch Winken mit der Hand vor der Kamera erfolgen.

Abbildung 7 zeigt ein Zeitdiagramm des Tests. Das Timing zwischen dem Ausschalten des Displays und der Aufnahme wird anhand der Ereignisergebnisse aus früheren Aufnahmen angepasst.

Abbildung 7. Zeitablaufdiagramm für test_scene_change

Bedingungen für Schichtarbeit:

• Wenn es einen Szenenwechsel gibt und afSceneChange == 1, gibt der Test PASS zurück.
• Wenn es einen Szenenwechsel und afSceneChange == 0 gibt, wird der Szenenwechsel um 5 Frames nach vorn verschoben, damit afSceneChange mehr Zeit hat, sich zu behaupten.
• Wenn es keine Szenenänderung und afSceneChange == 1 gibt, wird FAIL zurückgegeben.
• Wenn es keinen Szenenwechsel und afSceneChange == 0 gibt, wird der Szenenwechsel um 30 Frames nach vorn verschoben, um ihn zu erfassen.

Asserts

• Bildschirm- (Szenen-)Umschaltungen.
• Das Flag afSceneChange liegt im Bereich [0, 1].
• Wenn keine Szenenänderung erfolgt, konvergiert 3A (funktional identisch mit test_continuous_picture).
• Wenn afSceneChange == 1, muss sich die Helligkeit in der Szene ändern.
• PASS innerhalb von sechs Versuchen, wobei das Timing auf Grundlage der vorherigen Ergebnisse geändert wurde.

scene6/test_zoom

Methode

Für den Test von android.control.zoomRatioRange ist eine neue Szene erforderlich, da die vorhandenen Szenen entweder kein kleines genuges Feature zum Vergrößern haben (Szenen 1, 2 und 4) oder die Szene viele Objekte enthält, die nicht leicht zu identifizieren sind, was die Feature-Extraktion erschwert (Szene 3).

Abbildung 8 zeigt die neue Szene mit einer regelmäßigen Anordnung von Kreisen. Durch die Anordnung der Kreise werden die Anforderungen an die Zentrierung des DUT/Charts gelockert. So befindet sich immer ein Kreis in der Nähe der Mitte des aufgenommenen Bilds. In dieser Szene bedeckt ein Array aus 9 × 5 Kreisen mit schwarzem Rahmen das gesamte Tablet. Ein Kreis wird durch ein Quadrat in der oberen rechten Ecke ersetzt, um die Ausrichtung anzuzeigen. Die Kreise haben eine Fläche von etwa 7.500 Pixeln (radius=50pixels) für einen 4.000 × 3.000-Sensor, der mit einem Sichtfeld von etwa 80 Grad aufgenommen wurde.

Abbildung 8: test_zoom-Szene

Abbildung 9. Pixel 4-Kamera[0] – Zoom = [1, 3.33, 5.67, 8] – Bilder mit gefundenem Kreis

Abbildung 9 zeigt Aufnahmen der Rückkamera eines Pixel 4, bei denen der Zoom in vier Schritten von 1‑fach auf 8‑fach erhöht wird. Diese Bilder wurden ohne besondere Sorgfalt beim Zentrieren aufgenommen. Es wurde lediglich die Blende des Testgeräts mit zwei Öffnungen verwendet, um sowohl die Front- als auch die Rückkamera testen zu können. Eine Abweichung von der Mitte ist zu erwarten und wird auch beobachtet, da das Diagramm-Tablet leicht links von der Mitte positioniert ist. Außerdem scheint das Diagramm ausreichend zu sein, um Zoomfaktoren über 8‑fach zu testen.

Kreise finden

Der Test umfasst eine find_circle()-Methode mit findContours, die alle Konturen findet und die Kontursuche auf die gewünschten Kreise eingrenzt, indem Folgendes getestet wird:

• Konturen müssen eine Fläche von mehr als 10 Pixeln haben.
• Konturen müssen NUM_PTS >= 15 haben.
• Konturen müssen schwarze Mittelpunkte haben.
• Konturen müssen einem Kreis ähneln, d. h., ihre Fläche muss nahe an der Fläche der Kontur von pi*r2 liegen.

Testbereich

android.control.zoomRatioRange ist in 10 Schritte unterteilt.

• [1, 7] – Tests [1, 1.67, 2.33, 3, 3.67, 4.33, 5, 5.67, 6.33, 7]

Das Zoomen wird beendet, wenn der gefundene Kreis die Grenzen des Bildes berührt. Im Test wird geprüft, ob eine ausreichende Zoomstufe (10-fach) erreicht wird.

Asserts

• Bei jeder Zoomstufe ist mindestens ein Kreis zu sehen.
• Das 10-Fache oder maximal android.control.zoomRatioRange wird getestet.
• Der Kreisradius wird mit dem Zoom skaliert (RTOL 10% vom erwarteten Wert).
• Die Abweichung des Kreismittelpunkts vom Mittelpunkt skaliert mit dem Zoom (RTOL 10% vom erwarteten Wert).
• Die Zoomstufe ist ausreichend (2‑fach).

Mehr Tests mit eingeschränkter Kamera

In Android 11 werden mit den Tests in der folgenden Tabelle LIMITED-Kameras getestet. Zusätzlich zu den neuen Tests wurde der scene4/test_aspect_ratio_and_crop-Test aktualisiert, um das Testen von LIMITED-Geräten mit einem ersten API-Level von 30 oder höher zu ermöglichen.

Abbildung 10 zeigt den geheimen Decoderring für die ITS-Tests unter Android 11. Der Secret Decoder Ring zeigt, welche Testeinstellungen für die einzelnen Tests erforderlich sind. Die Gating-Informationen sind zur besseren Übersicht farblich codiert. Die wichtigsten Voraussetzungen sind:

• MANUAL_SENSOR
• READ_3A *erfordert MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *erfordert MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS *REALTIME
• MULTI_CAMERA

MANUAL SENSOR, READ_3A, COMPUTE_TARGET_EXPOSURES und PER_FRAME_CONTROL sind die meisten Tests. Außerdem werden Tests, die für LIMITED-Geräte aktiviert sind, hellgrün hervorgehoben.

Abbildung 10. Android 11: Geheime Decoder-App