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

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

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

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

scene0

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

רעידות בדיקה

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

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

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

אירועי_בדיקה_חיישן

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

ממשקי ה-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. לתיאור מפורט יותר של מתקני הבדיקה של המצלמות, ראו מארז ITS של המצלמה.

סצנה1

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

בדיקה_שחור_לבן

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

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

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

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

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

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

test_ev_compensation_basic

בדיקה_ev_compenation_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

בדיקה_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

בדיקה_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_latches_i=02.jpg
test_latches_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_latches_i=03.jpg test_latching_i=04.jpg test_latching_i=05.jpg
test_latching_i=06.jpg test_latches_i=07.jpg test_latching_i=08.jpg
test_latching_i=06.jpg test_latches_i=07.jpg test_latching_i=08.jpg
test_latching_i=09.jpg test_latating_i=10.jpg test_latching_i=11.jpg
test_latching_i=09.jpg test_latating_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_pairion_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_redocion_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.png

test_raw_exposure

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

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

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

test_raw_exposure_s=55

test_raw_exposure_s=55.png

(100 הוא 1 אלפיות שנייה, 101 הוא 10 אלפיות שנייה, 10–1 הוא 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 מוחלה על בקשות לעיבוד חוזר. צילום תמונות שעברו עיבוד חוזר כשהתאורה במצלמה עמומה. שימוש בשיפור אנלוגי גבוה כדי להבטיח שהתמונה שצולמה תהיה עם רעש. צילום שלוש תמונות שעברו עיבוד מחדש: במצב NR, במצב 'מהיר' וב'איכות גבוהה'. צילום תמונה שעברה עיבוד מחדש עם עוצמה נמוכה ו-NR מושבתת, ושימוש בשונות הזו כבסיס.

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

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

תרשים SNR אופייני לעומת NR_מצב

תרשים טיפוסי של 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

בדיקה_yuv_plus_dng

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

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

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

בדיקה_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 ו-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

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

אפקטים_בדיקה

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

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

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

בדיקה_אפקטים_MONO

test_effects_MONO.jpg

test_format_combos

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

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

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

מספר_פנים לבדיקה

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

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

בדיקה_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.

סצנה2_d

test_num_faces

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

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

אישור: Find 3 פרצופים.

scene2_e

test_continuous_picture

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

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

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

test_num_faces

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

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

אישור: Find 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_dge_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 של המצלמה הקדמית [C-1-5].

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

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

test_flip_mirror_scene_patch

test_flip_mirror_scene_patch.jpg

בדיקה

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

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

הצלחה:

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

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

בדיקה_aspect_ratio_and_crop

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

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

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

מנגנוני כשל:

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

test_multi_camera_alignment

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

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

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

מנגנוני כשל:

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

test_preview_aspect_ratio_and_crop

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

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

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

בדיקה_preview_stabilization_fov

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

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

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

test_video_aspect_ratio_and_crop

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

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

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

scene5

ב-scene5 נדרשת סצנה אפורה מוארת באופן אחיד. ניתן להשיג זאת על ידי מפזר מוצב מעל עדשת המצלמה. אנחנו ממליצים על המפיץ הבא: 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, הבדיקה תצלם שתי צילומים בטווח של הזום, שדה ראייה מלא (FoV) תמונה גולמית ותמונת RAW חתוכה. הבדיקה ממירה את התמונות למערכים של RGB, מקטינה את התמונה השלמה של קובץ ה-RAW שנחתכה לגודל שצוין ב-SCALER_RAW_CROP_REGION ומחשבת את ההפרש הממוצע המרובע (RMS) התלת-ממדי בין שתי התמונות.

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

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

test_zoom

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

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

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

בדיקה_זום

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.

סצנה7

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.

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

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

  • בדיקת AE: שינוי הלומה (luma) בין תמונות עדשת UW ו-W חייב להיות קטן מ-0.5%.
  • בדיקת AWB: ההפרש בין ערכי R/G ו-B/G בתמונות UW ו-W Lens חייב להיות קטן מ-0.5%.
  • בדיקת AF: השינוי של חדות התמונה בין התמונות עם עדשת UW ו-W חייב להיות פחות מ-2%.

סצנה8

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

סצנה9

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

scene9

scene9

test_jpeg_high_entropy

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

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

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

בדיקה_jpeg_quality

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

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

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

test_jpeg_quality

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

בדיקת_jpeg_quality נכשלה

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

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

scene_video

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

scene_video

test_preview_frame_drop

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

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

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

scene_extensions

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

scene_hdr

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

segment_hdr

segment_hdr

test_hdr_extension

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

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

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

scene_low_light

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

segment_low_light

scene_low_light

test_night_extension

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

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

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

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

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

scene_low_light_night_pass

test_low_light_boost_extension

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

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

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

Pass: ערך הלומה הממוצע של 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

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

כיול_בדיקה_lens_intrinsic

בדיקה של השינויים הפנימיים במרכז האופטי של העדשה כשהעדשה זזה עקב ייצוב תמונה אופטי (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_distructtion_example.jpg

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

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

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

test_preview_stabilization

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

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

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

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

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

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

חיישן_בדיקה

בדיקה של ההבדל בין חותמת הזמן של המצלמה לבין חותמת הזמן של הגירוסקופ באפליקציות 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% מהסיבוב של הג'ירוסקופ.

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

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

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

feature_combination

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

שילוב_תכונות_בדיקה

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

ב-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 יש מפת רווח תקינה.