סקירה כללית של Camera ITS

חבילת הבדיקות (ITS) של תמונות מהמצלמה היא מסגרת להרצת בדיקות על תמונות שנוצרו על ידי מצלמת Android. המטרה הכללית של כל בדיקה ב-ITS היא להגדיר את המצלמה באופן ספציפי, לצלם תמונה אחת או יותר ולבדוק את התמונות כדי לראות אם הן מכילות את נתוני התמונה הצפויים. ברוב הבדיקות צריך להפנות את המצלמה לתרשים יעד ספציפי או להאיר אותו בעוצמה ספציפית.

מערכת ITS נמצאת במסגרת הבדיקה של CTS Verifier בנתיב cts/apps/CameraITS. המכשירים צריכים לעבור את בדיקות ה-ITS שמתאימות לתכונות הנתמכות שמוצגות על ידי מסגרת המצלמה לאפליקציות של צד שלישי כקבוצת משנה של CTS.

הגדרה

כדי להריץ בדיקות ITS, צריך להגדיר את הדברים הבאים:

• מכשיר שנבדק (DUT)
• מחשב מארח (לדוגמה, מחשב נייד או מחשב שולחני עם Linux)
• סצנה שמצולמת על ידי המצלמה

הגדרת המכשיר שנבדק (DUT)

כדי להגדיר את המכשיר הנבדק, מבצעים את השלבים הבאים:

1. מחברים את המכשיר הנבדק למחשב מארח באמצעות USB.
2. נותנים הרשאות למארח לגשת למכשיר הנבדק דרך ADB.

3. מתקינים את אפליקציית CTS Verifier‏ (CtsVerifier.apk) במכשיר. מידע נוסף זמין במאמר בנושא שימוש ב-CTS Verifier.

   extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip
   cd android-cts-verifier
   adb install -r -g CtsVerifier.apk

4. במכשיר הנבדק, מפעילים את אפליקציית המצלמה שמוגדרת כברירת מחדל ומנקים את כל החלונות שמופיעים בהפעלה כדי למנוע הפרעות במהלך הבדיקה.

הגדרת המארח

מערכת ITS מחייבת שהמחשב המארח יהיה מחובר למכשיר הנבדק באמצעות USB, שתהיה לו אפשרות להשתמש ב-ADB לשליטה במכשיר ולתקשורת איתו, ושמותקנת בו התוכנה הנדרשת.

כדי להגדיר את המחשב המארח, צריך לוודא שהתוכנות הבאות מותקנות.

Android SDK Platform Tools

צריך להתקין את כלי הפלטפורמה של Android SDK ולוודא ש-ADB נמצא בנתיב ההפעלה של ה-Shell או הטרמינל שפועלים במחשב המארח. לגרסה שפורסמה לציבור של Android SDK Platform tools, אפשר לעיין בהערות לגבי הגרסה של SDK Platform Tools.

Python

צריך להתקין Python במחשב המארח. מומלץ להשתמש בחבילת הפצה של Python כדי להבטיח תמיכה בגרסאות תואמות. פרטים על גרסאות Python וחבילות שצריך להתקין לגרסה ספציפית מופיעים בנתוני הגרסה של Camera ITS לגרסה המתאימה.

Mobly

ב-Android מגרסה 12 ואילך, צריך להתקין את מסגרת הבדיקה של Mobly. ‫Mobly מאפשר להגדיר DUT ולוח תרשימים בכיתה its_base_test. כדי להתקין את מסגרת הבדיקה Mobly, מריצים את הפקודה:

pip install mobly

הגדרת הסביבה

כדי להגדיר את סביבת הבדיקה, מריצים את הפקודה:

cd CameraITS
source build/envsetup.sh

הפקודה הזו בודקת את ההתקנה של Python, מגדירה את משתנה הסביבה PYTHONPATH ומריצה בדיקות יחידה במודולים utils/*.py. אם לא מוצגות שגיאות בטרמינל, הסביבה מוכנה להרצת בדיקות ITS.

הגדרת סצנה

כדי להגדיר את הסצנות, מומלץ להשתמש בהגדרה של Camera ITS-in-a-box כדי להפוך את הבדיקה לאוטומטית, מהימנה ויעילה. מערכות הבדיקה של ITS-in-a-box תומכות בכל הדרישות של ITS בנוגע לתאורה, למיקום במרכז ולשינוי התרשים. בנוסף, נדרשת ITS-in-a-box כדי לבדוק תוספים למצלמה.

בבדיקות ידניות, חשוב לוודא את הדברים הבאים:

• ה-DUT מונח על חצובה
• מכוונים את ה-DUT לסצנה הנכונה לכל בדיקה. (תסריט הבדיקה של ITS מספק הנחיות לשינוי הגדרת הסצנה לפני התחלת הבדיקות בסצנה חדשה).
• ה-DUT מחובר למחשב המארח באמצעות USB.
• ה-DUT לא זז במהלך הרצת הבדיקה.
• הסצנה מוארת ממקור אור יציב שלא משתנה. (לא מומלץ להשתמש בתאורת פלורסנט כי היא גורמת להבהוב).

תסריט הבדיקה של ITS מציג הנחיה שמבקשת מהמשתמש לשנות את הגדרת הסצנה לפני שמתחילים בדיקות בסצנה חדשה.

צריך להגדיר את כיוון הטלפון כך שהמצלמה תצלם תמונות ללא סיבוב. הדרך הקלה ביותר לבדוק את זה היא באמצעות סצנות הפנים ב-scene2. ברוב הטלפונים, הטלפון נמצא במצב אופקי, כשהמצלמה האחורית מסובבת נגד כיוון השעון והמצלמה הקדמית מסובבת עם כיוון השעון.

קובצי תצורה

כדי להגדיר את סביבת הבדיקה של Mobly, צריך ליצור את קובץ התצורה config.yml באמצעות מסגרת Mobly. הנה כמה דוגמאות לתרחישי שימוש שונים.

קובץ ההגדרות config.yml של סצנות שמבוססות על טאבלט

הקובץ הבא הוא קובץ config.yml לדוגמה של סצנות שמבוססות על טאבלט. בבדיקות שמבוססות על טאבלטים, מילת המפתח TABLET צריכה להופיע בשם של סביבת הבדיקה. במהלך ההפעלה, כלי ההרצה של הבדיקות ב-Mobly מאתחל את הפרמטרים בקובץ ומעביר אותם לבדיקות הספציפיות.

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"  # "True" or "False"; quotes needed
      lighting_cntl: <controller-type>  # "arduino" or "None"; quotes needed
      lighting_ch: <controller-channel>
      camera: 0
      foldable_device: "False". # set "True" if testing foldable
      scene: <scene-name>  # if <scene-name> runs all scenes

כדי להפעיל את סביבת הבדיקה, מריצים את tools/run_all_tests.py. אם אין ערכים בשורת הפקודה שמציינים מצלמות או סצנות, הבדיקה מופעלת עם ערכי הקובץ config.yml. אם יש ערכים של שורת פקודה למצלמות או לסצנות, הם מבטלים את הערכים בקטע TestParams של הקובץ config.yml. לדוגמה:

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=0 scenes=scene_tele
python tools/run_all_tests.py camera=0.4 scenes=4,scene6_tele

הפרמטר chart_scaling

ב-Android מגרסה 17 ואילך, הפרמטר chart_scaling נכלל ב-config.yml עבור TEST_BED_TABLET_SCENES. הפרמטר הזה פותר בעיות של שינוי קנה מידה בתרשימים במכשירים עם מצלמה טלסקופית עם שדה ראייה רחב יותר, ומונע חיתוך של סצנות. בנוסף, הוא מבטיח שהמיקוד של המכשיר יהיה נכון במהלך הבדיקה.

הערכים הנתמכים של chart_scaling הם 1,‏ 0.33,‏ 0.5 או 0.67, כאשר None הוא ברירת המחדל. הגישה הזו מאפשרת למכשירים להשתמש בפקטור אופטימלי של שינוי גודל שמותאם לדרישות הספציפיות שלהם, ולשמור על בדיקות פונקציונליות בכל המכשירים.

אם chart_scaling מוגדר ל-None, הבדיקות קובעות אוטומטית את מקדם קנה המידה באמצעות chart_scaling_logic. אחרת, נעשה שימוש בערך שצוין ב-config.yml, או שמוצגת שגיאה אם שינוי הגודל לא זמין.

זו דוגמה לקובץ config.yml עם הפרמטר chart_scaling

TestBeds:
  -   Name: TEST_BED_TABLET_SCENES  # Need 'tablet' in name for tablet scenes
    # Use TEST_BED_MANUAL for manual testing and remove below lines:
    #     - serial <tablet_id>
    #       label: tablet
    # Test configuration for scenes[0:4, 6]
    Controllers:
        AndroidDevice:
          -   serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
          -   serial: <tablet-id>  # quotes needed if serial id entirely numeric
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # quotes needed
      lighting_cntl: <controller-type>  # can be arduino or "None"
      lighting_ch: <controller-channel>
      camera: <camera-id>
      scene: <scene-name>  # if <scene-name> runs all scenes
      foldable_device: "False"  # "True" if testing foldable device
      chart_scaling: "None"  # use the values available for scene to be tested
      resultstore_upload: "False"  # "True" if results should be uploaded to ResultStore

כדי להפעיל את היכולות של שינוי קנה מידה של תרשים ITS של המצלמה, צריך לבצע התאמות בצד הבדיקה. אם הבדיקה שבה אתם משתמשים לא תומכת בזה, צריך להגיש דוח על באג.

זו דוגמה לשינוי בצד הבדיקה עם הפרמטר chart_scaling.

# load chart for scene
      its_session_utils.load_scene(
          cam, props, self.scene, self.tablet, self.chart_distance,
          chart_scaling=self.chart_scaling)

קובץ sensor_fusion scene config.yml

הקובץ הבא הוא קובץ config_yml לדוגמה לבדיקות sensor_fusion. לצורך בדיקה של sensor_fusion, מילת המפתח SENSOR_FUSION צריכה להופיע בשם של סביבת הבדיקה. ‫Android מגרסה 13 ואילך תומך רק בבקר Arduino לשילוב חיישנים, בגלל בדיקות של תצוגה מקדימה וייצוב סרטונים. ‫Android 12 תומך בבקרים של Arduino ו-Canakit.

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
      rotator_ch: 1
      camera: 0

כדי להריץ בדיקות sensor_fusion באמצעות sensor fusion box, מריצים את הפקודה:

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
python tools/run_all_tests.py scenes=scene_flash,feature_combination
python tools/run_all_tests.py scenes=checkerboard camera=1

קובץ config.yml של כמה סביבות בדיקה

הקובץ הבא הוא קובץ config.yml לדוגמה עם כמה סביבות בדיקה, סביבת בדיקה לטאבלט וסביבת בדיקה sensor_fusion. הסביבה הנכונה לבדיקה נקבעת לפי הסצנות שנבדקות.

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

קובץ ההגדרות config.yml לבדיקה ידנית

הקובץ הבא הוא קובץ config.yml לדוגמה לבדיקה ידנית. ‫Android מגרסה 14 ואילך תומך בבדיקות ידניות לכל הבדיקות, למעט הבדיקות scene_extensions. בבדיקה ידנית, מילת המפתח MANUAL צריכה להופיע בשם של סביבת הבדיקה. בנוסף, אי אפשר לכלול בחלק AndroidDevice סדרות או תוויות לטאבלט.

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

    TestParams:
      debug_mode: "False"
      camera: 0
      scene: 1

קובץ Gen2 rig testing config.yml

הקובץ הבא הוא קובץ config.yml לדוגמה של TEST_BED_GEN2 testbed. סביבת הבדיקה הזו משמשת לבדיקות scene_ip, שבהן נעשה שימוש בערכת בדיקה מדור שני](/docs/compatibility/cts/camera-its-box-gen2). בדוגמה הבאה מוצגים הפרמטרים של סביבת הבדיקה כשהמערכת של Gen2 זמינה והבדיקות של scene_ip לא מדלגות.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: gen2_rotator   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: 0
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: gen2_lights  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: 1
      scene: scene_ip

בדוגמה הבאה מוצגים פרמטרים של סביבת בדיקה כשמערכת Gen2 rig לא זמינה והבדיקות scene_ip מדלגות.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: "None"   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: <controller-channel>
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: "None"  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: <controller-channel>
      scene: scene_ip

כדי להריץ את הבדיקה scene_ip, משתמשים באחת מהפקודות הבאות:

python tests/scene_ip/test_default_jca_ip.py -c config.yml
python tools/run_all_tests.py camera=<camera-id> scenes=scene_ip

הרצת בדיקות ITS

בקטע הזה מוסבר איך מריצים בדיקות ITS.

הפעלת בדיקות

אחרי שמגדירים את המכשיר, את המחשב המארח (כולל הסביבה) ואת הסצנה הפיזית, מריצים את בדיקות ה-ITS באמצעות התהליך הבא.

1. פותחים את אפליקציית CTS Verifier. בתפריט הבדיקות, בוחרים באפשרות Camera ITS Test (בדיקת ITS של המצלמה). ב-Android 17 ואילך, הבדיקות sensor_fusion ו-feature_combination נמצאות בפעילות נוספת בשם Camera ITS Sensor Fusion Rig Test.

2. במכונת המארח, מריצים את בדיקות ה-ITS מהספרייה CameraITS/. לדוגמה, כדי להגדיר מכשיר עם מצלמה קדמית ואחורית, מריצים את הפקודה הבאה:

   python tools/run_all_tests.py

   הסקריפט חוזר על עצמו לגבי מצלמות וסצנות בדיקה על סמך הקובץ config.yml. לצורך ניפוי באגים בהגדרות, מומלץ להפעיל אחת מscene2 הסצנות עם בדיקה אחת כדי לקבל את התוצאות הכי מהר.

   בבדיקות ידניות, לפני שמתחילים להריץ את סדרת הבדיקות של ITS בכל סצנה, הסקריפט מצלם את הסצנה הנוכחית, שומר אותה כקובץ JPEG, מדפיס את הנתיב לקובץ ה-JPEG במסוף ומבקש מהמשתמש לאשר שהתמונה תקינה. תהליך הצילום והאישור הזה חוזר על עצמו עד שהמשתמש מאשר שהתמונה תקינה. אלה ההודעות שמוצגות בתהליך הזה.

   Preparing to run ITS on camera 0
   Start running ITS on camera:  0
   Press Enter after placing camera 0 to frame the test scene:
   scene1_1
   The scene setup should be: A grey card covering at least the   middle 30% of the scene
   Running vendor 3A on device
   Capture an image to check the test scene
   Capturing 1 frame with 1 format [yuv]
   Please check scene setup in /tmp/tmpwBOA7g/0/scene1_1.jpg
   Is the image okay for ITS scene1_1? (Y/N)
   

   בכל הפעלה של הסקריפט מודפס יומן שבו מוצג הערך PASS, ‏ FAIL,‏ FAIL* או SKIP לכל בדיקת ITS. ‫FAIL* מציין שהבדיקה נכשלה, אבל מכיוון שהבדיקה עדיין לא נדרשת, היא תדווח כ-PASS ל-CtsVerifier. ‫SKIP מציין שהבדיקה עברה כי המכשיר לא פרסם את היכולת הבסיסית שנבדקה. לדוגמה, אם מכשיר לא משדר דרך ממשקי המצלמה שהוא תומך ב-DNG, המערכת מדלגת על בדיקות שקשורות לצילום קובץ DNG וסופרת אותן כ-PASS.

3. כדי לאשר שהבדיקות עמדו בדרישות, מקישים על לחצן סימן הווי הירוק. הערך Camera ITS Test בתפריט הבדיקות של CTS Verifier הופך לירוק, וזה מציין שהטלפון עבר את בדיקת Camera ITS.

בדיקה מקבילה של מכשירים

מכשירים עם Android מגרסה 14 ואילך תומכים בבדיקות מקבילות של DUT. כך אפשר לבדוק את ה-DUT במקביל לכמה מתקנים כדי להאיץ את הבדיקה הכוללת. לדוגמה, בדיקה מקבילה מאפשרת לכם לבדוק את מצלמה 0 במערכת אחת ואת מצלמה 1 במערכת אחרת בו-זמנית. ב-Android 17 ואילך, הבדיקות של Camera ITS מחולקות לשתי פעילויות, ולכן אפשר להריץ את הבדיקות sensor_fusion ו-feature_combination במקביל במכשיר אחד, ובדיקות אחרות במכשיר אחר. כל הבדיקות של סשנים של בדיקות מקבילות מצטברות בסשן של CTS Verifier ב-DUT של ההפניה. חובה להריץ בדיקות מקבילות עם בקרת תאורה של Arduino, כי בדיקות מקבילות לא תומכות בבקרת תאורה ידנית. מוודאים שערוץ אחר באותו בקר Arduino שולט בתאורה של כל מתקן.

הקובץ הבא הוא קובץ config.yml לדוגמה שמגדיר שלוש סביבות בדיקה להרצה במקביל.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES_INDEX_0
    Controllers:
        AndroidDevice:
          - serial: <device-id-0>
            label: dut
          - serial: <tablet-id-0>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-0>
      camera: 0
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  - Name: TEST_BED_TABLET_SCENES_INDEX_1
    Controllers:
        AndroidDevice:
          - serial: <device-id-1>
            label: dut
          - serial: <tablet-id-1>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-1>
      camera: 1
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  # TEST_BED_SENSOR_FUSION represents testbed index 2
  # Parallel sensor_fusion is currently unsupported due to Arduino requirements
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion
    Controllers:
        AndroidDevice:
          - serial: <device-id>
            label: dut
    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: "arduino"
      rotator_ch: <controller-channel-2>
      camera: <camera-id>
      foldable_device: "False"
      tablet_device: "False"
      lighting_cntl: "None"
      lighting_ch: <controller-channel>
      scene: "sensor_fusion"

כדי להריץ את סביבות הבדיקה במקביל, משתמשים בפקודה הבאה:

for i in 0 1 2; do python3 tools/run_all_tests.py testbed_index=$i num_testbeds=3 & done; wait

שליחת תוצאות בדיקה מצטברות

ב-Android 17 ואילך, אפשר לשלוח תוצאות מצטברות של בדיקות ITS של המצלמה לאישור בנייה. ‫CTS Verifier מאפשר לבדוק בו-זמנית כמה סצנות בכמה מכשירים, ולצבור תוצאות בדיקה מכמה דוחות של CTS Verifier (מריצות בדיקה או ממכשירים שונים) לשליחה מאוחדת אחת.

תהליך השליחה

כדי לשלוח תוצאות מצטברות של Camera ITS לאישור בנייה, פועלים לפי השלבים הבאים:

1. מכינים את המכשירים: אוספים שניים או שלושה מכשירים שנבדקים (DUT) עם טביעת אצבע זהה של גרסת ה-build.
2. מתקינים את CTS Verifier: מתקינים את קובץ ה-APK העדכני של CTS Verifier, שאפשר להשיג אותו מ-Build Explorer שסופק.

3. הרצת בדיקות במקביל:

   1. מרכיבים את המכשירים לבדיקה במתקנים נפרדים.
   2. להריץ סצנות שונות של Camera ITS בכל מכשיר בו-זמנית.
   3. אוסף דוחות: שליפת דוח CTS Verifier אחרי כל הרצה. זה כולל דוחות שבהם סצנות נכשלו. רק סצנות שנכשלו יופעלו מחדש בהפעלות הבאות.

4. שליחת דוחות: העלאה של כמה דוחות CTS Verifier שנאספו מכל המכשירים.

5. בדיקת התוצאות: אחרי העלאת הדוחות, בודקים את התוצאות המצטברות:

   • בקטע Test Analysis (ניתוח הבדיקה) מוצגת רשימה מלאה של כל הסצנות שהופעלו.

   • סצנות שלא בוצעו או שנכשלו מופיעות בקטע נכשלו.

     

     איור 1. תיעוד של סצנות שלא בוצעו או נכשלו.

   • סצנות שבהן יש כרטיס מנוי מפורטות בקטע כרטיס מצטבר.

     

     איור 2. סצנות שסווגו כ'מעבר מצטבר'

סטטוס אישור של בנייה

האישור לבנייה ניתן אחרי שכל הסצנות הנדרשות הושלמו בהצלחה בדוחות המצטברים.

מודל רעש DNG

במכשירים שמפרסמים את היכולת לצלם בפורמט RAW או DNG, צריך לספק מודל רעש במטא-נתונים של תוצאת הצילום של כל תמונה בפורמט RAW. מודל הרעש הזה צריך להיות מוטמע ב-HAL של המצלמה עבור כל מצלמה (לדוגמה, מצלמה קדמית ומצלמה אחורית) במכשיר שמוצהר לגביו שהוא תומך.

הטמעה של מודל רעש

כדי להטמיע מודל רעשים, פועלים לפי השלבים הבאים ליצירת מודל רעשים ולהטמעת המודל ב-HAL של המצלמה.

1. כדי ליצור מודל רעש לכל מצלמה, מריצים את הסקריפט dng_noise_model.py בספרייה tools. הפלט הוא קטע קוד בשפת C. למידע נוסף על הגדרת המצלמה וסביבת הצילום, אפשר לעיין במסמך DngNoiseModel.pdf בספרייה tools.

2. כדי להטמיע את מודל הרעש במכשיר, גוזרים את קטע הקוד ב-C ומדביקים אותו ב-HAL של המצלמה.

אימות של מודל רעש

בדיקת ה-ITS האוטומטית tests/scene1_1/test_dng_noise_model.py מאמתת את מודל הרעש על ידי בדיקה שהערכים של הרעש בחשיפה ובגיין שמופיעים בנתוני המצלמה נכונים.

בדיקות שעברו בקושי (סטטוס הבדיקה PASS*)

ב-Android 17 ואילך, העברה שולית (PASS*) מציינת שהבדיקה עברה, אבל מדדי הביצועים שלה קרובים מאוד לסף המעבר שהוגדר מראש. למרות שהבדיקה עומדת מבחינה טכנית בקריטריונים של מעבר, הקרבה לגבול הכשל מצביעה על הצורך בבדיקה מדוקדקת יותר.

היתרונות של מעבר שולי

לסטטוס של PASS* יש כמה יתרונות:

• מערכת אזהרה מוקדמת: מזהה בדיקות שעומדות להיכשל, ומאפשרת לצוותים לטפל בבעיות לפני שהן מובילות לכשלים מוחלטים.

• אופטימיזציה פרואקטיבית: מעודדת צוותים לבצע אופטימיזציה של בדיקות וקודים שפועלים בחלק התחתון של הטווח המקובל, וכך משפרת את היציבות הכוללת.

• שיפור האיכות: עוזר לשמור על רמת איכות גבוהה יותר על ידי סימון אזורים שעלולים להיות רגישים לרגרסיות עתידיות עם שינויים קלים בקוד.

• קיצור זמן הניפוי באגים: אם תזהו את הבדיקות של PASS* בשלב מוקדם, תוכלו לקצר משמעותית את הזמן והמאמץ שיידרשו לניפוי באגים של כשלים מלאים בעתיד.

פרטים על כרטיס המועדון*

הסטטוס PASS* כולל את האפשרויות הבאות:

• הגדרת ערכי סף: ערכי סף ספציפיים למעבר שולי מוגדרים לכל בדיקה רלוונטית ב-Camera ITS.

• זיהוי אוטומטי: מערכת האוטומציה של הבדיקות מזהה ומסווגת בדיקות כ-PASS* על סמך הספים המוגדרים.

• מנגנון התראות: הצוותים מקבלים התראות אוטומטיות על כל הבדיקות שמסומנות כPASS*, וההתראות מפנות אותם לבדוק את הבדיקה הספציפית ואת המדדים שלה.

• דיווח: סטטוסי מעבר שוליים מסומנים בבירור בדוחות הבדיקה ובמרכזי הבקרה כדי לשפר את הנראות שלהם. הם מסומנים בסימן PASS* בדוח ItsTestSummary, בדומה לסימן Fail* בבדיקות not_yet_mandated. הבדיקה ממשיכה להיות מסומנת בירוק כי היא ממשיכה לעמוד בסף שהוגדר, כדי למנוע בלבול נוסף. הסטטוס PASS* רלוונטי רק למחלקת בדיקה, ולא לכל הסצנה. לדוגמה, אפשר להחשיב את Scene_0 כ-PASS גם אם test_jitter ו-test_metadata הם PASS*.

• מעקב: נתוני הביצועים נאספים בבדיקות שעוברות באופן חלקי במכשיר. כך אפשר לעקוב אחרי שיפורים עתידיים במצלמות שמבצעים יצרני ציוד מקורי (OEM), אם הבדיקות האלה עוברות לסטטוס PASS.

הדוגמה הבאה ממחישה תוצאות בדיקה עם PASS*:

INFO:root:Reporting camera 1 ITS results to CtsVerifier
INFO:root:ITS results to CtsVerifier: {'scene0': {'result': 'PASS', 'TEST_STATUS': [{'test': 'test_jitter', 'status': 'PASS*'}, {'test': 'test_metadata', **'status': 'PASS*'**}, {'test': 'test_request_capture_match', 'status': 'PASS'}, {'test': 'test_sensor_events', 'status': 'PASS'}, {'test': 'test_solid_color_test_pattern', 'status': 'PASS'}, {'test': 'test_test_patterns', 'status': 'SKIP'}, {'test': 'test_tonemap_curve', 'status': 'SKIP'}, {'test': 'test_unified_timestamps', 'status': 'PASS'}, {'test': 'test_vibration_restriction', 'status': 'PASS'}], 'mpc_metrics': [], 'performance_metrics': [], 'feature_query_proto': [], 'feature_query_proto_path': [], 'summary': '/tmp/CameraITS_zojk4sdr/cam_id_1/scene0/scene_test_summary.txt', 'start': 1754330630345, 'end': 1754330764534}, 'scene1_1': {'result': 'NOT_EXECUTED'}, 'scene1_2': {'result': 'NOT_EXECUTED'}, 'scene1_3': {'result': 'NOT_EXECUTED'}, 'scene2_a': {'result': 'NOT_EXECUTED'}, 'scene2_b': {'result': 'NOT_EXECUTED'}, 'scene2_c': {'result': 'NOT_EXECUTED'}, 'scene2_d': {'result': 'NOT_EXECUTED'}, 'scene2_e': {'result': 'NOT_EXECUTED'}, 'scene2_f': {'result': 'NOT_EXECUTED'}, 'scene2_g': {'result': 'NOT_EXECUTED'}, 'scene3': {'result': 'NOT_EXECUTED'}, 'scene4': {'result': 'NOT_EXECUTED'}, 'scene6': {'result': 'NOT_EXECUTED'}, 'scene7': {'result': 'NOT_EXECUTED'}, 'scene8': {'result': 'NOT_EXECUTED'}, 'scene9': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_hdr': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_low_light': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene6_tele': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene7_tele': {'result': 'NOT_EXECUTED'}, 'scene_video': {'result': 'NOT_EXECUTED'}, 'scene5': {'result': 'NOT_EXECUTED'}, 'sensor_fusion': {'result': 'NOT_EXECUTED'}, 'feature_combination': {'result': 'NOT_EXECUTED'}, 'scene_flash': {'result': 'NOT_EXECUTED'}, 'scene_ip': {'result': 'NOT_EXECUTED'}}

מומלץ לשותפים:

• מעקב אחרי התראות של PASS*
• בדיקת שורש הבעיה של בדיקות PASS*
• אופטימיזציה יזומה של בדיקות וקוד שזוהו כPASS*

מטרת הסטטוס PASS* היא לשפר את החוסן והמהימנות של בדיקות Camera ITS, כדי להגיע למוצר יציב ואיכותי.