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/
androidpartner@rahisystems.com
+1-510-319-3802MYWAY-Design
4F., Nr. 163, Fu-Ying Road, Bezirk XinZhuang, New Taipei City, Taiwan
twmyway.com
sales@myway.tw
+886-2-29089060
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 29MANDATED
. - In Android 10 ist der
test_channel_saturation
-Test für alle GeräteMANDATED
.
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 TestPASS
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 AktivierungafSceneChange
zu geben. - Wenn es keinen Szenenwechsel gibt und
afSceneChange == 1
ist, gibt der TestFAIL
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
*erfordertMANUAL SENSOR
-
COMPUTE_TARGET_EXPOSURES
*erfordertMANUAL 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