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

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

שער ITS של מצלמה מבצע בדיקות לפי מאפייני המצלמה הנדרשים, רמת ה-API ורמת הביצועים של המדיה (MPC). ברמת ה-API, ‏ITS משתמש ב-ro.product.first_api_level כדי לפקח על בדיקות שנוספו ברמת API ספציפית, ובודקות חוויית משתמש שלילית של פונקציונליות ברמות API נמוכות יותר. ro.vendor.api_level משמש את ITS כדי לפקח על בדיקות של תכונות שנוספו ברמת 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_flash: פלאש אוטומטי, קצב פריימים מינימלי
  • scene_video: טיפות מסגרות
  • sensor_fusion: הפרש תזמון של מצלמה/ג'ירוסקופ
  • feature_combination: שילובי תכונות

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

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

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

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

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

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

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

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

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

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

test_capture_result_plot_lsc_auto_ch0

test_capture_result_plot_lsc_auto_ch0.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_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_ev_compensation_advanced

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

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

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

test_ev_compensation_advanced_plot_means

test_ev_compensation_advanced_plot_means.png

test_ev_compensation_basic

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

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

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

test_ev_compensation_basic

test_ev_compensation_basic.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_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_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

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_burst_sensitivity

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

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

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

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

test_raw_burst_sensitivity_variance

test_raw_burst_sensitivity_variance.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_raw_sensitivity

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

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

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

test_raw_sensitivity_variance

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

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

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_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_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 (ערך שורר-ממוצע-ריבוע של אות). בתמונות 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_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_num_faces

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

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

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

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

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

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

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

test_zoom

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

test_low_latency_zoom

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

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

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

test_preview_video_zoom_match

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

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

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

VGA_640x480_key_frame.png

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

preview_640x480_key_frame.png

preview_640x480_key_frame.png (לפני זום)

VGA_640x480_key_frame_zoomed.png

VGA_640x480_key_frame.png (אחרי זום)

preview_640x480_key_frame_zoomed.png

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

test_preview_zoom

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

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

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

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 בין התמונות של העדשה הרחבה לבין התמונות של העדשה הרגילה צריך להיות קטן מ-4% בכל כתמי הצבע, אם המכשיר תומך גם ב-ae_regions וגם ב-awb_regions. אם יש תמיכה רק ב-ae_regions, רק ערכי התיקון של הצבע האפור חייבים לעמוד בקריטריונים.
  • בדיקת AWB: ההפרש בין הערכים R/G ו-B/G בתמונות של העדשה הרחבה והעדשה הרגילה צריך להיות קטן מ-3% בכתמים בצבע אפור, וקטן מ-10% בכתמים בצבע אחר, אם המכשיר תומך גם ב-ae_regions וגם ב-awb_regions.
  • בדיקת AF: חדות התמונה בצילום עם עדשת W חייבת להיות גבוהה יותר מהחדות בצילום עם עדשת UW.

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 עוברות.

מנגנוני כשל:

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

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

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), ומוצאת את הממוצע של חמשת ההפרשים המחושבים.

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

עומד בדרישות: ערך הלומה הממוצע של 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), ומוצאת את הממוצע של חמשת ההפרשים המחושבים.

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

עומד בדרישות: ערך הלומה הממוצע של 6 הריבועים הראשונים חייב להיות לפחות 70, וההפרש הממוצע בערך הלומה של ריבועים רצופים עד הריבועים 5 ו-6 חייב להיות לפחות 17.

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

הצלחה: הפרש הזמן בין חותמות הזמן של המצלמה והג'ירוסקופ קטן מ-1 אלפית שנייה, בהתאם לקטע 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% מזווית הסיבוב של הגירוסקופ.

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

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

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

feature_combination

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

test_feature_combination

בדיקה של כל השילובים של שידורים שונים, ייצוב של תצוגה מקדימה, טווח יעד של קצב פריימים לשנייה, וידאו HDR באיכות 10 ביט ו-Ultra HDR שנתמכים במכשיר המצלמה. הבדיקה הזו צורכת הרבה זיכרון, לכן מומלץ להשתמש במארח עם זיכרון RAM בנפח של 128GB לפחות.

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

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

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

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