נתוני הגרסה של חבילת 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 (מארז ל-ITS) עם שדה ראייה רגיל (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 box (rev1a) ו-WFoV box (rev2.9).

בקר חדש למיזוג נתונים מהחיישנים

החומרה של בקר שילוב החיישנים עוצבה מחדש כדי לשפר את יכולת הייצור. הבקר החדש מבוסס על Arduino, עם מגן מותאם אישית של לוח ניתוב שמתחבר ל-Arduino. באיור 1 מוצג המגן, ובאיור 2 מוצגת התרשים המכני של המארז. הבקר החדש מופעל על ידי ספק יחיד של 5 V שמפעיל את המנוע ישירות. השליטה על האלקטרוניקה מתבצעת באופן מלא דרך מחבר ה-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 (סימן לכרומה), מטריצה של כרומה בגודל 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% את הממוצעים של מטריצת הקידוד.
• עומסי העבודה של מטריצות DQT הם מספרים ריבועיים.

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

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

scene2_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 פריימים אחורה כדי לקבל שינוי סצנה בצילום.

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

• מתגים של מסך (סצנה).
• הדגל 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