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

Android 12 リリースには、カメラ ITSの多くの変更が含まれています。このページには、次の 4 つの大きなカテゴリに分類される変更がまとめられています。

Python 3 へのリファクタリング

2020 年 1 月の Python 2.7 の非推奨により、カメラ ITS コードベース全体が Python 3 にリファクタリングされました。Android 12 では、次の Python バージョンとライブラリが必要です。

メインのテスト ランチャーtools/run_all_tests.py 、Android 11 以前のバージョンと同じままで、Python 3 にリファクタリングされています。

すべての個々のテストはリファクタリングされ、 tests/its_base_test.pyで定義された新しいテスト セットアップ クラスを使用します。ほとんどのテスト名と機能は変わりません。 Android 12 では、すべての個別のテストがシーンをロードするようになりました。各テストのシーンの読み込みにより全体のテスト時間は増加しますが、個々のテストのデバッグが可能になります。

個々のテストの変更の詳細については、 「テストの変更」を参照してください。

次の Python モジュールはリファクタリングされ、名前が変更されています。

  • pymodules/its/caps.pyutils/camera_properties_utils.py
  • pymodules/its/cv2image.pyutils/opencv_processing_utils.py
  • pymodules/its/device.pyutils/its_session_utils.py
  • pymodules/its/error.pyutils/error_util.py
  • pymodules/its/image.pyutils/image_processing_utils.py
  • pymodules/its/objects.pyutils/capture_request_utils.py
  • pymodules/its/target.pyutils/target_exposure_utils.py
  • tools/hw.pyutils/sensor_fusion_utils.py

Moblyテストフレームワークの採用

Moblyは、カスタム ハードウェア セットアップを備えた複数のデバイスを必要とするテスト ケースをサポートする Python ベースのテスト フレームワークです。カメラ ITS は、Mobly テスト インフラストラクチャを使用して、テストのより適切な制御とログ記録を可能にします。

カメラ ITS は、Mobly テスト インフラストラクチャを使用して、テストのより適切な制御とログ記録を可能にします。 Mobly は、カスタム ハードウェア セットアップを備えた複数のデバイスを必要とするテスト ケースをサポートする Python ベースのテスト フレームワークです。 Mobly の詳細については、 google/moblyを参照してください。

config.yml ファイル

Mobly フレームワークを使用すると、 its_base_testクラスでテスト対象デバイス (DUT) とチャート タブレットをセットアップできます。 config.yml (YAML) ファイルは、Mobly テストベッドの作成に使用されます。この構成ファイル内で複数のテストベッド (タブレットやセンサー フュージョン テストベッドなど) を構成できます。各テストベッドのコントローラー セクション内で、 device_ids指定して、テスト ランナーに対して適切な Android デバイスを識別できます。デバイス ID に加えて、タブレットのbrightnesschart_distancedebug_modecamera_idscene_idなどの他のパラメーターがテスト クラスで渡されます。一般的なテスト パラメータ値は次のとおりです。

brightness: 192  (all tablets except Pixel C)
chart_distance: 31.0  (rev1/rev1a box for FoV < 90° cameras)
chart_distance: 22.0 (rev2 test rig for FoV > 90° cameras)

タブレットベースのテスト

タブレットベースのテストの場合、テストベッド名にキーワードTABLET含まれている必要があります。初期化中に、Mobly テスト ランナーはTestParamsを初期化し、それらを個々のテストに渡します。

以下は、タブレットベースの実行用のサンプルconfig.ymlファイルです。

TestBeds:
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

テストベッドはtools/run_all_tests.pyを使用して呼び出すことができます。コマンド ライン値が存在しない場合、テストはconfig.ymlファイルの値を使用して実行されます。さらに、Android 11 以前と同様のコマンドを使用して、コマンド ラインでcamerascene構成ファイルの値をオーバーライドできます。

例えば:

python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=1 scenes=2,1,0

センサーフュージョン試験

センサー フュージョン テストの場合、テストベッド名にはキーワードSENSOR_FUSIONが含まれている必要があります。正しいテストベッドは、テストされるシーンによって決まります。 Android 12 は、センサー フュージョン用の Arduino コントローラーと Canakit コントローラーの両方をサポートしています。

以下は、センサー フュージョン実行用のサンプルconfig.ymlファイルです。

Testbeds
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

センサー フュージョンテスト リグを使用してセンサー フュージョンテストを実行するには、次を使用します。

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0

複数のテストベッド

複数のテストベッドを構成ファイルに含めることができます。最も一般的な組み合わせは、タブレット テストベッドとセンサー フュージョン テストベッドの両方を使用することです。

以下は、タブレットとセンサー フュージョン テストベッドの両方を含むサンプルconfig.ymlファイルです。

Testbeds
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>  # if <scene-name> runs all scenes

  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

手動テスト

手動テストは Android 12 でも引き続きサポートされます。ただし、テストベッドでは、テストベッド名にキーワードMANUALを使用してテスト自体を識別する必要があります。さらに、テストベッドにはタブレット ID を含めることはできません。

以下は、手動テスト用のサンプルconfig.ymlファイルです。

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      chart_distance: 31.0
      camera: 0
      scene: scene1

タブレットを使用しないテストシーン

シーン 0 とシーン 5 のテストは、 TEST_BED_TABLET_SCENESまたはTEST_BED_MANUALを使用して実行できます。ただし、テストがTEST_BED_TABLET_SCENESで行われる場合は、テスト クラスのセットアップによってタブレットのシリアル ID 値が割り当てられるため、タブレットが使用されていなくても、タブレットが接続されており、タブレットのシリアル ID が有効である必要があります。

個別のテストを実行する

個々のテストは、結果がCTS Verifierに報告されないため、デバッグ目的でのみ実行できます。 config.ymlファイルは、コマンド ラインでcameraおよびsceneに対して上書きできないため、問題の個々のテストのconfig.ymlファイル内のこれらのパラメータが正しい必要があります。さらに、構成ファイルに複数のテストベッドがある場合は、 --test_bedフラグを使用してテストベッドを指定する必要があります。例えば:

python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES

テスト成果物

Android 12 では、カメラ ITS のテスト アーティファクトは Android 11 以前と同様に保存されますが、次の変更があります。

  • テスト アーティファクト/tmpディレクトリには、わかりやすくするために 8 文字のランダムな文字列の先頭にCameraITS_追加されています。
  • テスト出力とエラーは、 test_name_stdout.txtおよびtest_name_stderr.txtではなく、各テストのtest_log.DEBUGに保存されます。
  • 個々のテストの DUT とタブレットの logcat は/tmp/CameraITS_########ディレクトリに保存され、3A の問題のデバッグに必要なすべての情報がログに記録されるため、デバッグが簡素化されます。

テストの変更

Android 12 では、タブレットのシーンは PDF ファイルではなく PNG ファイルです。 PNG ファイルを使用すると、より多くのタブレット モデルでシーンを適切に表示できるようになります。

scene0/test_jitter.py

test_jitterテストは、Android 12 の物理隠しカメラで実行されます。

scene1_1/test_black_white.py

Android 12 の場合、 test_black_whiteにはtest_black_whitetest_channel_saturationの両方の機能があります。

次の表では、Android 11 の 2 つの個別のテストについて説明します。

テスト名最初の API レベルアサーション
scene1_1/test_black_white.py全て短時間露光、低ゲイン RGB 値 ~[0, 0, 0]
長時間露光、高ゲイン RGB 値 ~[255, 255, 255]
scene1_1/test_channel_saturation.py 29 [255, 255, 255] の差の許容値を減らし、白画像の色合いを排除しました。

次の表では、Android 12 のマージされたテスト scene1_1/test_black_white.py について説明します。

テスト名最初の API レベルアサーション
scene1_1/test_black_white.py全て短時間露光、低ゲイン RGB 値 ~[0, 0, 0]
長時間露光、高ゲイン RGB 値 ~[255, 255, 255]、および値間の許容差を縮小して、白い画像の色合いを排除します。

scene1_1/test_burst_sameness_manual.py

test_burst_sameness_manualテストは、Android 12 の物理隠しカメラで実行されます。

scene1_2/test_tonemap_sequence.py

test_tonemap_sequenceテストは、Android 12 の限定されたカメラで実行されます。

scene1_2/test_yuv_plus_raw.py

test_yuv_plus_rawテストは、Android 12 の物理隠しカメラで実行されます。

scene2_a/test_format_combos.py

test_format_combosテストは、Android 12 の限定されたカメラで実行されます。

scene3/test_flip_mirror.py

test_flip_mirrorテストは、Android 12 の限定されたカメラで実行されます。

scene4/test_aspect_ratio_and_crop.py

scene4/test_aspect_ratio_and_crop.pyでの円の検索は Android 12 でリファクタリングされました。

以前の Android バージョンでは、サイズと色のフィルターを使用して、親輪郭 (正方形) の内側で子輪郭 (円) を検索する方法が使用されていました。 Android 12 では、すべての輪郭を見つけてから、最も円形の特徴を見つけてフィルタリングする方法が使用されています。ディスプレイ上の偽の円を取り除くには、最低限必要な輪郭領域があり、円の輪郭は黒でなければなりません。

輪郭とその選択基準を次の図に示します。

輪郭の概念図と選定基準

図1等高線の概念図と選定基準

Android 12 の方法はより簡単で、一部のディスプレイ タブレットでの境界ボックスのクリッピングの問題を解決するのに役立ちます。すべてのサークル候補は、デバッグ目的でログに記録されます。

Android 12 では、クロップ テストはFULLLEVEL3デバイスに対して実行されます。 Android 11 以前のバージョンでは、 FULLデバイスのクロップ テスト アサーションがスキップされます。

次の表に、特定のデバイス レベルと最初の API レベルに対応するtest_aspect_ratio_and_crop.pyのアサーションを示します。

デバイスレベル最初の API レベルアサーション
限定全てアスペクト比
4:3、16:9、2:1 フォーマットの FoV
満杯< 31アスペクト比
4:3、16:9、2:1 フォーマットの FoV
満杯≥ 31作物
アスペクト比
4:3、16:9、2:1 フォーマットの FoV
レベル3全て作物
アスペクト比
4:3、16:9、2:1 フォーマットの FoV

scene4/test_multi_camera_alignment.py

scene4/test_multi_camera_alignment.pyの YUV キャプチャのメソッドundo_zoom()リファクタリングされ、キャプチャのアスペクト比と一致しないセンサーでのトリミングをより正確に考慮できるようになりました。

Android 11 Python 2 コード

zoom_ratio = min(1.0 * yuv_w / cr_w, 1.0 * yuv_h / cr_h)
circle[i]['x'] = cr['left'] + circle[i]['x'] / zoom_ratio
circle[i]['y'] = cr['top'] + circle[i]['y'] / zoom_ratio
circle[i]['r'] = circle[i]['r'] / zoom_ratio

Android 12 Python 3 コード

yuv_aspect = yuv_w / yuv_h
relative_aspect = yuv_aspect / (cr_w/cr_h)
if relative_aspect > 1:
  zoom_ratio = yuv_w / cr_w
  yuv_x = 0
  yuv_y = (cr_h - cr_w / yuv_aspect) / 2
else:
  zoom_ratio = yuv_h / cr_h
  yuv_x = (cr_w - cr_h * yuv_aspect) / 2
  yuv_y = 0
circle['x'] = cr['left'] + yuv_x + circle['x'] / zoom_ratio
circle['y'] = cr['top'] + yuv_y + circle['y'] / zoom_ratio
circle['r'] = circle['r'] / zoom_ratio

センサーフュージョン/test_sensor_fusion.py

Android 12 では、センサー フュージョン テスト用に画像内の特徴を検出する方法が追加されています。

Android 12 より前のバージョンでは、画像全体を使用して最適な 240 個の機能が検索され、ローリング シャッター効果を避けるために中央の 20% がマスクされます。最小機能要件は 30 個です。

この方法で検出された特徴が不十分な場合、Android 12 では、まず特徴検出領域を中央の 20% にマスクし、最大特徴を最小特徴要件の 2 倍に制限します。

次の図は、Android 11 と Android 12 の機能検出の違いを示しています。最小特徴要件のしきい値を上げると、低品質の特徴が検出され、測定に悪影響を及ぼします。

Android 11 と Android 12 の機能検出の違い sensor_fusion 機能検出

図 2. Android 11 と Android 12 の機能検出の違い

新しいテスト

scene0/test_solid_color_test_pattern.py

新しいテストtest_solid_color_test_pattern Android 12 で有効になりました。このテストはすべてのカメラで有効になり、次の表で説明されます。

シーンテスト名最初の API レベル説明
0テストソリッドカラーテストパターン31ソリッドカラー画像出力と画像カラーのプログラマビリティを確認します。

カメラのプライバシー モードをサポートするには、単色のテスト パターンを有効にする必要があります。 test_solid_color_test_patternテストは、選択したパターンで定義された色で出力されたソリッド カラー YUV 画像を確認し、画像の色は仕様に従って変更されます。

パラメーター

  • cameraPrivacyModeSupport : カメラがプライバシー モードをサポートするかどうかを決定します。
  • android.sensor.testPatternMode : テストパターンモードを設定します。このテストではSOLID_COLORを使用します。
  • android.sensor.testPatternData : テスト パターン モードの R、Gr、Gb、G テスト パターン値を設定します。

単色のテスト パターンの説明については、 SENSOR_TEST_PATTERN_MODE_SOLID_COLORを参照してください。

方法

YUV フレームはパラメータ セットに対してキャプチャされ、画像コンテンツが検証されます。テストパターンはイメージセンサーから直接出力されるため、特定のシーンは必要ありません。 PER_FRAME_CONTROLがサポートされている場合、テストされる設定ごとに 1 つの YUV フレームがキャプチャされます。 PER_FRAME_CONTROLがサポートされていない場合は、 LIMITEDカメラでのテスト カバレッジを最大化するために、4 つのフレームがキャプチャされ、最後のフレームのみが分析されます。

YUV キャプチャは、完全に飽和したBLACKWHITEREDGREEN 、およびBLUEテスト パターンに設定されます。テスト パターンの定義はセンサーのベイヤー パターンごとに行われるため、次の表に示すようにカラー チャネルを色ごとに設定する必要があります。

テストパターンデータ (RGGB)
(0, 0, 0, 0)
(1, 1, 1, 1)
(1, 0, 0, 0)
(0, 1, 1, 0)
(0, 0, 0, 1)

アサーションテーブル

次の表では、 test_solid_color_test_pattern.pyのテスト アサーションを説明します。

カメラ
最初の API レベル
カメラの種類主張された色
31バイエル黒、白、赤、緑、青
31単核症黒、白
< 31バイエル/MONO

パフォーマンスクラスのテスト

scene2_c/test_camera_launch_perf_class.py

scene2_c の顔シーンで、前面と背面のプライマリ カメラの両方でカメラの起動が 500 ミリ秒未満であることを確認します。

scene2_c/test_jpeg_capture_perf_class.py

scene2_c の顔シーンを使用したフロントおよびリアのプライマリ カメラの両方で、1080p JPEG キャプチャの遅延が 1 秒未満であることを確認します。