การทดสอบ ITS ของกล้อง

หน้านี้แสดงรายการการทดสอบที่ครอบคลุมภายใต้ชุดทดสอบภาพจากกล้อง (ITS) ซึ่งเป็นส่วนหนึ่งของโปรแกรมตรวจสอบชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) การทดสอบ ITS เป็นการทดสอบฟังก์ชันการทำงาน ซึ่งหมายความว่าไม่ได้วัดคุณภาพของรูปภาพ แต่ตรวจสอบว่าฟังก์ชันกล้องที่โฆษณาทั้งหมดทำงานได้ตามที่คาดไว้ เอกสารนี้ช่วยให้นักพัฒนาแอปและผู้ทดสอบเข้าใจว่าแต่ละการทดสอบทําอะไรและวิธีแก้ไขข้อบกพร่องของการทดสอบที่ไม่สําเร็จ

ITS ของกล้องจะจำกัดการทดสอบตามพร็อพเพอร์ตี้กล้อง ระดับ API และระดับคลาสประสิทธิภาพสื่อ (MPC) ที่จำเป็น สำหรับระดับ API ITS จะใช้ ro.product.first_api_level เพื่อควบคุมการทดสอบที่เพิ่มในระดับ API ที่เจาะจง ซึ่งจะทดสอบประสบการณ์การใช้งานที่ไม่พึงประสงค์ของฟังก์ชันการทำงานในระดับ API ที่ต่ำกว่า ITS ใช้ ro.vendor.api_level เพื่อควบคุมการทดสอบฟีเจอร์ที่เพิ่มในระดับ API ที่เจาะจงซึ่งต้องใช้ความสามารถของฮาร์ดแวร์ใหม่ หากมีการกําหนด ro.odm.build.media_performance_class สําหรับอุปกรณ์ ITS จะต้องมีการทดสอบที่เฉพาะเจาะจงโดยขึ้นอยู่กับระดับ MPC

การทดสอบจะจัดกลุ่มตามฉาก ดังนี้

  • scene0: บันทึกข้อมูลเมตา การสั่น การหมุนรอบตัวเอง การสั่น
  • scene1: การเปิดรับแสง ความไวแสง การชดเชย EV, YUV เทียบกับ JPEG/RAW
  • scene2: การตรวจจับใบหน้า การทดสอบที่ต้องใช้ฉากสี
  • scene3: การเพิ่มคุณภาพขอบ การเคลื่อนไหวของเลนส์
  • scene4: สัดส่วนภาพ การครอบตัด มุมมอง
  • scene5: การแรเงาของเลนส์
  • scene6: ซูม
  • scene7: สวิตช์กล้องหลายตัว
  • scene8: การวัดแสงแบบเป็นพื้นที่ของ AE และ AWB
  • scene9: การบีบอัด JPEG
  • scene_extensions: ส่วนขยายกล้อง
  • scene_flash: แฟลชอัตโนมัติ อัตราเฟรมขั้นต่ำ
  • scene_video: เฟรมตก
  • sensor_fusion: ระยะห่างของเวลาของกล้อง/ไจโรสโคป
  • feature_combination: ชุดค่าผสมของฟีเจอร์

ดูคำอธิบายของแต่ละฉากได้ในส่วนต่างๆ

scene0

การทดสอบ Scene0 ไม่จำเป็นต้องมีข้อมูลฉากที่เฉพาะเจาะจง อย่างไรก็ตาม โทรศัพท์ต้องอยู่ในที่ที่ไม่มีการเคลื่อนที่สําหรับการทดสอบไจโรสโคปและการสั่น

test_jitter

วัดความผันผวนในการประทับเวลาของกล้อง

API ที่ทดสอบแล้ว:

ผ่าน: เฟรมมีความต่างอย่างน้อย 30 ms

test_jitter_plot.png

test_jitter_plot.png (สังเกตช่วงแกน y ที่แคบ จริงๆ แล้วความผันผวนมีน้อยมาก (ในผังนี้)

test_metadata

ทดสอบความถูกต้องของรายการข้อมูลเมตา ดูผลลัพธ์การจับภาพและวัตถุลักษณะของกล้อง การทดสอบนี้ใช้auto_capture_requestค่าการเปิดรับแสง และค่าอัตราขยาย เนื่องจากเนื้อหารูปภาพไม่สำคัญ

API ที่ทดสอบแล้ว:

ผ่าน: แท็กระดับฮาร์ดแวร์, rollingShutterSkew, frameDuration, timestampSource, croppingType, blackLevelPattern, pixel_pitch, FoV, ระยะโฟกัสที่คมชัดสุดแสดงอยู่และมีค่าที่ถูกต้อง

test_request_capture_match

ทดสอบว่าอุปกรณ์เขียนค่าการเปิดรับแสงและค่ารับแสงที่ถูกต้องโดยการอ่านข้อมูลเมตาการจับภาพ

API ที่ทดสอบแล้ว:

ผ่าน: ค่าข้อมูลเมตาของคำขอและค่าข้อมูลเมตาของภาพตรงกันในทุกช็อต

test_sensor_events

ทดสอบการค้นหาอุปกรณ์และพิมพ์เหตุการณ์เซ็นเซอร์สำหรับอุปกรณ์ที่โฆษณาการรองรับการผสานเซ็นเซอร์ เซ็นเซอร์ที่คาดหวังคือตัวตรวจวัดความเร่ง ที่หมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก การทดสอบนี้จะทำงานก็ต่อเมื่อหน้าจอเปิดอยู่ ซึ่งหมายความว่าอุปกรณ์ไม่ได้อยู่ในโหมดสแตนด์บาย

API ที่ทดสอบแล้ว:

ผ่าน: ระบบได้รับเหตุการณ์จากเซ็นเซอร์แต่ละตัว

test_solid_color_test_pattern

ทดสอบว่ารูปแบบการทดสอบที่เป็นสีพื้นสร้างขึ้นอย่างถูกต้องสำหรับการปิดเสียงกล้อง หากรองรับการปิดเสียงกล้อง อุปกรณ์จะต้องรองรับรูปแบบการทดสอบที่เป็นสีพื้น หากระบบไม่รองรับการปิดเสียงกล้อง ระบบจะทดสอบรูปแบบทดสอบที่เป็นสีพื้นเฉพาะในกรณีที่มีการโฆษณาความสามารถนี้เท่านั้น

หากรองรับรูปภาพ RAW ระบบจะทดสอบการกำหนดสีด้วย สีที่ทดสอบ ได้แก่ ดำ ขาว แดง น้ำเงิน และเขียว สำหรับกล้องที่ไม่รองรับรูปภาพ RAW ระบบจะทดสอบเฉพาะสีดำ

API ที่ทดสอบแล้ว:

ผ่าน: รูปแบบการทดสอบแบบสีล้วนที่รองรับเป็นสีที่ถูกต้องและมีความแปรปรวนต่ำในรูปภาพ

test_test_pattern

ทดสอบพารามิเตอร์ android.sensor.testPatternMode เพื่อจับเฟรมสำหรับแต่ละรูปแบบทดสอบที่ถูกต้อง และตรวจสอบว่าเฟรมที่สร้างสำหรับสีพื้นและแถบสีนั้นถูกต้อง การทดสอบนี้ประกอบด้วยขั้นตอนต่อไปนี้

  1. จับภาพสำหรับรูปแบบการทดสอบที่รองรับทั้งหมด
  2. ดำเนินการตรวจสอบความถูกต้องแบบง่ายสำหรับรูปแบบการทดสอบสีพื้นและแถบสี

API ที่ทดสอบแล้ว:

ผ่าน: รูปแบบการทดสอบที่รองรับสร้างขึ้นอย่างถูกต้อง

test_test_patterns_2

test_test_patterns_2.jpg

test_tonemap_curve

ทดสอบการเปลี่ยนรูปแบบทดสอบจาก RAW เป็น YUV ด้วยโทนแผนที่เป็นเส้นตรง การทดสอบนี้ต้องใช้ android.sensor.testPatternMode = 2 (COLOR_BARS) เพื่อสร้างรูปแบบรูปภาพที่สมบูรณ์สำหรับการแปลงโทนแผนที่ ตรวจสอบว่าไปป์ไลน์มีเอาต์พุตสีที่เหมาะสมด้วยโทนแผนที่เป็นเส้นตรงและอินพุตรูปภาพที่เหมาะเจาะ (ใช้ test_test_patterns)

API ที่ทดสอบแล้ว:

ผ่าน: YUV และ RAW ดูคล้ายกัน

test_tonemap_curve_raw_2

test_tonemap_curve_raw_2.jpg

test_tonemap_curve_yuv_2.jpg

test_tonemap_curve_yuv_2.jpg

test_unified_timestamp

ทดสอบว่าเหตุการณ์จากเซ็นเซอร์ตรวจจับการเคลื่อนไหวและรูปภาพอยู่ในโดเมนเวลาเดียวกันหรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: การประทับเวลาของการเคลื่อนไหวอยู่ระหว่างการประทับเวลาของรูปภาพ 2 รูป

test_vibration_restriction

ทดสอบว่าการสั่นของอุปกรณ์ทำงานตามที่คาดไว้หรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: อุปกรณ์ไม่สั่นเมื่อปิดเสียงโดย API การจำกัดเสียงของกล้อง

scene1

scene1 คือแผนภูมิสีเทา แผนภูมิสีเทาต้องครอบคลุมตรงกลางของขอบเขตการมองเห็นของกล้อง 30% แผนภูมิสีเทาคาดว่าจะท้าทาย 3A (การเปิดรับแสงอัตโนมัติ สมดุลแสงสีขาวอัตโนมัติ โฟกัสอัตโนมัติ) ในระดับปานกลางเนื่องจากบริเวณตรงกลางไม่มีองค์ประกอบ อย่างไรก็ตาม คำขอจับภาพจะระบุทั้งฉากซึ่งมีองค์ประกอบเพียงพอสำหรับ 3A ในการรวม

กล้อง RFoV ทดสอบได้ใน WFoV หรือแท่นทดสอบ RFoV หากทดสอบกล้อง RFoV ในแท่นทดสอบ WFoV ระบบจะปรับขนาดแผนภูมิเป็น ⅔ เพื่อให้ขอบเขตของแผนภูมิสีเทาใน FoV ช่วยในการรวม 3A ดูคำอธิบายโดยละเอียดของแท่นทดสอบกล้องได้ที่ ITS-in-a-box สำหรับกล้อง

scene1

scene1: แผนภูมิขนาดเต็ม (ซ้าย) แผนภูมิที่ปรับขนาด ⅔ (ขวา)

test_ae_precapture_trigger

ทดสอบสถานะการทำงานของ AE เมื่อใช้ทริกเกอร์การจับภาพก่อน บันทึกคำขอที่ดำเนินการด้วยตนเอง 5 รายการโดยปิดใช้ AE คำขอสุดท้ายมีการทริกเกอร์ก่อนการจับภาพ AE ซึ่งควรละเว้นเนื่องจาก AE ถูกปิดใช้

API ที่ทดสอบแล้ว:

ผ่าน: AE บรรจบ

test_auto_vs_manual

การทดสอบที่จับภาพอัตโนมัติและด้วยตนเองมีลักษณะเหมือนกัน

API ที่ทดสอบแล้ว:

ผ่าน: อัตราขยายและการเปลี่ยนรูปแบบการปรับสมดุลสีขาวด้วยตนเองที่รายงานในผลการจับภาพแต่ละรายการตรงกับการปรับสมดุลสีขาวอัตโนมัติ estimate จากอัลกอริทึม 3A ของกล้อง

test_auto_vs_manual_auto

test_auto_vs_manual_auto.jpg

test_auto_vs_manual_wb

test_auto_vs_manual_wb.jpg

test_auto_vs_manual_manual_wb_tm

test_auto_vs_manual_manual_wb_tm.jpg

test_black_white

ทดสอบว่าอุปกรณ์สร้างภาพขาวดําได้เต็มรูปแบบ ถ่ายภาพ 2 ภาพ โดยภาพแรกมีอัตราขยายต่ำมากและการเปิดรับแสงสั้น ซึ่งจะทำให้ได้รูปภาพสีดํา และภาพที่สองมีอัตราขยายสูงมากและการเปิดรับแสงนาน ซึ่งจะทำให้ได้รูปภาพสีขาว

API ที่ทดสอบแล้ว:

ผ่าน: สร้างรูปภาพขาวดํา ช่องสีอิ่มตัวของรูปภาพสีขาวจะมีค่า RGB เท่ากับ [255, 255, 255] โดยมีค่าความคลาดเคลื่อนน้อยกว่า 1%

test_black_white_black test_black_white_black
test_black_white_black.jpg test_black_white_white.jpg

test_black_white_plot_means

test_black_white_plot_means.png

test_burst_capture

ยืนยันว่าไปป์ไลน์การจับภาพทั้งหมดทำงานได้ทันกับความเร็วในการจับภาพขนาดเต็มและเวลาที่ใช้ CPU

API ที่ทดสอบแล้ว:

ผ่าน: จับภาพต่อเนื่องเป็นชุดขนาดเต็ม ตรวจสอบการหยุดเฟรมและระดับความสว่างของรูปภาพ

test_burst_sameness_manual

ถ่ายภาพ 50 ภาพแบบต่อเนื่อง 5 ชุดโดยใช้การตั้งค่าการจับภาพด้วยตนเอง และตรวจสอบว่ารูปภาพทั้งหมดเหมือนกัน การทดสอบนี้ใช้เพื่อระบุว่ามีเฟรมที่ประมวลผลต่างกันหรือมีสิ่งรบกวนหรือไม่

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 ที่ทดสอบแล้ว:

ผ่าน: ข้อมูลเมตาใช้ได้กับการจับภาพทั้งหมด และการตั้งค่าด้วยตนเองจะไม่ส่งผลต่อการจับภาพอัตโนมัติครั้งที่ 2 แสดงการแก้ไขแสงที่สะท้อนจากเลนส์สำหรับการจับภาพ

test_capture_result_plot_lsc_auto_ch0

test_capture_result_plot_lsc_auto_ch0.png

test_crop_region_raw

ทดสอบว่าสตรีม RAW ไม่สามารถครอบตัดได้

API ที่ทดสอบแล้ว:

ผ่าน: ระบบจะครอบตัดรูปภาพ YUV ตรงกลาง แต่จะไม่ครอบตัดรูปภาพ RAW

test_crop_region_raw_comp_raw_crop

test_crop_region_raw_comp_raw_crop.jpg

test_crop_region_raw_comp_raw_full

test_crop_region_raw_comp_raw_full.jpg

test_crop_region_raw_comp_yuv_crop

test_crop_region_raw_comp_yuv_crop.jpg

test_crop_region_raw_yuv_full

test_crop_region_raw_yuv_full.jpg

test_crop_regions

ทดสอบว่าพื้นที่ครอบตัดใช้งานได้ ถ่ายภาพเต็มรูปแบบและสร้างแพทช์ของภูมิภาคต่างๆ 5 ภูมิภาค (มุมและตรงกลาง) ถ่ายภาพโดยตั้งค่าการครอบตัดสำหรับภูมิภาค 5 แห่ง เปรียบเทียบค่าของแพทช์กับค่าของรูปภาพที่ครอบตัด

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพของพื้นที่ที่ครอบตัดตรงกับแพทช์ที่ตรงกับรูปภาพที่ครอบตัด

test_dng_noise_model

ยืนยันว่าพารามิเตอร์โมเดลไฟล์ RAW ของ DNG ถูกต้อง ผังแสดงความแปรปรวนที่วัดได้ของแพตช์ตรงกลางของการ์ดสีเทาในช็อต RAW ที่ถ่ายในย่านความไวแสงต่างๆ และเปรียบเทียบค่าเหล่านี้กับความแปรปรวนที่คาดไว้ที่ความไวแสงแต่ละระดับโดยโมเดลสัญญาณรบกวน DNG ใน HAL ของกล้อง (อิงตามพารามิเตอร์ O,S ที่แสดงผลในออบเจ็กต์ผลลัพธ์การจับภาพ) ดูรายละเอียดเพิ่มเติมเกี่ยวกับรูปแบบสัญญาณรบกวน DNG ได้โดยดาวน์โหลดเอกสารต่อไปนี้เกี่ยวกับรูปแบบสัญญาณรบกวน DNG

API ที่ทดสอบแล้ว:

ผ่าน: พารามิเตอร์โมเดลไฟล์ RAW ของ DNG ถูกต้อง ค่า RGB ที่คาดไว้ตรงกับค่า RGB จริงที่วัดได้

test_dng_noise_model_plog

test_dng_noise_model_plog.png

test_ev_compensation_advanced

ทดสอบว่าระบบใช้ค่าชดเชยการเปิดรับแสง (EV) หรือไม่ การทดสอบจะเพิ่มการเปิดรับแสงเป็น 8 ขั้นตอน และตรวจสอบความสว่างที่วัดได้เทียบกับความสว่างที่คาดไว้ ค่าที่คาดหวังจะคํานวณจากความสว่างของภาพโดยไม่มีการใช้การชดเชย EV และค่าที่คาดหวังจะอิ่มตัวหากค่าที่คำนวณได้เกินช่วงค่าของภาพจริง การทดสอบจะล้มเหลวหากค่าที่คาดไว้และค่าที่วัดได้ไม่ตรงกันหรือภาพสว่างเกินไปภายใน 5 ขั้นตอน

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพแสดงการเปิดรับแสงที่เพิ่มขึ้นโดยไม่เปิดรับแสงมากเกินไปภายใน 5 ขั้นตอน

test_ev_compensation_advanced_plot_means

test_ev_compensation_advanced_plot_means.png

test_ev_compensation_basic

ทดสอบว่าระบบใช้การชดเชย EV โดยใช้ช่วงที่สร้างด้วย CONTROL_AE_COMPENSATION_STEP ระบบจะจับภาพ 8 เฟรมที่ค่าชดเชยแต่ละค่า

API ที่ทดสอบแล้ว:

ผ่าน: จับภาพค่าความสว่างที่เพิ่มขึ้นด้วยการตั้งค่าการชดเชย EV ที่เพิ่มขึ้น และเฟรม 8 เฟรมที่จับภาพสำหรับการตั้งค่าการชดเชย EV แต่ละรายการมีค่าความสว่างที่สม่ำเสมอ

test_ev_compensation_basic

test_ev_compensation_basic.png

test_exposure_x_iso

ทดสอบว่าได้รับค่าการเปิดรับแสงคงที่เมื่อ ISO และเวลาการเปิดรับแสงแตกต่างกัน ถ่ายภาพชุดที่มี ISO และเวลาการเปิดรับแสงที่เลือกมาเพื่อปรับสมดุลกัน ผลลัพธ์ควรมีความสว่างเท่ากัน แต่รูปภาพควรมีสัญญาณรบกวนมากขึ้นเมื่อถ่ายทำต่อเนื่อง ยืนยันว่าค่าเฉลี่ยพิกเซลตัวอย่างใกล้เคียงกัน ตรวจสอบว่ารูปภาพไม่ได้ถูกจำกัดอยู่ที่ 0 หรือ 1 (ซึ่งจะทำให้รูปภาพดูเหมือนเส้นตรง) นอกจากนี้ คุณยังทำการทดสอบกับรูปภาพ RAW ได้โดยการตั้งค่า Flag debug ในไฟล์การกําหนดค่า

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพมีความสว่างเท่าเดิม แต่มีสัญญาณรบกวนมากขึ้นเมื่อ ISO สูงขึ้น ระนาบ RGB จะราบเรียบเมื่อค่า ISO*exposure คงที่ในพื้นที่การขยายที่ทดสอบ

กลไกการทำงานที่ไม่สําเร็จ:

  • ใน test_exposure_plot_means.png เมื่อค่าตัวคูณอัตราขยาย (แกน x) เพิ่มขึ้น ค่าเฉลี่ยของระนาบ RGB ที่แปลงค่าให้เป็นมาตรฐาน (แกน y) จะเริ่มเบี่ยงเบนจากค่าตัวคูณอัตราขยายต่ำ

test_exposure_plot_means

test_exposure_plot_means.png

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

test_jpeg

ทดสอบว่ารูปภาพ YUV ที่แปลงและรูปภาพ JPEG ของอุปกรณ์มีลักษณะเหมือนกัน การทดสอบจะนํา 10% ตรงกลางของรูปภาพมาคํานวณค่า RGB และตรวจสอบว่าตรงกัน

API ที่ทดสอบแล้ว:

ผ่าน: ความแตกต่างของค่า RGB โดยเฉลี่ยระหว่างรูปภาพแต่ละรูปน้อยกว่า 3%

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

test_latching

ทดสอบว่าการตั้งค่า (การเปิดรับแสงและอัตราขยาย) ยึดเฟรมที่ถูกต้องสำหรับกล้อง FULL และ LEVEL_3 ถ่ายภาพชุดๆ โดยใช้คําขอติดต่อกัน โดยเปลี่ยนพารามิเตอร์คําขอจับภาพระหว่างการถ่ายภาพ ตรวจสอบว่ารูปภาพมีคุณสมบัติตามที่คาดไว้

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพ [2, 3, 6, 8, 10, 12, 13] มี ISO หรือการเปิดรับแสงที่เพิ่มขึ้นและแสดงขึ้นโดยมีค่าเฉลี่ย RGB สูงกว่าใน test_latching_plot_means.png

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

test_latching_plot_means

test_latching_plot_means.png

test_linearity

ทดสอบว่าระบบประมวลผลของอุปกรณ์สามารถเปลี่ยนพิกเซลเชิงเส้นเป็นพิกเซลเชิงเส้นได้ จับภาพชุดภาพโดยที่อุปกรณ์เล็งไปยังเป้าหมายเดียวกัน

API ที่ทดสอบแล้ว:

ผ่าน: ค่า R, G, B ต้องเพิ่มขึ้นตามลำดับแบบเชิงเส้นเมื่อความไวเพิ่มขึ้น

test_linearity_plot_means

test_linearity_plot_means.png

test_locked_burst

ทดสอบการล็อก 3A และภาพต่อเนื่อง YUV (ใช้การตั้งค่าอัตโนมัติ) การทดสอบนี้ออกแบบมาให้ผ่านแม้ในอุปกรณ์แบบจำกัดที่ไม่มี MANUAL_SENSOR หรือ PER_FRAME_CONTROLS การทดสอบจะตรวจสอบความสอดคล้องของรูปภาพ YUV ขณะที่การตรวจสอบอัตราเฟรมอยู่ใน CTS

API ที่ทดสอบแล้ว:

ผ่าน: ภาพดูสอดคล้องกัน

test_locked_burst_frame0

test_locked_burst_frame0.jpg

test_locked_burst_frame1

test_locked_burst_frame1.jpg

test_locked_burst_frame2

test_locked_burst_frame2.jpg

test_param_color_correction

ทดสอบว่าระบบใช้พารามิเตอร์ android.colorCorrection.* เมื่อตั้งค่า ถ่ายภาพด้วยค่าการเปลี่ยนรูปแบบและค่ารับแสงที่แตกต่างกัน และทดสอบว่าภาพดูแตกต่างกันตามลำดับ ระบบจะเลือกการเปลี่ยนรูปแบบและอัตราขยายเพื่อให้เอาต์พุตเป็นสีแดงหรือน้ำเงินมากขึ้น ใช้แผนที่โทนสีเชิงเส้น การแมปโทนสีเป็นเทคนิคที่ใช้ในระบบประมวลผลภาพเพื่อแมปชุดสีหนึ่งกับอีกชุดหนึ่งเพื่อให้รูปภาพแบบช่วงไดนามิกสูงมีลักษณะใกล้เคียงกับสื่อที่มีช่วงไดนามิกจำกัดมากขึ้น

API ที่ทดสอบแล้ว:

ส่ง: เพิ่มค่า R และ B ตามการเปลี่ยนรูปแบบ

test_param_color_correction_plot_means

test_param_color_correction_plot_means.png

*แกน x คือคำขอบันทึก: 0 = Unity, 1=การเร่งสีแดง, 2= การเร่งสีน้ำเงิน

test_param_color_correction_req=0

test_param_color_correction_req=0.jpg

test_param_color_correctness_req=1

test_param_color_correctness_req=1.jpg (R boost)

test_param_color_correction_req=2

test_param_color_correction_req=2.jpg (B boost)

test_param_flash_mode

ทดสอบว่ามีการใช้พารามิเตอร์ android.flash.mode ตั้งค่าการเปิดเผยแสงให้อยู่ในด้านมืดด้วยตนเองเพื่อให้เห็นชัดเจนว่าแฟลชทำงานหรือไม่ และใช้โทนแผนที่เป็นเส้นตรง ตรวจสอบตรงกลางด้วยรูปภาพไทล์เพื่อดูว่ามีการสร้างการไล่ระดับสีขนาดใหญ่ขึ้นเพื่อยืนยันว่าแฟลชทำงานหรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: ตรงกลางของภาพไทล์มีการไล่ระดับสีขนาดใหญ่ ซึ่งหมายความว่าแฟลชทำงาน

test_param_flash_mode_1

test_param_flash_mode_1.jpg

test_param_flash_mode_1_tile

test_param_flash_mode_1_tile.jpg

test_param_flash_mode_2

test_param_flash_mode_2.jpg

test_param_flash_mode_2_tile

test_param_flash_mode_2_tile.jpg

test_param_noise_reduction

ทดสอบว่าพารามิเตอร์ android.noiseReduction.mode ใช้อย่างถูกต้องเมื่อตั้งค่า ถ่ายภาพด้วยกล้องที่มีแสงสลัว ใช้อัตราขยายแบบแอนะล็อกสูงเพื่อให้มั่นใจว่ารูปภาพที่จับได้มีสัญญาณรบกวน จับภาพ 3 ภาพสำหรับ 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_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 และตรวจสอบว่ารูปภาพเอาต์พุตได้รับการแก้ไขตามที่คาดไว้ การทดสอบนี้ประกอบด้วย 2 การทดสอบ ได้แก่ test1 และ test2

API ที่ทดสอบแล้ว:

บัตร:

  • test1: รูปภาพทั้ง 2 รูปมีโทนแผนที่เป็นเส้นตรง แต่ 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 โดยเพิ่มอัตราขยายและวัดสัญญาณรบกวน จับภาพแบบ RAW เท่านั้นแบบต่อเนื่อง

API ที่ทดสอบแล้ว:

ผ่าน: แต่ละช็อตมีสัญญาณรบกวนมากกว่าช็อตก่อนหน้า เนื่องจากกำลังขยายเพิ่มขึ้น

ใช้ความแปรปรวนของเซลล์ตารางกริดสถิติส่วนกลาง

test_raw_burst_sensitivity_variance

test_raw_burst_sensitivity_variance.png

test_raw_exposure

จับภาพชุดรูปภาพ RAW โดยเพิ่มเวลาเปิดรับแสงและวัดค่าพิกเซล

API ที่ทดสอบแล้ว:

ผ่าน: การเพิ่ม ISO (การขยายสัญญาณ) ทำให้พิกเซลไวต่อแสงมากขึ้น แผนภูมิจึงเลื่อนไปทางซ้าย

test_raw_exposure_s=55

test_raw_exposure_s=55.png

(10⁰ คือ 1 มิลลิวินาที, 10¹ คือ 10 มิลลิวินาที, 10⁻¹ คือ 0.1 มิลลิวินาที)

test_raw_exposure_s=132

test_raw_exposure_s=132.png

test_raw_exposure_s=209

test_raw_exposure_s=209.png

test_raw_exposure_s=286

test_raw_exposure_s=286.png

test_raw_exposure_s=363

test_raw_exposure_s=363.png

test_raw_exposure_s=440

test_raw_exposure_s=440.png

test_raw_sensitivity

จับภาพชุดรูปภาพ RAW โดยเพิ่มความไวแสงและวัดสัญญาณรบกวน (ความแปรปรวน) ตรงกลาง 10% ของรูปภาพ ทดสอบว่าแต่ละช็อตมีสัญญาณรบกวนมากกว่าช็อตก่อนหน้า

API ที่ทดสอบแล้ว:

ผ่าน: ความแปรปรวนจะเพิ่มขึ้นตามแต่ละช็อต

test_raw_sensitivity_variance

test_raw_sensitivity_variance.png

test_reprocess_noise_reduction

การทดสอบว่า android.noiseReduction.mode ใช้กับคำขอประมวลผลอีกครั้งหรือไม่ ถ่ายภาพที่ประมวลผลใหม่ด้วยกล้องที่มีแสงสลัว ใช้อัตราขยายแบบแอนะล็อกสูงเพื่อให้แน่ใจว่ารูปภาพที่จับได้มีสัญญาณรบกวน จับภาพ 3 รูปภาพที่ประมวลผลใหม่สำหรับ NR ที่ปิดอยู่ "เร็ว" และ "คุณภาพสูง" จับภาพที่ได้รับการประมวลผลใหม่โดยเปิดรับแสงต่ำและปิด NR และใช้ความแปรปรวนของภาพนี้เป็นฐาน

API ที่ทดสอบแล้ว:

ผ่าน: FAST >= OFF, HQ >= FAST, HQ >> OFF

ผัง SNR ทั่วไปเทียบกับ NR_MODE

ผัง SNR ทั่วไปเทียบกับ NR_MODE

test_tonemap_sequence

ทดสอบลำดับช็อตด้วยเส้นโค้งการปรับโทนสีแบบต่างๆ ถ่ายภาพด้วยตนเอง 3 ภาพ ด้วยโทนแผนที่เป็นเส้นตรง ถ่ายภาพด้วยตนเอง 3 ภาพโดยใช้แผนที่สีเริ่มต้น คํานวณค่าเดลต้าระหว่างคู่เฟรมที่ต่อเนื่องกันแต่ละคู่

API ที่ทดสอบแล้ว:

ผ่าน: มีเฟรมที่เหมือนกัน 3 เฟรมตามด้วยเฟรมที่เหมือนกันอีก 3 เฟรมในชุดอื่น

test_tonemap_sequence_i=0

test_tonemap_sequence_i=0.jpg

test_tonemap_sequence_i=1

test_tonemap_sequence_i=1.jpg

test_tonemap_sequence_i=2

test_tonemap_sequence_i=2.jpg

test_tonemap_sequence_i=3

test_tonemap_sequence_i=3.jpg

test_tonemap_sequence_i=4

test_tonemap_sequence_i=4.jpg

test_tonemap_sequence_i=5

test_tonemap_sequence_i=5.jpg

test_yuv_jpeg_all

ทดสอบว่าขนาดและรูปแบบที่รายงานทั้งหมดสำหรับการจับภาพรูปภาพใช้งานได้ ใช้คำขอด้วยตนเองที่มีโทนแผนที่เป็นเส้นตรงเพื่อให้ YUV และ JPEG มีลักษณะเหมือนกันเมื่อแปลงโดยโมดูล image_processing_utils ระบบจะไม่บันทึกรูปภาพโดยค่าเริ่มต้น แต่สามารถบันทึกได้โดยเปิดใช้ debug_mode

API ที่ทดสอบแล้ว:

ผ่าน: ศูนย์รูปภาพทั้งหมดมี RMS (ค่ารากค่าเฉลี่ยสี่เหลี่ยมจัตุรัสของสัญญาณ) สูงสุดที่แตกต่างกันในรูปภาพที่แปลงเป็น RGB กับรูปภาพ YUV ที่มีความละเอียดสูงสุด 3%

test_yuv_jpeg_all

test_yuv_jpeg_all.png

test_yuv_plus_dng

ทดสอบว่าขนาดและรูปแบบที่รายงานสำหรับการจับภาพรูปภาพใช้งานได้

API ที่ทดสอบแล้ว:

ผ่าน: การทดสอบเสร็จสมบูรณ์และแสดงรูปภาพที่ขอ

test_yuv_plus_dng

test_yuv_plus_dng.jpg

test_yuv_plus_jpeg

ทดสอบการจับภาพเฟรมเดียวเป็นเอาต์พุต YUV และ JPEG ใช้คำขอด้วยตนเองที่มีโทนแผนที่เป็นเส้นตรงเพื่อให้ YUV และ JPEG มีลักษณะเหมือนกันเมื่อแปลงโดยโมดูล image_processing_utils

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพ YUV และ JPEG คล้ายกันและมีความแตกต่างกันน้อยกว่า 1% RMS (ค่ารากค่าเฉลี่ยกำลังสองของสัญญาณ)

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

test_yuv_plus_raw

ทดสอบการจับภาพเฟรมเดียวทั้งที่เป็นเอาต์พุต RAW/RAW10/RAW12 และ YUV หากรองรับ ใช้คำขอด้วยตนเองที่มีการปรับโทนสีเชิงเส้นเพื่อให้ Raw และ YUV เหมือนกัน เปรียบเทียบค่า RGB 10% ตรงกลางของรูปภาพที่แปลงเป็น RGB บันทึกandroid.shading.mode

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพ YUV และ RAW คล้ายกันและมีความแตกต่างกันน้อยกว่า 3.5% RMS (ค่าเฉลี่ยกำลังสองของสัญญาณ)

test_yuv_plus_raw_shading=1_raw.jpg test_yuv_plus_raw_shading=1_yuv.jpg
test_yuv_plus_raw_shading=1_raw.jpg test_yuv_plus_raw_shading=1_yuv.jpg

scene2_a

scene2_a มีใบหน้า 3 ใบหน้าที่มีพื้นหลังสีเทาและเสื้อผ้าสีกลาง ใบหน้าเหล่านี้ได้รับการเลือกให้มีสีผิวที่หลากหลาย แผนภูมิต้องอยู่ในแนวที่ถูกต้องเพื่อให้การตรวจจับใบหน้าทำงานได้อย่างมีประสิทธิภาพสูงสุด

scene2_a

scene2_a

test_autoframing

ทดสอบลักษณะการจับเฟรมอัตโนมัติของอุปกรณ์กล้อง ทำการซูมเข้าจนไม่เห็นใบหน้าใดๆ ในฉาก เปิดใช้โหมดการจัดเฟรมอัตโนมัติโดยตั้งค่า AUTOFRAMING ใน CaptureRequest เป็น True และตรวจสอบว่าระบบตรวจจับใบหน้าทั้งหมดในฉากเดิมได้หรือไม่เมื่อสถานะบรรจบ (กล่าวคือ เมื่อตั้งค่า AUTOFRAMING_STATE ใน CaptureResult เป็น AUTOFRAMING_STATE_CONVERGED)

API ที่ทดสอบแล้ว:

ผ่าน: ตรวจพบใบหน้าทั้ง 3 ใบหน้า

test_display_p3

ทดสอบการจับภาพ Display P3 เป็น JPEG โดยใช้ ColorSpaceProfiles API ทดสอบว่า JPEG ที่บันทึกไว้มีโปรไฟล์ ICC ที่เหมาะสมในส่วนหัว และรูปภาพมีสีที่อยู่นอกช่วงสี sRGB

API ที่ทดสอบแล้ว:

ผ่าน: JPEG มีโปรไฟล์ ICC ของ Display P3 และมีสีที่อยู่นอกช่วงสี sRGB

test_effects

จับเฟรมสำหรับเอฟเฟกต์กล้องที่รองรับและตรวจสอบว่าเอฟเฟกต์สร้างขึ้นอย่างถูกต้องหรือไม่ การทดสอบจะตรวจสอบเฉพาะเอฟเฟกต์ OFF และ MONO แต่บันทึกรูปภาพสำหรับเอฟเฟกต์ที่รองรับทั้งหมด

API ที่ทดสอบแล้ว:

ผ่าน: จับภาพฉากที่มีเอฟเฟกต์ OFF และรูปภาพโมโนโครมโดยตั้งค่าเอฟเฟกต์เป็น MONO

test_effects_MONO

test_effects_MONO.jpg

test_format_combos

ทดสอบการผสมผสานรูปแบบเอาต์พุตแบบต่างๆ

API ที่ทดสอบแล้ว:

ผ่าน: บันทึกชุดค่าผสมทั้งหมดสําเร็จ

test_num_faces

ทดสอบการตรวจจับใบหน้า

API ที่ทดสอบแล้ว:

ผ่าน: พบใบหน้า 3 ใบหน้า

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_reprocess_uv_swap

ทดสอบว่าระบบประมวลผล YUV อีกครั้งไม่ได้สลับระนาบ U และ V ระบบจะตรวจหาการประมวลผลซ้ำโดยคำนวณผลรวมของความแตกต่างสัมบูรณ์ (SAD) ระหว่างรูปภาพที่ประมวลผลซ้ำกับภาพที่ไม่ได้ประมวลผลซ้ำ หากการสลับปุ่มเครื่องบิน U และ V ของเอาต์พุตจากการจับภาพที่ประมวลผลใหม่ส่งผลให้ SAD เพิ่มขึ้น ระบบจะถือว่าเอาต์พุตมีเครื่องบิน U และ V ที่ถูกต้อง

API ที่ทดสอบแล้ว:

ผ่าน: ไม่ได้สลับระนาบ U และ V

test_reprocess_uv_swap

test_reprocess_uv_swap.png

scene2_b

test_num_faces

ทดสอบการตรวจจับใบหน้าด้วยฉากใบหน้าที่มีสีผิวหลากหลายมากขึ้น

API ที่ทดสอบแล้ว:

ผ่าน: พบใบหน้า 3 ใบหน้า

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

test_yuv_jpeg_capture_sameness

จับภาพ 2 รูปโดยใช้รูปแบบ YUV และ JPEG ทั่วไปที่ใหญ่ที่สุดที่มีอัตราส่วนภาพเดียวกับรูปแบบ JPEG ที่ใหญ่ที่สุด โดยไม่เกินความละเอียด 1920x1440 ตั้งค่า jpeg.quality เป็น 100 และบันทึกคําขอพื้นผิวคู่ แปลงรูปภาพทั้ง 2 รูปเป็นอาร์เรย์ RGB และคำนวณผลต่างค่าเฉลี่ยกำลังสอง (RMS) 3 มิติระหว่างรูปภาพ 2 รูป

นอกจากนี้ การทดสอบนี้ยังยืนยันว่าเอาต์พุต YUV สำหรับ Use Case ของสตรีมทั้งหมดที่รองรับมีความคล้ายคลึงกับ YUV ใน Use Case STILL_CAPTURE ในระดับที่ยอมรับได้

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพ YUV และ JPEG สำหรับกรณีการใช้งาน STILL_CAPTURE มีความแตกต่าง RMS (ค่ารากค่าเฉลี่ยสี่เหลี่ยมจัตุรัสของสัญญาณ) น้อยกว่า 3%; รูปภาพ YUV สำหรับกรณีการใช้งานที่รองรับทั้งหมดมีความแตกต่าง RMS น้อยกว่า 10% จากรูปภาพ 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 ของ camera2 น้อยกว่า 1,000 มิลลิวินาทีสำหรับความละเอียด 1080p ตามที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว

test_camera_launch_perf_class

ทดสอบเวลาในการตอบสนองของการเปิดกล้องสำหรับคลาสประสิทธิภาพ S ตามที่ระบุไว้ในส่วน2.2.7.2 กล้องใน CDD

ผ่าน: ต้องมีความล่าช้าในการเริ่มต้นของ camera2 (เปิดกล้องเพื่อดูตัวอย่างเฟรมแรก) < 600ms โดยวัดจาก PerformanceTest ของกล้อง CTS ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว

test_default_camera_hdr

ทดสอบว่าภาพจากกล้องเริ่มต้นเป็น Ultra HDR สำหรับประสิทธิภาพระดับ 15 ตามที่ระบุไว้ในส่วนที่ 2.2.7.2 กล้องของ CDD

ผ่าน: การจับภาพแพ็กเกจกล้องเริ่มต้นต้องเป็น Ultra HDR สำหรับอุปกรณ์ระดับประสิทธิภาพ 15

scene2_d

test_num_faces

ทดสอบการตรวจจับใบหน้าด้วยฉากใบหน้าที่มีสีผิวหลากหลายมากขึ้น

API ที่ทดสอบแล้ว:

ผ่าน: พบใบหน้า 3 ใบหน้า

scene2_e

test_continuous_picture

ระบบจะจับภาพเฟรมความละเอียด VGA 50 เฟรมด้วยการตั้งค่าคำขอบันทึกแรก android.control.afMode = 4 (CONTINUOUS_PICTURE).

API ที่ทดสอบแล้ว:

ผ่าน: ระบบ 3A ทำงานเสร็จสิ้นภายในช่วงการจับภาพ 50 เฟรม

test_num_faces

ทดสอบการตรวจจับใบหน้าด้วยฉากใบหน้าที่มีสีผิวหลากหลายมากขึ้น

API ที่ทดสอบแล้ว:

ผ่าน: พบใบหน้า 3 ใบหน้า

scene2_f

scene2_f มีใบหน้า 3 ใบหน้าที่มีพื้นหลังสีขาวและเสื้อผ้าสีขาว ใบหน้ามีสีผิวที่หลากหลายและคอนทราสต์สูงกับพื้นหลัง

scene2_f.png

scene2_f

test_num_faces

ทดสอบการตรวจจับใบหน้าด้วยฉากใบหน้าที่มีสีผิวหลากหลายมากขึ้น

API ที่ทดสอบแล้ว:

ผ่าน: พบใบหน้า 3 ใบหน้า

test_num_faces_fd_mode_1

test_num_faces_fd_mode_1.jpg

scene3

Scene3 ใช้แผนภูมิ ISO12233 และการทดสอบส่วนใหญ่ใช้วิธีการดึงข้อมูลแผนภูมิเพื่อค้นหาแผนภูมิในฉาก ด้วยเหตุนี้ รูปภาพที่บันทึกส่วนใหญ่จึงไม่มีขอบเหมือนรูปภาพสำหรับฉากที่ 1, 2 หรือ 4 แต่มีเฉพาะแผนภูมิเท่านั้น แผนภูมิต้องอยู่ในแนวที่ถูกต้องเพื่อให้เครื่องมือค้นหาแผนภูมิทำงานได้อย่างมีประสิทธิภาพสูงสุด

test_edge_enhancement

ทดสอบว่าพารามิเตอร์ android.edge.mode ใช้อย่างถูกต้อง จับภาพรูปภาพที่ไม่มีการประมวลผลใหม่สำหรับโหมดขอบแต่ละโหมด และแสดงผลความคมชัดของรูปภาพเอาต์พุตและข้อมูลเมตาของผลการจับภาพ ประมวลผลคำขอจับภาพด้วยพารามิเตอร์โหมดขอบ ความไว เวลาเปิดรับแสง ระยะโฟกัส และพื้นผิวเอาต์พุตที่ระบุ

ผ่าน: โหมด HQ (2) คมชัดกว่าโหมด OFF (0) โหมด FAST (1) คมชัดกว่าโหมด OFF โหมด HQ คมชัดกว่าหรือเท่ากับโหมด FAST

API ที่ทดสอบแล้ว:

พารามิเตอร์ของกล้องที่ได้รับผลกระทบ:

  • EDGE_MODE

test_edge_enhancement_edge=0

test_edge_enhancement_edge=0.jpg

test_edge_enhancement_edge=1

test_edge_enhancement_edge=1.jpg (โหมดเร็ว)

test_edge_enhancement_edge=2

test_edge_enhancement_edge=2.jpg (โหมดคุณภาพสูง)

test_flip_mirror

ทดสอบว่ารูปภาพอยู่ในแนวที่ถูกต้องตามCDD ส่วน 7.5.2 กล้องหน้า [C-1-5] หรือไม่

รูปภาพที่สะท้อน กลับด้าน หรือหมุนจะระบุได้ด้วยสัญลักษณ์เพชรซึ่งอยู่ใกล้กับตรงกลาง

ผ่าน: รูปภาพไม่ได้พลิก สะท้อน หรือหมุน

test_flip_mirror_scene_patch

test_flip_mirror_scene_patch.jpg

test_imu_drift

ทดสอบว่าหน่วยวัดความเฉื่อย (IMU) มีเอาต์พุตที่เสถียรเป็นเวลา 30 วินาทีขณะที่อุปกรณ์อยู่กับที่และจับภาพตัวอย่างความละเอียดสูง

API ที่ทดสอบแล้ว:

บัตร:

  • ความคลาดเคลื่อนของไจโรน้อยกว่า 0.01 rad ตลอดระยะเวลาการทดสอบ
  • ความแปรปรวนของการอ่านค่าของไจโรน้อยกว่า 1E-7 rad2/s2/Hz ตลอดระยะเวลาการทดสอบ
  • ความคลาดเคลื่อนของเวกเตอร์การหมุนน้อยกว่า 0.01 rad ตลอดระยะเวลาการทดสอบ
  • (ยังไม่บังคับใช้) ความคลาดเคลื่อนของไจโรน้อยกว่า 1 องศาต่อวินาที

test_imu_drift_gyro_drift.png

test_imu_drift_gyro_drift.png

test_imu_drift_rotation_vector_drift.png

test_imu_drift_rotation_vector_drift.png

test_landscape_to_portrait

ทดสอบว่าฟังก์ชันการลบล้างจากแนวนอนเป็นแนวตั้งทํางานอย่างถูกต้องสําหรับเซ็นเซอร์ที่วางแนวนอน

API ที่ทดสอบแล้ว:

ผ่าน: การทดสอบสามารถค้นหาแผนภูมิที่มีการหมุนตามที่คาดไว้ (0 องศาเมื่อปิดใช้การลบล้างการวางแนวจากแนวนอนเป็นแนวตั้ง 90 องศาเมื่อเปิดใช้)

test_landscape_to_portrait

test_landscape_to_portrait.png

test_lens_movement_reporting

ทดสอบว่ามีการรายงาน Flag การเคลื่อนไหวของเลนส์อย่างถูกต้องหรือไม่ ถ่ายภาพต่อเนื่อง 24 ภาพ โดยเฟรม 12 เฟรมแรกจะมีระยะโฟกัสที่เหมาะสมที่สุด (ตามที่ 3A พบ) และเฟรม 12 เฟรมสุดท้ายจะมีระยะโฟกัสต่ำสุด ประมาณเฟรมที่ 12 เลนส์เคลื่อนไหวทำให้ความคมชัดลดลง ในที่สุดความคมชัดจะคงที่เมื่อเลนส์เลื่อนไปยังตำแหน่งสุดท้าย คุณควรระบุ Flag การเคลื่อนไหวของเลนส์ในทุกเฟรมที่ความคมชัดอยู่ในระดับปานกลางไปจนถึงคมชัดในเฟรม 2-3 เฟรมแรกเมื่อเลนส์ไม่เคลื่อนไหวในระยะโฟกัสที่เหมาะสม และเฟรม 2-3 เฟรมสุดท้ายเมื่อเลนส์ไม่เคลื่อนไหวในระยะโฟกัสขั้นต่ำ เฟรมที่เลนส์เคลื่อนไหวนั้นไม่สำคัญ สิ่งที่ระบบจะตรวจสอบคือมีการยืนยัน Flag การเคลื่อนไหวเมื่อเลนส์เคลื่อนไหว

API ที่ทดสอบแล้ว:

ผ่าน: Flag การเคลื่อนไหวของเลนส์คือ 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 มีความคมชัดแตกต่างไปจากเฟรม 2-3 เฟรมแรกที่มีระยะโฟกัสเหมาะสมหรือเฟรม 2-3 เฟรมสุดท้ายที่มีระยะโฟกัสต่ำสุด

test_reprocess_edge_enhancement

ทดสอบว่าวิธีการประมวลผลอีกครั้งที่รองรับสำหรับการปรับปรุงขอบทำงานได้อย่างถูกต้องหรือไม่ ประมวลผลคำขอจับภาพด้วยโหมดขอบที่ประมวลผลใหม่ที่กำหนด และเปรียบเทียบโหมดต่างๆ ในการจับภาพกับโหมดขอบที่ประมวลผลใหม่ปิดอยู่

API ที่ทดสอบแล้ว:

ผ่าน: ความคมชัดของโหมดขอบต่างๆ ถูกต้อง HQ (โหมด 2) คมชัดกว่า OFF (โหมด 0) และการปรับปรุงระหว่างโหมดต่างๆ นั้นคล้ายกัน

test_reprocess_edge_enhancement_plot

test_reprocess_edge_enhancement_plot.png

scene4

ฉาก 4 ประกอบด้วยวงกลมสีดําบนพื้นหลังสีขาวภายในสี่เหลี่ยมจัตุรัส การทดสอบใน scene4 อาจไวต่อการจัดแนว ดังนั้นตั้งแต่เวอร์ชัน 15 เป็นต้นไป คุณจะใช้ check_alignment.py ในไดเรกทอรีเครื่องมือเพื่อเปิดใช้การตรวจสอบ DUT และการจัดแนวแผนภูมิได้

scene4

scene4

test_30_60fps_preview_fov_match

ทดสอบว่าวิดีโอตัวอย่าง 30 FPS และ 60 FPS มี FoV เดียวกัน การทดสอบจะจับภาพวิดีโอ 2 รายการ รายการหนึ่งเป็น 30 FPS และอีกรายการเป็น 60 FPS ระบบจะเลือกเฟรมตัวแทนจากแต่ละวิดีโอและวิเคราะห์เพื่อให้แน่ใจว่าการเปลี่ยนแปลง FoV ในวิดีโอ 2 รายการอยู่ภายในข้อกำหนด ทดสอบว่าสัดส่วนภาพของวงกลมยังคงเดิม จุดศูนย์กลางของวงกลมยังคงอยู่ และรัศมีของวงกลมยังคงเดิม

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพไม่ยืด ตรงกลางของรูปภาพไม่แตกต่างกันเกิน 3% และการเปลี่ยนแปลงสัดส่วนภาพสูงสุดระหว่างวิดีโอ 30 FPS กับ 60 FPS ไม่เกิน 7.5%

กลไกที่ทำงานไม่สำเร็จ:

  • วงกลมจากวิดีโอ 30 FPS มีขนาดใหญ่กว่าวงกลมจากวิดีโอ 60 FPS อย่างเห็นได้ชัด
  • วงกลมในรูปภาพที่จับภาพถูกบิดเบือนโดยไปป์ไลน์การประมวลผล
  • วงกลมในรูปภาพที่จับภาพถูกครอบตัดเนื่องจากสัดส่วนภาพสุดโต่ง คำขอจับภาพที่ลดความสูงหรือความกว้างของรูปภาพ
  • วงกลมในรูปภาพที่ถ่ายมีแสงสะท้อนตรงกลางและดูเหมือนว่าไม่ได้เต็มวงกลม

test_aspect_ratio_and_crop

ทดสอบว่ารูปภาพบิดเบี้ยวหรือถูกครอบตัดโดยไม่คาดคิดในไปป์ไลน์รูปภาพหรือไม่ ถ่ายภาพวงกลมในรูปภาพทุกรูปแบบ ยืนยันว่าวงกลมไม่บิดเบี้ยว วงกลมไม่เคลื่อนออกจากจุดศูนย์กลางของรูปภาพ และวงกลมไม่เปลี่ยนขนาดอย่างไม่ถูกต้องเมื่อใช้สัดส่วนภาพหรือความละเอียดที่แตกต่างกัน

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพไม่ยืดออก ส่วนกลางของรูปภาพไม่แตกต่างกันเกิน 3% และรักษา FoV (มุมมอง) สูงสุดที่เป็นไปได้

กลไกที่ทำงานไม่สำเร็จ:

  • กล้องไม่ได้อยู่ในแนวเดียวกับวงกลมที่แสดงบนแท็บเล็ตตรงกลางของฉากที่จับภาพ
  • วงกลมในรูปภาพที่จับภาพถูกบิดเบือนโดยไปป์ไลน์การประมวลผล
  • รูปภาพที่มีความละเอียดต่ำได้รับการครอบตัด 2 ครั้งในไปป์ไลน์รูปภาพ ซึ่งทำให้ FoV ของรูปภาพความละเอียดสูงและต่ำแตกต่างกัน
  • วงกลมในรูปภาพที่จับภาพถูกครอบตัดเนื่องจากสัดส่วนภาพสุดโต่ง คำขอจับภาพที่ลดความสูงหรือความกว้างของรูปภาพ
  • วงกลมในรูปภาพที่ถ่ายมีแสงสะท้อนตรงกลางและดูเหมือนว่าไม่ได้เต็มวงกลม

test_multi_camera_alignment

ทดสอบพารามิเตอร์การปรับเทียบกล้องที่เกี่ยวข้องกับการวางตำแหน่งกล้องสำหรับระบบที่มีกล้องหลายตัว ใช้กล้องย่อยจริงแบบหลายกล้องเพื่อถ่ายภาพด้วยกล้องจริง 1 ตัว ค้นหาจุดศูนย์กลางของวงกลม โปรเจ็กต์จุดศูนย์กลางวงกลมไปยังพิกัดโลกสำหรับกล้องแต่ละตัว เปรียบเทียบความแตกต่างระหว่างจุดศูนย์กลางของวงกลมของกล้องในพิกัดโลก โปรเจ็กต์พิกัดโลกกลับเป็นพิกัดพิกเซลและเปรียบเทียบกับต้นฉบับเพื่อตรวจสอบความถูกต้อง เปรียบเทียบขนาดของวงกลมเพื่อดูว่าความยาวโฟกัสของกล้องแตกต่างกันหรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: ศูนย์กลางและขนาดของวงกลมตรงตามที่คาดไว้ในรูปภาพที่ฉายเมื่อเทียบกับรูปภาพที่ถ่ายโดยใช้ข้อมูลการปรับเทียบกล้องและความยาวโฟกัส

กลไกที่ทำงานไม่สำเร็จ:

  • LENS_INTRINSIC_CALIBRATION, LENS_POSE_TRANSLATION หรือ LENS_POSE_ROTATION คือค่าการออกแบบ ไม่ใช่ข้อมูลการปรับเทียบจริง
  • ระบบกล้องไม่เหมาะกับการตั้งค่าการทดสอบ เช่น การทดสอบระบบกล้องมุมกว้างและมุมกว้างพิเศษด้วยแท่นทดสอบ RFoV ดูข้อมูลเพิ่มเติมได้ที่คำถามที่พบบ่อยเกี่ยวกับ ITS-in-a-box ของกล้อง 1

test_preview_aspect_ratio_and_crop

การทดสอบนี้คล้ายกับการทดสอบ test_aspect_ratio_and_crop สําหรับภาพนิ่ง โดยจะตรวจสอบรูปแบบตัวอย่างที่รองรับเพื่อให้แน่ใจว่าเฟรมตัวอย่างไม่ได้ยืดหรือครอบตัดอย่างไม่เหมาะสม ตรวจสอบว่าสัดส่วนภาพของวงกลมไม่เปลี่ยนแปลง รูปภาพที่ครอบตัดจะวางวงกลมไว้ตรงกลางเฟรม และขนาดของวงกลมจะไม่เปลี่ยนแปลงสำหรับรูปแบบคงที่หรือความละเอียดที่แตกต่างกัน (การตรวจสอบมุมมอง)

API ที่ทดสอบแล้ว:

ผ่าน: รูปภาพไม่ยืด ตรงกลางของรูปภาพไม่แตกต่างกันเกิน 3% และรักษา FoV (มุมมอง) สูงสุดที่เป็นไปได้

test_preview_stabilization_fov

ตรวจสอบขนาดตัวอย่างที่รองรับเพื่อให้แน่ใจว่ามีการครอบตัด FoV อย่างเหมาะสม การทดสอบจะบันทึกวิดีโอ 2 รายการ รายการหนึ่งมีระบบกันภาพสั่นในตัวอย่าง ON และอีกรายการหนึ่งมีระบบกันภาพสั่นในตัวอย่าง OFF ระบบจะเลือกเฟรมที่แสดงถึงลักษณะของวิดีโอแต่ละรายการ และวิเคราะห์เพื่อให้แน่ใจว่าการเปลี่ยนแปลง FoV ในวิดีโอ 2 รายการนั้นเป็นไปตามข้อกำหนด

API ที่ทดสอบแล้ว:

ผ่าน: อัตราส่วนภาพวงกลมคงที่ ตำแหน่งศูนย์กลางของวงกลมคงที่ และขนาดของวงกลมเปลี่ยนแปลงไม่เกิน 20%

test_video_aspect_ratio_and_crop

ถ่ายวิดีโอวงกลมภายในสี่เหลี่ยมจัตุรัสในวิดีโอทุกรูปแบบ ดึงข้อมูลเฟรมหลัก และตรวจสอบว่าอัตราส่วนของวงกลมไม่เปลี่ยนแปลง รูปภาพที่ครอบตัดไว้ยังคงมีวงกลมอยู่ตรงกลาง และขนาดของวงกลมไม่เปลี่ยนแปลงสำหรับรูปแบบคงที่หรือความละเอียดที่แตกต่างกัน (การตรวจสอบมุมมอง)

API ที่ทดสอบแล้ว:

ผ่าน: เฟรมวิดีโอไม่ยืด ตรงกลางของเฟรมไม่แตกต่างกันเกิน 3% และรักษา FoV (มุมมอง) สูงสุดที่เป็นไปได้

scene5

ฉาก 5 ต้องใช้ฉากสีเทาที่มีแสงสม่ำเสมอ ซึ่งทำได้โดยใช้แผ่นกระจายแสงวางไว้บนเลนส์กล้อง เราขอแนะนำให้ใช้แผ่นกระจายแสงต่อไปนี้ www.edmundoptics.com/optics/window-diffusers/optical-diffusers/opal-diffusing-glass/46168

ในการเตรียมฉาก ให้ใส่แผ่นกระจายแสงไว้ด้านหน้ากล้องและเล็งกล้องไปยังแหล่งแสงที่มีค่าประมาณ 2, 000 ลักซ์ รูปภาพที่จับภาพสำหรับฉาก 5 ต้องให้แสงแบบกระจายโดยไม่มีองค์ประกอบที่เห็นได้ชัด ต่อไปนี้เป็นตัวอย่างรูปภาพ

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

ฉาก 6 คือตารางวงกลมเล็กๆ ที่มีสี่เหลี่ยมจัตุรัสที่มุมหนึ่งเพื่อระบุการวางแนว วงกลมเล็กๆ มีไว้เพื่อทดสอบฟังก์ชันการซูมในขอบเขตที่กว้าง การทดสอบใน scene6 อาจไวต่อการจัดแนว ดังนั้นตั้งแต่เวอร์ชัน 15 เป็นต้นไป คุณจะใช้ check_alignment.py ในไดเรกทอรีเครื่องมือเพื่อเปิดใช้การตรวจสอบ DUT และการจัดแนวแผนภูมิได้

scene6

scene6

test_in_sensor_zoom

ทดสอบลักษณะการทำงานของฟีเจอร์การซูมในเซ็นเซอร์ของกล้อง ซึ่งจะสร้างรูปภาพ RAW ที่ครอบตัด

เมื่อตั้งค่า Use Case สตรีมเป็น CROPPED_RAW การทดสอบจะจับภาพ 2 รูปในช่วงการซูม ได้แก่ รูปภาพ RAW มุมมองเต็ม (FoV) และรูปภาพ RAW ที่ครอบตัด การทดสอบจะแปลงรูปภาพเป็นอาร์เรย์ RGB, ปรับขนาดรูปภาพ RAW ที่ครอบตัดขนาดเต็มให้เล็กลงเป็นขนาดที่ SCALER_RAW_CROP_REGION รายงาน และคำนวณค่าเฉลี่ยความคลาดเคลื่อนกำลังสอง (RMS) 3 มิติระหว่างรูปภาพ 2 รูป

API ที่ทดสอบแล้ว:

ผ่าน: ผลต่างค่าเฉลี่ยกำลังสองของรูท (RMS) 3 มิติระหว่างรูปภาพ RAW ที่ครอบตัดและปรับขนาดลงกับรูปภาพ RAW มุมมองเต็มน้อยกว่าเกณฑ์ที่กำหนดในการทดสอบ

test_zoom

ทดสอบลักษณะการซูมของกล้อง ถ่ายภาพในช่วงการซูม และตรวจสอบว่าวงกลมมีขนาดใหญ่ขึ้นเมื่อกล้องซูมเข้าหรือไม่ สำหรับแต่ละรูปแบบ (YUV, JPEG) ระบบจะใช้เซสชันการจับภาพด้วยกล้องเดียวกันเพื่อรวม 3A และทำการจับภาพ

API ที่ทดสอบแล้ว:

ผ่าน: ขนาดสัมพัทธ์ของวงกลมที่จับภาพได้ถูกต้องตามอัตราส่วนการซูมที่ต้องการเพื่อให้แน่ใจว่ากล้องซูมอย่างถูกต้อง

test_zoom

test_zoom เพื่อหาเส้นขอบของวงกลมที่อยู่ใกล้กับจุดศูนย์กลางมากที่สุด

test_low_latency_zoom

ทดสอบลักษณะการซูมที่มีเวลาในการตอบสนองต่ำของกล้อง ถ่ายภาพในช่วงการซูมด้วย android.control.settingsOverride = 1 (SETTINGS_OVERRIDE_ZOOM) และตรวจสอบว่าวงกลมในรูปภาพเอาต์พุตตรงกับอัตราส่วนการซูมในข้อมูลเมตาของการจับภาพหรือไม่ ระบบจะใช้เซสชันการจับภาพกล้องเดียวกันเพื่อรวม 3A และทำการจับภาพ

API ที่ทดสอบแล้ว:

ผ่าน: ขนาดสัมพัทธ์ของวงกลมที่จับภาพนั้นถูกต้องตามข้อมูลเมตาของผลลัพธ์อัตราส่วนการซูม

test_preview_video_zoom_match

ทดสอบว่าขณะบันทึกและซูม ตัวอย่างวิดีโอและเอาต์พุตวิดีโอจะแสดงและบันทึกเอาต์พุตเดียวกัน คำนวณขนาดของวงกลมที่อยู่ใกล้กับศูนย์กลางมากที่สุดในอัตราส่วนการซูมต่างๆ และตรวจสอบว่าขนาดของวงกลมเพิ่มขึ้นเมื่ออัตราส่วนการซูมเพิ่มขึ้นหรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: ขนาดสัมพัทธ์ของวงกลมที่จับภาพไว้ถูกต้องตามสัดส่วนการซูมที่ขอในวิดีโอและตัวอย่าง

VGA_640x480_key_frame.png

VGA_640x480_key_frame.png (ก่อนซูม)

preview_640x480_key_frame.png

preview_640x480_key_frame.png (ก่อนซูม)

VGA_640x480_key_frame_zoomed.png

VGA_640x480_key_frame.png (หลังจากซูม)

preview_640x480_key_frame_zoomed.png

preview_640x480_key_frame.png (หลังจากซูม)

test_preview_zoom

ทดสอบว่าอัตราส่วนการซูมของเฟรมตัวอย่างแต่ละเฟรมตรงกับข้อมูลเมตาการจับภาพที่สอดคล้องกัน การทดสอบจะจับเฟรมตัวอย่างในช่วงการซูมและค้นหาเส้นขอบของวงกลมที่อยู่ใกล้กับจุดศูนย์กลางมากที่สุด จากนั้นระบบจะตรวจสอบว่าวงกลมที่เลือกนั้นใหญ่ขึ้นและศูนย์กลางของวงกลมนั้นเคลื่อนออกจากศูนย์กลางของรูปภาพเมื่อกล้องซูมเข้า

API ที่ทดสอบแล้ว:

ผ่าน: ขนาดสัมพัทธ์ของวงกลมที่เลือกถูกต้องสำหรับอัตราส่วนการซูมที่รายงานของผลการจับภาพที่สอดคล้องกันสำหรับเฟรมตัวอย่างทั้งหมด ระยะห่างสัมพัทธ์ของวงกลมที่เลือกจากจุดศูนย์กลางของภาพจะถูกต้องสำหรับอัตราส่วนการซูมที่รายงานของผลการจับภาพที่สอดคล้องกับเฟรมตัวอย่างทั้งหมด

test_zoom

รูปภาพ test_preview_zoom ที่แสดงวงกลมที่เลือกซึ่งอยู่ใกล้กับตรงกลางมากที่สุด

test_session_characteristics_zoom

ทดสอบช่วงอัตราส่วนการซูมสำหรับการกำหนดค่าเซสชันที่รองรับทั้งหมดที่แสดงใน CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION สําหรับการกําหนดค่าแต่ละรายการดังกล่าว หาก CameraDeviceSetup#isSessionConfigurationSupported แสดงผลเป็น "จริง" การทดสอบจะยืนยันว่าช่วงอัตราส่วนการซูมซึ่งแสดงผลใน CameraDeviceSetup#getSessionCharacteristics นั้นเข้าถึงได้

API ที่ทดสอบแล้ว:

ผ่าน: อัตราส่วนการซูมต่ำสุดและสูงสุดของ SessionConfiguration ที่รองรับแต่ละรายการใน CameraCharacteristics#INFO_SESSION_CONFIGURATION_QUERY_VERSION ใช้งานได้

scene7

Scene7 เป็นกรอบสี่เหลี่ยมผืนผ้าที่แบ่งออกเป็นสี่ส่วนเท่าๆ กัน โดยแต่ละส่วนจะเติมสีต่างกัน ตรงกลางสี่เหลี่ยมผืนผ้าคือแผนภูมิขอบเอียงสำหรับตรวจสอบความคมชัด เครื่องหมาย ArUco 4 ตัวจะจัดแนวกับมุมด้านนอกทั้ง 4 มุมของสี่เหลี่ยมผืนผ้าเพื่อช่วยในการหาพิกัดที่แม่นยำของเฟรมสี่เหลี่ยมผืนผ้าหลักในอัตราส่วนการซูมที่แตกต่างกัน

scene7

scene7

test_multi_camera_switch

การทดสอบนี้ยืนยันว่าระหว่างการบันทึกตัวอย่างด้วยอัตราส่วนการซูมที่แตกต่างกัน การสลับระหว่างเลนส์มุมกว้างพิเศษ (UW) กับเลนส์มุมกว้าง (W) จะให้ค่า RGB ที่คล้ายกัน

การทดสอบใช้อัตราส่วนการซูมที่แตกต่างกันภายในช่วงที่กําหนดไว้ล่วงหน้าเพื่อบันทึกตัวอย่างแบบไดนามิกและระบุจุดที่กล้องจริงมีการเปลี่ยนแปลง จุดนี้แสดงการครอสโอเวอร์จากเลนส์ UW ไปยังเลนส์ W

ระบบจะวิเคราะห์เฟรมที่บันทึกไว้ ณ และก่อนจุดตัดกันเพื่อหาค่าการเปิดรับแสงอัตโนมัติ (AE), สมดุลแสงขาวอัตโนมัติ (AWB) และโฟกัสอัตโนมัติ (AF)

การตรวจสอบ AE ช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลงความสว่างอยู่ในช่วงที่คาดไว้สำหรับทั้งรูปภาพจากเลนส์ UW และเลนส์ W การตรวจสอบ AWB จะยืนยันว่าอัตราส่วน R/G และ B/G อยู่ภายในค่าเกณฑ์สำหรับทั้งรูปภาพจากเลนส์ UW และเลนส์ W การตรวจสอบ AF จะประเมินค่าการประมาณความคมชัดตามขนาดของเส้นลาดเฉลี่ยระหว่างรูปภาพจากเลนส์ UW กับเลนส์ W

ขณะทำการทดสอบนี้ หากผลลัพธ์รบกวนด้วยเอฟเฟกต์ภาพซ้อน ให้ใช้แท็บเล็ตที่มีความละเอียดสูงขึ้นจากรายการแท็บเล็ตที่ผ่านการรับรอง ITS ของกล้อง

API ที่ทดสอบแล้ว:

ผ่าน: การตรวจสอบ AE และ AWB ต้องผ่านจึงจะถือว่าการทดสอบผ่าน ระบบจะใช้ผลการตรวจสอบ AF เพื่อบันทึกเท่านั้น เกณฑ์การตรวจสอบแต่ละรายการมีดังนี้

  • การตรวจสอบ AE: การเปลี่ยนแปลงความสว่างระหว่างรูปภาพจากเลนส์ UW กับเลนส์ W ต้องน้อยกว่า 4% สำหรับแพตช์สีทั้งหมด หากอุปกรณ์รองรับทั้ง ae_regions และ awb_regions หากระบบรองรับเฉพาะ ae_regions เฉพาะค่าของแพตช์สีเทียวเท่านั้นที่ตรงตามเกณฑ์
  • การตรวจสอบ AWB: ความแตกต่างระหว่างค่า R/G และ B/G สำหรับรูปภาพจากเลนส์ UW และเลนส์ W ต้องน้อยกว่า 3% สำหรับแพตช์สีเทา และต้องน้อยกว่า 10% สำหรับแพตช์สีอื่นๆ หากอุปกรณ์รองรับทั้ง ae_regions และ awb_regions
  • การตรวจสอบ AF: ความคมชัดของภาพที่ถ่ายด้วยเลนส์ W ต้องสูงกว่าความคมชัดของภาพที่ถ่ายด้วยเลนส์ UW

scene8

Scene8 คือเฟรมสี่เหลี่ยมผืนผ้าที่แบ่งออกเป็น 4 ภูมิภาคเท่าๆ กัน โดยแต่ละภูมิภาคจะมีภาพบุคคลที่ถ่ายโดยใช้การเปิดรับแสงที่แตกต่างกันหรือวางซ้อนกันด้วยเฉดสีที่ต่างกัน (เฉดสีน้ำเงิน การเปิดรับแสงที่เพิ่มขึ้น การเปิดรับแสงที่ลดลง เฉดสีเหลือง) เครื่องหมาย ArUco 4 ตัวจะจัดแนวให้ตรงกับมุมด้านนอกทั้ง 4 มุมของสี่เหลี่ยมผืนผ้าเพื่อให้ได้พิกัดที่แม่นยำของกรอบสี่เหลี่ยมผืนผ้าหลัก

scene8

scene8

test_ae_awb_regions

ทดสอบว่าค่า RGB และค่าความสว่างแตกต่างกันเมื่อบันทึกตัวอย่างในภูมิภาคต่างๆ ของการเปิดรับแสงอัตโนมัติ (AE) และการปรับสมดุลแสงสีขาวอัตโนมัติ (AWB)

การทดสอบจะบันทึกตัวอย่างวิดีโอ 8 วินาที โดยทำการวัดแสง AE และ AWB ในแต่ละส่วนเป็นเวลา 2 วินาที จากนั้นการทดสอบจะดึงเฟรมจากไฟล์บันทึกตัวอย่างของภูมิภาคแต่ละแห่ง และใช้เฟรมที่ดึงมาเพื่อดำเนินการตรวจสอบ AE และ AWB ต่อไปนี้

  • การตรวจสอบ AE: ยืนยันว่าเฟรมที่วัดแสงบริเวณที่มีการเปิดรับแสงลดลงมีค่า Luma เพิ่มขึ้นมากกว่า 1% เมื่อเทียบกับเฟรมที่วัดแสงบริเวณที่มีการเปิดรับแสงเพิ่มขึ้น วิธีนี้ช่วยให้มั่นใจว่ารูปภาพจะสว่างขึ้นเมื่อวัดแสงบริเวณที่มืด
  • การตรวจสอบ AWB: ยืนยันว่าอัตราส่วนของสีแดงต่อสีน้ำเงิน (ของค่า RGB เฉลี่ยของรูปภาพ) ในเฟรมที่มีพื้นที่การวัดสีน้ำเงินสูงกว่าเฟรมที่มีพื้นที่การวัดสีเหลืองมากกว่า 2% วิธีนี้ช่วยให้มั่นใจว่ารูปภาพมีค่า RGB ที่สมดุลเมื่อวัดแสงบริเวณสีเหลือง (อบอุ่น) หรือสีน้ำเงิน (เย็น)

API ที่ทดสอบแล้ว:

ผ่าน: ผ่านการตรวจสอบ AE และ AWB ทั้ง 2 รายการ

กลไกที่ทำงานไม่สำเร็จ:

  • การจับคู่เครื่องหมาย ArUco ทั้ง 4 รายการอย่างถูกต้องเป็นสิ่งจําเป็นสําหรับการทดสอบนี้ หากการตรวจจับครั้งแรกไม่สำเร็จ ระบบจะพยายามตรวจจับอีกครั้งโดยใช้รูปภาพเวอร์ชันขาวดํา รูปภาพสีเทาต่อไปนี้แสดงขั้นตอนการประมวลผลรอง

    เครื่องหมาย ArUco ไม่สอดคล้องกัน

scene9

Scene9 ประกอบด้วยวงกลมหลายพันวงที่มีขนาดและสีแบบสุ่มเพื่อสร้างฉากที่มีความซ้ำกันต่ำมากเพื่อทดสอบอัลกอริทึมการบีบอัด JPEG

scene9

scene9

test_jpeg_high_entropy

ทดสอบว่าการบีบอัด JPEG ของกล้องทำงานใน scene9 ที่มีเอนโทรปีสูงและตั้งค่าปัจจัยคุณภาพ JPEG เป็น 100% ระบบจะเพิ่มตัวคูณการซูมเพื่อให้แน่ใจว่าฉากที่แสดงบนแท็บเล็ตจะเต็มมุมมองของกล้อง

API ที่ทดสอบแล้ว:

ผ่าน: ไฟล์ JPEG ได้รับการบีบอัด เขียน และอ่านจากดิสก์อย่างถูกต้อง

test_jpeg_quality

ทดสอบคุณภาพการบีบอัด JPEG ของกล้อง ปรับคุณภาพ JPEG ทีละระดับผ่าน android.jpeg.quality และตรวจสอบว่าตารางการแปลงค่าเปลี่ยนแปลงอย่างถูกต้อง

API ที่ทดสอบแล้ว:

ผ่าน: เมทริกซ์การแปลงเชิงปริมาณลดลงเมื่อคุณภาพเพิ่มขึ้น (เมทริกซ์แสดงตัวคูณการหาร)

test_jpeg_quality

ค่าเฉลี่ยของเมทริกซ์ DQT ของค่าความสว่าง/ความต่างของสีของกล้องหลัง Pixel 4 เทียบกับคุณภาพ JPEG

test_jpeg_quality ไม่สําเร็จ

ตัวอย่างการทดสอบที่ไม่สําเร็จ

โปรดทราบว่าสำหรับรูปภาพคุณภาพต่ำมาก (jpeg.quality < 50) จะไม่มีการเพิ่มการบีบอัดในเมทริกซ์การแปลงเชิงปริมาณ

scene_video

ฉาก scene_video เป็นฉากวิดีโอ ประกอบด้วยวงกลม 4 สีที่เคลื่อนไหวไปมาด้วยอัตราเฟรมที่แตกต่างกันบนพื้นหลังสีขาว

scene_video

test_preview_frame_drop

ทดสอบว่าเฟรมเรตของตัวอย่างที่ขอได้รับการคงไว้ด้วยฉากแบบไดนามิก การทดสอบนี้จะทำงานกับกล้องทั้งหมดที่แสดงต่อแอปของบุคคลที่สาม

API ที่ทดสอบแล้ว:

ผ่าน: อัตราเฟรมของตัวอย่างอยู่ที่สูงสุดของช่วงอัตราเฟรมที่ขอ และค่าความผันผวนเฉลี่ยระหว่างเฟรมที่ต่อเนื่องกันน้อยกว่าความคลาดเคลื่อนสัมพัทธ์ที่ตั้งไว้ในการทดสอบ

scene_extensions

การทดสอบ scene_extensions เป็นการทดสอบส่วนขยายของกล้อง และต้องใช้ Camera ITS-in-a-Box เนื่องจากต้องมีการควบคุมสภาพแวดล้อมการทดสอบอย่างละเอียด นอกจากนี้ ต้องควบคุมการรั่วไหลของแสงทั้งหมด ซึ่งอาจต้องคลุมแท่นทดสอบ, DUT และแท็บเล็ตด้วยผ้าคลุม รวมถึงกำจัดแสงที่ลอดออกมาจากหน้าจอด้านหน้าของ DUT

scene_hdr

ฉาก scene_hdr ประกอบด้วยภาพบุคคลทางด้านซ้ายและคิวอาร์โค้ดที่มีคอนทราสต์ต่ำทางด้านขวา

scene_hdr

scene_hdr

test_hdr_extension

ทดสอบส่วนขยาย HDR ถ่ายภาพโดยเปิดและปิดใช้ส่วนขยาย แล้วตรวจสอบว่าส่วนขยายช่วยให้ตรวจพบคิวอาร์โค้ดได้ง่ายขึ้นหรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: ส่วนขยาย HDR จะลดจำนวนการเปลี่ยนแปลงคอนทราสต์ที่จําเป็นต่อการตรวจหาคิวอาร์โค้ดหรือลดการไล่ระดับสีในคิวอาร์โค้ด

scene_low_light

ฉาก scene_low_light ประกอบด้วยตารางสี่เหลี่ยมจัตุรัสที่มีเฉดสีเทาแตกต่างกันบนพื้นหลังสีดํา และตารางสี่เหลี่ยมจัตุรัสถูกกําหนดขอบด้วยเส้นสีแดง สี่เหลี่ยมจัตุรัสจะจัดเรียงในแนวโค้งฮิลเบิร์ต

scene_low_light

scene_low_light

test_night_extension

ทดสอบส่วนขยายกลางคืน ถ่ายภาพโดยเปิดใช้ส่วนขยาย และดำเนินการต่อไปนี้

  • ตรวจหาสี่เหลี่ยมจัตุรัส 20 รูป
  • คํานวณค่าความสว่างที่กําหนดขอบเขตโดยสี่เหลี่ยมจัตุรัสแต่ละรูป
  • คํานวณค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกตามการวางแนวตารางรูปโค้งฮิลเบิร์ต
  • คํานวณความแตกต่างของค่า Luma ของสี่เหลี่ยมจัตุรัสติดต่อกัน (เช่น สี่เหลี่ยมจัตุรัส 2 - สี่เหลี่ยมจัตุรัส 1) จนถึงสี่เหลี่ยมจัตุรัส 5 และ 6 (สี่เหลี่ยมจัตุรัส 6 - สี่เหลี่ยมจัตุรัส 5) และหาค่าเฉลี่ยของความแตกต่างที่คำนวณได้ 5 รายการ

API ที่ทดสอบแล้ว:

ผ่าน: ค่าความส่องสว่างโดยเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกต้องไม่ต่ำกว่า 85 และค่าความแตกต่างโดยเฉลี่ยของความส่องสว่างของสี่เหลี่ยมจัตุรัสติดต่อกันจนถึงสี่เหลี่ยมจัตุรัสที่ 5 และ 6 ต้องไม่ต่ำกว่า 17

ผังความสว่างต่อไปนี้แสดงลักษณะของผลการทดสอบที่ผ่าน

scene_low_light_night_pass

test_low_light_boost_extension

ทดสอบโหมด AE การเพิ่มแสงในสภาวะแสงน้อย หาก Camera2 รองรับโหมด AE เพิ่มแสงในที่แสงน้อย ระบบจะทำการทดสอบนี้สำหรับ Camera2 หากระบบรองรับส่วนขยายกล้องโหมดกลางคืนและส่วนขยายรองรับโหมด AE เพิ่มแสงต่ำ ระบบจะทำการทดสอบนี้กับส่วนขยายกล้องโหมดกลางคืนด้วย การทดสอบนี้จะตั้งค่าโหมด AE เป็นการเพิ่มคุณภาพในโหมดแสงน้อย นำเฟรมจากตัวอย่าง และดำเนินการต่อไปนี้

  • ตรวจหากล่อง 20 กล่อง
  • คํานวณค่าความสว่างที่กําหนดขอบเขตโดยแต่ละช่อง
  • คํานวณค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกตามการวางแนวตารางรูปโค้งฮิลเบิร์ต
  • คํานวณความแตกต่างของค่า Luma ของสี่เหลี่ยมจัตุรัสติดต่อกัน (เช่น สี่เหลี่ยมจัตุรัส 2 - สี่เหลี่ยมจัตุรัส 1) จนถึงสี่เหลี่ยมจัตุรัส 5 และ 6 (สี่เหลี่ยมจัตุรัส 6 - สี่เหลี่ยมจัตุรัส 5) และหาค่าเฉลี่ยของความแตกต่างที่คำนวณได้ 5 รายการ

API ที่ทดสอบแล้ว:

ผ่าน: ค่าความส่องสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกต้องไม่ต่ำกว่า 70 และค่าความแตกต่างของความส่องสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัสติดต่อกันจนถึงสี่เหลี่ยมจัตุรัสที่ 5 และ 6 ต้องไม่ต่ำกว่า 17

scene_flash

การทดสอบ scene_flash ต้องใช้ฉากที่มีแสงน้อยในช่องการผสานเซ็นเซอร์

test_auto_flash

ทดสอบว่าระบบเปิดแฟลชอัตโนมัติในฉากมืดสำหรับกล้องหลังและกล้องหน้า สำหรับกล้องหน้า ระบบแฟลชอัตโนมัติจะใช้หน้าจอเพื่อส่องสว่างฉาก ไม่ใช่หน่วยแฟลชจริง การทดสอบจะยืนยันว่าระบบเปิดแฟลชอัตโนมัติโดยตรวจสอบว่าตรงกลางของภาพการ์ดสว่างขึ้นเมื่อเปิดใช้แฟลชอัตโนมัติ หากต้องการเรียกให้แฟลชอัตโนมัติทำงาน คุณต้องปิดไฟในแท่นทดสอบ ซึ่งสามารถปิดไฟโดยอัตโนมัติด้วยตัวควบคุม Arduino ฉากต้องมืดสนิทเพื่อให้การทดสอบทำงานได้อย่างถูกต้อง ต้องติดตั้งแอป Jetpack Camera (JCA) ในอุปกรณ์ก่อนการทดสอบ แฟลชอัตโนมัติสำหรับกล้องหลังจะขึ้นอยู่กับสถานะ AE ที่จะทริกเกอร์ แต่แฟลชอัตโนมัติสำหรับกล้องหน้าจะไม่ขึ้นอยู่กับ AE และทริกเกอร์เสมอ

API ที่ทดสอบแล้ว:

ผ่าน: ตรงกลางของรูปภาพไทล์ที่เปิดใช้แฟลชอัตโนมัติสว่างกว่ารูปภาพฉากต้นฉบับสำหรับกล้องทั้งหมด

test_flash_strength

ทดสอบว่าการควบคุมความแรงของแฟลชในโหมด SINGLE ทำงานอย่างถูกต้อง

ยืนยันว่าหากอุปกรณ์รองรับการควบคุมความแรงของแฟลชระหว่างการใช้กล้องในโหมด SINGLE ความแรงของแฟลชจะเปลี่ยนไปตามระดับความแรงที่ขอ ยืนยันว่าการควบคุมความแรงแฟลชทำงานร่วมกับAE_MODES แบบต่างๆ ได้ ตัวอย่างเช่น หากโหมดการเปิดรับแสงอัตโนมัติเป็น ON หรือ OFF ระดับความแรงของแฟลชจะมีผลต่อความสว่าง และหากโหมดเป็น ON_AUTO_FLASH ระดับความแรงของแฟลชจะไม่มีผลต่อความสว่าง หากต้องการทำการทดสอบ คุณต้องปิดไฟในแท่นทดสอบ ไฟจะปิดโดยอัตโนมัติด้วยตัวควบคุม Arduino ฉากต้องมืดสนิทเพื่อให้การทดสอบทำงานได้อย่างถูกต้อง

API ที่ทดสอบแล้ว:

บัตร:

เมื่อโหมดการรับแสงอัตโนมัติเป็น ON หรือ OFF ความสว่างของส่วนต่างๆ ในรูปภาพจะเพิ่มขึ้นเมื่อระดับความแรงของแฟลชเพิ่มขึ้นจากไม่มีแฟลชเป็น FLASH_SINGLE_STRENGTH_MAX_LEVEL เมื่อโหมดการเปิดรับแสงอัตโนมัติเป็น ON_AUTO_FLASH ความแตกต่างของความสว่างของแพตช์รูปภาพจะอยู่ในเกณฑ์ที่ยอมรับได้เมื่อระดับความแรงของแฟลชเพิ่มขึ้นจากไม่มีแฟลชเป็น FLASH_SINGLE_STRENGTH_MAX_LEVEL

test_led_snapshot

ทดสอบว่าภาพนิ่งจาก LED ไม่ทำให้รูปภาพมีสีจัดหรือมีสี

การทดสอบนี้จะเพิ่มตัวควบคุมแสงลงในกล่องฟิวชันเซ็นเซอร์เพื่อควบคุมไฟ เมื่อตั้งค่าไฟเป็น OFF การทดสอบจะจับภาพโดยตั้งค่าโหมด AUTO_FLASH เป็น ON ในระหว่างการจับภาพนี้ การทดสอบจะเรียกใช้ลำดับก่อนการจับภาพโดยตั้งค่าทริกเกอร์ aePrecapture เป็น START และตั้งค่าความตั้งใจในการจับภาพเป็น Preview เพื่อจับภาพโดยใช้แฟลช

เนื่องจากภาพนี้มีฮอตสปอตที่โดดเด่นเนื่องจากแฟลช การทดสอบจะคํานวณค่าเฉลี่ยรูปภาพแฟลชของภาพทั้งหมดที่จับและตรวจสอบว่าค่าอยู่ในช่วง (68, 102) หรือไม่ หากต้องการตรวจสอบว่ารูปภาพมีการปรับสมดุลแสงอย่างเหมาะสมหรือไม่ การทดสอบจะคำนวณอัตราส่วน R/G และ B/G และตรวจสอบว่าอัตราส่วนอยู่ในช่วง 0.95 ถึง 1.05 หรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: อัตราส่วน R/G และ B/G อยู่ในช่วง 0.95 ถึง 1.05 ค่าเฉลี่ยของภาพแฟลชอยู่ในช่วง (68, 102)

test_preview_min_frame_rate

ทดสอบว่าอัตราเฟรมของตัวอย่างลดลงอย่างถูกต้องในฉากที่มืด หากต้องการให้การทดสอบนี้ทำงานอย่างถูกต้อง ผู้ควบคุมต้องปิดไฟในแท่นทดสอบหรือผู้ดำเนินการทดสอบต้องปิดไฟด้วยตนเอง

API ที่ทดสอบแล้ว:

ผ่าน: อัตราเฟรมของตัวอย่างอยู่ที่ระดับต่ำสุดของช่วงอัตราเฟรมที่ขอ และความแตกต่างระหว่างเฟรมน้อยกว่าความคลาดเคลื่อนสัมบูรณ์ที่ตั้งไว้ในการทดสอบ

test_torch_strength

ทดสอบว่าการควบคุมความแรงของแฟลชในโหมด TORCH ทำงานอย่างถูกต้อง

ยืนยันว่าหากอุปกรณ์รองรับการควบคุมความแรงของแฟลชระหว่างการใช้กล้องในโหมด TORCH ความแรงของไฟฉายจะเปลี่ยนไปตามระดับความแรงที่ขอ ยืนยันว่าการควบคุมความแรงแฟลชทำงานร่วมกับAE_MODES แบบต่างๆ ได้ ตัวอย่างเช่น หากโหมดการเปิดรับแสงอัตโนมัติเป็น ON หรือ OFF ระดับความแรงของแฟลชจะมีผลต่อความสว่าง และหากโหมดเป็น ON_AUTO_FLASH ระดับความแรงของแฟลชจะไม่มีผลต่อความสว่าง ยืนยันว่าความแรงของไฟฉายจะคงที่ตลอดระยะเวลาของพลุ โดยจำลองเซสชันการจับภาพวิดีโอ หากต้องการทำการทดสอบ คุณต้องปิดไฟในแท่นทดสอบ ซึ่งสามารถปิดไฟโดยอัตโนมัติด้วยตัวควบคุม Arduino ฉากต้องมืดสนิทเพื่อให้การทดสอบทำงานได้อย่างถูกต้อง

API ที่ทดสอบแล้ว:

บัตร:

เมื่อโหมดการรับแสงอัตโนมัติเป็น ON หรือ OFF ความสว่างของจุดแสงแฟลชจะเพิ่มขึ้นเมื่อระดับความแรงของแฟลชเพิ่มขึ้นจากไม่มีแฟลชเป็น FLASH_TORCH_STRENGTH_MAX_LEVEL เมื่อโหมดการเปิดรับแสงอัตโนมัติเป็น ON_AUTO_FLASH ความแตกต่างของความสว่างของแพตช์ภาพแบบต่อเนื่องจะอยู่ในช่วงที่ยอมรับได้เมื่อระดับความแรงของแฟลชเพิ่มขึ้นจากไม่มีแฟลชเป็น FLASH_TORCH_STRENGTH_MAX_LEVEL

sensor_fusion

การทดสอบการผสานเซ็นเซอร์ต้องใช้การเคลื่อนไหวของโทรศัพท์ในลักษณะที่เฉพาะเจาะจงหน้ารูปแบบตารางหมากรุกและเครื่องหมาย ArUco ตรวจสอบว่าแผนภูมิทดสอบติดตั้งอย่างราบเรียบเพื่อให้ได้ผลลัพธ์ที่ดีที่สุด แผนภูมิที่ไม่แบนจะส่งผลต่อการคำนวณการหมุนสําหรับการทดสอบหลายรายการ แผนภูมิต้องเต็มด้านหลังของกล่องฟิวชันเซ็นเซอร์โดยพิมพ์ขนาด 17"x17" (43x43 ซม.) การทดสอบ sensor_fusion สามารถทำแบบอัตโนมัติได้ด้วยกล่อง Sensor Fusion

แผนภูมิการผสานเซ็นเซอร์

แผนภูมิการผสานเซ็นเซอร์

แผนภูมิการรวมเซ็นเซอร์ใน Rig

แผนภูมิการผสานเซ็นเซอร์ที่เติมเต็มด้านหลังของกล่องการผสานเซ็นเซอร์

test_lens_intrinsic_calibration

ทดสอบว่าจุดศูนย์กลางออปติคอลของเลนส์มีการเปลี่ยนแปลงตามธรรมชาติเมื่อเลนส์เคลื่อนไหวเนื่องจากระบบกันภาพสั่นแบบออปติคัล (OIS) หากรองรับตัวอย่างจากเลนส์จริง ให้ทดสอบว่าจุดศูนย์กลางของแสงจากตัวอย่างจากเลนส์จริงเปลี่ยนแปลงเมื่อเลนส์เคลื่อนไหวเนื่องจากระบบกันภาพสั่นแบบออปติคัล (OIS) หรือไม่

API ที่ทดสอบแล้ว:

ผ่าน: ศูนย์กลางเชิงแสงของเลนส์มีการเปลี่ยนแปลงอย่างน้อย 1 พิกเซล หากระบบรองรับตัวอย่างจากเลนส์ ศูนย์กลางเชิงแสงของตัวอย่างจากเลนส์จะเปลี่ยนแปลงอย่างน้อย 1 พิกเซล

test_lens_intrinsic_calibration_example.png

ตัวอย่างผัง test_lens_intrinsic_calibration ที่แสดงการเปลี่ยนแปลงของจุดหลักเป็นพิกเซลสำหรับแต่ละเฟรม

test_multi_camera_frame_sync

ทดสอบว่าการประทับเวลาของเฟรมที่กล้องเชิงตรรกะจับได้อยู่ภายใน 10 มิลลิวินาทีโดยการคำนวณมุมของสี่เหลี่ยมจัตุรัสภายในตารางหมากรุกเพื่อระบุการประทับเวลา

API ที่ทดสอบแล้ว:

ผ่าน: มุมระหว่างรูปภาพจากกล้องแต่ละตัวไม่เปลี่ยนแปลงมากนักเมื่อหมุนโทรศัพท์

test_preview_distortion

ทดสอบว่าระบบแก้ไขการบิดเบือนในเฟรมตัวอย่างแต่ละเฟรมที่ถ่ายในระดับการซูมต่างๆ การทดสอบจะคำนวณจุดที่เหมาะสมสำหรับเฟรมแสดงตัวอย่างแต่ละเฟรมโดยอิงตามปัจจัยภายในและภายนอกของกล้อง ในภาพตัวอย่าง จุดที่เหมาะสมจะแสดงเป็นสีเขียว ส่วนจุดจริงจะแสดงเป็นสีแดง ระบบจะคํานวณข้อผิดพลาดในการบิดเบือนตามระยะทางพิกเซลค่าเฉลี่ยความคลาดเคลื่อนกำลังสอง (RMS) ระหว่างจุดจริงและจุดในอุดมคติ การใช้ไฮไลต์สีเขียวและสีแดงในรูปภาพมีไว้เพื่อตรวจหาพื้นที่ข้อผิดพลาดในการบิดเบือนด้วยสายตา

test_preview_distortion_example.jpg

รูปภาพกระดานหมากรุกที่มีจุดในอุดมคติเป็นสีเขียวและจุดจริงเป็นสีแดง

API ที่ทดสอบแล้ว:

ผ่าน: ข้อผิดพลาดในการบิดเบือนที่แปลงเป็นมาตรฐานของเฟรมตัวอย่างแต่ละเฟรมน้อยกว่าเกณฑ์ที่ตั้งไว้ในการทดสอบ

test_preview_stabilization

ทดสอบว่าวิดีโอตัวอย่างที่ระบบกันภาพสั่นหมุนน้อยกว่าไจโรสโคป

API ที่ทดสอบแล้ว:

ผ่าน: การหมุนมุมสูงสุดในเฟรมน้อยกว่า 70% ของการหมุนของไจโรสโคป

ต่อไปนี้คือตัวอย่างวิดีโอที่มีและไม่มีระบบกันภาพสั่น

  • ตัวอย่างวิดีโอที่มีระบบกันภาพสั่น

  • ตัวอย่างวิดีโอที่ไม่มีระบบกันภาพสั่น

test_sensor_fusion

ทดสอบความแตกต่างของการประทับเวลาระหว่างกล้องกับไจโรสโคปสําหรับแอปพลิเคชัน AR และ VR หมุนโทรศัพท์ 90 องศา 10 ครั้งต่อหน้ารูปแบบตารางหมากรุก การเคลื่อนไหวใช้เวลาไปกลับประมาณ 2 วินาที ระบบจะข้ามการทดสอบนี้หากไม่มี Gyroscope หรือไม่ได้เปิดใช้พารามิเตอร์REALTIMEแหล่งที่มาของการประทับเวลา

การทดสอบ test_sensor_fusion จะสร้างผังจำนวนหนึ่ง ผัง 2 รายการที่สําคัญที่สุดสำหรับการแก้ไขข้อบกพร่อง ได้แก่

  • test_sensor_fusion_gyro_events: แสดงเหตุการณ์ของไจโรสโคปสำหรับโทรศัพท์ในระหว่างการทดสอบ การเคลื่อนไหวในแนว x และ y หมายความว่าโทรศัพท์ไม่ได้ยึดกับเพลตยึดอย่างแน่นหนา ซึ่งจะลดโอกาสที่การทดสอบจะผ่าน จำนวนรอบในผังจะขึ้นอยู่กับความเร็วในการเขียนสำหรับการบันทึกเฟรม

    test_sensor_fusion_gyro_events.png

    test_sensor_fusion_gyro_events

  • test_sensor_fusion_plot_rotations: แสดงการจัดแนวของเครื่องวัดการหมุนและเหตุการณ์จากกล้อง ผังนี้ต้องแสดงการเคลื่อนไหวที่ตรงกันระหว่างกล้องกับไจโรสโคปเป็น +/-1 ms

    test_sensor_fusion_plot_rotations.png

    test_sensor_fusion_plot_rotations

API ที่ทดสอบแล้ว:

ผ่าน: การออฟเซ็ตการประทับเวลาของกล้องและไจโรสโคปน้อยกว่า 1 มิลลิวินาทีตามCDD ส่วน 7.3.9 เซ็นเซอร์ความเที่ยงตรงสูง [C-2-14]

กลไกที่ทำงานไม่สำเร็จ:

  • ข้อผิดพลาดของการออฟเซ็ต: ไม่ได้ปรับเทียบออฟเซ็ตของกล้องกับไจโรสโคปให้ถูกต้องภายใน +/-1 ms
  • เฟรมตก: ไปป์ไลน์ทำงานไม่เร็วพอที่จะจับภาพ 200 เฟรมอย่างต่อเนื่อง
  • ข้อผิดพลาดเกี่ยวกับซ็อกเก็ต: adb เชื่อมต่อกับ DUT ได้อย่างไม่น่าเชื่อถือเป็นเวลานานพอที่จะทำการทดสอบ
  • แผนภูมิไม่ได้ติดตั้งแบบวางราบ ผัง test_sensor_fusion_plot_rotations มีเฟรมที่การหมุนของไจโรสโคปและกล้องแตกต่างกันอย่างมากเมื่อกล้องหมุนผ่านส่วนต่างๆ ของแผนภูมิที่ไม่ราบ
  • กล้องไม่ได้ติดตั้งราบ ผัง test_sensor_fusion_gyro_events แสดงการเคลื่อนไหวในระนาบ X และ Y ปัญหานี้พบได้บ่อยในกล้องหน้า เนื่องจากกล้องหลังมักจะมีส่วนที่นูนขึ้นจากส่วนอื่นๆ ของโทรศัพท์ ซึ่งทำให้โทรศัพท์เอียงเมื่อยึดด้านหลังของโทรศัพท์เข้ากับเพลตยึด

test_video_stabilization

ทดสอบว่าวิดีโอที่ระบบกันภาพสั่นหมุนน้อยกว่าไจโรสโคป

API ที่ทดสอบแล้ว:

ผ่าน: การหมุนมุมสูงสุดในเฟรมน้อยกว่า 60% ของการหมุนของไจโรสโคป

ต่อไปนี้คือตัวอย่างวิดีโอที่มีและไม่มีระบบกันภาพสั่น

  • ตัวอย่างวิดีโอที่มีระบบกันภาพสั่น

  • ตัวอย่างวิดีโอที่ไม่มีระบบกันภาพสั่น

feature_combination

การทดสอบ feature_combination จะยืนยันว่าฟีเจอร์ทำงานได้อย่างถูกต้องเมื่อเปิดใช้ฟีเจอร์กล้องหลายรายการพร้อมกัน การทดสอบเหล่านี้ใช้รูปภาพตารางหมากรุกเดียวกันกับที่ใช้ในฉากการผสานเซ็นเซอร์

test_feature_combination

ทดสอบชุดค่าผสมทั้งหมดของสตรีมต่างๆ การปรับภาพตัวอย่างให้นิ่ง ช่วง FPS เป้าหมาย วิดีโอ HDR 10 บิต และ Ultra HDR ที่อุปกรณ์กล้องรองรับ การทดสอบนี้ใช้หน่วยความจำอย่างมาก เราจึงขอแนะนำให้ใช้โฮสต์ที่มี RAM อย่างน้อย 128 GB

สำหรับ Android 15 ขึ้นไป ไฟล์การกําหนดค่าจะมีช่อง log_feature_combo_support ซึ่งค่าเริ่มต้นคือ False เมื่อตั้งค่าช่อง log_feature_combo_support เป็น True การทดสอบจะเรียกใช้ชุดค่าผสมทั้งหมดของฟีเจอร์ที่รองรับ และบันทึกผลลัพธ์ลงในไฟล์โปรโตโดยไม่ถือว่าการทดสอบไม่ผ่าน สำหรับการทดสอบการปฏิบัติตามข้อกำหนด คุณต้องตั้งค่าช่อง log_feature_combo_support เป็น False

API ที่ทดสอบแล้ว:

ผ่าน: สำหรับชุดค่าผสมฟีเจอร์ที่รองรับแต่ละชุด ให้ทำดังนี้

  • สตรีมตัวอย่างจะมีความเสถียรหากเปิดการทำให้ภาพตัวอย่างมีความเสถียรไว้
  • อัตราเฟรมของตัวอย่างวิดีโออยู่ภายใน AE_TARGET_FPS_RANGE ที่กําหนดค่าไว้
  • พื้นที่สีของสตรีมตัวอย่างที่บันทึกไว้ตรงกับที่กําหนดไว้
  • การจับภาพ Ultra HDR มีแผนที่อัตราขยายที่ถูกต้อง