נתוני הגרסה של חבילת Android 11 לבדיקת תמונות במצלמה

בדף הזה מפורט סיכום של השינויים ב-Camera Image Test Suite‏ (ITS) ב-Android 11. השינויים מתחלקים לקטגוריות הבאות:

• שינויים בחומרה
• בדיקות חובה ברמת ה-API
• תאורת הבדיקה אומתה
• שינויים בשם הסצנה
• בדיקת שינויים והוספות
• בדיקות מצלמה מורחבות ומוגבלות

שינויי חומרה

ב-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 ITS-in-a-box עם שדה ראייה רגיל (RFoV) עוצב מחדש כך שישתמש בשיטות הייצור שבהן נעשה שימוש במארזי הבדיקה של הקופסה עם שדה ראייה רחב (WFoV) ושל הקופסה עם שילוב חיישנים. הפונקציונליות זהה, ולשם פשטות, העיצוב נקרא rev1a. העיצוב החדש מאפשר ליצרנים לאחסן סוג אחד של פלסטיק כדי לייצר את כל מארזי הבדיקות. בנוסף, עיצוב המתקן לטאבלט והתושבות של התאורה השתנה כדי להתאים למגוון רחב יותר של טאבלטים ופסי תאורת 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 וולט שמפעיל את המנוע ישירות. האלקטרוניקה נשלטת באופן מלא באמצעות מחבר ה-USB. ספק הכוח הנפרד מאפשר בידוד מלא בין האלקטרוניקה של הבקרה לבין מנוע הסרבו. בנוסף, ניתן לשלוט באמצעות בקר יחיד בעד שישה מנועי סרוו.

איור 1. מבט עליון על Arduino shield

איור 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 יכולות להיכשל, אבל הן מופיעות בטבלה כ-PASS לצורך דיווח של גורם אימות CTS. הדרישה לבדיקות MANDATED חלה גם על מכשירים משודרגים. הדרישה הזו למכשירים משודרגים שעומדים בכל הבדיקות של MANDATED גרמה לעיכוב בהפיכת בדיקות לבדיקות MANDATED, כי גם מכשירי דור קודם צריכים לעמוד בבדיקות.

ב-Android 11, הבדיקות של MANDATED מוגבלות על ידי הדגל הראשון ברמת ה-API מנכסי הטלפון. במכשירים שמשודרגים ל-Android 11, הבדיקות פועלות כבדיקות NOT_YET_MANDATED. כלומר, בדיקה יכולה להיכשל אבל להופיע בטבלה כ-PASS ב-CtsVerifier.apk.

לדוגמה:

• ב-Android 11, הבדיקה test_channel_saturation היא MANDATED במכשירים עם רמת API ראשונה גבוהה מ-29.
• ב-Android 10, הערך של הבדיקה test_channel_saturation הוא MANDATED בכל המכשירים.

אימות התאורה בסצנה

ב-Android 11, התאורה בסצנה מאומתת על ידי ניתוח הבהירות בפינות הסצנה. כל הסצנות הידניות מאומתות לתאורה, וסצנות מבוססות-טאבלט מאומתות למצלמות RFoV במתקן הבדיקה RFoV ולמצלמות WFoV במתקן הבדיקה WFoV. אם רמות התאורה לא מספיקות, תדווח שגיאה והבדיקה תיכשל.

שינויים בשמות של סצנות

ב-Android 10, סצנה 1 אחראית לרוב הבדיקות ולחלק גדול מזמן הבדיקה הכולל. אם אחת מהבדיקות בסצנה 1 נכשלת, צריך להריץ מחדש את כל הסצנה. מטבע הדברים, הפעלה מחדש של כל הסצנה מפחיתה את מספר הבדיקות שחולפות. ב-Android 11, זמני ההפעלה מחדש מופחתים על ידי פיצול סצנה 1 לשתי סצנות, scene1_1 ו-scene1_2.

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

בנוסף, מתבצע ניקוי של השמות. סצנה 2 מפוצלת עם אותיות וסצנה 1 מפוצלת במספרים. השמות של התוספים השונים הם:

• סצנות עם אותו תרשים, אבל עם בדיקות שונות: *_1,2,3
• סצנות עם תרשימים שונים, אבל עם אותם בדיקות: *_a,b,c

בדיקת השינויים

הבדיקות עודכנו כך שישתמשו ברמת ה-API הראשונה

ב-Android 11, הבדיקות בטבלה הבאה מתעדכנות לשימוש בדגל הראשון של רמת ה-API. בכל הבדיקות האלה נעשה שימוש ברמת API ראשונה של 29, מלבד הבדיקה test_tonemap_curve שבה נעשה שימוש ברמת API ראשונה של 30.

בדיקות עם שינויים

הבדיקות בטבלה הבאה מתעדכנות ב-Android 11. השינויים מתוארים בעמודה Description of changes.

בדיקות חדשות

הבדיקות בטבלה הבאה מופעלות ב-Android 11. הבדיקה מסכמת בטבלה, ותיאורים מפורטים מופיעים בקטעים הבאים.

scene0/test_vibration_restriction

בבדיקה הזו אין צורך בסצנה ספציפית, אבל צריך להניח את המכשיר בבדיקה (DUT) על משטח קשיח או להתקין אותו על משטח קשיח. כולל הרכבה על מארזי הבדיקה של ITS-in-a-box.

טענות לנכונות (asserts)

• אין רטט במהלך השימוש במצלמה

scene2_a/test_jpeg_quality

שיטה

חלקים שונים בקובץ ה-JPEG מוגדרים באמצעות סמנים של 2 בייטים. מידע נוסף זמין במאמר JPEG.

הבדיקה מחלצת את מטריצות הקידוד מהקובץ ה-JPEG שצולם. הסמן של מטריצות הקידוד בצילום ה-JPEG הוא הרצף [255, 219]. כשהסימן נמצא, שני הפריטים הבאים ברשימה הם הגודל. סמן הגודל של DQT ב-JPEG הוא בדרך כלל [0, 132] = 256*0+132 = 132, והוא מייצג את הגודל של נתוני DQT בצילום ה-JPEG. הנתונים המוטמעים מופיעים בפורמט: [255, 219, 0, 132, 0 (סמן לומה), מטריצת לומה 8x8, 1 (סמן Chroma), מטריצת Chroma 8x8].

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

בהמשך מוצגות דוגמאות למטריצות luma ו-chroma שחולצו עם גורמי איכות של 85 ו-25, עבור המצלמה האחורית של Pixel 4 שצילמה את scene2_a במתקן הבדיקה של ITS. ערכי המטריצה עולים באופן משמעותי (מצביע על דחיסת נתונים מוגברת) בהגדרת האיכות הנמוכה יותר. המטריצות האלה מודפסות עם הסקריפט רק אם מפעילים את הדגל 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. ממוצעים של מטריצות DQT של לומה/כרומה במצלמה האחורית של Pixel 4 לעומת איכות JPEG

טענות לנכונות (asserts)

• עבור [25, 45, 65, 86], הוספת 20 לאיכות מפחיתה ב-20% את הממוצעים של מטריצת הקידוד.
• מטענים ייעודיים (payloads) של מטריצות DQT הם מספרים ריבועיים.

באיור 4 מוצגת דוגמה של טלפון שנכשל בבדיקה. שימו לב שבתמונות באיכות נמוכה מאוד (jpeg.quality < 50), אין עלייה בדחיסה במטריצת הקוונטיזציה.

איור 4. דוגמה לבדיקה שנכשלה

segment2_d/e test_num_faces

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

איור 5. scene2_d

איור 6. scene2_e

טענות לנכונות (asserts)

• num_faces == 3

scene2_e/test_continuous_picture

שיטה

הבדיקה test_continuous_picture משתמשת בסצנה scene2_e, אבל אפשר להפעיל אותה עם כל אחת מהסצנות של הפנים. בבדיקה הזו מתועדים 50 פריימים של רזולוציית VGA באמצעות ההגדרה הראשונה של בקשת ההקלטה android.control.afMode = 4 (CONTINUOUS_PICTURE).

מערכת ה-3A אמורה להתייצב בסוף צילום של 50 פריימים.

טענות לנכונות (asserts)

• 3A נמצא במצב משולב בסוף הצילום.

scene_change/test_scene_change

שיטה

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

בנוסף, לצורך בדיקה ידנית, אפשר להניף את היד מול המצלמה כדי לשנות את הסצנה.

איור 7 מציג דיאגרמת תזמון של הבדיקה. התזמון בין כיבוי המסך לבין הצילום מתכוונן על סמך תוצאות האירועים מתמונות קודמות.

איור 7. תרשים תזמון של test_scene_change

תנאי השינוי:

• אם יש שינוי סצנה ו-afSceneChange == 1, הבדיקה מחזירה את הערך PASS.
• אם יש שינוי סצנה ו-afSceneChange == 0, שינוי הסצנה יועבר 5 פריימים אחורה כדי לתת יותר זמן ל-afSceneChange לבצע טענת נכוֹנוּת.
• אם לא חל שינוי בסצנה ו-afSceneChange == 1, הבדיקה תחזיר את הערך FAIL.
• אם לא חל שינוי בסצנה ו-afSceneChange == 0, שינוי הסצנה יזוז 30 פריימים מוקדם יותר כדי לצלם את השינוי בסצנה.

הצהרות

• מתגים של מסך (סצנה).
• הדגל afSceneChange נמצא בטווח [0, 1].
• אם אין שינוי סצנה, 3A מתכנס (פונקציונלית זהה ל-test_continuous_picture).
• אם afSceneChange == 1, הבהירות חייבת להשתנות בסצנה.
• PASS בתוך שישה ניסיונות עם התזמון השתנה על סמך התוצאות הקודמות.

scene6/test_zoom

שיטה

כדי לבדוק את android.control.zoomRatioRange צריך סצנה חדשה, כי בסצנות הקיימות אין מאפיין קטן מספיק כדי להגדיל אותו (סצנות [1, 2, 4]) או שיש בסצנה הרבה אובייקטים שקשה לזהות, מה שמקשה על חילוץ המאפיינים (סצנה 3).

באיור 8 מוצגת הסצנה החדשה עם מערך קבוע של עיגולים. מערך העיגולים מאפשר להקל על הדרישות לגבי מרכזת ה-DUT או התרשים, ומאפשר עיגולים שיוצגו תמיד ליד מרכז התמונה שצולמה. בסצנה הזו, מערך של 9x5 עיגולים עם מסגרת שחורה מכסה את כל הטאבלט. כדי לציין את הכיוון, עיגול אחד מוחלף במרובע בפינה השמאלית העליונה. בגדלי העיגולים יש תכונה עם שטח של כ-7,500 פיקסלים (radius=50pixels) בחיישן בגודל 4,000x3,000 שצולם עם שדה ראייה (FoV) של כ-80 מעלות.

איור 8. הסצנה test_Zoom

איור 9. Pixel 4 cam[0] zoom = [1, 3.33, 5.67, 8] images with found circle

באיור 9 מוצגות תמונות שצולמו במצלמה האחורית של Pixel 4 כשהזום עולה מ-1x ל-8x בארבעה שלבים. קבוצת התמונות הזו מצולמת ללא מחשבה מיוחדת במרכז, מלבד שימוש בצמצם הבדיקה של הטלפון עם שני פתחים, כדי לאפשר בדיקה של המצלמה הקדמית והאחורית. צפוי שינוי ממישור האמצע, והוא ניכר בכך שחלון התרשים נמצא מעט שמאלה ממרכז המסך. בנוסף, נראה שהתרשים מספיק לבדיקה עם יחסי מרחק מהתצוגה גבוהים מ-8x.

חיפוש מעגלים

הבדיקה כוללת שיטה find_circle() באמצעות findContours שמאתרת את כל קווי המתאר ומצמצמת את החיפוש של קווי המתאר לחישורים הרצויים על ידי בדיקה של האפשרויות הבאות:

• השטח של קווי המתאר חייב להיות גדול מ-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]

התכונה 'הגדלת התצוגה' מופסקת אם העיגול שנמצא נוגע בגבולות התמונה. יש בדיקה כדי לוודא שהגעתם לרמת זום מספקת בבדיקה (10x).

טענות לנכונות (asserts)

• בכל הגדרת זום מופיעה לפחות עיגול אחד.
• המערכת בודקת 10x או עד android.control.zoomRatioRange.
• רדיוס המעגל משתנה בהתאם לזום (RTOL 10% מהערך הצפוי).
• מרכז מעגלי הסטה מקנה המידה המרכזי עם זום (RTOL 10% מהמצופה).
• הגעת לרמת זום מספקת (2x).

בדיקה משופרת של המצלמה מוגבלת

ב-Android 11, בבדיקות שבטבלה הבאה נבדקות LIMITED מצלמות. בנוסף לבדיקות החדשות, הבדיקה של scene4/test_aspect_ratio_and_crop מעודכנת כדי לאפשר בדיקה של מכשירי LIMITED עם רמת API ראשונה של 30 ומעלה.

באיור 10 מוצג טבעת הפענוח הסודית של ITS ב-Android 11. טבעת המפענח הסודי מציגה את הגדרות הבדיקה שמוגבלות לכל בדיקה. השער מקודד לפי צבע כדי לפשט את הצפייה. הפריטים העיקריים שצריך לעמוד בהם כדי לקבל אישור הם:

• MANUAL_SENSOR
• READ_3A *נדרש MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *נדרש MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS *REALTIME
• MULTI_CAMERA

השגת רוב הבדיקות ב-MANUAL SENSOR, READ_3A, COMPUTE_TARGET_EXPOSURES ו-PER_FRAME_CONTROL. בנוסף, בדיקות שמופעלות במכשירי LIMITED מודגשות בירוק בהיר.

איור 10. טבעת מפענח סודית ל-Android 11