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

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

מבחני Camera 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: Zoom
  • ‫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 plot

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

test_metadata

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

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

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

test_request_capture_match

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

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

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

test_sensor_events

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

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

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

test_solid_color_test_pattern

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

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

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

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

test_test_pattern

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

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

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

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

test_test_patterns example

איור 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 שנבדקו:

עבר: המכשיר לא רוטט כשהוא מושתק על ידי Camera audio restriction API.

scene1_1

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

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

דוגמה ל-scene1

איור 5. תרשים של סצנה 1 בגודל מלא (משמאל), תרשים מוקטן ל-2/3 (מימין).

test_ae_precapture_trigger

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

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

הצלחה: מתבצעת התכנסות של AE.

test_auto_vs_manual

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

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

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

test_auto_vs_manual auto example

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

דוגמה לבדיקה של איזון לבן אוטומטי לעומת איזון לבן ידני

איור 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, black example

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

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

איור 10. test_black_white, white example.

test_black_white plot means example

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

test_burst_capture

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

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

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

test_burst_sameness_manual

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

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

עבר: התמונות זהות מבחינה חזותית ובערכי RGB.

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

  • הסבילות היא 3% עבור first_API_level < 30
  • ערך הסבילות הוא 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

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

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

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

test_crop_region_raw comp raw crop example

איור 14. דוגמה לחיתוך גולמי של test_crop_region_raw.

test_crop_region_raw comp raw full example

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

דוגמה לחיתוך של רכיב YUV test_crop_region_raw

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

test_crop_region_raw_yuv_full example

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

test_crop_regions

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

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

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

test_ev_compensation

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

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

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

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

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

test_ev_compensation_basic

איור 18. test_ev_compensation_basic.

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

test_latching plot means example

איור 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. בדיקת נעילה i=11.

test_latching i=12

איור 36. test_latching i=12.

test_linearity

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

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

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

test_linearity plot means example

איור 37. דוגמה לתרשים של בדיקת לינאריות.

test_locked_burst

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

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

עבר: הצילומים נראים עקביים.

test_locked_burst frame0 example

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

test_locked_burst frame1 example

איור 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.* מוחלים כשהם מוגדרים. מצלמים תמונות עם ערכים שונים של טרנספורמציה ורווח, ובודקים שהן נראות שונות בהתאם. הטרנספורמציה וההגברות נבחרות כך שהפלט יהיה אדום או כחול יותר ויותר. נעשה שימוש במיפוי טונים ליניארי.

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

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

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

test_param_color_correction plot means example

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

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

test_param_color_correction req=0 unity example

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

test_param_color_correctness req=1 red boost example

איור 43. דוגמה לשימוש בפרמטר test_param_color_correctness עם הערך req=1 red boost.

test_param_color_correction req=2 blue boost example

איור 44. דוגמה לשיפור של צבע כחול בבקשה test_param_color_correction req=2.

test_param_flash_mode

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

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

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

test_param_flash_mode 1 example

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

דוגמה ל-test_param_flash_mode 1 tile

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

test_param_flash_mode_2 example

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

דוגמה ל-test_param_flash_mode 2 tile

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

test_param_noise_reduction

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

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

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

דוגמה ל-SNRs של העלילה test_param_noise_reduction

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

‫0: כבוי, 1: מהיר, 2: איכות גבוהה, 3: מינימלי , 4: ZSL

test_param_noise_reduction high gain nr=0 example

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

test_param_noise_reduction high gain nr=1 example

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

test_param_noise_reduction high gain nr=2 example

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

test_param_noise_reduction high gain nr=3 example

איור 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 lens shading map, mode 0 loop 0 example

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

test_param_shading_mode lens shading map, mode 1 loop 0 example

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

test_param_shading_mode lens shading map, mode 2 loop 0 example

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

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 with n=1

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

test_post_raw_sensitivity_boost

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

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

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

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

איור 60. test_post_raw_sensitivity_boost raw s=3583 boost=0100 example.

test_post_raw_sensitivity_boost raw s=1792 boost=0200 example

איור 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 example.

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 example

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

test_post_raw_sensitivity_boost raw plot means example

איור 66. test_post_raw_sensitivity_boost raw plot means example.

test_post_raw_sensitivity_boost YUV s=0112 boost=3199 example

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

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

איור 68. test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example.

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 example.

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 example

איור 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

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

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

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

דוגמה ל-test_raw_exposure ISO=55

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

‫10⁰ הוא 1 אלפית השנייה, 10¹ הוא 10 אלפיות השנייה ו-10⁻¹ הוא 0.1 אלפית השנייה.

test_raw_exposure ISO=132 example

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

דוגמה ל-test_raw_exposure ISO=209

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

test_raw_exposure ISO=286 example

איור 76. דוגמה ל-ISO של test_raw_exposure‏=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 מוחל עליהן לעיבוד מחדש של בקשות. מצלם תמונות שעברו עיבוד מחדש כשהתאורה במצלמה עמומה. משתמש ברווח אנלוגי גבוה כדי לוודא שהתמונה שצולמה רועשת. מצלם שלוש תמונות שעברו עיבוד מחדש, ללא הפחתת רעשים, עם הפחתת רעשים מהירה ועם הפחתת רעשים באיכות גבוהה. מצלם תמונה שעברה עיבוד מחדש עם הגברה נמוכה (low gain) וביטול של NR, ומשתמש בשונות של התמונה הזו כבסיס.

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

עובר: FAST >= OFF,‏ HQ >= FAST ו-HQ >> OFF.

גרף אופייני של יחס אות לרעש לעומת מצב NR

איור 79. דוגמה לתרשים של יחס אות לרעש (SNR) לעומת מצב NR.

test_tonemap_sequence

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

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

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

test_tonemap_sequence i=0 example

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

test_tonemap_sequence i=1 example

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

test_tonemap_sequence i=2 example

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

test_tonemap_sequence i=3 example

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

test_tonemap_sequence_i=4 example

איור 84. test_tonemap_sequence i=4 example.

test_tonemap_sequence i=5 example

איור 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 example

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

test_yuv_plus_dng

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

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

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

test_yuv_plus_dng example

איור 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 raw נכונים. בתרשים מוצג השונות שנמדדה בטלאי מרכזי של כרטיס אפור בצילומים גולמיים שצולמו בטווח רגישויות, והשוואה בין הערכים האלה לבין השונות שצפויה בכל רגישות לפי מודל הרעש של DNG ב-HAL של המצלמה (על סמך הפרמטרים O ו-S שמוחזרים באובייקטים של תוצאות הצילום). לפרטים נוספים על מודל הרעש של DNG, אפשר להוריד את המסמך הבא בנושא מודל הרעש של DNG.

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

עבר: הפרמטרים של מודל DNG raw נכונים. ערכי ה-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

בודקת את הלכידה של פריים יחיד כפלט RAW (10-bit ו-12-bit RAW) ו-YUV אם נתמך. משתמשים בבקשה ידנית עם מיפוי טונים לינארי, ולכן מצפים ש-raw ו-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 באמצעות ColorSpaceProfiles API. בודק אם קובץ ה-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, שבה הוחלו באופן ידני פרמטרי החשיפה (רגישות, זמן חשיפה, משך זמן של פריים, הגברת רגישות אחרי עיבוד RAW) שהתקבלו ב-CaptureResult של התמונה שצולמה עם הפעלת AE.

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

עובר: ההבדל היחסי בבהירות בין שני הצילומים קטן מ-4%.

test_format_combos

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

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

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

test_num_faces

בודק את זיהוי הפנים.

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

עובר: נמצאו שלוש פנים.

test_num_faces face detection mode 1 example

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

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 שנבדקו:

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

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 ms ברזולוציה של 1080p, כפי שנמדד על ידי PerformanceTest של מצלמת CTS בתנאי תאורה של ITS ‏ (3,000K) בשתי המצלמות הראשיות.

test_camera_launch_perf_class

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

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

test_default_camera_hdr

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

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

scene2_d

test_preview_num_faces

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

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

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

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 example

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

test_preview_num_faces

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

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

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

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 שנבדקו:

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

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 example

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

test_edge_enhancement edge=2 example

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

test_flip_mirror

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

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

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

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

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

test_imu_drift

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

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

כרטיס:

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

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

איור 112. דוגמה לסחיפה של גירוסקופ test_imu_drift.

דוגמה לסחף של וקטור סיבוב test_imu_drift

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

test_landscape_to_portrait

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

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

Pass: The test locates a chart with the expected rotation (0 degrees when the landscape-to-portrait override is disabled, 90 degrees when enabled).

דוגמה ל-test_landscape_to_portrait

איור 114. דוגמה לשינוי מתמונה לרוחב לתמונה לאורך.

test_lens_movement_reporting

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

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

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

עובר: דגל התנועה של Lens הוא 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

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

test_30_60fps_preview_fov_match

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

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

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

מנגנוני כשל:

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

test_aspect_ratio_and_crop

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

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

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

מנגנוני כשל:

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

test_multi_camera_alignment

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

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

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

מנגנוני כשל:

  • הערכים LENS_INTRINSIC_CALIBRATION,‏ LENS_POSE_TRANSLATION ו-LENS_POSE_ROTATION הם ערכי עיצוב ולא נתוני כיול בפועל.
  • מערכת המצלמה לא מתאימה להגדרת הבדיקה, למשל, בדיקת מערכת מצלמה רחבה ומערכת מצלמה רחבה במיוחד באמצעות מתקן הבדיקה RFoV. מידע נוסף זמין בשאלה הראשונה בשאלות הנפוצות בנושא Camera 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

איור 117. דוגמה לצילום של סצנה 5.

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

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

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

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

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

test_zoom

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

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

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

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. בבדיקת ה-AF, ערך ההערכה של החדות מחושב על סמך גודל הממוצע של השיפוע בין תמונות שצולמו בעדשת UW ובעדשת W.

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

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

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

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

test_multi_camera_switch_gray_uw_y

איור 126. טלאי אפור שצולם עם עדשת UW.

test_multi_camera_switch_gray_w_y

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

scene8

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

דוגמה ל-scene8

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

test_ae_awb_regions

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

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 example

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

test_night_extension

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

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

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

במכשירים עם 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 על סמך מרחק המיקוד של המצלמה הרחבה ומצלמת הטלפוטו.

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

scene6_tele

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

אם התמונות שצולמו ב-scene6_tele נראות חשופות מדי ב-modular rig, צריך להסיר את הפלטה הקדמית של modular rig.

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

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

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

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 וגם בתמונות שצולמו עם עדשת טלה. בבדיקת ה-AF, ערך ההערכה של החדות מחושב על סמך גודל הממוצע של השיפוע בין תמונות שצולמו עם עדשת W ועדשת טלפוטו.

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

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

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

scene_flash

בבדיקות scene_flash נדרש להציג סצנה חשוכה בתיבה של שילוב החיישנים.

test_auto_flash

בדיקות שבהן ההפעלה האוטומטית של הפלאש מופעלת בסצנה חשוכה במצלמות האחוריות והקדמיות. במצלמות קדמיות, הפלאש האוטומטי משתמש במסך כדי להאיר את הסצנה, ולא ביחידת פלאש פיזית. בבדיקה מוודאים שהפלאש האוטומטי מופעל על ידי בדיקה שהמרכז של תמונת המשבצת בהיר יותר כשהפלאש האוטומטי מופעל. כדי להפעיל את הפלאש האוטומטי, צריך לכבות את האורות במתקן הבדיקה. אפשר לכבות את האורות באופן אוטומטי באמצעות בקר Arduino. כדי שהבדיקה תפעל בצורה תקינה, הסצנה צריכה להיות חשוכה לגמרי. צריך להתקין במכשיר את אפליקציית המצלמה של Jetpack‏ (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 כדי לשלוט באורות. כשהתאורה מוגדרת ל-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 אינץ'. ‫(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: הצגת היישור של הג'ירוסקופ ואירועי המצלמה. התרשים הזה צריך להציג תנועה תואמת בין המצלמה לבין הג'ירוסקופ, עם סטייה של עד +/-1 אלפיות השנייה.

    דוגמה לסיבובי תרשים של test_sensor_fusion

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

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

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

מנגנוני כשל:

  • שגיאת היסט: ההיסט של הגירוסקופ של המצלמה לא מכויל בצורה נכונה בטווח של ‎+/-1 ms.
  • נשירת פריימים: הצינור לא מהיר מספיק כדי לצלם 200 פריימים ברצף.
  • שגיאות Socket: 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

הבדיקה כוללת את כל השילובים של הגדרות שונות של הזרמת וידאו, מצב ייצוב הווידאו, טווח קצב הפריימים לשנייה, וידאו 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 camera ITS-in-a-box.
  • התאורה ובקרי הסרוו שכלולים במתקן Gen2 משמשים לשליטה בסביבת הבדיקה
  • תרשים של תכונת בדיקה מוצב בתוך מערכת Gen2.

test_chart_gen2

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

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

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

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

test_default_jca_ip

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

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

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

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

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