הערות גרסה של Android 11 Camera Image Test Suite

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

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

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

יצרן נוסף

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

שיטות ייצור אחידות

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

להורדת התיאורים והשרטוטים המכניים העדכניים ביותר, ראה תיבת RFoV (rev1a) ו- WFoV box (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) .

בקר היתוך חיישנים חדש

החומרה עבור בקר היתוך החיישן עוצבה מחדש כדי לשפר את יכולת הייצור. הבקר החדש מבוסס על ארדואינו , עם מגן לוח ניתוב מותאם המותקן על גבי הארדואינו. איור 1 מציג את המגן ואיור 2 מציג את השרטוט המכני של המתחם. הבקר החדש מופעל על ידי אספקת 5 וולט בודדת שמניעה את המנוע ישירות. האלקטרוניקה נשלטת לחלוטין דרך מחבר ה-USB. ספק הכוח הנפרד מאפשר בידוד מוחלט בין אלקטרוניקת הבקרה למנוע הסרוו. בנוסף, בקר יחיד יכול לשלוט על עד שישה מנועי סרוו.

מבט מלמעלה של ארדואינו

איור 1. מבט מלמעלה של מגן Arduino

עיצוב מארז

איור 2. עיצוב המארז

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

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

לדוגמה:

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

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

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

שינוי שם הסצנה

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

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

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

  • סצנות עם אותו תרשים, אבל מבחנים שונים: *_1,2,3
  • סצנות עם תרשימים שונים, אך אותם מבחנים: *_a,b,c
סְצֵינָה מספר מבחנים זמן ריצה של Pixel 4 (דקה:שניות)
0 11 1:12
1_1 22 5:12
1_2 13 5:20
2_א 5 3:22
2_ב 1 0:24
2_ג 1 0:24
3 6 2:04
4 2 2:46

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

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

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

סְצֵינָה שם המבחן רמת API ראשונה תיאור
0 test_tonemap_curve 30 ודא שלצינור יש פלטי צבע נאותים עם מפת גוונים ליניארית וקלט תמונה אידיאלי (מסתמך על test_test_patterns ).
1 test_ae_precapture_trigger 29 בדוק את מכונת מצב ה-AE בעת שימוש בטריגר ה-precapture. ודא שעם AE מושבת שלטריגר לכידה מוקדמת אין השפעה.
test_channel_saturation 29 ודא כי ערוצי RGB רוויים לערכים דומים כדי למנוע גוון באזורים רוויים.
2_a/b/c test_num_faces 29 הגדל את גיוון הגילאים בסצנות פנים.

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

הבדיקות בטבלה הבאה מעודכנות באנדרואיד 11. השינויים מתוארים בעמודה תיאור השינויים .

סְצֵינָה שם המבחן רמת API ראשונה תיאור השינויים
1 test_burst_sameness_manual 30 הפחת את הסובלנות ל-2%.
4 test_aspect_ratio_and_crop 30 שנה להפעלה במכשירים מוגבלים.
test_multi_camera_alignment 30 עברו דרך המצלמות בנפרד אם צילום מרובה מצלמות אינו נתמך. עבד מחדש את הלוגיקה של בחירת המצלמה כדי לקחת בחשבון מערכות של שלוש וארבע מצלמות, ולדלג על מצלמות מונו, עומק בלבד ו-IR.

מבחנים חדשים

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

סְצֵינָה שם המבחן רמת API ראשונה תיאור
0 test_vibration_restrictions 30 ודא שהתרעות ורעידות אינן מופעלות במהלך לכידת תמונה.
2_א test_jpeg_quality 30 בדוק שטבלאות קוונטיזציה מפחיתות את הדחיסה לאיכות JPEG מוגברת.
2_d/2_e test_num_faces 30 הגדל את גיוון גיל הפנים.
2_ה test_continuous_picture 30 ודא ש-3A מתיישב ב- android.control.afAvailableModes = CONTINUOUS_PICTURE.
שינוי test_scene_change 31 android.control.afSceneChange נטען עם שינוי הסצנה.
6 test_zoom 30 בדוק את android.control.zoomRatioRange .

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 עבור סמן ה-chroma נראה עקבי עבור מספר מכשירים כולל טלפונים שמפרידים בין שתי המטריצות למקטעי DQT נפרדים בקובץ ה-JPEG. למטריצות Luma נוטות להיות מגוון גבוה יותר של ערכים בהשוואה למטריצות כרומה מכיוון שהעין האנושית רגישה יותר ללומה מאשר תמונות כרומה ותמונות JPEG לוקחות זאת בחשבון.

מטריצות לומה ו-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 גדלה, רמת הדחיסה (ממוצע של מטריצת luma/chroma DQT) יורדת.

ערכי מטרה ממוצעים של Pixel 4

איור 3. ממוצעים של מטריצת מצלמה אחורית של Pixel 4 luma/chroma DQT לעומת איכות JPEG

טוען

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

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

דוגמה למבחן נכשל

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

scene2_d/e test_num_faces

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

סצנה2_ד

איור 5. scene2_d

סצנה2_ה

איור 6. scene2_e

טוען

  • num_faces == 3

scene2_e/test_continuous_picture

שיטה

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

מערכת 3A צפויה להתיישב בתום לכידת 50 פריימים.

טוען

  • 3A נמצא במצב התכנס בסוף הלכידה.

סצנה_change/test_scene_change

שיטה

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

בנוסף, לבדיקה ידנית, ניתן לבצע את שינוי הסצנה על ידי הנפת יד מול המצלמה.

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

דיאגרמת תזמון עבור test_scene_change

איור 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 עם גבול שחור מכסה את כל הטאבלט. עיגול אחד מוחלף בריבוע בפינה הימנית העליונה כדי להראות כיוון. לגדלי העיגול יש תכונה בשטח של כ-7500 פיקסלים ( radius=50pixels ) לחיישן 4000x3000 שנלכד עם שדה ראייה (FoV) של כ-80 מעלות.

סצנת test_zoom

איור 8. סצנת test_zoom

עיגול נמצא Pixel 4

איור 9. זום של מצלמת Pixel 4[0] = [1, 3.33, 5.67, 8] תמונות עם עיגול שנמצא

איור 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 .
  • קנה המידה של רדיוס עיגול עם זום (RTOL 10% מהצפוי).
  • היסט מרכז עיגול מקנה המידה המרכזי עם זום (RTOL 10% מהצפוי).
  • הושגה רמת זום מספקת (2x).

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

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

סְצֵינָה שם המבחן
0 test_vibration_restrictions
2_א test_jpeg_quality
2_d/2_e test_num_faces
4 test_aspect_ratio_and_crop
6 test_zoom

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

  • 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