Versionshinweise für die Android 11 Camera Image Test Suite

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 ERFORDERLICHE TESTS AUF API-Ebene
• Testbeleuchtung validiert
• Änderung des Szenennamens
• Änderungen und Ergänzungen testen
• Erhöhte Anzahl der BESCHRÄNKTEN 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 Fertigungsmethoden
• Mehr Tabletoptionen
• Reduzierte Tabletöffnung
• Neuer Sensorfusionscontroller

Zusätzlicher Hersteller

Rahi Systems ist neben unserem bestehenden Lieferanten MYWAY Design qualifiziert, ITS-Testgehäuse herzustellen. Die Informationen zum Unternehmen für qualifizierte Anbieter sind:

• 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
  4F., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Einheitliche Fertigungsverfahren

Das Testgehäuse für das ITS-in-a-Box mit normalem Sichtfeld (RFoV) der Version 1 wurde neu gestaltet, um die Herstellungsmethoden zu verwenden, die für die Testgehäuse des Box mit Weitwinkel (WFoV) und des Box mit Sensorfusion verwendet werden. Die Funktionalität ist identisch und aus Gründen der Einfachheit wird das Design als rev1a bezeichnet. Durch das neue Design können Hersteller einen einzigen Kunststofftyp für die Herstellung aller Testgehäuse lagern. Außerdem wurden die Tablethalterung und die Halterungen für die LED-Leisten neu gestaltet, um eine größere Vielfalt an Tablets und LED-Leisten zu ermöglichen.

Die neuesten Beschreibungen und mechanischen Zeichnungen finden Sie unter RFoV-Box (Rev1a) und WFoV-Box (Rev2.9).

Mehr Tabletoptionen

Tablets wie das Samsung Galaxy Tab A 10.1 und das Chuwi Hi9 Air 10.1 wurden der Liste der empfohlenen Tablets hinzugefügt. Das Tablet darf keine Pulsweitenmodulation (PWM) zur Einstellung der Bildschirmhelligkeit haben, um Streifen in aufgenommenen Bildern zu vermeiden.

Aktuelle Informationen zu empfohlenen Tablets finden Sie unter Anforderungen an Tablets.

Verringerte Tabletöffnung

Damit das Galaxy Tab A 10.1 verwendet werden kann, ist die Öffnung für das Tablet sowohl im RFoV-Testgehäuse (Rev. 1a) als auch im WFoV-Testgehäuse (Rev. 2) etwas niedriger. Die Änderungen sind in den Versionen rev1a.1 und rev2.9 enthalten. Diese Zeichnungen finden Sie unter RFoV-Box (Rev1a) und WFoV-Box (Rev2.9).

Neuer Sensorfusionscontroller

Die Hardware für die Sensorfusionssteuerung wurde neu gestaltet, um die Herstellbarkeit zu verbessern. Der neue Controller basiert auf Arduino und hat ein benutzerdefiniertes Shield, das auf dem Arduino montiert wird. Abbildung 1 zeigt den Schirm und Abbildung 2 die mechanische Zeichnung für das Gehäuse. Der neue Controller wird über ein einzelnes 5‑V-Netzteil versorgt, das den Motor direkt antreibt. Die Elektronik wird vollständig über den USB-Anschluss gesteuert. Die separate Stromversorgung ermöglicht eine vollständige Isolierung zwischen der Steuerelektronik und dem Servomotor. Außerdem kann ein einzelner Controller bis zu sechs Servomotoren steuern.

Abbildung 1: Draufsicht auf 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

Erste API-Ebene

In Android 10 werden ITS-Tests als MANDATED und NOT_YET_MANDATED bezeichnet. Damit Ihr Gerät als Android 10-Gerät eingeführt werden kann, müssen alle MANDATED Tests bestanden werden. Die NOT_YET_MANDATED-Tests können fehlschlagen, werden aber in den Berichten des CTS-Verifiers als PASS aufgeführt. Die Anforderung an die MANDATED-Tests gilt auch für aktualisierte Geräte. Da aktualisierte Geräte alle MANDATED-Tests bestehen mussten, dauerte es länger, bis die Tests als MANDATED-Tests gekennzeichnet werden konnten, da auch ältere Geräte die Tests bestehen mussten.

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

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 prüfen

Unter Android 11 wird die Beleuchtung der Szene durch Analyse der Helligkeit in den Ecken der Szene validiert. Alle manuellen Szenen werden auf Beleuchtung geprüft. Tabletbasierte Szenen werden für RFoV-Kameras im RFoV-Testgestell und für WFoV-Kameras im WFoV-Testgestell validiert. Wenn die Beleuchtungsstärke nicht ausreicht, wird ein Fehler gemeldet und der Test schlägt fehl.

Änderungen am 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. Durch das Wiederholen der gesamten Szene wird die Wahrscheinlichkeit verringert, dass marginale Tests bestanden werden. Unter 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 von Pixel 4 für verschiedene Szenen aufgeführt. Die Anzahl der Tests wird aufgeteilt, um die Testzeit auszugleichen, nicht um die Anzahl der Tests auszugleichen.

Außerdem werden Namen bereinigt. Szene 2 wird 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 denselben Tests: *_a,b,c

Änderungen testen

Tests wurden auf die erste API-Ebene aktualisiert

In Android 11 werden die Tests in der folgenden Tabelle aktualisiert, um das Flag der ersten API-Ebene zu verwenden. Bei allen diesen Tests wird eine erste API-Ebene von 29 verwendet, mit Ausnahme des test_tonemap_curve-Tests, bei dem eine erste API-Ebene von 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 werden sie ausführlich beschrieben.

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 in den ITS-in-a-Box-Testgehäusen.

Asserts

• Keine Vibrationen bei der Verwendung der Kamera

scene2_a/test_jpeg_quality

Method

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

Dabei 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 in der JPEG-Aufnahme entspricht. Die eingebetteten Daten haben das folgende Format: [255, 219, 0, 132, 0 (Luma-Markierung), 8 × 8 Luma-Matrix, 1 (Chroma-Markierung), 8 × 8 Chroma-Matrix].

Die 0 für die Luma-Matrix-Markierung und die 1 für die Chroma-Markierung werden auf einer Reihe von Geräten, einschließlich Smartphones, konsistent verwendet, die die beiden Matrizen in separate DQT-Abschnitte in der JPEG-Datei unterteilen. Luma-Matrizen haben im Vergleich zu Chroma-Matrizen in der Regel eine größere Vielfalt an Werten, da das menschliche Auge empfindlicher auf Luma als auf Chroma reagiert. Bei JPEG-Bildern wird dies berücksichtigt.

Unten sind Beispiele für extrahierte Luma- und Chroma-Matrizen mit den Qualitätsfaktoren 85 und 25 für die Rückkamera von Pixel 4 zu sehen, die Szene 2_a mit dem ITS-Testgestell aufnimmt. Die Matrixwerte steigen bei der niedrigeren Qualitätseinstellung deutlich an, was eine stärkere Komprimierung bedeutet. Diese Matrizen werden nur mit dem Script gedruckt, wenn das Flag debug=True angewendet wird. Beachten Sie die größere Variation der Einträge in den Luminanzmatrizen im Vergleich zu den Chromamatrizen.

    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 von Google Pixel 4 im Vergleich zur JPEG-Qualität. Je höher die JPEG-Qualität ist, desto niedriger ist die Komprimierungsstufe (DQT-Matrix-Mittelwert für Luminanz/Chromatik).

Abbildung 3: DQT-Matrix-Mittelwerte für Luminanz/Chromatik der Rückkamera von Pixel 4 im Vergleich zur JPEG-Qualität

Asserts

• Bei [25, 45, 65, 86] führt ein Qualitätswert von +20 zu einer 20-prozentigen Reduzierung der Quantisierungsmatrixdurchschnitte.
• DQT-Matrixnutzlasten sind quadratische Zahlen.

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 einen 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 verschiedener Kameras ist das schwierigste Gesicht voraussichtlich das linkseste in „scene2_d“. Das Modell trägt einen Hut und einen Bart, was in den Gesichtsszenen neu ist. Die neuen Szenen sind in Abbildung 5 und 6 dargestellt.

Abbildung 5: scene2_d

Abbildung 6: scene2_e

Asserts

• num_faces == 3

scene2_e/test_continuous_picture

Method

Für den test_continuous_picture-Test wird „scene2_e“ verwendet, aber es kann mit jeder der Gesichterszenen aktiviert werden. In diesem Test werden 50 Frames in VGA-Auflösung erfasst, wobei in der ersten Aufnahmeanfrage android.control.afMode = 4 (CONTINUOUS_PICTURE) festgelegt wird.

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

Asserts

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

scene_change/test_scene_change

Method

Ein neuer Test wird aktiviert, um zu prüfen, ob das Flag android.control.afSceneChange bei einer Szenenänderung gesetzt wird. Bei der Szenenübergang wird das Tablet verwendet, um eine Gesichtsszene anzuzeigen und dann ein- und auszuschalten, um einen Szenenübergang zu erstellen. In der Szene wird „scene2_e“ wiederverwendet, sie befindet sich jedoch in einer separaten Szene, da die erforderliche Tabletsteuerung verwendet wird.

Bei manuellen Tests können Sie die Szene auch ändern, indem Sie vor der Kamera mit der Hand winken.

Abbildung 7 zeigt ein Zeitdiagramm des Tests. Die Zeit zwischen dem Ausschalten des Displays und der Aufnahme wird anhand der Ereignisergebnisse aus vorherigen Aufnahmen angepasst.

Abbildung 7. Timing-Diagramm für test_scene_change

Schichtbedingungen:

• Wenn es einen Szenenwechsel und afSceneChange == 1 gibt, gibt der Test PASS zurück.
• Wenn es eine Szenenänderung und afSceneChange == 0 gibt, wird die Szenenänderung um 5 Frames vorverlegt, damit afSceneChange mehr Zeit für die Bestätigung hat.
• Wenn keine Szenenänderung und afSceneChange == 1 vorhanden sind, gibt der Test FAIL zurück.
• Wenn es keinen Szenenwechsel und afSceneChange == 0 gibt, wird der Szenenwechsel um 30 Frames vorverlegt, damit er bei der Aufnahme erfasst wird.

Asserts

• Bildschirm (Szene) wird ein- und ausgeschaltet.
• Das Flag afSceneChange liegt im Bereich [0, 1].
• Bei keiner Szenenänderung 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 die Zeit basierend auf den vorherigen Ergebnissen angepasst wird.

scene6/test_zoom

Method

Für den Test von android.control.zoomRatioRange ist eine neue Szene erforderlich, da die vorhandenen Szenen entweder kein Element enthalten, das klein genug ist, um vergrößert zu werden (Szenen [1, 2, 4]), oder die Szene viele Objekte enthält, die sich nicht leicht identifizieren lassen, was die Elementextraktion 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/Diagramms gelockert und es ist immer möglich, einen Kreis in der Nähe der Mitte des aufgenommenen Bilds zu platzieren. In dieser Szene bedeckt eine Anordnung von 9 × 5 Kreisen mit schwarzem Rahmen das gesamte Tablet. Ein Kreis wird oben rechts durch ein Quadrat ersetzt, um die Ausrichtung anzuzeigen. Die Kreisgrößen haben eine Fläche von etwa 7.500 Pixeln (radius=50pixels) für einen 4.000 x 3.000 Pixel großen Sensor, der mit einem Sichtfeld von etwa 80 Grad aufgenommen wurde.

Abbildung 8: Szene „test_zoom“

Abbildung 9. Pixel 4 cam[0] zoom = [1, 3.33, 5.67, 8] Bilder mit gefundenem Kreis

Abbildung 9 zeigt aufgenommene Bilder mit der Rückkamera eines Google Pixel 4, wobei der Zoom in vier Schritten von 1-fach auf 8-fach erhöht wird. Bei diesen Bildern wurde nicht besonders auf die Ausrichtung geachtet, es wurde lediglich die Testöffnung des Smartphones mit zwei Öffnungen verwendet, um sowohl die Front- als auch die Rückkamera zu testen. Ein Versatz vom Mittelpunkt ist normal und wird beobachtet, da sich das Diagrammtablet etwas links vom Mittelpunkt befindet. Außerdem scheint das Diagramm für Tests mit einem Zoomfaktor von mehr als 8 fach ausreichend zu sein.

Kreise finden

Der Test enthält eine find_circle()-Methode mit findContours, die alle Konturen findet und die Suche nach Konturen 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 dem Wert π*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 Ränder des Bildes berührt. Es wird geprüft, ob im Test eine ausreichende Zoomstufe (10-fach) erreicht wird.

Asserts

• Bei jeder Zoomeinstellung wird mindestens ein Kreis gefunden.
• Es werden zehnmal oder maximal android.control.zoomRatioRange Varianten getestet.
• Der Radius des Kreises skaliert mit dem Zoom (RTOL 10% vom erwarteten Wert).
• Der Mittelpunkt des Kreises weicht beim Zoomen vom Mittelpunkt der Skala ab (RTOL 10% vom erwarteten Wert).
• Eine ausreichende Zoomstufe (2-fach) ist erreicht.

Erhöhte Anzahl der TESTS MIT EINGRENZENDEN VORAUSSETZUNGEN für Kameras

In Android 11 werden mit den Tests in der folgenden Tabelle LIMITED Kameras getestet. Neben den neuen Tests wurde der scene4/test_aspect_ratio_and_crop-Test aktualisiert, um LIMITED-Geräte mit einem ersten API-Level von 30 oder höher testen zu können.

Abbildung 10 zeigt den geheimen Decoderring von Android 11 ITS. Der geheime Decoderring zeigt, durch welche Testeinstellungen einzelne Tests aktiviert werden. Die Zugriffsbeschränkungen sind farblich gekennzeichnet, um die Übersichtlichkeit zu verbessern. Die wichtigsten Elemente für die Zulassung 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. Außerdem sind Tests, die für LIMITED-Geräte aktiviert sind, hellgrün hervorgehoben.

Abbildung 10. Geheimer Decoderring für Android 11