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
• ERZWUNGENE Tests der ersten 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
• Verringerte Öffnung des Tablets
• Neuer Sensorfusionscontroller

Weiterer Hersteller

Rahi Systems ist zusätzlich zu unserem bestehenden Lieferanten MYWAY Design qualifiziert, ITS-Testgehäuse herzustellen. Unternehmensinformationen für qualifizierte Anbieter:

• 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 regulärem 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. 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 (Version 2.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 genutzt werden kann, wurde die Höhe der Tablet-Öffnung sowohl für die RFoV-Testgehäuse (rev1a) als auch für die WFoV-Testgehäuse (rev2) geringfügig reduziert. 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 den Sensor Fusion-Controller wurde neu gestaltet, um die Herstellungsbarkeit zu verbessern. Der neue Controller basiert auf Arduino und hat ein spezielles Schild für das Routingboard, das auf dem Arduino angebracht 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. Das separate Netzteil ermöglicht eine vollständige Isolierung zwischen der Regelelektronik und dem Servomotor. Darüber hinaus kann eine einzelne Steuerung 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 das 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 für die CTS-Prüfungsberichte als PASS tabellarisch dargestellt. Die MANDATED-Testanforderung gilt auch für aktualisierte Geräte. Aufgrund dieser Anforderung, dass aktualisierte Geräte alle MANDATED-Tests bestehen mussten, wurden die Tests verzögert in MANDATED-Tests umgewandelt, da ältere Geräte die Tests ebenfalls bestehen müssen.

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 größer als 29.
• In Android 10 ist der test_channel_saturation-Test für alle Geräte MANDATED.

Szenenbeleuchtung wird überprüft

In 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 die Mehrheit 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 erneutes Ausführen der gesamten Szene werden Grenztests reduziert. Unter Android 11 werden die Wiederholungszeiten reduziert, indem Szene 1 in zwei Szenen aufgeteilt wird: scene1_1 und scene1_2.

Die folgende Tabelle zeigt die Testzeiten für die Pixel 4-Rückkamera in verschiedenen Szenen. 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 erste Flag auf 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 finden Sie detaillierte Beschreibungen.

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 auf 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 in der Regel [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 in der Regel eine größere Vielfalt von Werten im Vergleich zu Chromamatrizes, da das menschliche Auge gegenüber Luma-empfindlicher ist als bei Chroma- und JPEG-Bildern.

Unten sind Beispiel-Luma- und Chroma-Matrizen für die Rückkamera von Pixel 4 mit den Qualitätsfaktoren 85 und 25 zu sehen, die Szene 2_a mit dem ITS-Testgestell aufgenommen haben. Die Matrixwerte steigen bei der niedrigeren Qualitätseinstellung deutlich an, was eine stärkere Komprimierung bedeutet. Diese Matrizen werden nur mit dem Script ausgegeben, wenn das Flag debug=True angewendet wird. Beachten Sie die größere Abweichung bei den Einträgen 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 Pixel 4-Rückkamera 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 Durchschnittswerte der Rückkamera für Luma/Chroma DQT Matrix von Pixel 4 im Vergleich zur JPEG-Qualität

Bestätigt

• Bei [25, 45, 65, 86] führt eine Qualitätssteigerung um 20 auf 20% reduzierte 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 zu sehen.

Abbildung 5: Scene2_d

Abbildung 6: scene2_e

Asserts

• num_faces == 3

Szene2_e/test_fortlaufendes_Bild

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 mit VGA-Auflösung mit der Einstellung android.control.afMode = 4 (CONTINUOUS_PICTURE) für die erste Erfassungsanfrage erfasst.

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 eine Tabletsteuerung erforderlich ist.

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. Das Timing zwischen dem Abschalten des Bildschirms und der Aufnahme wird anhand der Ereignisergebnisse früherer Aufnahmen angepasst.

Abbildung 7. Timing-Diagramm für test_scene_change

Bedingungen ändern:

• Wenn es einen Szenenwechsel und afSceneChange == 1 gibt, gibt der Test PASS zurück.
• Wenn es einen Szenenwechsel und afSceneChange == 0 gibt, wird der Szenenwechsel um 5 Frames vorverlegt, damit afSceneChange mehr Zeit für die Bestätigung hat.
• Wenn es keinen Szenenwechsel gibt und afSceneChange == 1 zurückgegeben wird, 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) umschalten
• 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 im Bild ändern.
• PASS innerhalb von sechs Versuchen, wobei die Zeit basierend auf den vorherigen Ergebnissen angepasst wird.

scene6/test_zoom

Method

Zum Testen von android.control.zoomRatioRange ist eine neue Szene erforderlich, da die etablierten Szenen entweder kein Element haben, das klein genug für eine Vergrößerung ist (Szenen [1, 2, 4]) oder viele Objekte enthält, die nicht leicht zu identifizieren sind, was die Extraktion von Merkmalen 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 Funktion mit einem Bereich von etwa 7.500 Pixeln (radius=50pixels) für einen 4.000 × 3.000 Pixel großen Sensor, der mit einem Sichtfeld von etwa 80 Grad erfasst 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. Diese Bilder werden ohne besondere Sorgfalt beim Zentrieren aufgenommen, mit der Ausnahme, dass die Blende zum Testen des Smartphones mit zwei Öffnungen verwendet wird, um sowohl die Front- als auch die Rückkamera zu testen. Ein Versatz von der Mitte wird erwartet und ist zu sehen, wenn die Diagrammtabellenkalkulation leicht links von der Mitte ausgerichtet ist. Außerdem scheint das Diagramm für Tests mit Zoomverhältnissen von mehr als 8-fachen Vergrößerungswerten 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 kreisförmig sein, d. h. ihr Bereich muss nahe am pi*r2-Bereich der Kontur 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 erreicht wurde (10x).

Bestätigt

• Bei jeder Zoomeinstellung wird mindestens ein Kreis gefunden.
• Es werden zehnmal oder maximal android.control.zoomRatioRange Testvarianten 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.

Mehr Kameratests für LIMITED

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