Android 11 カメラ画像テストスイート リリースノート

このページでは、Android 11 のカメラ画像テストスイート（ITS）の変更点の概要を説明します。変更は、次のカテゴリに分類されます。

• ハードウェアの変更
• 初期 API レベルの MANDATED テスト
• テスト照明の検証
• シーン名の変更
• テストの変更と追加
• LIMITED カメラのテストを追加

ハードウェアの変更

Android 11 では、コストを抑え可用性を高めるため、ハードウェアの変更がいくつか行われています。これらの変更は、次のカテゴリに分類されます。

• メーカーの追加
• 製造方法の統一
• タブレット オプションの追加
• タブレットの開口部の縮小
• 新しいセンサー フュージョン コントローラ

メーカーの追加

既存のサプライヤーである MYWAY design に加えて、Rahi Systems が ITS テスト エンクロージャーを作成する資格を得ました。認定ベンダーの会社情報を以下に掲載します。

• 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

製造方法の統一

rev1 標準視野角（RFoV）ITS-in-a-box を再設計し、広視野角（WFoV）ボックス テスト エンクロージャーおよびセンサー フュージョン ボックス テスト エンクロージャーで使用されている製造方法を採用しました。機能に変更はありませんが、わかりやすくするため、この設計の名称を rev1a とします。再設計により、メーカーは 1 種類のプラスチックを仕入れることで、すべてのテスト エンクロージャーを製造できるようになりました。さらに、タブレット マウントとライトホルダーを再設計して、対応できるタブレットと LED ライトバーのバリエーションを広げています。

最新の説明と機械図面をダウンロードするには、RFoV ボックス（rev1a）と WFoV ボックス（rev2.9）をご覧ください。

タブレット オプションの追加

Samsung Galaxy Tab A 10.1 や Chuwi Hi9 Air 10.1 などのタブレットを推奨タブレットのリストに追加しました。撮影した画像に縞模様が生じることを回避するため、タブレットで画面の明るさの調整にパルス幅変調（PWM）が使用されていないことが重視されています。

推奨タブレットの最新情報については、タブレットの要件をご覧ください。

タブレットの開口部の縮小

Galaxy Tab A 10.1 を使用できるように、RFoV（rev1a）と WFoV（rev2）の両方のテスト エンクロージャーでタブレットの開口部の高さをわずかに下げています。これらの変更を反映しているリビジョンは rev1a.1 と rev2.9 です。これらの図面については、RFoV ボックス（rev1a）と WFoV ボックス（rev2.9）をご覧ください。

新しいセンサー フュージョン コントローラ

センサー フュージョン コントローラのハードウェアを再設計して、製造可能性を改善しました。新しいコントローラは Arduino をベースとし、Arduino の上にカスタム ルーティング ボード シールドが搭載されています。図 1 にシールドを、図 2 にエンクロージャーの機械図面を示しています。新しいコントローラは、モーターを直接駆動する単一の 5 V の電源を動力源とします。電子機器は USB コネクタを介して完全に制御されます。独立した電源により、制御電子機器とサーボモーターを完全に分離できます。また、1 つのコントローラで最大 6 個のサーボモーターを操作できます。

図 1. Arduino シールドの上面図

図 2. エンクロージャーの設計

Android 11 は、既存のコントローラと下位互換性があります。Arduino ベースのコントローラを使用してテストを開始するには、以下を使用します。

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

初期 API レベル

Android 10 では、ITS テストは MANDATED および NOT_YET_MANDATED として指定されています。Android 10 デバイスとしてリリースするには、すべての MANDATED テストに合格する必要があります。NOT_YET_MANDATED テストは失敗しても問題はなく、CTS 検証ツールのレポート機能では PASS として表示されます。MANDATED テスト要件は、アップグレードしたデバイスにも適用されます。アップグレードしたデバイスがすべての MANDATED テストに合格することを求めるこの要件によって、古いデバイスも同じテストに合格する必要があることから、テストが MANDATED テストとなるのに遅延が発生していました。

Android 11 では、MANDATED テストは、スマートフォン プロパティの初期 API レベルのフラグによってゲートされます。Android 11 にアップグレードするデバイスの場合は、NOT_YET_MANDATED テストとしてテストを実行します。つまり、テストに失敗しても問題はなく、CtsVerifier.apk で PASS として表示されます。

例:

• Android 11 では、初期 API レベルが 29 を超えるデバイスでは、test_channel_saturation テストが MANDATED になります。
• Android 10 では、すべてのデバイスで test_channel_saturation テストが MANDATED になります。

シーンの照明の検証

Android 11 では、シーンの隅の明るさを分析することによりシーンの照明が検証されます。すべての手動シーンで照明の検証が行われ、タブレット ベースのシーンで FoV テスト装置の WFoV カメラと RFoV テスト装置の RFoV カメラの検証が行われます。照明レベルが不十分である場合、エラーが報告され、テストは失敗します。

シーン名の変更

Android 10 では、シーン 1 がテストの大部分を占め、合計テスト時間の大部分を構成しています。シーン 1 内のテストが失敗した場合は、シーン全体を再実行する必要があります。設計上、シーン全体を再実行すると、限界テストの合格率が低下します。Android 11 では、シーン 1 を scene1_1 と scene1_2 という 2 つのシーンに分割することで再実行時間を短縮します。

次の表は、さまざまなシーンでの Pixel 4 の背面カメラのテスト時間を示しています。テストの数は、テストの数を均等にするのではなく、テスト時間を均等にするように分割されています。

また、名前のクリーンアップも行われています。シーン 2 はアルファベットで分割され、シーン 1 は数字で分割されています。各拡張機能の命名法は次のとおりです。

• チャートが同じでテストが異なるシーン: *_1,2,3
• チャートが異なる、同じテストのシーン: *_a,b,c

テストの変更

初期 API レベルを使用するようにテストを更新しました

Android 11 では、次の表に記載されているテストが初期 API レベルのフラグを使用するように更新されます。初期 API レベル 30 を使用する test_tonemap_curve テストを除き、これらのテストではすべて、初期 API レベル 29 を使用します。

変更を加えたテスト

Android 11 では、次の表に記載されたテストが更新されています。変更の詳細については、「変更の説明」列をご覧ください。

新しいテスト

Android 11 では、次の表に記載されたテストが追加されています。テストの概要は表をご覧ください。また、詳細な説明は以降のセクションをご確認ください。

scene0/test_vibration_restriction

このテストには特定のシーンは必要ありませんが、テスト対象デバイス（DUT）を硬質な面の上に配置する、または取り付ける必要があります。これには、ITS-in-a-box のエンクロージャーへの取り付けが含まれます。

アサート

• カメラ使用中のバイブレーションなし

scene2_a/test_jpeg_quality

方法

JPEG ファイルの各要素は、2 バイトのマーカーによって定義されます。詳細については、JPEG をご覧ください。

このテストでは、JPEG キャプチャから量子化マトリックスを抽出します。JPEG キャプチャの量子化マトリックスのマーカーは、シーケンス [255, 219] です。マーカーが検出された場合は次の 2 つのリストサイズが表示されます。JPEG DQT サイズマーカーは通常、[0, 132] = 256*0+132 = 132 です。これは、JPEG 撮影での DQT データのサイズの構成を表しています。埋め込みデータの形式は、[255, 219, 0, 132, 0 (luma marker), 8x8 luma matrix, 1 (chroma marker), 8x8 chroma matrix] です。

輝度マトリックス マーカーの 0 と彩度マーカーの 1 は、2 つのマトリックスを JPEG ファイルの別々の DQT セクションに分割するスマートフォンなど、さまざまなデバイスで一貫しているようです。輝度マトリックスの値は、彩度マトリックスと比較して値の変動幅が大きくなります。これは人間の目が、彩度よりも輝度に対して敏感であり、JPEG 画像はこの点を反映していることが理由です。

ITS テスト機器で scene2_a を撮影する Pixel 4 の背面カメラを対象として抽出した輝度および彩度のマトリックスのサンプルを以下に示します。サンプルの品質係数は 85 と 25 です。マトリックス値は、品質設定が低いほど大幅に増加します（圧縮率の上昇を示します）。これらのマトリックスは、debug=True フラグが適用されている場合にのみ、スクリプトとともに出力されます。彩度マトリックスと比較して輝度マトリックスのエントリの変動が大きいことがわかります。

    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]]

図 3 は、Pixel 4 の背面カメラの平均マトリックス値と JPEG 品質の関係を示しています。JPEG の品質が向上すると、圧縮レベル（輝度/彩度 DQT マトリックス平均）は低くなります。

図 3. Pixel 4 の背面カメラの輝度/彩度 DQT マトリックスの平均と JPEG 品質の関係

アサート

• [25, 45, 65, 86] の場合、品質が +20 のときに量子化マトリックスの平均が 20% 低下しています。
• DQT マトリックス ペイロードは平方数の値です。

図 4 は、テストに失敗したスマートフォンの例を示しています。見ての通り、品質が非常に低い画像（jpeg.quality < 50）で量子化マトリックスの圧縮率が高くなっていません。

図 4. 失敗したテスト例

scene2_d/e test_num_faces

顔検出アルゴリズムのチェックで顔の多様性を高めるため、2 つの新しい顔検出シーンを追加しました。複数のカメラを繰り返しテストする場合に、検出が最も困難な顔は scene2_d の左端の顔であることが予想されます。特に、このモデルには帽子とあごひげの両方があり、従来の顔のシーンにはなかったタイプのモデルです。新しいシーンを図 5 と 6 に示します。

図 5. scene2_d

図 6. scene2_e

アサート

• num_faces == 3

scene2_e/test_continuous_picture

方法

test_continuous_picture テストは scene2_e を使用していますが、どの顔のシーンでも有効にできます。このテストでは、撮影リクエストの最初の設定 android.control.afMode = 4 (CONTINUOUS_PICTURE) により、VGA 解像度の 50 フレームを撮影しています。

3A システムは、50 フレームを撮影し終わった時点で安定することが予想されます。

アサート

• 3A は撮影の終了時に収束状態になります。

scene_change/test_scene_change

方法

シーンの変更で android.control.afSceneChange フラグがアサートされているかどうかをテストするため、新しいテストが有効になりました。シーンの変更では、顔のシーンを表示しているタブレットを使用し、タブレットのオンとオフを切り替えてシーンの変更を作成します。シーンは scene2_e を再利用しますが、タブレットの制御が必要なため、別のシーンにあります。

さらに、手動テストでは、カメラの前で手を振ることによってシーンを切り替えることができます。

図 7 に、テストのタイミング図を示します。画面がオフになるまでの時間とキャプチャのタイミングは、以前のキャプチャのイベント結果に基づいて調整されます。

図 7. test_scene_change のタイミング図

シフト条件:

• シーンの変更があり、afSceneChange == 1 の場合、テストは PASS を返します。
• シーンの変更があり、afSceneChange == 0 の場合、afSceneChange がアサーションを行う時間を追加するために、シーンの変更が 5 フレーム前にシフトします。
• シーンの変更がなく、afSceneChange == 1 の場合、テストは FAIL を返します。
• シーンの変更がなく、afSceneChange == 0 の場合、撮影時のシーンの変更を取得するためにシーンの変更が 30 フレーム前にシフトします。

アサート

• 画面（シーン）が切り替わります。
• afSceneChange フラグは [0, 1] にあります。
• シーンの変更がない場合、3A は収束します（機能的には test_continuous_picture と同じです）。
• afSceneChange == 1 の場合は、シーン内で明るさを変更する必要があります。
• 以前の結果に基づいてタイミングを変更することにより、6 回以内の試行で PASS になります。

scene6/test_zoom

方法

android.control.zoomRatioRange をテストするには、新しいシーンが必要です。これは、従来型のシーンには、拡大対象としてふさわしい十分に小さい特徴が存在しない（シーン [1, 2, 4]）、またはシーンに容易に判別できない対象が多数含まれており、特徴の抽出が困難である（シーン 3）ためです。

図 8 は、規則的に並べられた円が新しいシーンを表しています。円の配列は、テストデバイス/グラフの中央揃えの要件を緩め、キャプチャした画像の中心付近に常に円を配置できるようにします。このシーンでは、黒い枠線付きの 9×5 の円の配列がタブレット全体に表示されています。右上の 1 つの円が四角形になっており、方向を表しています。約 80 度の視野角（FoV）でキャプチャされる 4000x3000 センサーのキャプチャの場合、円のサイズは約 7,500 ピクセル（radius=50pixels）の領域を持ちます。

図 8. test_zoom シーン

図 9. Pixel 4 cam[0] zoom = [1, 3.33, 5.67, 8] 検出された円の画像

図 9 は、Pixel 4 の背面カメラで撮影された画像を示しています。1 倍から 8 倍までの 4 段階のズームで撮影されています。この一連の画像は、2 つの開口部を備えたスマートフォンのテスト開口を使用して前面カメラと背面カメラの両方のテストを可能にすることを除いて、被写体を中央に配置することに特別な注意を払わずに撮影されています。中心からのオフセットが想定され、チャート用タブレットが中心からわずかに左に寄っていることが確認できます。さらに、チャートは 8 倍を超えるズーム比でテストするのに十分な要件を満たしていると考えられます。

円の検出

テストには、findContours を使用する find_circle() メソッドが用意されています。このメソッドは、すべての輪郭を検出して、次の内容をテストすることによって対象の輪郭に絞り込みます。

• 輪郭の領域は 10 ピクセルより大きいことが必要です。
• 輪郭には NUM_PTS >= 15 が必要です。
• 輪郭の中心部は黒色であることが必要です。
• 輪郭は円に近似していることが必要です。つまり、輪郭の領域は輪郭の pi*r2 領域に近いことが必要です。

テスト範囲

android.control.zoomRatioRange は 10 ステップに分かれています。

• [1, 7] テスト [1, 1.67, 2.33, 3, 3.67, 4.33, 5, 5.67, 6.33, 7]

検出された円が画像の境界に達すると、ズームは停止します。テストで十分なズームレベル（10 倍）に達していることを確認するためのチェックを行います。

アサート

• 各ズーム設定で少なくとも 1 つの円が検出されます。
• android.control.zoomRatioRange の 10 倍または最大値をテストします。
• 円の半径はズームに合わせて調整されます（予想値に基づき RTOL は 10%）。
• ズームによる中心スケールからの円の中心オフセット（予想値に基づき RTOL は 10%）
• 十分なズームレベル（2 倍）に達します。

LIMITED カメラのテストを追加

Android 11 では、次の表のテストで LIMITED カメラをテストします。新しいテストに加えて、初期 API レベルが 30 以上の LIMITED デバイスをテストできるように scene4/test_aspect_ratio_and_crop テストを更新しました。

図 10 は、Android 11 ITS のシークレット デコーダー リングを示しています。シークレット デコーダー リングは、個別のテストがどのテスト設定によってゲートされるかを示します。ゲート設定は、見やすくするために色分けされています。ゲート設定の主な項目は次のとおりです。

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

MANUAL SENSOR、READ_3A、COMPUTE_TARGET_EXPOSURES、PER_FRAME_CONTROL はテストの大部分をゲートします。また、LIMITED デバイスに対して有効に設定されているテストは、薄い緑色でハイライト表示されます。

図 10. Android 11 シークレット デコーダー リング