נתוני הגרסה של חבילת 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 בדיקות ייכשלו, אבל הן יופיעו כNOT_YET_MANDATED בדוחות של CTS Verifier.PASS הדרישה של MANDATED tests רלוונטית גם למכשירים משודרגים. הדרישה הזו שמכשירים משודרגים יעברו את כל הבדיקות של 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]. כשמוצאים את הסמן, שני הפריטים הבאים ברשימה הם הגודל. סמן הגודל של JPEG DQT הוא בדרך כלל [0, 132] = 256*0+132 = 132, שזה הגודל של נתוני DQT בצילום JPEG. הנתונים המוטמעים הם מהצורה: [255, 219, 0, 132, 0 (סמן בהירות), מטריצת בהירות 8x8, ‏ 1 (סמן צבע), מטריצת צבע 8x8].

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

חיפוש מעגלים

הבדיקה כוללת שיטה 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).

טענות

• לפחות עיגול אחד נמצא בכל הגדרת זום.
• המערכת בודקת פי 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