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

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

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

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

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

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

scene0

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

test_jitter

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

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

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

test_jitter_plot.png

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

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

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

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

test_test_pattern

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

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

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

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

test_test_patterns_2

test_test_patterns_2.jpg

test_tonemap_curve

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

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

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

test_tonemap_curve_raw_2

test_tonemap_curve_raw_2.jpg

test_tonemap_curve_yuv_2.jpg

test_tonemap_curve_yuv_2.jpg

test_unified_timestamp

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

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

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

test_vibration_restriction

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

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

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

scene1_1

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

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

scene1

scene1: תרשים בגודל מלא (שמאל). תרשים בגודל ⅔ (ימין).

test_ae_precapture_trigger

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

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

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

test_auto_vs_manual

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

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

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

test_auto_vs_manual_auto

test_auto_vs_manual_auto.jpg

test_auto_vs_manual_wb

test_auto_vs_manual_wb.jpg

test_auto_vs_manual_manual_wb_tm

test_auto_vs_manual_manual_wb_tm.jpg

test_black_white

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

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

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

test_black_white_black test_black_white_black
test_black_white_black.jpg test_black_white_white.jpg

test_black_white_plot_means

test_black_white_plot_means.png

test_burst_capture

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

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

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

test_burst_sameness_manual

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

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

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

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

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

test_burst_sameness_manual_mean

test_burst_sameness_manual_mean.jpg

test_burst_sameness_manual_plot_means

test_burst_sameness_manual_plot_means.png

test_crop_region_raw

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

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

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

test_crop_region_raw_comp_raw_crop

test_crop_region_raw_comp_raw_crop.jpg

test_crop_region_raw_comp_raw_full

test_crop_region_raw_comp_raw_full.jpg

test_crop_region_raw_comp_yuv_crop

test_crop_region_raw_comp_yuv_crop.jpg

test_crop_region_raw_yuv_full

test_crop_region_raw_yuv_full.jpg

test_crop_regions

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

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

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

test_ev_compensation

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

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

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

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

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

test_ev_compensation_basic

test_ev_compensation_basic.png

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

test_ev_compensation_advanced_plot_means

test_ev_compensation_advanced_plot_means.png

test_exposure_x_iso

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

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

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

מנגנון כשל:

  • בתרשים test_exposure_plot_means.png, ככל שערכי מכפיל הרווח (ציר ה-x) עולים, הערכים הממוצעים של מישור ה-RGB המנורמלי (ציר ה-y) מתחילים לסטות מערכי מכפיל הרווח הנמוכים.

test_exposure_plot_means

test_exposure_plot_means.png

test_exposure_mult=1.00 test_exposure_mult=64.00
test_exposure_mult=1.00.jpg test_exposure_mult=64.00.jpg

test_latching

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

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

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

test_latching_i=00.jpg test_latching_i=01.jpg test_latching_i=02.jpg
test_latching_i=00.jpg test_latching_i=01.jpg test_latching_i=02.jpg
test_latching_i=03.jpg test_latching_i=04.jpg test_latching_i=05.jpg
test_latching_i=03.jpg test_latching_i=04.jpg test_latching_i=05.jpg
test_latching_i=06.jpg test_latching_i=07.jpg test_latching_i=08.jpg
test_latching_i=06.jpg test_latching_i=07.jpg test_latching_i=08.jpg
test_latching_i=09.jpg test_latching_i=10.jpg test_latching_i=11.jpg
test_latching_i=09.jpg test_latching_i=10.jpg test_latching_i=11.jpg
test_latching_i=12.jpg
test_latching_i=12.jpg

test_latching_plot_means

test_latching_plot_means.png

test_linearity

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

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

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

test_linearity_plot_means

test_linearity_plot_means.png

test_locked_burst

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

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

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

test_locked_burst_frame0

test_locked_burst_frame0.jpg

test_locked_burst_frame1

test_locked_burst_frame1.jpg

test_locked_burst_frame2

test_locked_burst_frame2.jpg

scene1_2

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

test_param_color_correction

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

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

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

test_param_color_correction_plot_means

test_param_color_correction_plot_means.png

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

test_param_color_correction_req=0

test_param_color_correction_req=0.jpg

test_param_color_correctness_req=1

test_param_color_correctness_req=1.jpg (R boost)

test_param_color_correction_req=2

test_param_color_correction_req=2.jpg (B boost)

test_param_flash_mode

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

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

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

test_param_flash_mode_1

test_param_flash_mode_1.jpg

test_param_flash_mode_1_tile

test_param_flash_mode_1_tile.jpg

test_param_flash_mode_2

test_param_flash_mode_2.jpg

test_param_flash_mode_2_tile

test_param_flash_mode_2_tile.jpg

test_param_noise_reduction

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

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

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

test_param_noise_reduction_plot_SNRs

test_param_noise_reduction_plot_SNRs.png

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

test_param_noise_reduction_high_gain_nr=0

test_param_noise_reduction_high_gain_nr=0.jpg

test_param_noise_reduction_high_gain_nr=1

test_param_noise_reduction_high_gain_nr=1.jpg

test_param_noise_reduction_high_gain_nr=2

test_param_noise_reduction_high_gain_nr=2.jpg

test_param_noise_reduction_high_gain_nr=3

test_param_noise_reduction_high_gain_nr=3.jpg

test_param_noise_reduction_low_gain

test_param_noise_reduction_low_gain.jpg

test_param_shading_mode

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

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

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

test_param_shading_mode_ls_maps_mode_0_loop_0

test_param_shading_mode_ls_maps_mode_0_loop_0.png

test_param_shading_mode_ls_maps_mode_1_loop_0

test_param_shading_mode_ls_maps_mode_1_loop_0.png

test_param_shading_mode_ls_maps_mode_2_loop_0

test_param_shading_mode_ls_maps_mode_2_loop_0.png

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.jpg test_param_tonemap_mode_n=1.jpg
test_param_tonemap_mode_n=0.jpg test_param_tonemap_mode_n=1.jpg

test_post_raw_sensitivity_boost

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

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

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

test_post_raw_sensitivity_boost_raw_s=3583_boost=0100

test_post_raw_sensitivity_boost_raw_s=3583_boost=0100.jpg

test_post_raw_sensitivity_boost_raw_s=1792_boost=0200

test_post_raw_sensitivity_boost_raw_s=1792_boost=0200.jpg

test_post_raw_sensitivity_boost_raw_s=0896_boost=0400

test_post_raw_sensitivity_boost_raw_s=0896_boost=0400.jpg

test_post_raw_sensitivity_boost_raw_s=0448_boost=0800

test_post_raw_sensitivity_boost_raw_s=0448_boost=0800.jpg

test_post_raw_sensitivity_boost_raw_s=0224_boost=1600

test_post_raw_sensitivity_boost_raw_s=0224_boost=1600.jpg

test_post_raw_sensitivity_boost_raw_s=0112_boost=3199

test_post_raw_sensitivity_boost_raw_s=0112_boost=3199.jpg

test_post_raw_sensitivity_boost_raw_plot_means

test_post_raw_sensitivity_boost_raw_plot_means.png

test_post_raw_sensitivity_boost_yuv_s=0112_boost=3199

test_post_raw_sensitivity_boost_yuv_s=0112_boost=3199.jpg

test_post_raw_sensitivity_boost_yuv_s=0448_boost=0800

test_post_raw_sensitivity_boost_yuv_s=0448_boost=0800.jpg

test_post_raw_sensitivity_boost_yuv_s=0896_boost=0400

test_post_raw_sensitivity_boost_yuv_s=0896_boost=0400.jpg

test_post_raw_sensitivity_boost_yuv_s=1792_boost=0200

test_post_raw_sensitivity_boost_yuv_s=1792_boost=0200.jpg

test_post_raw_sensitivity_boost_yuv_s=3585_boost=0100

test_post_raw_sensitivity_boost_yuv_s=3585_boost=0100.jpg

test_post_raw_sensitivity_boost_yuv_plot_means

test_post_raw_sensitivity_boost_yuv_plot_means.png

test_raw_exposure

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

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

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

test_raw_exposure_s=55

test_raw_exposure_s=55.png

(10⁰ הוא 1 אלפית שנייה, 10¹ הוא 10 אלפיות שנייה, 10⁻¹ הוא 0.1 אלפית שנייה)

test_raw_exposure_s=132

test_raw_exposure_s=132.png

test_raw_exposure_s=209

test_raw_exposure_s=209.png

test_raw_exposure_s=286

test_raw_exposure_s=286.png

test_raw_exposure_s=363

test_raw_exposure_s=363.png

test_raw_exposure_s=440

test_raw_exposure_s=440.png

test_reprocess_noise_reduction

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

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

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

תרשים טיפוסי של SNR לעומת NR_MODE

תרשים טיפוסי של SNR לעומת NR_MODE

test_tonemap_sequence

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

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

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

test_tonemap_sequence_i=0

test_tonemap_sequence_i=0.jpg

test_tonemap_sequence_i=1

test_tonemap_sequence_i=1.jpg

test_tonemap_sequence_i=2

test_tonemap_sequence_i=2.jpg

test_tonemap_sequence_i=3

test_tonemap_sequence_i=3.jpg

test_tonemap_sequence_i=4

test_tonemap_sequence_i=4.jpg

test_tonemap_sequence_i=5

test_tonemap_sequence_i=5.jpg

test_yuv_jpeg_all

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

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

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

test_yuv_jpeg_all

test_yuv_jpeg_all.png

test_yuv_plus_dng

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

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

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

test_yuv_plus_dng

test_yuv_plus_dng.jpg

scene1_3

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

test_capture_result

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

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

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

test_capture_result_plot_lsc_auto_ch0

test_capture_result_plot_lsc_auto_ch0.png

test_dng_noise_model

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

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

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

test_dng_noise_model_plog

test_dng_noise_model_plog.png

test_jpeg

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

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

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

test_jpeg_fmt=jpg.jpg test_jpeg=fmt=yuv.jpg
test_jpeg_fmt=jpg.jpg test_jpeg=fmt=yuv.jpg

test_raw_burst_sensitivity

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

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

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

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

test_raw_burst_sensitivity_variance

test_raw_burst_sensitivity_variance.png

test_raw_sensitivity

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

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

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

test_raw_sensitivity_variance

test_raw_sensitivity_variance.png

test_yuv_plus_jpeg

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

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

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

test_yuv_plus_jpg_jpg.jpg test_yuv_plus_jpeg_yuv.jpg
test_yuv_plus_jpg_jpg.jpg test_yuv_plus_jpeg_yuv.jpg

test_yuv_plus_raw

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

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

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

test_yuv_plus_raw_shading=1_raw.jpg test_yuv_plus_raw_shading=1_yuv.jpg
test_yuv_plus_raw_shading=1_raw.jpg 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

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

test_effects_MONO.jpg

test_exposure_keys_consistent

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

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

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

test_format_combos

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

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

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

test_num_faces

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

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

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_reprocess_uv_swap

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

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

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

test_reprocess_uv_swap

test_reprocess_uv_swap.png

scene2_b

test_preview_num_faces

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

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

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

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 (Root-Mean-Square value of a signal). בתמונות YUV בכל תרחישי השימוש הנתמכים יש הבדל של פחות מ-10% RMS ביחס לתמונות YUV בתרחיש השימוש STILL_CAPTURE.

scene2_c

test_num_faces

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

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

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_jpeg_capture_perf_class

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

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

test_camera_launch_perf_class

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

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

test_default_camera_hdr

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

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

scene2_d

test_preview_num_faces

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

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

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

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

scene2_f

test_preview_num_faces

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

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

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

scene2_g

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

scene2_g.png

scene2_g

test_preview_num_faces

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

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

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

test_preview_num_faces

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

test_edge_enhancement_edge=0.jpg

test_edge_enhancement_edge=1

test_edge_enhancement_edge=1.jpg (מצב מהיר)

test_edge_enhancement_edge=2

test_edge_enhancement_edge=2.jpg (מצב איכות גבוהה)

test_flip_mirror

הבדיקה בודקת אם התמונה בכיוון הנכון בהתאם לקטע 7.5.2 ב-CDD בנושא מצלמה קדמית [C-1-5].

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

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

test_flip_mirror_scene_patch

test_flip_mirror_scene_patch.jpg

test_imu_drift

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

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

אישור:

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

test_imu_drift_gyro_drift.png

test_imu_drift_gyro_drift.png

test_imu_drift_rotation_vector_drift.png

test_imu_drift_rotation_vector_drift.png

test_landscape_to_portrait

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

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

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

test_landscape_to_portrait

test_landscape_to_portrait.png

test_lens_movement_reporting

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

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

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

מנגנוני כשל:

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

test_reprocess_edge_enhancement

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

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

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

test_reprocess_edge_enhancement_plot

test_reprocess_edge_enhancement_plot.png

scene4

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

scene4

scene4

test_30_60fps_preview_fov_match

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

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

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

מנגנוני כשל:

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

test_aspect_ratio_and_crop

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

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

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

מנגנוני כשל:

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

test_multi_camera_alignment

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

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

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

מנגנוני כשל:

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

test_preview_aspect_ratio_and_crop

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

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

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

test_preview_stabilization_fov

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

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

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

test_video_aspect_ratio_and_crop

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

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

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

scene5

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

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

scene5

scene5 capture

test_lens_shading_and_color_uniformity

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

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

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

scene6

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

scene6

scene6

test_in_sensor_zoom

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

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

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

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

test_zoom

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

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

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

test_zoom

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

HD_1280x720_key_frame.png (לפני הגדלה)

preview_1280x720_key_frame.png

preview_1280x720_key_frame.png (לפני הזום)

HD_1280x720_key_frame_zoomed.png

HD_1280x720_key_frame.png (אחרי שינוי מרחק התצוגה)

preview_1280x720_key_frame_zoomed.png

preview_1280x720_key_frame.png (אחרי הזום)

test_preview_zoom

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

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

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

test_zoom

תמונות של 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

scene7

test_multi_camera_switch

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

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

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

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

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

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

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

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

test_multi_camera_switch_gray_uw_y

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

test_multi_camera_switch_gray_w_y

כתם אפור שצולם עם עדשת W

scene8

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

scene8

scene8

test_ae_awb_regions

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

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

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

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

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

test_ae_awb_regions_dark_region

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

test_ae_awb_regions_light_region

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

מנגנוני כשל:

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

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

test_color_correction_mode_cct

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

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

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

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

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

scene9

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

scene9

scene9

test_jpeg_high_entropy

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

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

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

test_jpeg_quality

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

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

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

test_jpeg_quality

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

test_jpeg_quality נכשל

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

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

scene_video

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

scene_video

test_preview_frame_drop

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

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

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

scene_extensions

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

scene_hdr

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

scene_hdr

scene_hdr

test_hdr_extension

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

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

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

scene_low_light

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

scene_low_light

scene_low_light

test_night_extension

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

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

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

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

אישור:

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

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

scene_low_light_night_pass

test_low_light_boost_extension

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

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

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

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

אישור:

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

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

scene_tele

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

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

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

scene6_tele

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

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

remove_phone_mount

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

remove_front_plate

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

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

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

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

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

scene_flash

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

test_auto_flash

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

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

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

test_flash_strength

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

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

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

אישור:

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

test_led_snapshot

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

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

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

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

הצלחה: היחסים R/G ו-B/G נמצאים בטווח שבין 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. כדי לקבל תוצאות אופטימליות, חשוב לוודא שתרשים הבדיקה מותקן בצורה ישרה. תרשימים שאינם שטוחים משפיעים על חישובי הסיבוב של רבים מהבדיקות. התרשים צריך למלא את החלק האחורי של תיבת מיזוג החיישנים. לשם כך, צריך להדפיס אותו בגודל 17"x17" (43x43 ס"מ). אפשר להפוך את הבדיקות של sensor_fusion לאוטומטיות באמצעות Sensor Fusion Box.

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

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

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

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

test_lens_intrinsic_calibration

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

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

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

test_lens_intrinsic_calibration_example.png

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

test_multi_camera_frame_sync

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

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

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

test_preview_distortion

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

test_preview_distortion_example.jpg

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

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

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

test_preview_stabilization

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

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

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

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

  • סרטון לדוגמה עם ייצוב

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

test_sensor_fusion

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

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

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

    test_sensor_fusion_gyro_events.png

    test_sensor_fusion_gyro_events

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

    test_sensor_fusion_plot_rotations.png

    test_sensor_fusion_plot_rotations

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

הצלחה: הפרש הזמן בין חותמות הזמן של המצלמה והג'ירוסקופ קטן מ-1ms, בהתאם לקטע 7.3.9 ב-CDD בנושא חיישנים ברזולוציה גבוהה [C-2-14].

מנגנוני כשל:

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

test_video_stabilization

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

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

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

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

  • סרטון לדוגמה עם ייצוב

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

test_video_stabilization_jca

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

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

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

feature_combination

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

test_feature_combination

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

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

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

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

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

scene_ip

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

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

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

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

test_chart_gen2

Gen2chart_sample.png

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

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

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

test_default_jca_ip

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

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

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

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

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