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

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

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

שינויים בחומרה

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

• יצרן נוסף
• שיטות ייצור מאוחדות
• אפשרויות נוספות לטאבלטים
• צמצום הפתיחה של הטאבלט
• בקר חדש של מיזוג חיישנים

יצרן נוסף

חברת Rahi Systems מוסמכת לייצר מארזי בדיקה של ITS בנוסף לספק הקיים שלנו, MYWAY design. פרטי החברה של ספקים שעומדים בדרישות הם:

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

כדי להוריד את התיאורים והשרטוטים המכניים העדכניים, אפשר לעיין בקופסת RFoV (גרסה 1a) ובקופסת WFoV (גרסה 2.9).

אפשרויות נוספות לטאבלט

טאבלטים, כולל Samsung Galaxy Tab A 10.1 ו-Chuwi Hi9 Air 10.1, נוספו לרשימת הטאבלטים המומלצים. חשוב שלטאבלט לא יהיה אפנון רוחב פולס (PWM) כדי להתאים את בהירות המסך ולמנוע פסים בתמונות שצולמו.

מידע עדכני על טאבלטים מומלצים זמין במאמר בנושא דרישות לטאבלטים.

פתיחה מופחתת של טאבלטים

כדי לאפשר שימוש ב-Galaxy Tab A 10.1, הגובה של הפתח בטאבלט קטן יותר במעט עבור מארזי הבדיקה של RFoV (גרסה 1a) ו-WFOV (גרסה 2). העדכונים שמשקפים את השינויים האלה הם rev1a.1 ו-rev2.9. לשרטוטים האלה, אפשר לעיין בתיבת RFoV (גרסה rev1a) ובתיבת WFoV (גרסה 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, כלומר בדיקה יכולה להיכשל אבל להיכלל בטבלה כ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. השינויים מתוארים בעמודה תיאור השינויים.

בדיקות חדשות

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

scene0/test_vibration_restriction

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

טענות

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

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 (luma marker), 8x8 luma matrix, 1 (chroma marker), 8x8 chroma matrix].

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

למטה מוצגות דוגמאות של מטריצות בהירות וצבע שחולצו עבור גורמי איכות של 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

טענות

• עבור [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

טענות

• num_faces == 3

scene2_e/test_continuous_picture

שיטה

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

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

טענות

• ‫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 כשהזום גדל מ-1 ל-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]

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

טענות

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

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

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