Versionshinweise zur 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 fallen in die folgenden Kategorien:

• Hardwareänderungen
• Erste obligatorische API-Level-Tests
• Testbeleuchtung validiert
• Szenennamen ändern sich
• Testen Sie Änderungen und Ergänzungen
• Erhöhte BEGRENZTE Kameratests

Hardwareänderungen

Android 11 führt mehrere Hardwareänderungen ein, um die Kosten zu senken und die Verfügbarkeit zu erhöhen. Diese Änderungen fallen in die folgenden Kategorien:

• Zusätzlicher Hersteller
• Einheitliche Herstellungsmethoden
• Erweiterte Tablet-Optionen
• Reduzierte Tablet-Öffnung
• Neuer Sensorfusionscontroller

Zusätzlicher Hersteller

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

• Rahi Systems Inc.
  48303 Fremont Blvd, Fremont CA 94538, USA
  rahisystems.com/products/android-device-testing-equipment/
  [e-mail]
  [phone]

• MYWAY-Design
  4F., Nr. 163, Fu-Ying Road, Bezirk XinZhuang, New Taipei City, Taiwan
  twmyway.com
  [e-mail]
  [phone]

Einheitliche Herstellungsmethoden

Das ITS-in-a-Box-Testgehäuse rev1 mit regulärem Sichtfeld (RFoV) wurde neu gestaltet, um die Herstellungsmethoden zu nutzen, die bei den Testgehäusen für Boxen mit weitem Sichtfeld (WFoV) und Sensor-Fusion-Boxen verwendet werden. Die Funktionalität ist identisch und der Einfachheit halber wird das Design als rev1a bezeichnet. Die Neugestaltung ermöglicht es den Herstellern, für die Herstellung aller Prüfgehäuse eine einzige Kunststoffsorte auf Lager zu haben. Darüber hinaus wurden die Tablet-Halterung und die Lichthalter neu gestaltet, um eine größere Vielfalt an Tablets und LED-Lichtleisten zu ermöglichen.

Um die neuesten Beschreibungen und mechanischen Zeichnungen herunterzuladen, siehe RFoV-Box (Rev. 1a) und WFoV-Box (Rev. 2.9) .

Erweiterte Tablet-Optionen

Tablets, darunter das Samsung Galaxy Tab A 10.1 und das Chuwi Hi9 Air 10.1, werden zur Liste der empfohlenen Tablets hinzugefügt. Es ist wichtig, dass das Tablet nicht über Pulsweitenmodulation (PWM) zur Anpassung der Bildschirmhelligkeit verfügt, um Streifenbildung in aufgenommenen Bildern zu vermeiden.

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

Reduzierte Tablet-Öffnung

Um die Verwendung des Galaxy Tab A 10.1 zu ermöglichen, ist die Höhe der Tablet-Öffnung sowohl bei den Testgehäusen RFoV (rev1a) als auch WFoV (rev2) leicht verringert. Die Revisionen, die diese Änderungen widerspiegeln, sind rev1a.1 und rev2.9. Diese Zeichnungen finden Sie unter RFoV-Box (Rev. 1a) und WFOV-Box (Rev. 2.9) .

Neuer Sensorfusionscontroller

Die Hardware für den Sensorfusionscontroller wurde neu gestaltet, um die Herstellbarkeit zu verbessern. Der neue Controller basiert auf Arduino und verfügt über eine spezielle Routing-Board- Abschirmung , die auf dem Arduino montiert wird. Abbildung 1 zeigt die Abschirmung und Abbildung 2 zeigt die mechanische Zeichnung für das Gehäuse. Der neue Controller wird von einer einzelnen 5-V-Versorgung gespeist, die den Motor direkt mit Strom versorgt. Die Steuerung der Elektronik erfolgt komplett über den USB-Anschluss. Die separate Stromversorgung ermöglicht eine vollständige Trennung zwischen der Steuerelektronik und dem Servomotor. Darüber hinaus kann ein einzelner Controller bis zu sechs Servomotoren steuern.

Abbildung 1. Draufsicht auf das Arduino-Schild

Abbildung 2. Gehäusedesign

Android 11 ist abwärtskompatibel mit vorhandenen Controllern. Um Tests mit dem Arduino-basierten Controller aufzurufen, verwenden Sie:

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

Erste API-Ebene

In Android 10 werden ITS-Tests als MANDATED und NOT_YET_MANDATED bezeichnet. Um als Android 10-Gerät zu starten, müssen alle MANDATED Tests bestanden werden. Die NOT_YET_MANDATED Tests können fehlschlagen, werden aber für die CTS-Verifizierer-Berichterstellung als PASS aufgeführt. Die Pflicht MANDATED Tests gilt auch für aufgerüstete Geräte. Diese Anforderung, dass aktualisierte Geräte alle MANDATED Tests bestehen müssen, führte dazu, dass sich Tests verzögerten, bis sie zu MANDATED Tests wurden, da auch ältere Geräte die Tests bestehen müssen.

In Android 11 werden MANDATED Tests durch das Flag der ersten API-Ebene in den Telefoneigenschaften gesteuert. Bei Geräten, die auf Android 11 aktualisiert werden, werden Tests als NOT_YET_MANDATED Tests ausgeführt, was bedeutet, dass ein Test fehlschlagen kann, aber in CtsVerifier.apk als PASS aufgeführt wird.

Zum Beispiel:

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

Validierung der Szenenbeleuchtung

In Android 11 wird die Szenenbeleuchtung durch Analyse der Helligkeit in den Ecken der Szene validiert. Alle manuellen Szenen werden hinsichtlich der Beleuchtung validiert, und Tablet-basierte Szenen werden für RFoV-Kameras im RFoV-Teststand und WFOV-Kameras im WFoV-Teststand validiert. Bei unzureichender Beleuchtung wird ein Fehler gemeldet und der Test schlägt fehl.

Szenennamen ändern sich

In Android 10 macht Szene 1 den Großteil der Tests und einen großen Prozentsatz der gesamten Testzeit aus. Wenn ein Test innerhalb von Szene 1 fehlschlägt, muss die gesamte Szene erneut ausgeführt werden. Das erneute Ausführen der gesamten Szene verringert konstruktionsbedingt das Durchlaufen marginaler Tests. In Android 11 werden die Wiederholungszeiten reduziert, indem Szene 1 in zwei Szenen aufgeteilt wird, Szene1_1 und Szene1_2.

Die folgende Tabelle zeigt die tabellarischen Testzeiten für die Rückfahrkamera des Pixel 4 für verschiedene Szenen. Die Anzahl der Tests wird aufgeteilt, um die Testzeit auszugleichen, nicht um die Anzahl der Tests anzugleichen.

Zusätzlich gibt es eine Namensbereinigung. Szene 2 ist durch Buchstaben und Szene 1 durch Zahlen unterteilt. Die Nomenklatur für die verschiedenen Erweiterungen lautet:

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

Szene	Anzahl der Tests	Pixel 4-Laufzeit (Min.:Sek.)
0	11	1:12
1_1	22	5:12
1_2	13	5:20
2_a	5	3:22
2_b	1	0:24
2_c	1	0:24
3	6	2:04
4	2	2:46

Testen Sie Änderungen

Tests wurden aktualisiert, um die erste API-Ebene zu verwenden

In Android 11 werden die Tests in der folgenden Tabelle aktualisiert, um das Flag der ersten API-Ebene zu verwenden. Alle diese Tests verwenden eine erste API-Ebene von 29, mit Ausnahme des test_tonemap_curve Tests, der eine erste API-Ebene von 30 verwendet.

Szene	Testname	Erste API-Ebene	Beschreibung
0	test_tonemap_curve	30	Stellen Sie sicher, dass die Pipeline über korrekte Farbausgaben mit linearer Tonemap und idealer Bildeingabe verfügt (basiert auf test_test_patterns ).
1	test_ae_precapture_trigger	29	Testen Sie die AE-Zustandsmaschine, wenn Sie den Precapture-Trigger verwenden. Stellen Sie sicher, dass der Precapture-Trigger bei deaktivierter AE keine Wirkung hat.
	test_channel_saturation	29	Stellen Sie sicher, dass die Sättigung der RGB-Kanäle ähnliche Werte aufweist, um Farbtöne in gesättigten Bereichen zu beseitigen.
2_a/b/c	test_num_faces	29	Erhöhen Sie die Altersvielfalt in Gesichtsszenen.

Tests mit Änderungen

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

Szene	Testname	Erste API-Ebene	Beschreibung der Änderungen
1	test_burst_sameness_manual	30	Toleranz auf 2 % reduzieren.
4	test_aspect_ratio_and_crop	30	Zur Ausführung auf LIMITED-Geräten ändern.
	test_multi_camera_alignment	30	Gehen Sie die Kameras einzeln durch, wenn die Aufnahme mit mehreren Kameras nicht unterstützt wird. Überarbeiten Sie die Kameraauswahllogik, um Systeme mit drei und vier Kameras zu berücksichtigen, und überspringen Sie Mono-, Nur-Tiefen- und IR-Kameras.

Neue Tests

Die Tests in der folgenden Tabelle sind in Android 11 aktiviert. Die Tests sind in der Tabelle zusammengefasst und detaillierte Beschreibungen finden Sie in den folgenden Abschnitten.

Szene	Testname	Erste API-Ebene	Beschreibung
0	test_vibration_restrictions	30	Stellen Sie sicher, dass während der Bildaufnahme keine Warnungen und Vibrationen aktiviert sind.
2_a	test_jpeg_quality	30	Testen Sie, dass Quantisierungstabellen die Komprimierung verringern, um die JPEG-Qualität zu verbessern.
2_d/2_e	test_num_faces	30	Erhöhen Sie die Altersvielfalt im Gesicht.
2_e	test_continuous_picture	30	Stellen Sie sicher, dass sich 3A in android.control.afAvailableModes = CONTINUOUS_PICTURE.
ändern	test_scene_change	31	android.control.afSceneChange wird bei Szenenwechsel aktiviert.
6	test_zoom	30	Testen Sie android.control.zoomRatioRange .

scene0/test_vibration_restriction

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

Behauptet

• Keine Vibrationen während der Kameranutzung

scene2_a/test_jpeg_quality

Methode

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

Der Test extrahiert die Quantisierungsmatrizen aus der JPEG-Aufnahme. Der Marker für die Quantisierungsmatrizen in der JPEG-Erfassung ist die Sequenz [255, 219]. Wenn die Markierung gefunden wird, geben die nächsten beiden Listenelemente die Größe an. Die JPEG-DQT-Größenmarkierung ist normalerweise [0, 132] = 256*0+132 = 132, was die Größe der DQT-Daten in der JPEG-Erfassung berücksichtigt. Die eingebetteten Daten haben die Form: [255, 219, 0, 132, 0 (Luma-Marker), 8x8-Luma-Matrix, 1 (Chroma-Marker), 8x8-Chroma-Matrix].

Die 0 für den Luma-Matrix-Marker und 1 für den Chroma-Marker scheint für eine Reihe von Geräten konsistent zu sein, einschließlich Telefonen, die die beiden Matrizen in separate DQT-Abschnitte in der JPEG-Datei aufteilen. Luma-Matrizen weisen im Vergleich zu Chroma-Matrizen tendenziell eine größere Wertevielfalt auf, da das menschliche Auge empfindlicher auf Luma als auf Chroma reagiert und JPEG-Bilder dies berücksichtigen.

Nachfolgend werden Beispiele für extrahierte Luma- und Chroma-Matrizen für Qualitätsfaktoren von 85 und 25 für die Rückfahrkamera des Pixel 4 angezeigt, die Szene 2_a mit dem ITS-Prüfstand aufnimmt. Die Matrixwerte steigen bei der niedrigeren Qualitätseinstellung erheblich an (was auf eine erhöhte Komprimierung hinweist). Diese Matrizen werden mit dem Skript nur gedruckt, wenn das Flag debug=True angewendet wird. Beachten Sie die größere Variation der Einträge in den Luma-Matrizen im Vergleich zu den Chroma-Matrizen.

    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 nimmt der Grad der Komprimierung (Luma/Chroma-DQT-Matrix-Durchschnitt) ab.

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

Behauptet

• Für [25, 45, 65, 86] hat eine Qualität von +20 eine Reduzierung der Quantisierungsmatrixdurchschnitte um 20 %.
• Die Nutzlasten der DQT-Matrix sind Quadratzahlen.

Abbildung 4 zeigt ein Beispiel für ein Telefon, das den Test nicht besteht. Beachten Sie, dass es bei Bildern mit sehr geringer Qualität ( jpeg.quality < 50 ) zu keiner Erhöhung der Komprimierung in der Quantisierungsmatrix kommt.

Abbildung 4. Beispiel für einen fehlgeschlagenen Test

scene2_d/e test_num_faces

Es wurden zwei neue Gesichtserkennungsszenen hinzugefügt, um die Gesichtsvielfalt der Gesichtserkennungsalgorithmusprüfungen zu erhöhen. Bei wiederholten Tests mehrerer Kameras wird erwartet, dass das anspruchsvollste Gesicht das Gesicht ganz links in Szene2_d ist. Insbesondere trägt das Model sowohl einen Hut als auch einen Bart, etwas Neues in den Gesichtsszenen. Die neuen Szenen sind in Abbildung 5 und 6 dargestellt.

Abbildung 5. scene2_d

Abbildung 6. scene2_e

Behauptet

• num_faces == 3

scene2_e/test_continuous_picture

Methode

Der test_continuous_picture Test nutzt scene2_e, kann aber mit jeder Gesichtsszene aktiviert werden. In diesem Test werden 50 Bilder mit VGA-Auflösung erfasst, wobei die Aufnahmeanforderung zunächst auf android.control.afMode = 4 (CONTINUOUS_PICTURE) gesetzt ist.

Es wird erwartet, dass sich das 3A-System am Ende einer 50-Frame-Aufnahme eingependelt hat.

Behauptet

• 3A befindet sich am Ende der Erfassung im konvergenten Zustand.

scene_change/test_scene_change

Methode

Ein neuer Test wird aktiviert, um zu testen, ob das android.control.afSceneChange Flag bei einem Szenenwechsel aktiviert wird. Beim Szenenwechsel wird auf dem Tablet eine Gesichtsszene angezeigt und dann das Tablet ein- und ausgeschaltet, um einen Szenenwechsel zu erzeugen. Die Szene verwendet scene2_e wieder, befindet sich jedoch aufgrund der erforderlichen Tablet-Steuerung in einer separaten Szene.

Für manuelle Tests kann der Szenenwechsel außerdem durch eine Handbewegung vor der Kamera erfolgen.

Abbildung 7 zeigt ein Zeitdiagramm des Tests. Der Zeitpunkt zwischen dem Ausschalten des Bildschirms und der Aufnahme wird basierend auf den Ereignisergebnissen früherer Aufnahmen angepasst.

Abbildung 7. Zeitdiagramm für test_scene_change

Schichtbedingungen:

• Wenn es einen Szenenwechsel gibt und afSceneChange == 1 ist, gibt der Test PASS zurück.
• Wenn es einen Szenenwechsel gibt und afSceneChange == 0 ist, verschiebt sich der Szenenwechsel um 5 Frames früher, um mehr Zeit für die Aktivierung afSceneChange zu geben.
• Wenn es keinen Szenenwechsel gibt und afSceneChange == 1 ist, gibt der Test FAIL zurück.
• Wenn es keinen Szenenwechsel gibt und afSceneChange == 0 ist, verschiebt sich der Szenenwechsel 30 Bilder früher, um den Szenenwechsel bei der Aufnahme zu erhalten.

Behauptet

• Bildschirm (Szene) schaltet um.
• Das afSceneChange Flag befindet sich in [0, 1].
• Wenn sich die Szene nicht ändert, konvergiert 3A (funktionell identisch mit test_continuous_picture ).
• Wenn afSceneChange == 1 , muss sich die Helligkeit in der Szene ändern.
• PASS innerhalb von sechs Versuchen, wobei das Timing basierend auf früheren Ergebnissen geändert wurde.

scene6/test_zoom

Methode

Zum Testen android.control.zoomRatioRange ist eine neue Szene erforderlich, da die etablierten Szenen entweder kein Feature aufweisen, das klein genug ist, um vergrößert zu werden (Szenen [1, 2, 4]) oder die Szene viele Objekte enthält, die nicht leicht identifiziert werden können , was die Merkmalsextraktion erschwert (Szene 3).

Abbildung 8 zeigt die neue Szene mit einer regelmäßigen Anordnung von Kreisen. Die Anordnung der Kreise lockert die Anforderungen an die Zentrierung des Prüflings/Diagramms und ermöglicht einen Kreis, der sich immer in der Nähe der Mitte des aufgenommenen Bildes befindet. In dieser Szene bedeckt eine Reihe von 9 x 5 Kreisen mit schwarzem Rand das gesamte Tablet. Ein Kreis wird durch ein Quadrat in der oberen rechten Ecke ersetzt, um die Ausrichtung anzuzeigen. Die Kreisgrößen haben ein Merkmal mit einer Fläche von etwa 7500 Pixeln ( radius=50pixels ) für einen 4000 x 3000-Sensor, der mit einem Sichtfeld (FoV) 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 aufgenommene Bilder für die Rückkamera eines Pixel 4, während der Zoom in vier Schritten von 1 auf 8x erhöht wird. Dieser Satz von Bildern wird ohne besondere Sorgfalt bei der Zentrierung aufgenommen, außer dass die Telefontestöffnung mit zwei Öffnungen verwendet wird, um das Testen sowohl der Vorder- als auch der Rückkamera zu ermöglichen. Ein Versatz von der Mitte ist zu erwarten und wird beobachtet, wenn sich das Kartentablett leicht links von der Mitte befindet. Darüber hinaus scheint das Diagramm für Tests mit Zoomverhältnissen über 8x ausreichend zu sein.

Kreise finden

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

• Konturen müssen eine Fläche größer als 10 Pixel haben.
• Konturen müssen NUM_PTS >= 15 haben.
• Konturen müssen schwarze Zentren haben.
• Konturen müssen einem Kreis ähneln, d. h. ihre Fläche liegt nahe an der pi*r2-Fläche der Kontur.

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 angehalten, wenn der gefundene Kreis die Bildränder berührt. Im Test wird überprüft, ob eine ausreichende Zoomstufe erreicht wird (10x).

Behauptet

• Bei jeder Zoomeinstellung wird mindestens ein Kreis gefunden.
• 10x oder maximal von android.control.zoomRatioRange wird getestet.
• Der Kreisradius skaliert mit Zoom (RTOL 10 % vom erwarteten Wert).
• Versatz des Kreismittelpunkts vom Mittelpunkt skaliert mit Zoom (RTOL 10 % vom erwarteten Wert).
• Ausreichende Zoomstufe ist erreicht (2x).

Erhöhte BEGRENZTE Kameratests

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

Szene	Testname
0	test_vibration_restrictions
2_a	test_jpeg_quality
2_d/2_e	test_num_faces
4	test_aspect_ratio_and_crop
6	test_zoom

Abbildung 10 zeigt den geheimen Decoderring von Android 11 ITS. Der geheime Decoderring zeigt an, durch welche Testeinstellungen einzelne Tests gesteuert werden. Zur Vereinfachung der Betrachtung ist der Anschnitt farblich gekennzeichnet. Die wichtigsten Gating-Elemente 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 steuern die meisten Tests. Darüber hinaus werden Tests, die für LIMITED Geräte aktiviert sind, hellgrün hervorgehoben.

Abbildung 10. Geheimer Decoderring für Android 11