בדיקות ITS למצלמה

בדף הזה מופיעה רשימה מקיפה של הבדיקות במסגרת חבילה לבדיקת תמונות מצלמה (ITS), שהיא חלק ממכשיר האימות של חבילה לבדיקות תאימות ל-Android‏ (CTS). בדיקות ITS הן בדיקות פונקציונליות, כלומר הן לא מודדות את איכות התמונה, אלא את העובדה שכל הפונקציות של המצלמה שפורסמו פועלות כמצופה. המסמך הזה מאפשר למפתחים ולבודקים להבין מהם המבחנים השונים ואיך לנפות באגים במבחנים שנכשלו.

שער ITS של מצלמה מבצע בדיקות לפי מאפייני המצלמה הנדרשים, רמת ה-API ורמת הביצועים של המדיה (MPC). ברמת ה-API, מערכת ITS משתמשת ב-ro.product.first_api_level כדי לפקח על בדיקות שנוספו ברמת API ספציפית, ובודקות חוויית משתמש שלילית של פונקציונליות ברמות API נמוכות יותר. ‏ITS משתמש ב-ro.vendor.api_level כדי לפקח על בדיקות של תכונות שנוספו ברמת API ספציפית, שדורשות יכולות חומרה חדשות. אם הערך ro.odm.build.media_performance_class מוגדר למכשיר, מערכת ITS דורשת להריץ בדיקות ספציפיות בהתאם לרמת ה-MPC.

הבדיקות מקובצות לפי סצנה באופן הבא:

  • scene0: תיעוד מטא-נתונים, רעידות, גירוסקופ, רטט
  • scene1: חשיפה, רגישות, פיצוי של ערך חשיפה (EV), YUV לעומת JPEG ו-RAW
  • scene2: זיהוי פנים, בדיקות שדורשות סצנות צבעוניות
  • scene3: שיפור של קווי המתאר, תנועת העדשה
  • scene4: יחס גובה-רוחב, חיתוך, שדה ראייה
  • scene5: הצללה על העדשה
  • scene6: שינוי מרחק התצוגה
  • scene7: מתג למספר מצלמות
  • scene8: מדידת אזור לחשיפה אוטומטית (AE) ולאיזון לבן אוטומטי (AWB)
  • scene9: דחיסת JPEG
  • scene_extensions: תוספים למצלמה
  • scene_tele: מעבר לעדשת טלפוטו
  • scene_flash: פלאש אוטומטי, קצב פריימים מינימלי
  • scene_video: ירידה במסגרות
  • sensor_fusion: הפרש בזמני התיזמון של המצלמה והג'ירוסקופ
  • feature_combination: שילובי תכונות
  • scene_ip: תאימות בין התמונות באפליקציית המצלמה שמוגדרת כברירת מחדל לבין התמונות באפליקציית המצלמה של Jetpack‏ (JCA)

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

scene0

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

test_jitter

מדידת רעידות בחותמות הזמן של המצלמה.

ממשקי ה-API שנבדקו:

הצלחה: יש מרווח זמן של לפחות 30 אלפיות השנייה בין הפריימים.

שימו לב לטווח הקטן של ציר ה-y באיור הבא. בתרשים הזה, התנודות קטנות.

תרשים test_jitter

איור 1. תרשים test_jitter.

test_metadata

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

ממשקי ה-API שנבדקו:

הצלחה: התגים rollingShutterSkew,‏ frameDuration,‏ timestampSource,‏ croppingType,‏ blackLevelPattern,‏ pixel_pitch,‏ שדה הראייה (FoV) והמרחק ההיפרפוקלי נמצאים ברמת החומרה ויש להם ערכים תקינים.

test_request_capture_match

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

ממשקי ה-API שנבדקו:

הצלחה: ערכי המטא-נתונים של הבקשה והצילום תואמים בכל הצילומים.

test_sensor_events

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

ממשקי ה-API שנבדקו:

הצלחה: מתקבלים אירועים לכל חיישן.

test_solid_color_test_pattern

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

אם יש תמיכה בתמונות גולמיות, גם הקצאת הצבעים נבדקת. הצבעים שנבדקו הם שחור, לבן, אדום, כחול וירוק. במצלמות שלא תומכות בתמונות ברו, נבדק רק הצבע השחור.

ממשקי ה-API שנבדקו:

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

test_test_pattern

בדיקה של הפרמטר android.sensor.testPatternMode כדי לתעד פריימים לכל דפוס בדיקה תקין, ובדיקה שהפריימים נוצרים בצורה נכונה עבור צבעים אחידים ופסים צבעוניים. הבדיקה הזו כוללת את השלבים הבאים:

  1. צילום תמונות של כל דפוסי הבדיקה הנתמכים.
  2. ביצוע בדיקת תקינות של תבנית בדיקה בצבע אחיד ופסים צבעוניים.

ממשקי ה-API שנבדקו:

הצלחה: דפוסי הבדיקה הנתמכים נוצרים בצורה נכונה.

דוגמה ל-test_test_patterns

איור 2. דוגמה ל-test_test_patterns.

test_tonemap_curve

בדיקה של המרת דפוס בדיקה מ-raw ל-YUV באמצעות מפת גוונים לינארית. כדי לבצע את הבדיקה הזו, android.sensor.testPatternMode = 2 (COLOR_BARS) צריך ליצור דפוס תמונה מושלם להמרת טונמפ. בדיקה של צבעי הפלט של צינור עיבוד הנתונים עם מפת צבעים לינארית וקלט תמונה אידיאלי (הבדיקה מסתמכת על test_test_patterns).

ממשקי ה-API שנבדקו:

הבדיקה עברה: קובצי ה-YUV וה-RAW נראים דומים זה לזה.

דוגמה ל-test_tonemap_curve בפורמט גולמי

איור 3. דוגמה גולמית של test_tonemap_curve.

דוגמה ל-YUV של test_tonemap_curve

איור 4. דוגמה ל-YUV של test_tonemap_curve.

test_unified_timestamp

הבדיקה בודקת אם אירועי התמונה ואירועי חיישן התנועה נמצאים באותו תחום זמן.

ממשקי ה-API שנבדקו:

הצלחה: חותמות הזמן של התנועה נמצאות בין שתי חותמות הזמן של התמונות.

test_vibration_restriction

בדיקה אם הרטט במכשיר פועל כצפוי.

ממשקי ה-API שנבדקו:

הצלחה: המכשיר לא רוטט כשהוא מושתק על ידי ממשק ה-API של הגבלת האודיו במצלמה.

scene1_1

scene1 הוא תרשים אפור. התרשים האפור צריך לכסות את 30% המרכזיים של שדה הראייה (FoV) של המצלמה. התרשים האפור צפוי להציב אתגר מתון ל-3A (AE,‏ AWB ו-AF), כי באזור המרכזי אין תכונות. עם זאת, בבקשת הצילום מצוין כל הסצנה, שכוללת מספיק תכונות כדי לאפשר ל-3A להגיע להסכמה.

אפשר לבדוק מצלמות RFoV במתקן הבדיקה WFoV או במתקן הבדיקה RFoV. אם מצלמת RFoV נבדקת במתקן הבדיקה של WFoV, התרשים משוער ב-2/3 כדי לציין גבולות מסוימים של התרשים האפור ב-FoV, כדי לעזור להתכנסות של 3A. לתיאורים מפורטים יותר של ערכות הבדיקה של המצלמות, ראו Camera ITS-in-a-box.

scene1 example

איור 5. תרשים scene1 בגודל מלא (משמאל), תרשים בגודל 2/3 (מימין).

test_ae_precapture_trigger

בדיקה של מכונת המצבים של AE כשמשתמשים בטריגר של צילום מקדים. מתועדות חמש בקשות ידניות כש-AE מושבת. בבקשה האחרונה יש טריגר ל-AE לפני הצילום, שצריך להתעלם ממנו כי התכונה AE מושבתת.

ממשקי ה-API שנבדקו:

הצלחה: AE מתכנס.

test_auto_vs_manual

הבדיקות שצולמו באופן אוטומטי וידני נראות זהות.

ממשקי ה-API שנבדקו:

הצלחה: התוצאות של התאמת האיזון הלבן הידנית והטרנספורמציה שדווחו בכל צילום תואמות לאיזון הלבן האוטומטי estimate מתוך אלגוריתם ה-3A של המצלמה.

דוגמה אוטומטית של test_auto_vs_manual

איור 6. דוגמה לניסוי אוטומטי מסוג test_auto_vs_manual.

דוגמה לאיזון לבן של test_auto_vs_manual

איור 7. דוגמה לאיזון לבן של test_auto_vs_manual.

דוגמה לטרנספורמציה של איזון לבן ידני ב-test_auto_vs_manual

איור 8. דוגמה לטרנספורמציה של איזון לבן ידני ב-test_auto_vs_manual.

test_black_white

בדיקה שמטרתה לוודא שהמכשיר יוצר תמונות בשחור-לבן מלא. מתבצעים שני צילומים: הראשון עם רווח נמוך מאוד וחשיפה קצרה, וכתוצאה מכך מתקבלת תמונה שחורה. השני עם רווח גבוה מאוד וחשיפה ארוכה, וכתוצאה מכך מתקבלת תמונה לבנה.

ממשקי ה-API שנבדקו:

העברה: הפקת תמונות בשחור-לבן. לערוצים רוויים של תמונות לבנות יש ערכי RGB של [255, 255, 255] עם מרווח שגיאה של פחות מ-1%.

test_black_white, דוגמה בשחור

איור 9. דוגמה לשחור ב-test_black_white.

דוגמה לטרנספורמציה של איזון לבן ידני ב-test_auto_vs_manual

איור 10. דוגמה ל-test_black_white, לבן.

דוגמה ל-plot means של test_black_white

איור 11. test_black_white, plot means example.

test_burst_capture

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

ממשקי ה-API שנבדקו:

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

test_burst_sameness_manual

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

ממשקי ה-API שנבדקו:

הצלחה: התמונות זהות מבחינה חזותית וגם בערכים של RGB.

כישלון: מוצג עלייה חדה או ירידה חדה בתרשים הממוצע של RGB בתחילת כל התפרצות

  • הערך של first_API_level < 30 הוא 3%
  • ערך הסף הוא 2% עבור first_API_level >= 30

test_burst_sameness_manual_mean

איור 12. דוגמה לממוצע של test_burst_sameness_manual.

test_burst_sameness_manual_plot_means

איור 13. test_burst_sameness_manual_plot_means

test_crop_region_raw

בדיקה שלא ניתן לחתוך את הזרמים בפורמט RAW.

ממשקי ה-API שנבדקו:

הצלחה: תמונות YUV נחתכות במרכז, אבל לא תמונות RAW.

דוגמה לחיתוך גולמי של תמונה ב-comp: test_crop_region_raw

איור 14. דוגמה לחיתוך של קובץ test_crop_region_raw comp raw.

דוגמה מלאה של test_crop_region_raw comp raw

איור 15. דוגמה מלאה של test_crop_region_raw comp raw.

דוגמה לחיתוך של YUV ב-comp‏ test_crop_region_raw

איור 16. דוגמה לחיתוך YUV של test_crop_region_raw comp.

דוגמה ל-test_crop_region_raw_yuv_full

איור 17. דוגמה מלאה ל-YUV ב-test_crop_region_raw.

test_crop_regions

בדיקה של אזורי החיתוך. צילום תמונה מלאה ויצירת תיקונים של חמישה אזורים שונים (פינות ומרכז). צילום תמונות עם הגדרת חיתוך לחמישה אזורים. האופרטור משווה בין הערכים של התיקון לבין הערכים של התמונה לאחר החיתוך.

ממשקי ה-API שנבדקו:

הצלחה: התמונה של האזור החתוך תואמת לתיקון שתואם לתמונה החתוכה.

test_ev_compensation

בדיקה אם מתבצעת תיקון של ערך החשיפה (EV). הבדיקה מורכבת מחלק בסיסי ומחלק מתקדם.

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

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

ממשקי ה-API שנבדקו:

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

test_ev_compensation_basic

איור 18. test_ev_compensation_basic.

Advanced section pass:מתועדת עלייה ב-luma ככל שההגדרה של פיצוי EV עולה. לשמונה התמונות שצולמו לכל הגדרת פיצוי EV יש ערכים יציבים של לומינס.

test_ev_compensation_advanced_plot_means

איור 19. test_ev_compensation_advanced_plot_means.

test_exposure_x_iso

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

ממשקי ה-API שנבדקו:

הצלחה: לתמונות יש אותה בהירות, אבל הן יותר רועשות כשה-ISO גבוה יותר. המישורים של RGB הם שטוחים כשהערך של ISO*exposure הוא קבוע במרחב הרווח שנבדק.

מנגנון הכשל: בתרשים הבא, ככל שערכי מכפיל הרווח (ציר ה-x) גדלים, הערכים הממוצעים של מישור ה-RGB המנורמלי (ציר ה-y) מתחילים לסטות מערכי מכפיל הרווח הנמוכים.

test_exposure_plot_means

איור 20. test_exposure_plot_means.

test_exposure_mult=1.00.jpg

איור 21. test_exposure_mult=1.00.

test_exposure_mult=64.00

איור 22. test_exposure_mult=64.00.

test_latching

בדיקה שההגדרות (חשיפה ורווחים) מוחזקות בפריים הנכון במצלמות FULL ו-LEVEL_3. צילום סדרה של תמונות באמצעות בקשות רצופות, עם שינוי הפרמטרים של בקשת הצילום בין התמונות. הבדיקה מוודאת שלתמונות יש את המאפיינים הצפויים.

ממשקי ה-API שנבדקו:

הצלחה: בתמונות [2, 3, 6, 8, 10, 12, 13] הוגדרו ערכי ISO או חשיפה גבוהים יותר, והן מופיעות עם ערכי RGB ממוצעים גבוהים יותר בתרשים שבתרשים הבא.

דוגמה למשמעות של plot של test_latching

איור 23. דוגמה למשמעות של תרשים test_latching.

test_latching i=00

איור 24. test_latching i=00.

test_latching i=01

איור 25. test_latching i=01.

test_latching i=02

איור 26. test_latching i=02.

test_latching i=03

איור 27. test_latching i=03.

test_latching i=04

איור 28. test_latching i=04.

test_latching i=05

איור 29. test_latching i=05.

test_latching i=06

איור 30. test_latching i=06.

test_latching i=07

איור 31. test_latching i=07.

test_latching i=08

איור 32. test_latching i=08.

test_latching i=09

איור 33. test_latching i=09.

test_latching i=10

איור 34. test_latching i=10.

test_latching i=11

איור 35. test_latching i=11.

test_latching i=12

איור 36. test_latching i=12.

test_linearity

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

ממשקי ה-API שנבדקו:

הצלחה: הערכים של R,‏ G ו-B צריכים לעלות באופן לינארי ככל שהרגישות עולה.

דוגמה למשמעות של plot ב-test_linearity

איור 37. דוגמה לתרשים של test_linearity.

test_locked_burst

בדיקה של נעילת 3A ופרץ YUV (באמצעות הגדרה אוטומטית). הבדיקה הזו אמורה לעבור גם במכשירים מוגבלים שאין בהם את MANUAL_SENSOR או את PER_FRAME_CONTROLS. הבדיקה בודקת את עקביות התמונה בפורמט YUV, בעוד שהבדיקה של קצב הפריימים מתבצעת ב-CTS.

ממשקי ה-API שנבדקו:

עומד בדרישות: התמונות והסרטונים נראים עקביים.

דוגמה ל-test_locked_burst frame0

איור 38. דוגמה ל-frame0 של test_locked_burst.

דוגמה ל-test_locked_burst frame1

איור 39. דוגמה ל-test_locked_burst frame1.

test_locked_burst_frame2

איור 40. דוגמה ל-test_locked_burst frame2.

scene1_2

scene 1_2 הוא עותק זהה מבחינה פונקציונלית של scene 1_1, שמטמיע מבנה של סצנות משנה כדי לקצר את משך הזמן הארוך של scene 1.

test_param_color_correction

בדיקה שהפרמטרים android.colorCorrection.* חלים כשהם מוגדרים. צילום תמונות עם ערכי טרנספורמציה וערך שונה, ובדיקה שהן נראות שונות בהתאם. הטרנספורמציה והשיפורים נבחרים כך שהפלט יהיה אדום או כחול יותר ויותר. נעשה שימוש במיפוי טונוס ליניארי.

מיפוי גוונים הוא טכניקה שמשמשת לעיבוד תמונות, ומטרתה למפות קבוצת צבעים אחת לקבוצה אחרת כדי להתקרב למראה של תמונות בטווח דינמי גבוה (HDR) באמצעי שמוצג בו טווח דינמי מוגבל יותר.

ממשקי ה-API שנבדקו:

העברה: ערכי R ו-B מוגדלים בהתאם לטרנספורמציה.

דוגמה למשמעות של plot של test_param_color_correction

איור 41. דוגמה למשמעות של תרשים test_param_color_correction.

בתרשים הבא, ציר ה-x מייצג את בקשות הצילום: 0 = אחדות, 1 = הגברת אדום ו-2 = הגברת כחול.

דוגמה ל-test_param_color_correction req=0 unity

איור 42. דוגמה ל-test_param_color_correction req=0 ב-Unity.

דוגמה ל-test_param_color_correctness req=1 red boost

איור 43. דוגמה ל-boost אדום של test_param_color_correctness req=1.

דוגמה ל-test_param_color_correction req=2 blue boost

איור 44. דוגמה ל-test_param_color_correction req=2 blue boost.

test_param_flash_mode

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

ממשקי ה-API שנבדקו:

הצלחה: במרכז התמונה של המשבצת יש שינוי הדרגתי גדול, כלומר הפלאש הופעל.

דוגמה 1 של test_param_flash_mode

איור 45. דוגמה ל-test_param_flash_mode 1.

דוגמה ל-test_param_flash_mode 1

איור 46. דוגמה לשימוש ב-test_param_flash_mode עם משבצת אחת.

דוגמה ל-test_param_flash_mode_2

איור 47. דוגמה ל-test_param_flash_mode 2.

דוגמה לכותרת 2 של test_param_flash_mode

איור 48. דוגמה לשני משבצות של test_param_flash_mode.

test_param_noise_reduction

בדיקה שהפרמטר android.noiseReduction.mode מיושם בצורה נכונה כשמגדירים אותו. צילום תמונות כשהמצלמה מוארת באור עמום. שימוש בשיפור אנלוגי גבוה כדי לוודא שהתמונה שצולמה תהיה עם רעש. צילום של שלוש תמונות: ללא סינון רעשי רקע, מהיר ואיכות גבוהה. התכונה גם מתעדת תמונה עם רווח נמוך והשבתה של ביטול הרעשי, ומשתמשת בתנודות של התמונה הזו כנקודת ההתחלה. ככל שיחס האות לרעש (SNR) גבוה יותר, כך איכות התמונה טובה יותר.

ממשקי ה-API שנבדקו:

הצלחה: ערך SNR משתנה בהתאם למצבים שונים של הפחתת רעש, וההתנהגות שלו דומה לתרשים הבא:

דוגמה לתרשים SNR של test_param_noise_reduction

איור 49. דוגמה לתרשים SNR של test_param_noise_reduction.

0: OFF, ‏ 1: FAST, ‏ 2: HQ, ‏ 3: MIN , ‏ 4: ZSL

דוגמה ל-test_param_noise_reduction high gain nr=0

איור 50. דוגמה ל-test_param_noise_reduction high gain nr=0.

דוגמה ל-test_param_noise_reduction high gain nr=1

איור 51. דוגמה ל-test_param_noise_reduction high gain nr=1.

דוגמה ל-test_param_noise_reduction high gain nr=2

איור 52. דוגמה ל-test_param_noise_reduction עם gain גבוה nr=2.

דוגמה ל-test_param_noise_reduction high gain nr=3

איור 53. דוגמה ל-test_param_noise_reduction high gain nr=3.

דוגמה ל-test_param_noise_reduction עם רווח נמוך

איור 54. דוגמה ל-test_param_noise_reduction עם רווח נמוך.

test_param_shading_mode

בדיקה שהפרמטר android.shading.mode מיושם.

ממשקי ה-API שנבדקו:

הצלחה: מצבי ההצללה מוחלפים ומפות ההצללה של העדשה משתנות כצפוי.

דוגמה למיפוי הצללה של עדשה ב-test_param_shading_mode, מצב 0 לולאה 0

איור 55. מפת הצללה של עדשה ב-test_param_shading_mode, דוגמה למצב 0 לולאה 0.

דוגמה למיפוי הצללה של עדשה ב-test_param_shading_mode, מצב 1 לולאה 0

איור 56. מפה של עיוות עדשה מסוג test_param_shading_mode, דוגמה למצב 1 לולאה 0.

דוגמה למיפוי הצללה של עדשת test_param_shading_mode, מצב 2 לולאה 0

איור 57. מפה של עיוות עדשה במצב test_param_shading_mode, דוגמה למצב 2 לולאה 0.

test_param_tonemap_mode

בדיקה שהפרמטר android.tonemap.mode מיושם. הפונקציה מחילה עקומות שונות של מפת צבעים על כל ערוץ R,‏ G ו-B, ובודקת שתמונות הפלט שונו כצפוי. הבדיקה הזו מורכבת משתי בדיקות, test1 ו-test2.

ממשקי ה-API שנבדקו:

אישור:

  • test1: בשתי התמונות יש מפת צבעים לינארית, אבל ל-n=1 יש שיפוע תלול יותר. הערוץ G (ירוק) בהיר יותר בתמונה n=1.
  • test2: אותו מפת טונוס, אבל באורך שונה. התמונות זהות.

test_param_tonemap_mode עם n=0

איור 58. test_param_tonemap_mode עם n=0.

test_param_tonemap_mode עם n=1

איור 59. test_param_tonemap_mode עם n=1.

test_post_raw_sensitivity_boost

בדיקה לאחר הגברת הרגישות הגולמית. הקוד מתעד קבוצה של תמונות גולמיות ו-YUV עם רגישות שונה, מפרסם שילוב של הגברת הרגישות בתמונות גולמיות ובודק אם ממוצע הפיקסלים בפלט תואם להגדרות הבקשה.

ממשקי ה-API שנבדקו:

הצלחה: תמונות גולמיות נהיות כהות יותר ככל שהשיפור גדל, בעוד שהבהירות של תמונות YUV נשארת קבועה.

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

איור 60. דוגמה של test_post_raw_sensitivity_boost raw s=3583 boost=0100.

דוגמה ל-test_post_raw_sensitivity_boost raw s=1792 boost=0200

איור 61. דוגמה של test_post_raw_sensitivity_boost raw s=1792 boost=0200.

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

איור 62. דוגמה ל-test_post_raw_sensitivity_boost raw s=0896 boost=0400.

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

איור 63. דוגמה ל-test_post_raw_sensitivity_boost raw s=0448 boost=0800.

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

איור 64. דוגמה ל-test_post_raw_sensitivity_boost raw s=0224 boost=1600.

דוגמה ל-test_post_raw_sensitivity_boost raw s=0112 boost=3199

איור 65. דוגמה ל-test_post_raw_sensitivity_boost raw s=0112 boost=3199.

דוגמה לתרשים של הערך הממוצע של test_post_raw_sensitivity_boost

איור 66. דוגמה למשמעות של תרשים נתונים גולמיים של test_post_raw_sensitivity_boost.

דוגמה ל-test_post_raw_sensitivity_boost YUV s=0112 boost=3199

איור 67. דוגמה ל-test_post_raw_sensitivity_boost YUV s=0112 boost=3199.

דוגמה ל-test_post_raw_sensitivity_boost YUV s=0448 boost=0800

איור 68. דוגמה ל-test_post_raw_sensitivity_boost YUV s=0448 boost=0800.

test_post_raw_sensitivity_boost YUV s=0896 boost=0400 example

איור 69. דוגמה ל-test_post_raw_sensitivity_boost YUV s=0896 boost=0400.

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

איור 70. דוגמה ל-test_post_raw_sensitivity_boost YUV s=1792 boost=0200.

דוגמה ל-test_post_raw_sensitivity_boost YUV s=3585 boost=0100

איור 71. דוגמה ל-test_post_raw_sensitivity_boost YUV s=3585 boost=0100.

test_post_raw_sensitivity_boost_yuv_plot_means

איור 72. test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

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

ממשקי ה-API שנבדקו:

הצלחה: הגברת ה-ISO (השיפור) מגדילה את הרגישות של הפיקסלים לאור, ולכן התרשים ינוע שמאלה.

דוגמה ל-test_raw_exposure ISO=55

איור 73. דוגמה ל-test_raw_exposure ISO=55.

הערך 10⁰ הוא 1 אלפית שנייה, הערך 10¹ הוא 10 אלפיות שנייה והערך 10⁻¹ הוא 0.1 אלפית שנייה.

דוגמה ל-test_raw_exposure ISO=132

איור 74. דוגמה ל-test_raw_exposure ISO=132.

דוגמה ל-test_raw_exposure ISO=209

איור 75. דוגמה ל-test_raw_exposure ISO=209.

דוגמה ל-test_raw_exposure ISO=286

איור 76. דוגמה ל-test_raw_exposure ISOs=286.

דוגמה ל-test_raw_exposure ISO=363

איור 77. דוגמה ל-test_raw_exposure ISO=363.

test_raw_exposure_s=440

איור 78. דוגמה ל-test_raw_exposure ISO=440.

test_reprocess_noise_reduction

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

ממשקי ה-API שנבדקו:

הצלחה: FAST >= OFF,‏ HQ >= FAST ו-HQ >> OFF.

תרשים אופייני של SNR לעומת מצב NR

איור 79. דוגמה אופיינית לתרשים של SNR לעומת מצב NR.

test_tonemap_sequence

בדיקה של רצף של צילומים עם עקומות שונות של מפת הטונים. צילום של 3 תמונות ידניות עם מפת צבעים לינארית. צילום 3 תמונות ידניות עם מפת הטונים שמוגדרת כברירת מחדל. חישוב הדלתה בין כל צמד פריימים רצופים.

ממשקי ה-API שנבדקו:

הבדיקה עברה: יש שלוש מסגרות זהות, ואחריה קבוצה אחרת של שלוש מסגרות זהות.

דוגמה ל-test_tonemap_sequence i=0

איור 80. דוגמה ל-test_tonemap_sequence i=0.

דוגמה ל-test_tonemap_sequence i=1

איור 81. דוגמה ל-test_tonemap_sequence i=1.

דוגמה ל-test_tonemap_sequence i=2

איור 82. דוגמה ל-test_tonemap_sequence i=2.

דוגמה ל-test_tonemap_sequence i=3

איור 83. דוגמה ל-test_tonemap_sequence i=3.

דוגמה ל-test_tonemap_sequence_i=4

איור 84. דוגמה ל-test_tonemap_sequence i=4.

דוגמה ל-test_tonemap_sequence i=5

איור 85. דוגמה ל-test_tonemap_sequence i=5.

test_yuv_jpeg_all

בדיקה שכל הגדלים והפורמטים שדווחו לצילום תמונות פועלים. הבקשה היא ידנית עם מפת צבעים לינארית, כך שהקובץ YUV והקובץ JPEG ייראו זהים אחרי שהם יומרו על ידי המודול image_processing_utils. התמונות לא נשמרות כברירת מחדל, אבל אפשר לשמור אותן על ידי הפעלת debug_mode.

ממשקי ה-API שנבדקו:

הצלחה: ההפרש המרבי של שורר ריבוע ממוצע (RMS) (ערך של אות) בכל מרכזי התמונות בתמונות RGB המומרות הוא 3% מהתמונה בפורמט YUV ברזולוציה הגבוהה ביותר.

דוגמה ל-test_yuv_jpeg_all

איור 86. דוגמה ל-test_yuv_jpeg_all.

test_yuv_plus_dng

בדיקה שהגדלים והפורמטים שדווחו לצילום התמונה תקינים.

ממשקי ה-API שנבדקו:

הצלחה: הבדיקה מסתיימת והתמונות המבוקשות מוחזרות.

דוגמה ל-test_yuv_plus_dng

איור 87. דוגמה ל-test_yuv_plus_dng.

scene1_3

scene 1_3 הוא עותק זהה מבחינה פונקציונלית של scene 1_1, שמטמיע מבנה של סצנות משנה כדי לקצר את משך הזמן הארוך של scene 1.

test_capture_result

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

ממשקי ה-API שנבדקו:

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

test_capture_result_plot_lsc_auto_ch0

איור 88. test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

בדיקה שהפרמטרים של מודל DNG הגולמי נכונים. בתרשים מוצגת השונות שנמדדה של תיקון מרכזי בכרטיס האפור בתמונות גולמיות שצולמו במגוון רגישויות, והערכים האלה משווים לשונות הצפויה בכל רגישות לפי מודל הרעש של DNG ב-HAL של המצלמה (על סמך הפרמטרים O,S שמוחזרים באובייקטים של תוצאות הצילום). למידע נוסף על מודל הרעש של DNG, אפשר להוריד את המסמך הבא בנושא מודל הרעש של DNG.

ממשקי ה-API שנבדקו:

הצלחה: הפרמטרים של מודל DNG גולמי נכונים. ערכי ה-RGB הצפויים תואמים לערכי ה-RGB בפועל שנמדדו.

test_dng_noise_model_plog

איור 89. test_dng_noise_model_plog.

test_jpeg

בדיקות שמראות שתמונות YUV שהומרו ותמונות JPEG מהמכשיר נראות אותו הדבר. הבדיקה מתחילה ב-10% המרכזיים של התמונה, מחשבת את ערך ה-RGB ומאמתת שהם תואמים.

ממשקי ה-API שנבדקו:

הצלחה: ההבדל הממוצע ב-RGB בין כל תמונה הוא קטן מ-3%.

test_jpeg_fmt=jpg.jpg

איור 90. test_jpeg_fmt=jpg.jpg.

test_jpeg=fmt=yuv.jpg

איור 91. test_jpeg=fmt=yuv.jpg.

test_raw_burst_sensitivity

צילום קבוצה של תמונות גולמיות עם הגברה הולכת וגוברת ומדידת הרעש. צילום בפורמט RAW בלבד, ברצף.

ממשקי ה-API שנבדקו:

מעבר: כל צילום רועש יותר מהצילום הקודם, כי ההגברה הולכת וגדלה.

הנוסחה משתמשת בשונות של התא במרכז של רשת הנתונים הסטטיסטיים.

test_raw_burst_sensitivity_variance

איור 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

צילום קבוצה של תמונות גולמיות עם רגישויות הולכות וגדלות, ומדידה של הרעש (השונות) ב-10% המרכזיים של התמונה. בדיקה של כל צילום כדי לראות אם הוא רועש יותר מהצילום הקודם.

ממשקי ה-API שנבדקו:

מעבר: השונות גדלה עם כל קלוז-אפ.

test_raw_sensitivity_variance

איור 93. test_raw_sensitivity_variance.

test_yuv_plus_jpeg

בדיקה של צילום של פריים יחיד כפלט YUV וגם כפלט JPEG. הבקשה היא ידנית עם מפת צבעים לינארית, כך שהקובץ YUV והקובץ JPEG ייראו זהים אחרי שהם יומרו על ידי המודול image_processing_utils.

ממשקי ה-API שנבדקו:

הצלחה: התמונות בפורמט YUV ובפורמט JPEG דומות, וההבדל ביניהן הוא פחות מ-1% RMS (ערך של אות).

test_yuv_plus_jpeg בפורמט JPEG

איור 94. test_yuv_plus_jpeg בפורמט JPEG.

test_yuv_plus_jpeg בפורמט YUV

איור 95. test_yuv_plus_jpeg בפורמט YUV.

test_yuv_plus_raw

בדיקה של צילום של פריים יחיד כפלט גולמי (10 ביט ו-12 ביט גולמי) וגם כפלט YUV, אם יש תמיכה בכך. המערכת משתמשת בבקשה ידנית עם מפת צבעים לינארית, כך שהקובץ הגולמי והקובץ בפורמט YUV צפויים להיות זהים. השוואה של ערכי ה-RGB של 10% מהמרכז של תמונות שהוסבו ל-RGB. יומניםandroid.shading.mode.

ממשקי ה-API שנבדקו:

הצלחה: התמונות בפורמט YUV ובפורמט גולמי דומות, וההפרש ביניהן הוא פחות מ-3.5% RMS (ערך שורר-ממוצע-ריבוע של אות).

test_yuv_plus_raw_shading=1_raw.jpg

איור 96. test_yuv_plus_raw_shading=1_raw.jpg.

test_yuv_plus_raw_shading=1_yuv.jpg

איור 97. test_yuv_plus_raw_shading=1_yuv.jpg.

test_sensitivity_priority

בדיקות CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY במגוון הגדרות ISO כדי לאשר קורלציה בין רמות ISO גבוהות יותר לבין רמות רעש גבוהות יותר.

ממשקי ה-API שנבדקו:

הצלחה: ערכי ISO גבוהים יותר גורמים לרמות רעש גבוהות יותר.

בדיקת קריטריונים לדילוג

הבדיקה test_sensitivity_priority.py מועברת אם מתקיים אחד מהקריטריונים הבאים:

test_exposure_time_priority

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

ממשקי ה-API שנבדקו:

הצלחה: הבהירות יציבה (בטווח הסבלה) בכל זמני החשיפה אם ערך ה-ISO נמצא בטווח הפיצוי שלו.

בדיקת קריטריונים לדילוג

הבדיקה test_exposure_time_priority מועברת אם מתקיים אחד מהקריטריונים הבאים:

scene2_a

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

דוגמה ל-scene2_a

איור 98. דוגמה ל-scene2_a.

test_autoframing

בדיקה של התנהגות התכונה 'חיתוך אוטומטי' במצלמה. מבצעים זום גדול כך שאף אחד מהפנים בסצנה לא גלוי, מפעילים את מצב התאמת הפריים האוטומטית על ידי הגדרת AUTOFRAMING ב-CaptureRequest לערך True, ומאמתים אם ניתן לזהות את כל הפנים בסצנה המקורית כשהמצב מתכנס (כלומר, כש-AUTOFRAMING_STATE ב-CaptureResult מוגדר לערך AUTOFRAMING_STATE_CONVERGED).

ממשקי ה-API שנבדקו:

הצלחה: כל שלוש הפנים זוהו.

test_display_p3

בדיקה של צילום Display P3 בפורמט JPEG באמצעות ה-API ‏ColorSpaceProfiles. הבדיקה בודקת אם ל-JPEG שצולם יש פרופיל ICC מתאים בכותרת שלו, ואם התמונה מכילה צבעים מחוץ לטווח הצבעים של sRGB.

ממשקי ה-API שנבדקו:

הצלחה: קובץ ה-JPEG מכיל פרופיל ICC של Display P3 וצבעים מחוץ לטווח הצבעים של sRGB.

test_effects

צילום פריים לאפקטים נתמכים במצלמה ובדיקה אם הם נוצרים בצורה נכונה. הבדיקה בודקת רק את האפקטים OFF ו-MONO, אבל שומרת תמונות של כל האפקטים הנתמכים.

ממשקי ה-API שנבדקו:

מעבר: צילום של תמונת הסצנה עם האפקטים OFF ותמונה מונוכרום עם האפקטים מוגדרים כ-MONO.

test_effects_MONO

איור 99. test_effects_MONO.

test_exposure_keys_consistent

הבדיקה הזו משווה בין הלומה הממוצעת של צילום עם AE מופעל לבין צילום עם AE מושבת שבו מופעלים באופן ידני פרמטרי החשיפה (רגישות, משך חשיפה, משך פריים, שיפור רגישות לאחר עיבוד נתונים גולמיים) שהתקבלו ב-CaptureResult של הצילום עם AE מופעל.

ממשקי ה-API שנבדקו:

הצלחה: ההבדל היחסי ב-luma בין שתי התמונות הוא פחות מ-4 אחוזים.

test_format_combos

בדיקה של שילובים שונים של פורמטים של פלט.

ממשקי ה-API שנבדקו:

הצלחה: כל השילובים מתועדים בהצלחה.

test_num_faces

בדיקה של זיהוי הפנים.

ממשקי ה-API שנבדקו:

הצלחה: נמצאו שלושה פנים.

דוגמה אחת למצב זיהוי הפנים test_num_faces

איור 100. דוגמה לזיהוי פנים במצב 1 של test_num_faces.

test_reprocess_uv_swap

בדיקה שמאשרת שהעיבוד מחדש של YUV לא מחליף בין המישורים U ו-V. כדי לזהות את הבעיה, מחשבים את סכום ההפרשים המוחלטים (SAD) בין התמונה שעברה עיבוד חוזר לבין צילום שלא עבר עיבוד חוזר. אם החלפת המישורים U ו-V של הפלט מהצילום שעבר עיבוד מחדש מובילה לעלייה ב-SAD, ההנחה היא שהמישורים U ו-V של הפלט נכונים.

ממשקי ה-API שנבדקו:

הצלחה: המישורים U ו-V לא הוחלפו.

test_reprocess_uv_swap

איור 101. דוגמה ל-test_reprocess_uv_swap.

scene2_b

test_preview_num_faces

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

ממשקי ה-API שנבדקו:

הצלחה: נמצאו שלושה פנים עם ציוני דרך בפנים בתיבות הסף של הפנים.

test_num_faces_fd_mode_1

איור 102. דוגמה למצב 1 של זיהוי הפנים test_num_faces.

test_yuv_jpeg_capture_sameness

צילום שתי תמונות בפורמטים הנפוצים הגדולים ביותר של YUV ו-JPEG, באותו יחס גובה-רוחב של פורמט ה-JPEG הגדול ביותר, וברזולוציה של עד 1920x1440. מגדיר את jpeg.quality לערך 100 ומצלם בקשה עם שני משטחים. הפונקציה ממירה את שתי התמונות למערכים של RGB ומחשבת את ההפרש הממוצע בריבוע (RMS) התלת-ממדי בין שתי התמונות.

בנוסף, הבדיקה הזו מאמתת שפלט ה-YUV של כל התרחישים לדוגמה של סטרימינג נתמכים דומה למדי ל-YUV בתרחיש לדוגמה STILL_CAPTURE.

ממשקי ה-API שנבדקו:

הצלחה: בתמונות YUV ו-JPEG בתרחיש השימוש STILL_CAPTURE יש הבדל של פחות מ-3% RMS (ערך שורר-ממוצע-ריבוע של אות). בתמונות YUV בכל תרחישי השימוש הנתמכים יש הבדל של פחות מ-10% RMS ביחס לתמונות YUV בתרחיש השימוש STILL_CAPTURE.

scene2_c

test_num_faces

בדיקה של זיהוי פנים עם מגוון רחב יותר של גווני עור בסצנות של פנים.

ממשקי ה-API שנבדקו:

הצלחה: נמצאו שלושה פנים.

test_num_faces_fd_mode_1

איור 103. דוגמה למצב זיהוי הפנים test_num_faces.

test_jpeg_capture_perf_class

בדיקה של זמן האחזור לצילום JPEG עבור סיווג הביצועים S, כפי שמפורט בקטע 2.2.7.2 מצלמה במסמך CDD.

הצלחה: זמן האחזור לצילום JPEG של camera2 חייב להיות קטן מ-1,000 אלפיות שנייה ברזולוציה של 1080p, כפי שנמדד על ידי בדיקת הביצועים של מצלמת CTS בתנאים של תאורה ITS (3,000K) בשתי המצלמות הראשיות.

test_camera_launch_perf_class

בדיקה של זמן האחזור להפעלת המצלמה עבור סיווג הביצועים S, כפי שמפורט בקטע 2.2.7.2 מצלמה ב-CDD.

הצלחה: זמן האחזור של הפעלת camera2 (פתיחת המצלמה עד לפריים התצוגה המקדימה הראשון) חייב להיות קטן מ-600ms, כפי שנמדד על ידי בדיקת הביצועים של מצלמת CTS בתנאים של תאורה ITS (3000K) בשתי המצלמות הראשיות.

test_default_camera_hdr

בדיקה שהצילום שמוגדר כברירת מחדל במצלמה הוא Ultra HDR עבור רמת הביצועים 15, כפי שמפורט בקטע 2.2.7.2 מצלמה במסמך ה-CDD.

הצלחה: חבילת התמונות שמוגדרת כברירת מחדל במצלמה חייבת להיות באיכות Ultra HDR במכשיר ברמת הביצועים 15.

scene2_d

test_preview_num_faces

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

ממשקי ה-API שנבדקו:

הצלחה: נמצאו שלושה פנים עם ציוני דרך בפנים בתיבות הסף של הפנים.

scene2_e

test_continuous_picture

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

ממשקי ה-API שנבדקו:

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

test_num_faces

בדיקה של זיהוי פנים עם מגוון רחב יותר של גווני עור בסצנות של פנים.

ממשקי ה-API שנבדקו:

הצלחה: נמצאו 3 פנים.

scene2_f

scene2_f כולל שלושה פרצופים עם רקע לבן ובגדים לבנים. הפנים צריכים להיות במגוון רחב של גווני עור עם ניגודיות גבוהה לרקע.

דוגמה ל-scene2_f

איור 104. דוגמה ל-scene2_f.

test_preview_num_faces

בדיקה של זיהוי פנים עם מגוון רחב יותר של גווני עור בסצנות של פנים.

ממשקי ה-API שנבדקו:

הצלחה: נמצאו שלושה פנים עם ציוני דרך בפנים בתיבות הסף של הפנים.

test_num_faces_fd_mode_1

איור 105. דוגמה ל-test_num_faces_fd_mode_1.

scene2_g

ל-scene2_g יש שלושה פרופילים עם רקע לבן ובגדים לבנים. הפנים כוללים מגוון רחב של גווני עור וניגודיות גבוהה לרקע.

scene2_g.png

איור 106. דוגמה ל-scene2_g.

test_preview_num_faces

בדיקה של זיהוי פנים עם מגוון רחב יותר של גווני עור בסצנות של פנים.

ממשקי ה-API שנבדקו:

הצלחה: נמצאו שלושה פנים עם ציוני דרך בפנים בתיבות הסף של הפנים.

test_preview_num_faces

איור 107. דוגמה ל-test_preview_num_faces.

scene3

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

test_edge_enhancement

בדיקה של הפרמטר android.edge.mode כדי לוודא שהוא מיושם בצורה נכונה. הפונקציה מתעדת תמונות ללא עיבוד חוזר לכל מצב קצה ומחזירה את חדות התמונה בתוצר ואת המטא-נתונים של תוצאת הצילום. עיבוד בקשת צילום עם מצב קצה, רגישות, זמן חשיפה, מרחק מיקוד ופרמטר של משטח פלט נתונים נתונים.

הצלחה: איכות התמונה במצב HQ (2) חדה יותר מזו במצב OFF (0). התמונה במצב FAST (1) חדה יותר מאשר במצב OFF. התמונה במצב HQ חדה יותר או שווה לזו במצב FAST.

ממשקי ה-API שנבדקו:

פרמטרים של המצלמה שהושפעו:

  • EDGE_MODE

test_edge_enhancement_edge=0

איור 108. דוגמה ל-test_edge_enhancement edge=0.

דוגמה ל-test_edge_enhancement edge=1

איור 109. דוגמה ל-test_edge_enhancement edge=1 (מצב מהיר).

דוגמה ל-test_edge_enhancement edge=2

איור 110. דוגמה ל-test_edge_enhancement edge=2 (מצב איכות גבוהה).

test_flip_mirror

בדיקה אם התמונה בכיוון הנכון, בהתאם לקטע 7.5.2 מצלמה קדמית במסמך CDD.

אפשר לזהות תמונות שמוצגות במראה, הפוכות או מסובבות לפי הסמל של יהלום ליד המרכז.

עומד בדרישות: התמונה לא הפוכה, לא הושבה או לא סובבה.

דוגמה לתיקון של סצנה מסוג test_flip_mirror

איור 111. דוגמה לתיקון סצנה של test_flip_mirror.

test_imu_drift

הבדיקה בודקת אם ליחידת המדידה האינרציאלית (IMU) יש פלט יציב במשך 30 שניות בזמן שהמכשיר נייח ומצלם תצוגה מקדימה באיכות HD.

ממשקי ה-API שנבדקו:

אישור:

  • ההטיה של הגירוסקופ קטנה מ-0.01 רדיאן במהלך הבדיקה.
  • סטיית התקן של קריאת הגירוסקופ קטנה מ-1E-7rad2/s2/Hz במהלך הבדיקה.
  • ההטיה של וקטור הסיבוב היא פחות מ-0.01 רדיאן במהלך זמן הבדיקה.
  • (עדיין לא נדרש) ההטיה של הגירוסקופ היא פחות מ-1 מעלה לשנייה.

דוגמה לסטייה של ג&#39;ירוסקופ ב-test_imu_drift

איור 112. דוגמה לסטייה של ג'יירוסקופ ב-test_imu_drift.

דוגמה לתנודות בוקטור הסיבוב של test_imu_drift

איור 113. דוגמה לתנודות של וקטור הסיבוב test_imu_drift.

test_landscape_to_portrait

בדיקה אם שינוי המצב מלאופק לרוחב פועל בצורה תקינה בחיישנים בכיוון לאופק.

ממשקי ה-API שנבדקו:

הצלחה: הבדיקה מאתרת תרשים עם הסיבוב הצפוי (0 מעלות כשהשינוי מפורמט לרוחב לפורמט לאורך מושבת, 90 מעלות כשהוא מופעל).

דוגמה ל-test_landscape_to_portrait

איור 114. דוגמה ל-test_landscape_to_portrait.

test_lens_movement_reporting

הבדיקה בודקת אם הדגל של תנועת העדשה מדווח בצורה תקינה. מצלמים רצף של 24 תמונות, כאשר 12 הפריים הראשונים מתועדים במרחק המיקוד האופטימלי (כפי שנקבע על ידי 3A) ו-12 הפריים האחרונים מתועדים במרחק המיקוד המינימלי. בסביבות מסגרת 12, העדשה זזה וגורמת לירידה בחדות. בסופו של דבר, החדות מתייצבת כשהעדשה נעה למיקום הסופי.

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

ממשקי ה-API שנבדקו:

הצלחה: הדגל של תנועת העדשה הוא True בפריים עם שינוי החדות.

מנגנוני כשל:

  • ההצהרה lens_moving: True (android.hardware.camera2.CaptureResult#LENS_STATE = 1) ב-test_log.DEBUG מתבצעת רק בפריימים שבהם החדות לא משתנה.
  • בפריימים עם lens_moving: False (android.hardware.camera2.CaptureResult#LENS_STATE = 0) ב-test_log.DEBUG יש הבדל בחדות בהשוואה לפריימים הראשונים במרחק המוקד האופטימלי או לפריימים האחרונים במרחק המוקד המינימלי.

test_reprocess_edge_enhancement

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

ממשקי ה-API שנבדקו:

הצלחה: החדות של מצבי הקצה השונים תקינה. התמונה ב-HQ (מצב 2) חדה יותר מזו ב-OFF (מצב 0), והשיפור בין המצבים השונים דומה.

דוגמה לתרשים של test_reprocess_edge_enhancement

איור 115. דוגמה לתרשים של test_reprocess_edge_enhancement.

scene4

scene4 מורכב מעיגול שחור על רקע לבן בתוך ריבוע.

בדיקות ב-scene4 יכולות להיות רגישות ליישור, לכן החל מ-Android 15 אפשר להשתמש ב-check_alignment.py בספריית הכלים כדי להפעיל בדיקה של DUT ויישור התרשים.

scene4 example

איור 116. דוגמה של scene4.

test_30_60fps_preview_fov_match

הבדיקה נועדה לוודא שלסרטוני תצוגה מקדימה ב-30 FPS וב-60 FPS יש את אותו שדה ראייה. במסגרת הבדיקה מתועדים שני סרטונים, אחד בקצב של 30 FPS והשני בקצב של 60 FPS. נבחר פריים מייצג מכל סרטון ומנתחים אותו כדי לוודא שהשינויים ב-FoV בשני הסרטונים עומדים בדרישות. בדיקה שהיחס בין גובה לרוחב של העיגול נשאר קבוע, שמרכז העיגול נשאר יציב ורדיוס העיגול נשאר קבוע.

ממשקי ה-API שנבדקו:

הסרטון עובר: התמונות לא מורחבות, המרכז של התמונות לא שונה ביותר מ-3% והשינוי המקסימלי ביחס הגובה-רוחב בין סרטונים של 30 FPS לבין סרטונים של 60 FPS הוא לא יותר מ-7.5%

מנגנוני כשל:

  • העיגול בסרטון בקצב של 30 FPS שונה באופן משמעותי בגודל מהעיגול בסרטון בקצב של 60 FPS.
  • העיגול בתמונה שצולמה מעוות על ידי צינור עיבוד הנתונים.
  • העיגול בתמונה שצולמה נחתך בגלל בקשת צילום ביחס גובה-רוחב קיצוני, שמצמצם את הגובה או הרוחב של התמונה.
  • בעיגול בתמונה שצולמה יש השתקפות במרכז והוא לא מלא לגמרי.

test_aspect_ratio_and_crop

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

ממשקי ה-API שנבדקו:

הצלחה: התמונות לא מורחבות, מרכז התמונות לא שונה ביותר מ-3% והשדה החזותי המקסימלי נשמר.

מנגנוני כשל:

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

test_multi_camera_alignment

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

ממשקי ה-API שנבדקו:

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

מנגנוני כשל:

  • הערכים LENS_INTRINSIC_CALIBRATION,‏ LENS_POSE_TRANSLATION ו-LENS_POSE_ROTATION הם ערכי תכנון ולא נתוני כיול בפועל.
  • מערכת המצלמה לא מתאימה להגדרת הבדיקה. לדוגמה, בדיקה של מערכת מצלמה רחבה ומערכת מצלמה רחבה במיוחד באמצעות ערכת הבדיקה RFoV. מידע נוסף זמין במאמר שאלה 1 בנושא שאלות נפוצות בנושא מצלמת ITS-in-a-box.

test_preview_aspect_ratio_and_crop

בדומה לבדיקה test_aspect_ratio_and_crop של צילומי סטילס, הבדיקה הזו בודקת את הפורמטים הנתמכים של קטעים לדוגמה כדי לוודא שפריימים של קטעים לדוגמה לא נמתחים או חתוכים בצורה לא הולמת. בודק שיחס הגובה-רוחב של העיגול לא משתנה, שהתמונות החתוכות שומרות על העיגול במרכז המסגרת ושגודל העיגול לא משתנה בפורמט קבוע או ברזולוציות שונות (בדיקת שדה הראייה).

ממשקי ה-API שנבדקו:

הצלחה: התמונות לא מורחבות, מרכז התמונות לא שונה ביותר מ-3% והשדה החזותי המקסימלי נשמר.

test_preview_stabilization_fov

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

ממשקי ה-API שנבדקו:

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

test_video_aspect_ratio_and_crop

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

ממשקי ה-API שנבדקו:

הסרטון עובר: הפריים של הסרטון לא נמתח, מרכז הפריים לא שונה ביותר מ-3% והשדה החזותי המקסימלי נשמר.

scene5

ב-scene5 נדרשת סצנה אפורה עם תאורה אחידה. כדי לעשות זאת, מניחים מפזר אור מעל עדשת המצלמה. אנחנו ממליצים על המפיץ הבא: www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168.

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

scene5 example

איור 117. דוגמה לצילום של scene5.

test_lens_shading_and_color_uniformity

הבדיקה נועדה לוודא שהתיקון של ההצללה בעדשה מיושם בצורה נכונה, ושצבע של סצנה מונוכרום אחידה מופץ באופן שווה. ביצוע הבדיקה הזו על פריים YUV עם 3A אוטומטי. ההערכה של הצללה בעדשה מתבצעת על סמך ערוץ ה-y. הפונקציה מודדת את ערך ה-y הממוצע לכל בלוק לדגימה שצוין, ומחליטה אם הבדיקה עוברת או נכשלת על סמך השוואה לערך ה-y במרכז. בדיקת אחידות הצבע מתבצעת במרחב אדום-ירוק ובמרחב כחול-ירוק.

ממשקי ה-API שנבדקו:

הצלחה: כדי לעבור את הבדיקה, ההבדל בין הערך האדום-ירוק לערך הכחול-ירוק חייב להיות קטן מ-20% ברדיוס שצוין בתמונה.

scene6

scene6 הוא רשת של סמנים ייחודיים של ArUco. בדיקות ב-scene6 יכולות להיות רגישות ליישור, לכן החל מגרסה 15 אפשר להשתמש ב-check_alignment.py בספריית הכלים כדי להפעיל בדיקה של DUT ויישור התרשים.

scene6

איור 118. דוגמה של scene6.

test_in_sensor_zoom

בדיקה של התנהגות התכונה 'זום בתוך החיישן' במצלמה, שמפיקה תמונות גולמיות חתוכות.

כשמגדירים את תרחיש לדוגמה של הסטרימינג ל-CROPPED_RAW, מתבצעות במהלך הבדיקה שתי צילומים בטווח הזום: תמונה גולמית מלאה של שדה הראייה ותמונה גולמית חתוכה. הבדיקה ממירה את התמונות למערכים של RGB, מקטינה את התמונה הגולמית החתוכה בגודל מלא לגודל שצוין ב-SCALER_RAW_CROP_REGION ומחשבת את ההבדל ב-RMS תלת-ממדי בין שתי התמונות.

ממשקי ה-API שנבדקו:

הצלחה: ההבדל ב-RMS תלת-ממדי בין התמונה הגולמית החתוכה והמוקטנת לבין התמונה הגולמית במלוא שדה הראייה קטן מהסף שהוגדר בבדיקה.

test_zoom

בדיקה של התנהגות הזום במצלמה מהעדשה הרחבה במיוחד לעדשה הרחבה. המצלמה מצלמת בטווח מרחק התצוגה ומבדיקה אם סמלי ArUco גדלים ככל שמרחק התצוגה קטן. הבדיקה גם בודקת אם המיקום של סמן המרכז משתנה באופן צפוי בכל צילום. המרחק ממרכז הסמן במרכז התמונה יכול להשתנות בקצב קבוע ביחס ליחס הזום עד שמבצעים החלפה פיזית של המצלמה, או שהוא יכול להשתנות באופן מונוטוני לכיוון המיקום של אותו סמן אחרי שמבצעים החלפה פיזית של המצלמה. לפני הבדיקה, צריך להתקין במכשיר את אפליקציית Jetpack Camera (JCA).

ממשקי ה-API שנבדקו:

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

test_zoom כדי למצוא את קווי המתאר של סמן ArUco הקרוב ביותר למרכז

איור 119. test_zoom כדי למצוא את קווי המתאר של סמן ArUco הקרוב ביותר למרכז.

test_low_latency_zoom

בדיקה של התנהגות הזום של המצלמה עם זמן אחזור נמוך. הפונקציה מצלמת תמונות בטווח הזום באמצעות android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) ובודקת אם הסמנים בתמונות הפלט תואמים ליחסי הזום במטא-נתונים של הצילום. אותו סשן צילום במצלמה משמש כדי למזג את 3A ולבצע צילומים.

ממשקי ה-API שנבדקו:

הצלחה: הגודל היחסי של הסמן שצולם תואם למטא-נתונים של תוצאת יחס הזום.

test_preview_video_zoom_match

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

ממשקי ה-API שנבדקו:

הצלחה: הגודל היחסי של הסמן שצולם תואם ליחס הזום המבוקש בסרטון ובתצוגה המקדימה.

HD_1280x720_key_frame.png

איור 120. HD_1280x720_key_frame.png (לפני הזום).

preview_1280x720_key_frame.png

איור 121. preview_1280x720_key_frame.png (לפני הגדלת התצוגה).

HD_1280x720_key_frame_zoomed.png

איור 122. HD_1280x720_key_frame.png (אחרי הגדלה).

preview_1280x720_key_frame_zoomed.png

איור 123. preview_1280x720_key_frame.png (אחרי הגדלה).

test_preview_zoom

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

ממשקי ה-API שנבדקו:

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

תמונות של test_preview_zoom שמציגות את הסמן שנבחר הקרוב ביותר למרכז

איור 124. תמונות של test_preview_zoom שבהן מוצג הסמן שנבחר והקרוב ביותר למרכז

test_session_characteristics_zoom

בדיקה של טווח יחס הזום לכל הגדרות הסשן הנתמכות שמפורטות בקטע CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION. לכל אחת מההגדרות האלה, אם הפונקציה CameraDeviceSetup#isSessionConfigurationSupported מחזירה את הערך true, הבדיקה מאמתת שאפשר להגיע לטווח של יחס הזום שמוחזר ב-CameraDeviceSetup#getSessionCharacteristics.

ממשקי ה-API שנבדקו:

הצלחה: אפשר להגיע ליחסי הזום המינימליים והמקסימליים לכל SessionConfiguration נתמך שמופיע ב-CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION.

scene7

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

scene7

איור 125. scene7.

test_multi_camera_switch

הבדיקה הזו מאשרת שבמהלך הקלטת תצוגה מקדימה ביחסי זום שונים, המעבר בין העדשה הרחבה במיוחד (UW) לעדשה הרחבה (W) מניב ערכים דומים של RGB.

הבדיקה מתבססת על יחסי זום שונים בטווח שהוגדר מראש, כדי לבצע הקלטה של תצוגה מקדימה דינמית ולזהות את הנקודה שבה המצלמה הפיזית משתנה. הנקודה הזו מסמנת את המעבר מהעדשה הרחבה במיוחד (UW) לעדשה הרחבה (W).

הפריימים שצולמו לפני נקודת המעבר וגם בנקודת המעבר עצמה נבדקים כדי לקבוע את הערך של החשיפת האוטו (AE), של איזון הלבן האוטומטי (AWB) ושל המיקוד האוטומטי (AF).

בדיקת ה-AE מוודאת ששינוי הלומה נמצא בטווח הצפוי גם בתמונות עם עדשת UW וגם בתמונות עם עדשת W. בדיקת ה-AWB מוודאת שהיחסים בין האדום לירוק ובין הכחול לירוק נמצאים בטווח הערכים הסף גם בתמונות עם עדשת UW וגם בתמונות עם עדשת W. בדיקת המיקוד האוטומטי מעריכה את הערך של אומדן החדות על סמך עוצמת השיפוע הממוצעת בין תמונות של עדשת UW לבין תמונות של עדשת W.

במהלך ביצוע הבדיקה, אם אפקט ה-Moire מפריע לתוצאות, צריך להשתמש בטאבלט עם רזולוציה גבוהה יותר מהרשימה של טאבלטים שאושרו על ידי Camera ITS.

ממשקי ה-API שנבדקו:

הצלחה: כדי שהבדיקה תעבור, הבדיקות של AE ו-AWB חייבות לעבור. תוצאות הבדיקה של AF משמשות רק לצורכי רישום ביומן. אלה הקריטריונים לכל בדיקה:

  • בדיקת AE: השינוי ב-luma (ערך Y) בין התמונות של העדשה הרחבה והעדשה הרגילה חייב להיות קטן מ-4% בכל תיקוני הצבעים, אם המכשיר תומך גם ב-ae_regions וגם ב-awb_regions. אם יש תמיכה רק ב-ae_regions, רק הערכים של תיקוני הצבע האפור חייבים לעמוד בקריטריונים.
  • בדיקת AWB: אם המכשיר תומך ב-ae_regions וב-awb_regions, ההפרש בין הערכים של האדום-ירוק והכחול-ירוק בתמונות של עדשת UW ושל עדשת W חייב להיות קטן מ-3% בכתמי הצבע האפורים, וקטן מ-10% בכתמי צבע אחרים.
  • בדיקת AF: חדות התמונה שצולמה באמצעות עדשת W צריכה להיות גבוהה יותר מחדות התמונה שצולמה באמצעות עדשת UW.

test_multi_camera_switch_gray_uw_y

איור 126. כתם אפור שצולם באמצעות עדשת UW.

test_multi_camera_switch_gray_w_y

איור 127. כתם אפור שצולם באמצעות עדשת W.

scene8

scene8 הוא מסגרת מלבנית שמחולקת לארבעה אזורים שווים, כל אחד מהם מכיל דיוקן שצולם בחשיפה שונה או עם שכבת-על בצבע שונה (גוון כחול, חשיפה מוגברת, חשיפה מופחתת, גוון צהוב). ארבעת הסמנים של ArUco מותאמים לארבעת הפינות החיצוניות של המלבן כדי לקבל קואורדינטות מדויקות של מסגרת המלבן הראשית.

scene8 example

איור 128. דוגמה של scene8.

test_ae_awb_regions

בדיקה שמראה שהערכים של RGB ו-luma שונים כשמצלמים קטע מקדים באזורים שונים של AE ו-AWB.

הבדיקה מתעדת הקלטה של תצוגה מקדימה באורך 8 שניות, ומבצעת מדידה של AE ו-AWB בכל רבעון למשך 2 שניות כל אחד. לאחר מכן, הבדיקה מחלצת פריים מהקלטת התצוגה המקדימה של כל אזור, ומשתמשת בפריימים שחולצו כדי לבצע את הבדיקות הבאות של AE ו-AWB:

  • בדיקת AE: בדיקה שמאשרת שלפריים שמבצע מדידה של האזור עם חשיפת תמונה מופחתת יש ערך לומינה גבוה יותר מ-1% בהשוואה לפריים שמבצע מדידה של האזור עם חשיפת תמונה מוגברת. כך אפשר לוודא שהתמונות מוארות יותר כשמדידת התאורה מתבצעת באזור חשוך.
  • בדיקת AWB: בודקת שיחס האדום לכחול (של ערכי ה-RGB הממוצעים של התמונה) בפריים עם אזור המדידה הכחול גבוה ב-2% לפחות מהפריים עם אזור המדידה הצהוב. כך מוודאים שלתמונות יש ערך RGB מאוזן כשמודדים אזור צהוב (חם) או כחול (קר).

ממשקי ה-API שנבדקו:

הצלחה: הבדיקות של AE ו-AWB עוברות.

test_ae_awb_regions_dark_region

איור 129. מדידת התאורה בפריים של אזור כהה עם חשיפה מוגברת.

test_ae_awb_regions_light_region

איור 130. מדידת פריימים באזור בהיר יותר עם חשיפה מופחתת.

מנגנוני כשל:

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

    חוסר התאמה של סמנים מסוג ArUco

    איור 131. אי-התאמה של סמנים מסוג ArUco.

test_color_correction_mode_cct

בדיקות של COLOR_CORRECTION_MODE עם טמפרטורות וצבעי טינט שונים, כדי לוודא שינויים ביחסי RGB בהשוואה לסצנה שצולמה, scene8.

ממשקי ה-API שנבדקו:

הצלחה: יחסי ה-RGB מציגים את העליות או הירדות הצפויות ביחס לטמפרטורות ולגוונים שנבחרו.

בדיקת קריטריונים לדילוג

הבדיקה test_color_correction_mode_cct מועברת אם מתקיים אחד מהקריטריונים הבאים:

scene9

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

scene9 example

איור 132. דוגמה לסצנה 9.

test_jpeg_high_entropy

בדיקה של דחיסת JPEG במצלמה שפועלת ב-scene9 עם אנטרופי גבוה וגורם איכות JPEG מוגדר ל-100%. גורם הזום גדל כדי לוודא שהסצנה שמוצגת בטאבלט ממלאת את שדה הראייה של המצלמה.

ממשקי ה-API שנבדקו:

הצלחה: קובץ ה-JPEG נדחס כראוי, נכתב ונקרא מחדש מהדיסק.

test_jpeg_quality

בדיקה של איכות דחיסת ה-JPEG במצלמה. מעבירים איכות JPEG דרך android.jpeg.quality ומוודאים ששולחנות הקידוד משתנים בצורה נכונה.

ממשקי ה-API שנבדקו:

הצלחה: מטריצת הקידוד מצטמצמת ככל שהאיכות עולה. (המטריצה מייצגת את גורם החלוקה).

ממוצעים של מטריצות DQT של לומה וצבע במצלמה האחורית של Pixel 4 בהשוואה לאיכות JPEG

איור 133. ממוצעים של מטריצות DQT של לומה וצבע במצלמה האחורית של Pixel 4 בהשוואה לאיכות JPEG.

דוגמה לבדיקה שנכשלה של test_jpeg_quality

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

scene_video

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

איור 135. דוגמה ל-scene_video.

test_preview_frame_drop

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

ממשקי ה-API שנבדקו:

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

scene_extensions

הבדיקות מסוג scene_extensions מיועדות לתוספי מצלמה, וצריך להשתמש ב-Camera ITS-in-a-Box, כי הן דורשות שליטה מדויקת בסביבת הבדיקה. בנוסף, צריך לשלוט בכל דליפות האור. יכול להיות שתצטרכו לכסות את מכונת הבדיקה, את ה-DUT ואת הטאבלט במפה, וגם למנוע זליגת אור מהמסך הקדמי של ה-DUT.

scene_hdr

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

scene_hdr

איור 136. דוגמה ל-scene_hdr.

test_hdr_extension

בדיקה של תוסף ה-HDR. מצלמים תמונות עם התוסף מופעל וגם בלי התוסף מופעל, ובודקים אם התוסף עוזר לזהות את קוד ה-QR.

ממשקי ה-API שנבדקו:

הצלחה: התוסף HDR מפחית את מספר השינויים בניגודיות הנדרשים לזיהוי קוד ה-QR או מפחית את הדרגתיות בקוד ה-QR.

scene_low_light

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

דוגמה ל-scene_low_light

איור 137. דוגמה ל-scene_low_light.

test_night_extension

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

  • זיהוי נוכחות של 20 ריבועים
  • חישוב הלומה שמוקפת בכל ריבוע
  • חישוב הערך הממוצע של הלומה ב-6 הריבועים הראשונים בהתאם לכיוון של רשת עקומת הילברט
  • מחשבת את ההפרש בערך הלומה של ריבועים עוקבים (לדוגמה, square2 - square1) עד הריבועים 5 ו-6 (square6 - square5), ומוצאת את הממוצע של חמשת ההפרשים המחושבים.

במכשירים עם Android מגרסה 16 ואילך, בקשת הצילום כוללת אזור מחושב שתואם למלבן שמקיף את רשת הריבועיים. ההוספה הזו משנה את קריטריונים הסף לקבלת אישור.

ממשקי ה-API שנבדקו:

אישור:

  • במכשירים עם Android מגרסה 16 ואילך, ערך הלומה הממוצע של 6 הריבועים הראשונים צריך להיות לפחות 80, וההפרש הממוצע בערך הלומה של ריבועים רצופים עד הריבועים 5 ו-6 צריך להיות לפחות 18.75.
  • במכשירים עם Android מגרסה 15 וגרסאות קודמות, הערך הממוצע של הלומה ב-6 הריבועים הראשונים חייב להיות לפחות 85, וההפרש הממוצע בערך הלומה של ריבועים עוקבים עד הריבועים 5 ו-6 חייב להיות לפחות 17.

בתרשים הבהירות הבא מוצגת תוצאת בדיקה שעברה.

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

איור 138. דוגמה לתמונה של לילה בתאורה חלשה שעברה את הבדיקה.

test_low_light_boost_extension

בדיקה של מצב AE עם הגברת התאורה החלשה. אם Camera2 תומך במצב AE לשיפור התמונה בתאורה חלשה, הבדיקה הזו מתבצעת עבור Camera2. אם יש תמיכה בתוסף המצלמה של מצב הלילה והתוסף תומך במצב AE לשיפור התמונה בתאורה חלשה, הבדיקה הזו מתבצעת גם בתוסף המצלמה של מצב הלילה. בבדיקה הזו מגדירים את מצב ה-AE ל'שיפור בתנאי תאורה חלשה', מצלמים פריים מהתצוגה המקדימה ומבצעים את הפעולות הבאות:

  • זיהוי נוכחות של 20 תיבות
  • חישוב הלומה (luma) שמוגדר על ידי כל תיבה
  • חישוב הערך הממוצע של הלומה של 6 הריבועים הראשונים בהתאם לכיוון של רשת עקומת הילברט
  • מחשבת את ההפרש בערך הלומה של ריבועים עוקבים (לדוגמה, square2 - square1) עד הריבועים 5 ו-6 (square6 - square5), ומוצאת את הממוצע של חמשת ההפרשים המחושבים.

במכשירים עם Android מגרסה 16 ואילך, בקשת הצילום כוללת אזור מחושב שתואם למלבן שמקיף את רשת הריבועיים. ההוספה הזו משנה את קריטריונים הסף לקבלת אישור.

ממשקי ה-API שנבדקו:

אישור:

  • במכשירים עם Android מגרסה 16 ואילך, ערך הלומה הממוצע של 6 הריבועים הראשונים חייב להיות לפחות 54, וההפרש הממוצע בערך הלומה של ריבועים רצופים עד הריבועים 5 ו-6 חייב להיות לפחות 17.

  • במכשירים עם Android מגרסה 15 וגרסאות קודמות, הערך הממוצע של הלומה ב-6 הריבועים הראשונים חייב להיות לפחות 70, וההבדל הממוצע בערך הלומה של ריבועים רצופים עד הריבועים 5 ו-6 חייב להיות לפחות 18.

scene_tele

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

הגדרת scene_tele על סמך מרחק המיקוד של מצלמה רחבה ומצלמת טלפוטו

איור 139. הגדרת scene_tele על סמך מרחק המיקוד של מצלמה רחבה ומצלמת טלפוטו.

מידע נוסף על הגדרת חומרת הבדיקה זמין במאמר הגדרת ציוד להרחבת טווח.

scene6_tele

הסצנה scene6_tele מורכבת מרשת של סמנים מסוג ArUco על רקע לבן.

אם התמונות שצולמו ב-scene6_tele נראות כהות מדי במערך הצילום המודולרי, מסירים את הלוח הקדמי של מערך הצילום המודולרי.

מנתקים את ערכת הבדיקה של שדה הראייה הפתוח מהתוסף ומסירים את מעמד הטלפון.

מנתקים את ערכת הבדיקה של WFoV מהתוסף ומסירים את מעמד הטלפון.

איור 140. מנתקים את ערכת הבדיקה של שדה הראייה הפתוח מהתוסף ומסירים את מעמד הטלפון.

remove_front_plate

איור 141. מסירים את הלוח הקדמי.

test_zoom_tele

בדיקה של התנהגות הזום במצלמה מהעדשה הרחבה לעדשת הטלפוטו. הבדיקה זהה לבדיקה test_zoom, אבל היא בודקת את התנהגות הזום של המצלמה מהעדשה הרחבה לעדשת הטלפוטו.

ממשקי ה-API שנבדקו:

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

test_preview_zoom_tele

בדיקה של התנהגות הזום במצלמה בפריימים של תצוגה מקדימה מהעדשה הרחבה ועד לעדשת הטלפוטו. הבדיקה זהה לבדיקה test_preview_zoom, אבל היא בודקת את התנהגות הזום של המצלמה בפריימים של התצוגה המקדימה מהעדשה הרחבה לעדשת הטלפוטו.

ממשקי ה-API שנבדקו:

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

scene7_tele

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

test_multi_camera_switch_tele

הבדיקה הזו מאשרת שבמהלך הקלטת תצוגה מקדימה ביחסי זום שונים, המעבר בין העדשה הרחבה (W) לעדשת הטלפוטו (tele) גורם לערכים דומים של RGB.

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

הפריימים שצולמו בנקודת המעבר וקודם לה נבדקים לצורך התאמת AE,‏ AWB ו-AF.

בדיקת ה-AE מוודאת ששינוי הלומה נמצא בטווח הצפוי גם בתמונות עם עדשת W וגם בתמונות עם עדשת טלה. בדיקת ה-AWB מוודאת שהיחסים בין האדום לירוק ובין הכחול לירוק נמצאים בטווח הערכים הסף גם בתמונות עם עדשת W וגם בתמונות עם עדשת טלה. בדיקת המיקוד האוטומטי מעריכה את הערך של אומדן החדות על סמך עוצמת השיפוע הממוצעת בין תמונות שצולמו עם עדשת W לבין תמונות שצולמו עם עדשת טלה.

ממשקי ה-API שנבדקו:

הצלחה: כדי שהבדיקה תעבור, כל הבדיקות של AE,‏ AWB ו-AF צריכות לעבור. אלה הקריטריונים לכל בדיקה:

  • בדיקת AE: השינוי ב-luma בין התמונות שצולמו עם עדשת W לבין התמונות שצולמו עם עדשת הטלפוטו חייב להיות קטן מ-4%.
  • בדיקת AWB: במרחב הצבעים LAB, הערך של דלתא C בין אדום-ירוק לבין כחול-ירוק לצילום רחב ולצילום טלפוטו לא יכול לחרוג מ-10.
  • בדיקת AF: חדות התמונה של עדשת הטלה חייבת להיות גבוהה יותר מזו של עדשת W.

scene_flash

כדי לבצע את הבדיקות של scene_flash, צריך סצנה חשוכה בתיבה של שילוב החיישנים.

test_auto_flash

הבדיקה נועדה לוודא שהפלאש האוטומטי מופעל בסצנה חשוכה במצלמה האחורית ובמצלמה הקדמית. במצלמות קדמיות, הפלאש האוטומטי משתמש במסך כדי להאיר את הסצנה, ולא ביחידה פיזית של פלאש. הבדיקה נועדה לוודא שהפלאש האוטומטי מופעל. לשם כך, היא בודקת אם מרכז התמונה של המשבצת בהיר יותר כשהפלאש האוטומטי מופעל. כדי להפעיל את הפלאש האוטומטי, צריך לכבות את הנורות במתקן הבדיקה. אפשר לכבות את הנורות באופן אוטומטי באמצעות בקר Arduino. כדי שהבדיקה תפעל כמו שצריך, הסצנה צריכה להיות חשוכה לגמרי. לפני הבדיקה, צריך להתקין במכשיר את אפליקציית Jetpack Camera (JCA). הפלאש האוטומטי במצלמות אחוריות פועל רק אם מצב ה-AE מופעל, אבל הפלאש האוטומטי במצלמות קדמיות פועל תמיד, ללא קשר למצב ה-AE.

ממשקי ה-API שנבדקו:

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

test_flash_strength

בדיקה שהבקרה על עוצמת הפלאש במצב SINGLE הוטמעה כראוי.

בדיקה אם המכשיר תומך בשליטה בעוצמת הפלאש במהלך השימוש במצלמה במצב SINGLE, ואם עוצמת הפלאש משתנה בהתאם לרמות עוצמה שונות שנדרשות. בדיקה שהשליטה בעוצמת הפלאש פועלת עם AE_MODES שונים. לדוגמה, אם מצב החשיפה האוטומטי הוא ON או OFF, עוצמת הפלאש משפיעה על הבהירות. אם המצב הוא ON_AUTO_FLASH, עוצמת הפלאש לא משפיעה על הבהירות.

כדי לבצע את הבדיקה, צריך לכבות את התאורה במתקן הבדיקה. אפשר לכבות את התאורה באופן אוטומטי באמצעות בקר Arduino. כדי שהבדיקה תפעל כראוי, הסצנה צריכה להיות חשוכה לחלוטין.

ממשקי ה-API שנבדקו:

אישור:

כשמצב החשיפה האוטומטי הוא ON או OFF, הבהירות של כתמי התמונה עולה ככל שעוצמתו של הפלאש עולה, מבלי להפעיל את הפלאש ועד ל-FLASH_SINGLE_STRENGTH_MAX_LEVEL. כשמצב החשיפה האוטומטי הוא ON_AUTO_FLASH, ההבדל בבהירות של כתמי התמונה נמצא בטווח הסביר כשרמת עוצמת הפלאש עולה מאפס ל-FLASH_SINGLE_STRENGTH_MAX_LEVEL.

test_led_snapshot

בדיקה שמטרתה לוודא שתמונות ה-LED לא גורמות לרוויה או לגוון של התמונה.

בבדיקה הזו מוסיפים ל-Sensor Fusion Box בקר תאורה כדי לשלוט בתאורה. כשהנורות מוגדרות למצב OFF, הבדיקה מתבצעת במצב AUTO_FLASH שמוגדר ל-ON. במהלך הצילום, הבדיקה מפעילה רצף של צילום מראש עם הטריגר aePrecapture שמוגדר ל-START, ומגדירה את הכוונה לצילום כ-Preview כדי לבצע את הצילום עם פלאש.

מכיוון שלצילום יש נקודה חמה ייחודית עקב הפעלת הפלאש, הבדיקה מחשבת את הממוצע של התמונה עם הפלאש מכל הצילום ומוודאת שהערך נמצא בטווח (68, 102). כדי לבדוק אם התמונה מאוזנת באופן סביר, הבדיקה מחשבת את היחסים בין אדום לירוק ובין כחול לירוק, ובודקת אם היחסים נעים בין 0.95 ל-1.05.

ממשקי ה-API שנבדקו:

עומד בדרישות: היחסים בין אדום-ירוק ובין כחול-ירוק נעים בין 0.95 ל-1.05. הממוצע של התמונה עם הפלאש נמצא בטווח (68, 102).

test_night_mode_indicator

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

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

  1. הפעלה: הבדיקה מפעילה את ItsSession ומאחזרת את מאפייני המצלמה. הוא גם יוצר חיבור למתג התאורה.
  2. תנאי דילוג: הבדיקה מועברת אם המכשיר לא תומך ברמת ה-API הנדרשת או בתכונה של אינדיקטור מצב לילה.
  3. Camera2 Session:
    • הבדיקה מתחילה סשן צילום של תצוגה מקדימה באמצעות סשן Camera2.
    • הנורה תידלק ותתבצע צילום של מסגרת תצוגה מקדימה.
    • הבדיקה מוודאת שהסמל של מצב הלילה נמצא במצב OFF.
    • התאורה נכבית ומצולמת תמונה של תצוגה מקדימה.
    • הבדיקה מוודאת שהסמל של מצב הלילה נמצא במצב ON.
  4. סשן של תוסף המצלמה:
    • הבדיקה חוזרת על אותה פרוצדורה כמו בסשן Camera2, אבל באמצעות סשן CameraExtension עם התוסף EXTENSION_NIGHT.
  5. ניקוי: הבדיקה סוגרת את ItsSession ומבטלת את הנעילה של בקר התאורה.

ממשקי ה-API שנבדקו:

אישור:

  • כשהנורה דולקת, האינדיקטור של מצב הלילה אמור להיות במצב OFF.
  • כשהנורה כבויה, האינדיקטור של מצב הלילה צריך להיות במצב ON.
  • ההגדרה חלה גם על סשנים של Camera2 וגם על סשנים של CameraExtension.

test_preview_min_frame_rate

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

ממשקי ה-API שנבדקו:

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

test_torch_strength

בדיקה שהבקרה על עוצמת הפלאש במצב TORCH הוטמעה כראוי.

הפונקציה מאמתת שאם המכשיר תומך בשליטה בעוצמת הפלאש במהלך השימוש במצלמה במצב TORCH, עוצמת הפנס משתנה בהתאם לרמות עוצמה שונות שנדרשות. בדיקה שהשליטה בעוצמת הפלאש פועלת עם AE_MODES שונים. לדוגמה, אם מצב החשיפה האוטומטי הוא ON או OFF, עוצמת הפלאש משפיעה על הבהירות. אם המצב הוא ON_AUTO_FLASH, עוצמת הפלאש לא משפיעה על הבהירות. בדיקה שמאשרת שעצמת הפנס נשארת זהה לאורך כל רצף התמונות, בסימולציה של סשן צילום וידאו. כדי לבצע את הבדיקה, צריך לכבות את התאורה במתקן הבדיקה. אפשר לכבות את התאורה באופן אוטומטי באמצעות בקר Arduino. כדי שהבדיקה תפעל כמו שצריך, הסצנה צריכה להיות חשוכה לגמרי.

ממשקי ה-API שנבדקו:

אישור:

כשמצב החשיפה האוטומטי הוא ON או OFF, הבהירות של קטעי התמונות ברצף עולה ככל שעוצמתו של הפלאש עולה, מבלי להפעיל את הפלאש ועד ל-FLASH_TORCH_STRENGTH_MAX_LEVEL. כשמצב החשיפה האוטומטי הוא ON_AUTO_FLASH, ההבדל בבהירות של קטעי התמונה ברצף הוא בטווח הסביר ככל שרמת עוצמת הפלאש עולה, מבלי להפעיל פלאש ועד FLASH_TORCH_STRENGTH_MAX_LEVEL.

sensor_fusion

כדי לבצע בדיקות של שילוב חיישנים, צריך להזיז את הטלפון באופן ספציפי מול דפוס של משחק דמקה וסימני ArUco. כדי לקבל תוצאות מיטביות, צריך לוודא שהתרשים לבדיקה מותקן בצורה ישרה. גרפים שאינם שטוחים משפיעים על חישובי הסיבוב של רבים מהבדיקות. צריך להדפיס את התרשים בגודל 17x17 in כדי למלא את החלק האחורי של תיבת מיזוג החיישנים. (43x43 ס"מ). אפשר להפוך את הבדיקות של sensor_fusion לאוטומטיות באמצעות Sensor Fusion Box.

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

איור 142. תרשים של מיזוג חיישנים.

תרשים של מיזוג חיישנים ב-Rig

איור 143. תרשים של שילוב חיישנים שממלא את החלק האחורי של התיבה של שילוב החיישנים.

test_lens_intrinsic_calibration

בדיקה של השינויים הפנימיים במרכז האופטי של העדשה כשהעדשה זזה עקב ייצוב תמונה אופטי (OIS). אם יש תמיכה במדגם פנימי של עדשה, הבדיקה בודקת שהמרכז האופטי של המדגם הפנימי של העדשה משתנה כשהעדשה זזה בגלל OIS.

ממשקי ה-API שנבדקו:

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

באיור הבא מוצגת דוגמה לתרשים test_lens_intrinsic_calibration שמציג שינויים בנקודות הראשיות בפיקסלים לכל פריים:

test_lens_intrinsic_calibration_example.png

איור 144. דוגמה לתרשים של test_lens_intrinsic_calibration שמראה שינויים בנקודות הראשיות בפיקסלים לכל פריים.

test_multi_camera_frame_sync

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

ממשקי ה-API שנבדקו:

הצלחה: הזווית בין התמונות מכל מצלמה לא משתנה באופן משמעותי כשהטלפון מסתובב.

test_preview_distortion

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

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

test_preview_distortion_example.jpg

איור 145. תמונה של לוח שחמט עם נקודות אידיאליות בצבע ירוק ונקודות בפועל בצבע אדום.

ממשקי ה-API שנבדקו:

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

test_preview_stabilization

בדיקות שמראות שהסרטון המייצב של התצוגה המקדימה מסתובב פחות מאשר הגירוסקופ.

ממשקי ה-API שנבדקו:

הבדיקה עברה: זווית הסיבוב המקסימלית בפריימים נמוכה מ-70% מסיבוב הגירוסקופ.

לפניכם דוגמאות לסרטונים עם ייצוב וידאו וללא ייצוב:

איור 146. סרטון לדוגמה עם ייצוב.

איור 147. דוגמה לסרטון ללא ייצוב.

test_sensor_fusion

בדיקה של ההבדל בין חותמת הזמן של המצלמה לבין חותמת הזמן של הגירוסקופ באפליקציות AR ו-VR. הטלפון מסובב ב-90 מעלות 10 פעמים מול דפוס המשבצות. זמן הנסיעה הלוך ושוב הוא כ-2 שניות. הבדיקה הזו מועברת אם לא כללתם גירוסקופ או אם הפרמטר REALTIME של מקור חותמת הזמן לא מופעל.

הבדיקה test_sensor_fusion יוצרת מספר תרשימים. שני התרשימים החשובים ביותר לניפוי באגים הם:

  • test_sensor_fusion_gyro_events: הצגת אירועי הג'ירוסקופ בטלפון במהלך הבדיקה. תנועה בכיוון x ו-y מעידה על כך שהטלפון לא מותקן בצורה מאובטחת בלוחית הקיבוע, וכתוצאה מכך פוחתת הסבירות לכך שהבדיקה תעבור. מספר המחזורים בתרשים תלוי במהירות הכתיבה לשמירת פריימים.

    דוגמה לאירועי ג&#39;ירוסקופ של test_sensor_fusion

    איור 148. דוגמה לאירועי גירוסקופ של test_sensor_fusion.

  • test_sensor_fusion_plot_rotations: הצגת ההתאמה של האירועים מהג'ירוסקופ ומהמצלמה. בתרשים הזה צריך להופיע תנועה תואמת בין המצלמה לבין הגירוסקופ, ברמת דיוק של +/-1ms.

    דוגמה לתנועות של תרשים ב-test_sensor_fusion

    איור 149. דוגמה לתנועות של תרשים ב-test_sensor_fusion.

ממשקי ה-API שנבדקו:

הצלחה: הפרש הזמן בין חותמות הזמן של המצלמה והג'ירוסקופ קטן מ-1 אלפית שנייה, בהתאם ל-7.3.9 חיישנים ברזולוציה גבוהה במסמך ה-CDD.

מנגנוני כשל:

  • שגיאת סטייה: הסטייה של הגירוסקופ במצלמה לא מותאמת בצורה נכונה בטווח של +/-1ms.
  • טיפות פריימים: צינור עיבוד הנתונים לא מהיר מספיק כדי לצלם 200 פריימים ברציפות.
  • שגיאות שקשורות ליציאות: adb לא מצליח להתחבר באופן מהימן ל-DUT למשך זמן מספיק כדי לבצע את הבדיקה.
  • התרשים לא מותקן בצורה ישרה. בתרשים test_sensor_fusion_plot_rotations יש פריימים שבהם יש הבדלים משמעותיים בין הסיבוב של הגירוסקופ לבין הסיבוב של המצלמה, כאשר המצלמה מסתובבת בחלקים של התרשים שאינם שטוחים.
  • המצלמה לא מותקנת בצורה ישרה. בתרשים test_sensor_fusion_gyro_events מוצגת תנועה במישורים X ו-Y. התקלה הזו נפוצה יותר במצלמות קדמיות, כי לרוב המצלמה האחורית בולטת מחלקי הגוף האחרים של הטלפון, וכתוצאה מכך הטלפון נוטה כשמחברים את החלק האחורי שלו ללוח ההרכבה.

test_video_stabilization

בדיקות שמראות שהסרטון המיוצב מסתובב פחות מאשר הגירוסקופ.

ממשקי ה-API שנבדקו:

הצלחה: זווית הסיבוב המקסימלית בפריימים נמוכה מ-60% מסיבוב הגירוסקופ.

בהמשך מופיעות דוגמאות לסרטונים עם ייצוב ובלי ייצוב.

איור 150. סרטון לדוגמה עם ייצוב.

איור 151. דוגמה לסרטון ללא ייצוב.

test_video_stabilization_jca

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

ממשקי ה-API שנבדקו:

הצלחה: זווית הסיבוב המקסימלית בפריימים שחולצו מסרטון שצולם באמצעות JCA היא פחות מ-70% מסיבוב הגירוסקופ.

feature_combination

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

test_feature_combination

בדיקה של כל השילובים של שילובי סטרימינג שונים, מצב ייצוב וידאו, טווח יעד של FPS, וידאו HDR באיכות 10 ביט ו-Ultra HDR שנתמכים במכשיר המצלמה.

ב-Android מגרסה 16 ואילך, הבדיקה מפעילה את כל השילובים של התכונות הנתמכות ומתעדת את התוצאות בקובץ proto. טענות הנכוֹנוּת של הכשל מופעלות רק בשילובים של תכונות שבהם הפונקציה isSessionConfigurationSupported מחזירה את הערך True.

ממשקי ה-API שנבדקו:

הצלחה: לכל שילוב של תכונות נתמכות:

  • אם התכונה 'יציבות התצוגה המקדימה' מופעלת, שידור התצוגה המקדימה יהיה יציב.
  • קצב הפריימים של התצוגה המקדימה נמצא בטווח של AE_TARGET_FPS_RANGE שהוגדר.
  • מרחב הצבעים של שידור התצוגה המקדימה המוקלט תואם למרחב הצבעים שהוגדר.
  • לצילום Ultra HDR יש מפת רווח תקינה.

scene_ip

ב-Android מגרסה 16 ואילך, הסצנה scene_ip מאפשרת לבצע בדיקות של תקינות תמונות בין אפליקציית המצלמה שמוגדרת כברירת מחדל לבין אפליקציית המצלמה של Jetpack‏ (JCA), כדי לזהות הבדלים משמעותיים בין התמונות שצולמו. ה-JCA מעתיק את התמונות שצולמו באפליקציות של רשתות חברתיות ומספק תמונה בסיסית שאפליקציות של רשתות חברתיות מעבדות ומחדדות.

דרישות להגדרת החומרה

כדי לבצע את הבדיקות של scene_ip, נדרשת הגדרת החומרה הבאה:

  • הבדיקות מתבצעות במצלמת Gen2 ITS-in-a-box.
  • בקרי התאורה והסרוו שמרכיבים את ערכת Gen2 משמשים לשלוט בסביבת הבדיקה
  • תרשים של תכונות הבדיקה ממוקם בתוך המתקן של Gen2.

test_chart_gen2

איור 152. דוגמה ל-Gen2chart_sample.

בדיקת קריטריונים לדילוג

הבדיקות של scene_ip מושמטות אם מתקיים אחד מהקריטריונים הבאים:

  • רמת ה-API הראשונה (first_api_level) של המכשיר היא 35 או פחות.
  • המכשיר הוא לא טלפון עם מצלמה קדמית ועיקרית אחורית (למשל, טאבלט או טלוויזיה).

test_default_jca_ip

הכלי מצליב את תרשימים של תכונות הבדיקה בתנאים מבוקרים של תאורה באמצעות אפליקציית המצלמה שמוגדרת כברירת מחדל ו-JCA, ומבצע את הבדיקות הבאות:

  • שדה הראייה: בדיקה ששדה הראייה של התמונות שצולמו באפליקציית המצלמה שמוגדרת כברירת מחדל וב-JCA זהה. בבדיקת הזו נעשה שימוש בתכונה של קוד QR במרכז, שמחולץ מתמונת התרשים שצולמה.

  • בהירות: הבדיקה בודקת שההבדל במדד הבהירות שנמדד בין אפליקציית המצלמה שמוגדרת כברירת מחדל לבין JCA לא חורג מ-10. הבדיקה הזו משתמשת בתיקון של טווח דינמי למדידת הבהירות.

  • איזון לבן: הבדיקה בודקת שההבדל באיזון הלבן בין אפליקציית המצלמה שמוגדרת כברירת מחדל לבין JCA לא עולה על 4. הבדיקה הזו משתמשת בתיקון של טווח דינמי למדידת הבהירות.

הצלחה בחלק הבסיסי: הבדיקה עוברת את הבדיקות של שדה הראייה, הבהירות ואיזון הלבן. ב-Android 16, הבדיקה הזו לא חובה (NOT_YET_MANDATED).