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

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

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

ב-Android מגרסה 17 ואילך, בדיקות Camera ITS מחולקות לשתי פעילויות ב-CTS Verifier כדי לאפשר הרצה במקביל ולקצר את זמן הבדיקה: פעילות אחת לבדיקות feature_combination ו-sensor_fusion, ופעילות נוספת לכל שאר הבדיקות. למידע נוסף, קראו את המאמר צמצום זמן הבדיקה.

ב-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: יחס גובה-רוחב, חיתוך, שדה הראייה
  • ‫scene6: זום
  • scene7: מעבר בין כמה מצלמות
  • scene8: מדידת אזור של חשיפה אוטומטית (AE) ואיזון לבן אוטומטי (AWB)
  • ‫scene9: דחיסת JPEG
  • ‫scene_extensions: תוספים למצלמה
  • ‫scene_tele: מעבר לעדשת טלפוטו
  • scene_video: דילוג על פריימים

סצנות בדיקה שמבוססות על Gen2 rig או sensor_fusion

  • ‫feature_combination: שילובים של תכונות
  • ‫scene_flash: פלאש אוטומטי, קצב פריימים מינימלי
  • ‫scene_gen2_chart: בדיקות באמצעות תרשים הנייר של Gen2
  • scene_ip: התאמה בין התמונות באפליקציית המצלמה שמוגדרת כברירת מחדל לבין התמונות באפליקציית Jetpack Camera App‏ (JCA)
  • ‫sensor_fusion: היסט התזמון של המצלמה והגירוסקופ

סצנת בדיקה מבוססת-מפזר

  • ‫scene5: הצללת עדשה

סצנת בדיקה מבוססת-טאבלט עם סולם צבעים רחב

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

סצנות בדיקה בטאבלט

scene0

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

test_jitter

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

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

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

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

test_jitter plot

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

test_metadata

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

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

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

test_request_capture_match

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

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

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

test_sensor_events

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

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

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

test_solid_color_test_pattern

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

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

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

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

test_test_pattern

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

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

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

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

דוגמה ל-test_test_patterns

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

test_tonemap_curve

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

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

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

דוגמה ל-test_tonemap_curve raw

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

דוגמה ל-YUV של test_tonemap_curve

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

test_unified_timestamp

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

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

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

test_vibration_restriction

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

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

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

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

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

test_auto_vs_manual

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

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

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

test_auto_vs_manual auto example

איור 6. דוגמה ל-test_auto_vs_manual auto.

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

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

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

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

test_black_white

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

ממשקי ה-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

איור 11. test_black_white, דוגמה לתרשים ממוצעים.

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

בדיקה שאי אפשר לחתוך את הסטרימינג בפורמט RAW.

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

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

test_crop_region_raw comp raw crop example

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

test_crop_region_raw comp raw full example

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

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

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

דוגמה ל-test_crop_region_raw_yuv_full

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

test_crop_regions

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

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

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

test_ev_compensation

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

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

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

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

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

test_ev_compensation_basic

איור 18. test_ev_compensation_basic.

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

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

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

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

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

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

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

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

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

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

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

test_param_color_correction req=0 unity example

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

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

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

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 example

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

test_param_flash_mode_2 example

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

test_param_flash_mode 2 tile example

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

test_param_noise_reduction

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

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

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

test_param_noise_reduction plot SNRs example

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

איור 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, דוגמה למצב 2 לולאה 0.

test_param_tonemap_mode

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

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

כרטיס:

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

test_param_tonemap_mode with 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.

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.

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.

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.

דוגמה ל-test_post_raw_sensitivity_boost YUV s=0896 boost=0400

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

test_post_raw_sensitivity_boost YUV s=1792 boost=0200 example

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

test_post_raw_sensitivity_boost YUV s=3585 boost=0100 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

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

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

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

דוגמה ל-test_raw_exposure ISO=55

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

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

test_raw_exposure ISO=132 example

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

test_raw_exposure ISO=209 example

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

test_raw_exposure ISO=286 example

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

test_raw_exposure ISO=363 example

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

test_raw_exposure_s=440

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

test_reprocess_noise_reduction

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

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

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

תרשים של SNR אופייני לעומת מצב 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

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

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

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

test_yuv_plus_dng

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

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

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

דוגמה ל-test_yuv_plus_dng

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

scene1_3

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

test_capture_result

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

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

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

test_capture_result_plot_lsc_auto_ch0

איור 88. test_capture_result_plot_lsc_auto_ch0.

test_dng_noise_model

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

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

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

test_dng_noise_model_plog

איור 89. test_dng_noise_model_plog.

test_jpeg

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

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

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

test_jpeg_fmt=jpg.jpg

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

test_jpeg=fmt=yuv.jpg

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

test_raw_burst_sensitivity

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

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

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

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

test_raw_burst_sensitivity_variance

איור 92. test_raw_burst_sensitivity_variance.

test_raw_sensitivity

צילום קבוצה של תמונות RAW עם רגישויות הולכות וגדלות ומדידת הרעש (השונות) ב-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 with YUV format

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

test_yuv_plus_raw

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

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

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

test_yuv_plus_raw_shading=1_raw.jpg

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

test_yuv_plus_raw_shading=1_yuv.jpg

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

test_sensitivity_priority

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

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

עובר: ערך ISO גבוה יותר גורם לרמות רעש גבוהות יותר.

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

המערכת מדלגת על הבדיקה test_sensitivity_priority.py אם מתקיים אחד מהתנאים הבאים:

test_exposure_time_priority

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

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

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

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

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

scene2_a

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

דוגמה ל-scene2_a

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

test_autoframing

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

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

עובר: כל שלושת הפנים זוהו.

test_display_p3

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

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

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

test_effects

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

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

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

test_effects_MONO

איור 99. test_effects_MONO.

test_exposure_keys_consistent

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

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

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

test_format_combos

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

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

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

test_num_faces

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

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

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

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

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

test_reprocess_uv_swap

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

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

תקין: מישורי ה-U וה-V לא הוחלפו.

test_reprocess_uv_swap

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

scene2_b

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

test_preview_num_faces

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

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

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

test_num_faces_fd_mode_1

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

test_yuv_jpeg_capture_sameness

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

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

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

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

scene2_c

test_num_faces

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

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

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

test_num_faces_fd_mode_1

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

test_jpeg_capture_perf_class

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

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

test_camera_launch_perf_class

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

עובר: זמן האחזור של הפעלת camera2 (פתיחת המצלמה עד לפריים הראשון של התצוגה המקדימה) חייב להיות פחות מ-600 אלפיות השנייה, כפי שנמדד על ידי 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 שנבדקו:

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

scene2_e

test_continuous_picture

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

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

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

test_num_faces

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

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

הצלחה: המערכת מזהה 3 פנים.

scene2_f

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

דוגמה ל-scene2_f

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

test_preview_num_faces

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

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

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

test_num_faces_fd_mode_1

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

scene2_g

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

scene2_g.png

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

test_preview_num_faces

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

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

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

test_preview_num_faces

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

scene3

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

scene3_aruco_chart

תרשים 108. תרשים scene3.

test_edge_enhancement

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

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

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

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

  • EDGE_MODE

test_edge_enhancement_edge=0

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

test_edge_enhancement edge=1 example

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

test_edge_enhancement edge=2 example

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

test_flip_mirror

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

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

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

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

test_imu_drift

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

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

כרטיס:

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

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

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

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

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

test_landscape_to_portrait

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

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

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

דוגמה ל-test_landscape_to_portrait

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

test_lens_movement_reporting

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

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

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

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

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

מנגנוני כשל:

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

test_reprocess_edge_enhancement

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

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

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

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

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

scene4

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

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

דוגמה לסצנה 4

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

test_30_60fps_preview_fov_match

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

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

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

מנגנוני כשל:

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

test_aspect_ratio_and_crop

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

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

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

מנגנוני כשל:

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

test_multi_camera_alignment

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

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

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

מנגנוני כשל:

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

test_preview_aspect_ratio_and_crop

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

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

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

test_preview_stabilization_fov

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

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

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

test_video_aspect_ratio_and_crop

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

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

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

scene6

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

scene6

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

test_in_sensor_zoom

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

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

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

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

test_zoom

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

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

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

test_zoom to find the contour of the ArUco marker closest to the center

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

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

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

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

test_preview_zoom images showing selected marker closest to the center

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

test_session_characteristics_zoom

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

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

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

scene7

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

scene7

איור 125. סצנה 7.

test_multi_camera_switch

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

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

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

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

scene8

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

דוגמה ל-scene8

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

test_ae_awb_regions

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

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

  • בדיקת חשיפה אוטומטית: מוודאת שלפריים שמודד את האזור עם החשיפה המופחתת יש ערך בהירות גבוה יותר מ-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_extensions

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

scene_hdr

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

scene_hdr

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

test_hdr_extension

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

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

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

scene_low_light

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

דוגמה ל-scene_low_light

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

test_night_extension

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

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

בתרשים הבהירות הבא אפשר לראות איך נראית תוצאת בדיקה תקינה.

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

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

test_low_light_boost_extension

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

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

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

scene6_tele

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

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

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

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

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

remove_front_plate

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

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

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

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

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

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

scene_video

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

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

test_preview_frame_drop

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

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

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

סצנות בדיקה מבוססות על sensor_fusion / מתקן Gen2

feature_combination

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

test_feature_combination

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

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

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

עובר: לכל שילוב של תכונות נתמכות:

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

scene_flash

כדי לבצע את הבדיקות של scene_flash, צריך סצנה חשוכה בתיבת ה-sensor fusion. ב-Android מגרסה 17 ואילך, אפשר לבצע בדיקות scene_flash באמצעות מתקן Gen2.

test_auto_flash

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

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

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

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

test_flash_strength

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

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

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

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

כרטיס:

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

test_led_snapshot

בדיקה שמוודאת שתמונות המצב של ה-LED לא רוויות או צובעות את התמונה.

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

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

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

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

test_night_mode_indicator

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

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

  1. אתחול: הבדיקה מאתחלת ItsSession ומאחזרת את מאפייני המצלמה. הוא גם יוצר חיבור עם בקר התאורה.
  2. תנאים לדילוג: המערכת מדלגת על הבדיקה אם המכשיר לא תומך ברמת ה-API הנדרשת או בתכונה של אינדיקטור מצב לילה.
  3. סשן של Camera2:
    • הבדיקה מתחילה סשן של צילום תצוגה מקדימה באמצעות סשן 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.

scene_gen2_chart

ב-Android מגרסה 17 ואילך, scene_gen2_chart משתמש בתרשים הנייר של Gen2.

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

test_chart_gen2

איור 142. דוגמה לתרשים מדור 2.

test_tonemap_sequence

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

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

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

איור 143. תרשים רצף של מיפוי גוונים לבדיקה.

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

עובר: ההבדל בבהירות בין עקומת ברירת המחדל לעקומה הלינארית הוא יותר מ-15%, וההבדל בין שתי העקומות האקספוננציאליות הוא פחות מ-8%.

test_multi_camera_switch

הבדיקה הזו מאמתת את העקביות של הצבע והחשיפה במהלך מעברים של זום דינמי. הבדיקה מוודאת שמעבר בין העדשות Ultrawide (UW)‎ ו-Wide (W)‎ במהלך הקלטת תצוגה מקדימה שומר על ערכי CIELAB כמעט זהים, ומונע שינויים גלויים בחוויית המשתמש.

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

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

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

עבר: כדי לעבור את הבדיקה, צריך לעבור את הבדיקות הבאות של AE ו-AWB:

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

uw_dynamic_range_patch_cell_8

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

w_dynamic_range_patch_cell_7

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

scene_ip

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

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

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

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

test_chart_gen2

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

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

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

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

test_default_jca_ip

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

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

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

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

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

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

test_jca_jpegr_ip

מוודא שההבדל באיזון הלבן בין תמונת המצב של התצוגה המקדימה של JPEG_R JCA לבין התמונות שצולמו לא עולה על 4.

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

עבר: ההבדל באיזון הלבן בין תמונת המצב של התצוגה המקדימה של JCA לבין תמונת JPEG_R שצולמה הוא בטווח הסף (ברירת המחדל היא 4).

sensor_fusion

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

תרשים של שילוב חיישנים

איור 147. תרשים של שילוב חיישנים.

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

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

test_lens_intrinsic_calibration

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

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

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

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

test_lens_intrinsic_calibration_example.png

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

test_multi_camera_frame_sync

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

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

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

test_preview_distortion

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

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

test_preview_distortion_example.jpg

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

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

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

test_preview_stabilization

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

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

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

הנה סרטונים לדוגמה עם ייצוב ובלי ייצוב:

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

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

test_sensor_fusion

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

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

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

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

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

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

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

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

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

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

מנגנוני כשל:

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

test_video_stabilization

הוצאה משימוש: הבדיקה הזו הוצאה משימוש ב-Android מגרסה 17. ב-Android מגרסה 17 ואילך, הבדיקה הזו מוחלפת ב-test_video_stabilization_jca.

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

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

עובר: זווית הסיבוב המקסימלית בפריימים קטנה מ-60% מסיבוב הג'ירוסקופ.

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

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

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

test_video_stabilization_jca

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

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

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

סצנת בדיקה מבוססת-מפזר

scene5

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

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

דוגמה לסצנה 5

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

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

test_lens_shading_and_color_uniformity

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

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

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

מנגנוני כשל:

  • התמונות כהות מדי בקצוות (vignetting)
  • גבולות שחורים בתמונות

test_lens_shading_and_color_uniformity_y_plane

איור 158. test_lens_shading_and_color_uniformity_y_plane.

test_lens_shading_and_color_uniformity_color_uniformity_result

איור 159. test_lens_shading_and_color_uniformity_color_uniformity.

test_lens_shading_and_color_uniformity_lens_shading_result

איור 160. test_lens_shading_and_color_uniformity_lens_shading_result.

סצנת בדיקה מבוססת-טאבלט עם סולם צבעים רחב

scene_wide_gamut

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

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

test_display_p3

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

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

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

test_display_p3 example

איור 161. דוגמה ל-test_display_p3.