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

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

סצנה0

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

test_burst_capture

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

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

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

test_capture_result_dump

בדיקה אם תוצאת צילום מוחזרת מצילום ידני, ואז היא תוחלף.

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

עובר: השלמת הצילום והעלאה של תוצאות הצילום.

בדיקה_גירו_הטיה

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

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

עובר: הדלתא של קריאת הג'יירו קטנה מ-0.01 לאורך זמן.

test_gyro_bias_plot.png

test_gyro_bias_plot.png

רעידות בדיקה

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

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

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

test_jitter_plot.png

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

מטא-נתונים לבדיקה

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

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

עובר: רמת החומרה, rollingShutterSkew, תגים frameDuration, timestampSource, croppingType, blackLevelPattern, pixel_pitch, FoV ומרחק היפר-פוקוס קיימים וערכים תקינים.

test_param_sensitivity_burst

בדיקות שהפרמטר android.sensor.sensitivity מיושם בצורה תקינה ברצף. הפונקציה בודקת רק את המטא-נתונים של הפלט.

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

עובר: לנתוני הפלט יש סבילות לשגיאות של פחות מ-0.2%.

בדיקה_קריאה_כתיבה

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

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

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

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

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

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

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

test_solid_color_test_pattern

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

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

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

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

דפוס_בדיקה

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

סצנה1

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

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

סצנה1

segment1: תרשים בגודל מלא (משמאל). תרשים 2⁄3 מדורג (ימין).

בדיקה_3a

בודק את ההתכנסות של 3A עם יעד מאתגר למדי.

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

עובר: 3A מתכנס והערכים 3A שהוחזרו תקפים.

בדיקה_ae_af

בדיקה בנפרד של האלגוריתמים של החשיפה האוטומטית 3A (AE) והמיקוד האוטומטי (AF).

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

עובר: 3A מתכנס והערכים 3A שהוחזרו הם חוקיים.

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

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

בדיקה_שחור_לבן_שחור בדיקה_שחור_לבן_שחור
test_black_white_black.jpg test_black_white_white.jpg

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

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

test_burst_sameness_manual

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

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

תוצאת_בדיקה

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

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

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

test_capture_result_plot_lsc_auto_ch0

test_capture_result_plot_lsc_auto_ch0.png

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

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

בדיקה_dng_noise_model

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

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

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

test_dng_noise_model_plog

בדיקה_dng_noise_model_plog.png

test_ev_compensation_advanced

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

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

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

test_ev_compenation_Advanced_plot_means

test_ev_compenation_advanced_plot_means.png

בדיקה_ev_compenation_basic

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

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

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

בדיקה_ev_compenation_basic

בדיקה_ev_compenation_basic.png

חשיפת_בדיקה

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

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

עובר: הבהירות של התמונות זהה, אבל רמת הבהירות של ה-ISO גבוהה יותר. מישורי RGB שטוחים כשהערך של ISO*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

בדיקה_ברגים

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

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

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

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

test_latating_plot_means

בדיקה_latches_plot_means.png

ליניאריות_בדיקה

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

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

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

בדיקה_ליניאריות_plot_means

בדיקה_לינארית_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

בדיקה_פרמטר_צבע_תיקון

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

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

test_param_color_Correction_req=2

test_param_color_fixion_req=2.jpg (הגדלה B)

test_param_exposure_time

בדיקה שהפרמטר android.sensor.exposureTime הוחל.

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

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

test_param_exposure_time_frame0

test_param_exposure_time_frame0.jpg

test_param_exposure_time_plot

test_param_exposure_time_plot.png

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_retraction

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

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

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

test_param_noise_reduction_plot_SNRs

test_param_noise_reduction_plot_SNRs.png

0: כבוי, 1: מהיר, 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_redocion_low_gain.jpg

test_param_sensitivity

בדיקה שהפרמטר android.sensor.sensitivity הוחל. הבדיקה מגבירה את הרגישות ב-5 שלבים עם חשיפה קבועה לכל צילום.

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

עבר: המשמעות של RGB היא 'מרכז 10%' עם רגישות גבוהה יותר.

test_param_sensitivity_iso=0055

test_param_sensitivity_iso=0055.jpg

test_param_sensitivity_iso=1819

test_param_sensitivity_iso=1819.jpg

test_param_sensitivity_iso=3583

test_param_sensitivity_iso=3583.jpg

test_param_sensitivity_iso=5347

test_param_sensitivity_iso=5347.jpg

test_param_sensitivity_iso=7111

test_param_sensitivity_iso=7111.jpg

test_param_sensitivity_plot

test_param_sensitivity_plot.png

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 הוחל. התכונה הזו מחילה עקומות שונות ב-tonemap בכל ערוץ 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

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

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

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

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

בדיקת_המהירות_והרגישה_של_המהירות

test_raw_burst_sensitivity_variance.png

בדיקה_גולמית_חשיפה

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

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

test_reprocess_noise_reduction

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

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

עובר: FAST >= כבוי, HQ >= FAST, HQ >> מושבת

תרשים 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

בדיקה_yuv_jpeg_all

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

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

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

בדיקה_yuv_jpeg_all

test_yuv_jpeg_all.png

בדיקה_yuv_plus_dng

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

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

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

בדיקה_yuv_plus_dng

test_yuv_plus_dng.jpg

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

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

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

segment2_a

segment2_a

test_auto_Flash

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

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

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

בדיקה_אוטומטי-פריים

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

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

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

test_אפקטים_MONO.jpg

test_format_combos

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

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

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

בדיקה_jpeg_quality

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

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

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

בדיקה_jpeg_quality

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

בדיקת_jpeg_quality נכשלה

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

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

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

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

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

אישור: חיפוש שלוש פנים.

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_preview_min_frame_rate

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

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

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

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

סצנה2_b

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

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

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

אישור: Find 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).

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

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

segment2_c

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

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

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

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

בדיקה_jpeg_capture_perf_class

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

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

test_camera_launch_perf_class

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

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

סצנה2_d

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

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

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

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

segment2_e

בדיקה_רציף_תמונה

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

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

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

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

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

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

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

segment2_f

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

סצנה2_f.png

segment2_f

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

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

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

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

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

סצנה3

Scene3 משתמש בתרשים ISO12233, ורוב הבדיקות משתמשות בשיטה של חילוץ תרשימים כדי למצוא את התרשים בסצנה. לכן לרוב התמונות השמורות אין גבולות כמו בתמונות בסצנות 1, 2 או 4, אלא רק בתרשים. התרשים חייב להיות בכיוון הנכון כדי שמוצא התרשימים יפעל בצורה אופטימלית.

בדיקה_3a_consistency

בדיקות לעקביות 3A.

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

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

בדיקת_קצה_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_dge_enhancement_edge=2

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

שיקוף_היפוך

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

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

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

בדיקה_flip_mirror_scene_patch

test_flip_mirror_scene_patch.jpg

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

סצנה4

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

סצנה4

סצנה4

בדיקה_aspect_ratio_and_crop

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

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

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

מנגנוני כשל:

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

בדיקה_ריבוי_מצלמות

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

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

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

מנגנוני כשל:

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

test_preview_aspect_ratio_and_crop

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

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

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

בדיקה_preview_stabilization_fov

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

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

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

test_video_aspect_ratio_and_crop

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

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

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

סצנה5

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

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

סצנה5

צילום סצינה5

test_lens_shading_and_color_uniformity

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

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

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

סצנה6

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

סצנה6

סצנה6

בדיקה_בחיישן_הזום

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

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

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

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

בדיקה_זום

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

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

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

בדיקה_זום

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

בדיקה_נמוך_זמן_זמן_זום

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

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

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

בדיקה_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 (לאחר שינוי מרחק התצוגה)

segment_extensions

הבדיקות של scene_extensions מיועדות לתוספי מצלמה, וחייבת להשתמש במצלמות ITS-in-Box כי הן דורשות שליטה מדויקת בסביבת הבדיקה.

segment_hdr

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

segment_hdr

segment_hdr

בדיקה_hdr_extension

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

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

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

סצנה_לילה

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

סצנה_לילה

סצנה_לילה

test_night_extension

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

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

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

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

חיישן_היתוך

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

לוח דמקה

תמונה של לוח דמקה

בדיקה_multi_camera_frame_sync

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

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

    test_sensor_fusion_plot_rotations.png

    sensor_fusion_plot_rotations

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

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

מנגנוני כשל:

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

בדיקה_וידאו_stabilization

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

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

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

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

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

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

בדיקה_לידי_snapshot

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

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

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

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

עובר: היחסים R/G ו-B/G הם בטווח של 0.95 ו-1.05. הממוצע של תמונת ה-Flash נמצא בטווח של (68, 102).