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

בדף הזה מופיעה רשימה מקיפה של הבדיקות בחבילת הבדיקות של תמונות המצלמה (ITS), שהיא חלק מ-CTS Verifier (חבילת הבדיקות לתאימות עם Android). בדיקות 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. תרשים של מבחן 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

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

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

דוגמה של סצנה 1

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

test_ae_precapture_trigger

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

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

הצלחה: איחוד האמירויות הערביות מתכנסת.

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, דוגמה לבנה.

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 בפורמט 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 יש ערכי בהירות יציבים.

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. test_latching 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 (באמצעות הגדרה אוטומטית). הבדיקה הזו מיועדת לעבור גם במכשירים מוגבלים שאין בהם MANUAL_SENSOR או PER_FRAME_CONTROLS. הבדיקה בודקת את העקביות של תמונת YUV בזמן שבדיקת קצב הפריימים מתבצעת ב-CTS.

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

עבר: התמונות נראות עקביות.

test_locked_burst frame0 example

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

דוגמה ל-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 מוגדלים בהתאם לשינוי.

test_param_color_correction plot means example

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

באיורים הבאים, ציר ה-x הוא בקשות הצילום: 0 = unity,‏ 1 = red boost ו-2 = blue boost.

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

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

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

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

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

test_raw_exposure ISO=55 example

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

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

דוגמה ל-ISO=132 של test_raw_exposure

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

דוגמה ל-test_raw_exposure ISO=209

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

test_raw_exposure ISO=286 example

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

דוגמה ל-test_raw_exposure ISO=363

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

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

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

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

Pass: מצלם את תמונת הסצנה עם אפקטים 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 1

איור 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 במצלמה2 חייב להיות < 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 ‏ (3000K) עבור שתי המצלמות הראשיות.

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

test_imu_drift

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

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

כרטיס:

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

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

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

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

ממשקי 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_BED_MANUAL testbed. דוגמה מופיעה במאמר בנושא קובץ ההגדרות config.yml לבדיקה ידנית. קובץ ברירת המחדל config.yml לא כולל את TEST_BED_MANUAL, אבל אפשר לשנות את הקובץ כך שיכלול אותו.

test_lens_shading_and_color_uniformity

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

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

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

scene6

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

scene6

איור 118. דוגמה של סצנה 6.

test_in_sensor_zoom

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

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

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

עובר: ההבדל בתלת-ממד RMS בין התמונה המוקטנת והחתוכה בפורמט 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) בין תמונות העדשה UW והעדשה W צריך להיות קטן מ-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 שניות, ומבצעת מדידה של חשיפה אוטומטית ואיזון לבן אוטומטי בכל רבעון למשך 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. דוגמה ל-scene9.

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