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

หน้านี้แสดงรายการการทดสอบที่ครอบคลุมภายใต้ชุดทดสอบภาพ (ITS) ของกล้อง ซึ่งเป็นส่วนหนึ่งของโปรแกรมตรวจสอบชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ของ Android การทดสอบ 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_tele: การเปลี่ยนเลนส์เทเลโฟโต้
  • scene_flash: แฟลชอัตโนมัติ อัตราเฟรมขั้นต่ำ
  • scene_video: เฟรมตก
  • sensor_fusion: ออฟเซ็ตการจับเวลาของกล้องและไจโรสโคป
  • feature_combination: การรวมฟีเจอร์
  • scene_ip: ความสอดคล้องของรูปภาพระหว่างแอปกล้องเริ่มต้นกับแอปกล้อง Jetpack (JCA)

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

scene0

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

test_jitter

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

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

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

ในรูปภาพต่อไปนี้ ให้สังเกตช่วงแกน y ที่แคบ ความผันผวนนั้นมีค่าน้อยในผังนี้

แผนภูมิ test_jitter

รูปที่ 1 ผัง test_jitter

test_metadata

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

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

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

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

test_tonemap_curve

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

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

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

ตัวอย่างไฟล์ RAW ของ test_tonemap_curve

รูปที่ 3 ตัวอย่างไฟล์ RAW ของ test_tonemap_curve

ตัวอย่าง YUV ของ test_tonemap_curve

รูปที่ 4 ตัวอย่าง YUV ของ test_tonemap_curve

test_unified_timestamp

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

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

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

test_vibration_restriction

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

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

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

scene1_1

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

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

scene1 example

รูปที่ 5 แผนภูมิ Scene1 ขนาดเต็ม (ซ้าย) แผนภูมิที่ปรับขนาด 2/3 (ขวา)

test_ae_precapture_trigger

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

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

ผ่าน: AE บรรจบ

test_auto_vs_manual

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

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

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

ตัวอย่างอัตโนมัติของ test_auto_vs_manual

รูปที่ 6 ตัวอย่างอัตโนมัติของ test_auto_vs_manual

ตัวอย่างไวท์บาลานซ์ test_auto_vs_manual

รูปที่ 7 ตัวอย่างไวท์บาลานซ์ test_auto_vs_manual

ตัวอย่างการเปลี่ยนรูปแบบไวท์บาลานซ์ด้วยตนเอง test_auto_vs_manual

รูปที่ 8 ตัวอย่างการเปลี่ยนการปรับสมดุลแสงขาวด้วยตนเอง test_auto_vs_manual

test_black_white

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

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

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

test_black_white, ตัวอย่างสีดํา

รูปที่ 9 test_black_white ตัวอย่างสีดํา

ตัวอย่างการเปลี่ยนรูปแบบไวท์บาลานซ์ด้วยตนเอง test_auto_vs_manual

รูปที่ 10 test_black_white ตัวอย่างสีขาว

ตัวอย่างค่ามัธยฐานของผัง test_black_white

รูปที่ 11 test_black_white, ตัวอย่างค่าเฉลี่ยของผัง

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

รูปที่ 12 ตัวอย่างค่าเฉลี่ย test_burst_sameness_manual

test_burst_sameness_manual_plot_means

รูปที่ 13 test_burst_sameness_manual_plot_means

test_crop_region_raw

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

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

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

test_crop_region_raw comp raw crop example

รูปที่ 14. ตัวอย่างการครอบตัดดิบของ test_crop_region_raw comp

test_crop_region_raw comp raw full example

รูปที่ 15 ตัวอย่าง test_crop_region_raw comp raw full

ตัวอย่างการครอบตัด YUV ของ test_crop_region_raw comp

รูปที่ 16 ตัวอย่างการครอบตัด YUV ของ comp test_crop_region_raw

ตัวอย่าง test_crop_region_raw_yuv_full

รูปที่ 17 ตัวอย่าง YUV แบบเต็มของ test_crop_region_raw

test_crop_regions

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

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

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

test_ev_compensation

ทดสอบว่าระบบใช้ค่าชดเชยการเปิดรับแสง (EV) หรือไม่ การทดสอบประกอบด้วยส่วนพื้นฐานและส่วนขั้นสูง

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

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

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

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

test_ev_compensation_basic

รูปที่ 18 test_ev_compensation_basic

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

test_ev_compensation_advanced_plot_means

รูปที่ 19 test_ev_compensation_advanced_plot_means

test_exposure_x_iso

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

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

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

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

test_exposure_plot_means

รูปที่ 20 test_exposure_plot_means

test_exposure_mult=1.00.jpg

รูปที่ 21 test_exposure_mult=1.00

test_exposure_mult=64.00

รูปที่ 22 test_exposure_mult=64.00

test_latching

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

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

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

ตัวอย่างค่ามัธยฐานของผัง test_latching

รูปที่ 23 ตัวอย่างความหมายของผัง test_latching

test_latching i=00

รูปที่ 24 test_latching i=00

test_latching i=01

รูปที่ 25 test_latching i=01

test_latching i=02

รูปที่ 26 test_latching i=02

test_latching i=03

รูปที่ 27 test_latching i=03

test_latching i=04

รูปที่ 28 test_latching i=04

test_latching i=05

รูปที่ 29 test_latching i=05

test_latching i=06

รูปที่ 30 test_latching i=06

test_latching i=07

รูปที่ 31 test_latching i=07

test_latching i=08

รูปที่ 32 test_latching i=08

test_latching i=09

รูปที่ 33 test_latching i=09

test_latching i=10

รูปที่ 34. test_latching i=10

test_latching i=11

รูปที่ 35 test_latching i=11

test_latching i=12

รูปที่ 36 test_latching i=12

test_linearity

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

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

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

ตัวอย่างค่ามัธยฐานของผัง test_linearity

รูปที่ 37 ผัง test_linearity หมายถึงตัวอย่าง

test_locked_burst

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

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

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

test_locked_burst frame0 example

รูปที่ 38 ตัวอย่าง test_locked_burst frame0

ตัวอย่าง test_locked_burst frame1

รูปที่ 39 ตัวอย่าง test_locked_burst frame1

test_locked_burst_frame2

รูปที่ 40 ตัวอย่าง test_locked_burst frame2

scene1_2

scene 1_2 เป็นสำเนาของ scene 1_1 ที่ทำงานเหมือนกันทุกประการ โดยใช้โครงสร้างฉากย่อยเพื่อลดระยะเวลาที่ยาวนานของ scene 1

test_param_color_correction

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

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

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

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

ตัวอย่างค่ามัธยฐานของผัง test_param_color_correction

รูปที่ 41 ตัวอย่างค่าเฉลี่ยของผัง test_param_color_correction

ในรูปภาพต่อไปนี้ แกน x คือคําขอบันทึก ดังนี้ 0 = Unity, 1 = การเพิ่มประสิทธิภาพสีแดง และ 2 = การเพิ่มประสิทธิภาพสีน้ำเงิน

test_param_color_correction req=0 unity example

รูปที่ 42 ตัวอย่าง test_param_color_correction req=0 ใน Unity

test_param_color_correctness req=1 red boost example

รูปที่ 43 ตัวอย่างการเพิ่มสีแดง test_param_color_correctness req=1

test_param_color_correction req=2 blue boost example

รูปที่ 44 ตัวอย่าง test_param_color_correction req=2 blue boost

test_param_flash_mode

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

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

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

ตัวอย่าง test_param_flash_mode 1

รูปที่ 45 ตัวอย่าง test_param_flash_mode 1

ตัวอย่างการ์ด test_param_flash_mode 1

รูปที่ 46 ตัวอย่างไทล์เดียวของ test_param_flash_mode

ตัวอย่าง test_param_flash_mode_2

รูปที่ 47 ตัวอย่าง test_param_flash_mode 2

ตัวอย่างการ์ด test_param_flash_mode 2

รูปที่ 48 ตัวอย่าง 2 ไทล์ของ test_param_flash_mode

test_param_noise_reduction

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

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

ผ่าน: SNR จะแตกต่างกันไปตามโหมดการลดเสียงรบกวนต่างๆ และมีลักษณะการทำงานคล้ายกับกราฟต่อไปนี้

ตัวอย่าง SNR ของผัง test_param_noise_reduction

รูปที่ 49 ตัวอย่าง SNR ของผัง test_param_noise_reduction

0: ปิด, 1: เร็ว, 2: HQ, 3: MIN , 4: ZSL

test_param_noise_reduction high gain nr=0 example

รูปที่ 50 ตัวอย่าง test_param_noise_reduction high gain nr=0

test_param_noise_reduction high gain nr=1 example

รูปที่ 51 ตัวอย่าง test_param_noise_reduction high gain nr=1

test_param_noise_reduction high gain nr=2 example

รูปที่ 52 ตัวอย่าง test_param_noise_reduction high gain nr=2

test_param_noise_reduction high gain nr=3 example

รูปที่ 53 ตัวอย่าง test_param_noise_reduction high gain nr=3

ตัวอย่างการลดสัญญาณรบกวนที่มีอัตราขยายต่ำ test_param_noise_reduction

รูปที่ 54 ตัวอย่างการลดสัญญาณรบกวนที่มีอัตราขยายต่ำของ test_param_noise_reduction

test_param_shading_mode

ทดสอบว่ามีการใช้พารามิเตอร์ android.shading.mode

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

ผ่าน: ระบบจะสลับโหมดการแรเงาและแก้ไขแผนที่การแรเงาของเลนส์ตามที่คาดไว้

ตัวอย่างแผนที่การปรับแสงเลนส์ test_param_shading_mode โหมด 0 ลูป 0

รูปที่ 55 แผนที่แรเงาเลนส์ของ test_param_shading_mode ตัวอย่างโหมด 0 ลูป 0

ตัวอย่างแผนที่การปรับแสงเลนส์ test_param_shading_mode โหมด 1 ลูป 0

รูปที่ 56 แผนที่การแรเงาเลนส์ของ test_param_shading_mode ตัวอย่างโหมด 1 ลูป 0

ตัวอย่างแผนที่การแรเงาเลนส์ของ test_param_shading_mode, โหมด 2 ลูป 0

รูปที่ 57 แผนที่การแรเงาเลนส์ของ test_param_shading_mode ตัวอย่างโหมด 2 ลูป 0

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

รูปที่ 58 test_param_tonemap_mode ที่มี n=0

test_param_tonemap_mode with n=1

รูปที่ 59 test_param_tonemap_mode ที่มี n=1

test_post_raw_sensitivity_boost

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

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

ผ่าน: รูปภาพ RAW จะมืดขึ้นเมื่อการบูสต์เพิ่มขึ้น ขณะที่ความสว่างของรูปภาพ YUV คงที่

test_post_raw_sensitivity_boost raw s=3583 boost=0100 example

รูปที่ 60 ตัวอย่าง test_post_raw_sensitivity_boost raw s=3583 boost=0100

ตัวอย่าง test_post_raw_sensitivity_boost raw s=1792 boost=0200

รูปที่ 61 ตัวอย่าง test_post_raw_sensitivity_boost raw s=1792 boost=0200

test_post_raw_sensitivity_boost raw s=0896 boost=0400 example

รูปที่ 62 ตัวอย่าง test_post_raw_sensitivity_boost raw s=0896 boost=0400

test_post_raw_sensitivity_boost raw s=0448 boost=0800 example

รูปที่ 63 ตัวอย่าง test_post_raw_sensitivity_boost raw s=0448 boost=0800

test_post_raw_sensitivity_boost raw s=0224 boost=1600 example

รูปที่ 64 ตัวอย่าง test_post_raw_sensitivity_boost raw s=0224 boost=1600

ตัวอย่าง test_post_raw_sensitivity_boost raw s=0112 boost=3199

รูปที่ 65 ตัวอย่าง test_post_raw_sensitivity_boost raw s=0112 boost=3199

ตัวอย่างค่ามัธยฐานของผังข้อมูลดิบ test_post_raw_sensitivity_boost

รูปที่ 66 ตัวอย่างผังข้อมูลดิบของ test_post_raw_sensitivity_boost

ตัวอย่าง test_post_raw_sensitivity_boost YUV s=0112 boost=3199

รูปที่ 67 ตัวอย่าง test_post_raw_sensitivity_boost YUV s=0112 boost=3199

test_post_raw_sensitivity_boost YUV s=0448 boost=0800 example

รูปที่ 68 ตัวอย่าง test_post_raw_sensitivity_boost YUV s=0448 boost=0800

ตัวอย่าง test_post_raw_sensitivity_boost YUV s=0896 boost=0400

รูปที่ 69 ตัวอย่าง test_post_raw_sensitivity_boost YUV s=0896 boost=0400

ตัวอย่าง test_post_raw_sensitivity_boost YUV s=1792 boost=0200

รูปที่ 70 ตัวอย่าง test_post_raw_sensitivity_boost YUV s=1792 boost=0200

ตัวอย่าง test_post_raw_sensitivity_boost YUV s=3585 boost=0100

รูปที่ 71 ตัวอย่าง test_post_raw_sensitivity_boost YUV s=3585 boost=0100

test_post_raw_sensitivity_boost_yuv_plot_means

รูปที่ 72 test_post_raw_sensitivity_boost_yuv_plot_means

test_raw_exposure

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

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

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

ตัวอย่าง test_raw_exposure ISO=55

รูปที่ 73 ตัวอย่าง test_raw_exposure ISO=55

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

ตัวอย่าง test_raw_exposure ISO=132

รูปที่ 74 ตัวอย่าง test_raw_exposure ISO=132

ตัวอย่าง test_raw_exposure ISO=209

รูปที่ 75 ตัวอย่าง test_raw_exposure ISO=209

ตัวอย่าง test_raw_exposure ISO=286

รูปที่ 76 ตัวอย่าง test_raw_exposure ISOs=286

ตัวอย่าง test_raw_exposure ISO=363

รูปที่ 77 ตัวอย่าง test_raw_exposure ISO=363

test_raw_exposure_s=440

รูปที่ 78 ตัวอย่าง test_raw_exposure ISO=440

test_reprocess_noise_reduction

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

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

ผ่าน: FAST >= OFF, HQ >= FAST และ HQ >> OFF

ผัง SNR ทั่วไปเทียบกับโหมด NR

รูปที่ 79 ตัวอย่างผัง SNR เทียบกับโหมด NR ทั่วไป

test_tonemap_sequence

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

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

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

test_tonemap_sequence i=0 example

รูปที่ 80 ตัวอย่าง test_tonemap_sequence i=0

ตัวอย่าง test_tonemap_sequence i=1

รูปที่ 81 ตัวอย่าง test_tonemap_sequence i=1

ตัวอย่าง test_tonemap_sequence i=2

รูปที่ 82 ตัวอย่าง test_tonemap_sequence i=2

ตัวอย่าง test_tonemap_sequence i=3

รูปที่ 83 ตัวอย่าง test_tonemap_sequence i=3

ตัวอย่าง test_tonemap_sequence_i=4

รูปที่ 84 ตัวอย่าง test_tonemap_sequence i=4

ตัวอย่าง test_tonemap_sequence i=5

รูปที่ 85 ตัวอย่าง test_tonemap_sequence i=5

test_yuv_jpeg_all

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

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

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

ตัวอย่าง test_yuv_jpeg_all

รูปที่ 86 ตัวอย่าง test_yuv_jpeg_all

test_yuv_plus_dng

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

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

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

ตัวอย่าง test_yuv_plus_dng

รูปที่ 87 ตัวอย่าง test_yuv_plus_dng

scene1_3

scene 1_3 เป็นสำเนาของ scene 1_1 ที่ทำงานเหมือนกันทุกประการ โดยใช้โครงสร้างฉากย่อยเพื่อลดระยะเวลาที่ยาวนานของ scene 1

test_capture_result

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

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

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

test_capture_result_plot_lsc_auto_ch0

รูปที่ 88 test_capture_result_plot_lsc_auto_ch0

test_dng_noise_model

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

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

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

test_dng_noise_model_plog

รูปที่ 89 test_dng_noise_model_plog

test_jpeg

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

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

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

test_jpeg_fmt=jpg.jpg

รูปที่ 90 test_jpeg_fmt=jpg.jpg

test_jpeg=fmt=yuv.jpg

รูปที่ 91. test_jpeg=fmt=yuv.jpg

test_raw_burst_sensitivity

จับภาพชุดรูปภาพ RAW โดยเพิ่มอัตราขยายและวัดสัญญาณรบกวน จับภาพแบบ RAW เท่านั้นแบบต่อเนื่อง

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

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

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

test_raw_burst_sensitivity_variance

รูปที่ 92. test_raw_burst_sensitivity_variance

test_raw_sensitivity

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

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

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

test_raw_sensitivity_variance

รูปที่ 93. test_raw_sensitivity_variance

test_yuv_plus_jpeg

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

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

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

test_yuv_plus_jpeg ในรูปแบบ JPEG

รูปที่ 94 test_yuv_plus_jpeg ในรูปแบบ JPEG

test_yuv_plus_jpeg ในรูปแบบ YUV

รูปที่ 95 test_yuv_plus_jpeg ในรูปแบบ YUV

test_yuv_plus_raw

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

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

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

test_yuv_plus_raw_shading=1_raw.jpg

รูปที่ 96 test_yuv_plus_raw_shading=1_raw.jpg

test_yuv_plus_raw_shading=1_yuv.jpg

รูปที่ 97 test_yuv_plus_raw_shading=1_yuv.jpg

test_sensitivity_priority

ทดสอบ CONTROL_AE_PRIORITY_MODE_SENSOR_SENSITIVITY_PRIORITY ในการตั้งค่า ISO ต่างๆ เพื่อยืนยันความสัมพันธ์ระหว่าง ISO ที่สูงขึ้นกับระดับสัญญาณรบกวนเพิ่มขึ้น

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

ผ่าน: ISO ที่สูงขึ้นทำให้ระดับสัญญาณรบกวนเพิ่มขึ้น

ทดสอบเกณฑ์การข้าม

ระบบจะข้ามการทดสอบ test_sensitivity_priority.py หากเป็นไปตามเกณฑ์ข้อใดข้อหนึ่งต่อไปนี้

test_exposure_time_priority

ทดสอบ CONTROL_AE_PRIORITY_MODE_SENSOR_EXPOSURE_TIME_PRIORITY กับเวลาการเปิดรับแสงที่หลากหลาย โดยตรวจสอบความสว่างที่เสถียรในช่วงที่ ISO สามารถชดเชยได้

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

ผ่าน: ความสว่างมีความเสถียร (ภายในความคลาดเคลื่อน) ตลอดระยะเวลาการเปิดรับแสงหาก ISO อยู่ภายในช่วงการชดเชย

ทดสอบเกณฑ์การข้าม

ระบบจะข้ามการทดสอบ test_exposure_time_priority หากเป็นไปตามเกณฑ์ข้อใดข้อหนึ่งต่อไปนี้

scene2_a

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

scene2_a example

รูปที่ 98 ตัวอย่าง 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

รูปที่ 99 test_effects_MONO

test_exposure_keys_consistent

การทดสอบนี้จะเปรียบเทียบค่าความสว่างเฉลี่ยของการจับภาพที่เปิดใช้ AE กับการจับภาพที่ปิดใช้ AE ที่ใช้พารามิเตอร์การเปิดรับแสง (ความไวแสง เวลาการเปิดรับแสง ระยะเวลาเฟรม การเพิ่มความไวแสงหลังการแปลง RAW) ด้วยตนเองซึ่งได้รับใน CaptureResult ของการจับภาพที่เปิดใช้ AE

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

ผ่าน: ความแตกต่างสัมพัทธ์ของค่าความสว่างระหว่างการจับภาพ 2 รายการน้อยกว่า 4 เปอร์เซ็นต์

test_format_combos

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

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

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

test_num_faces

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

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

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

ตัวอย่าง 1 รายการในโหมดการตรวจจับใบหน้า test_num_faces

รูปที่ 100 ตัวอย่างโหมดการตรวจจับใบหน้า test_num_faces 1

test_reprocess_uv_swap

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

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

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

test_reprocess_uv_swap

รูปที่ 101 ตัวอย่าง test_reprocess_uv_swap

scene2_b

test_preview_num_faces

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

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

ผ่าน: พบใบหน้า 3 ใบหน้าที่มีจุดสังเกตใบหน้าในกล่องขอบเขตใบหน้า

test_num_faces_fd_mode_1

รูปที่ 102 ตัวอย่างโหมดการตรวจจับใบหน้า test_num_faces 1

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

รูปที่ 103 ตัวอย่างโหมดการตรวจจับใบหน้า test_num_faces

test_jpeg_capture_perf_class

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

ผ่าน: ต้องมีความล่าช้าในการจับภาพ JPEG ของกล้อง 2 น้อยกว่า 1,000 ms สำหรับความละเอียด 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_preview_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 example

รูปที่ 104. ตัวอย่าง scene2_f

test_preview_num_faces

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

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

ผ่าน: พบใบหน้า 3 ใบหน้าที่มีจุดสังเกตใบหน้าในกล่องขอบเขตใบหน้า

test_num_faces_fd_mode_1

รูปที่ 105 ตัวอย่าง test_num_faces_fd_mode_1

scene2_g

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

scene2_g.png

รูปที่ 106 ตัวอย่าง scene2_g

test_preview_num_faces

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

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

ผ่าน: พบใบหน้า 3 ใบหน้าที่มีจุดสังเกตใบหน้าในกล่องขอบเขตใบหน้า

test_preview_num_faces

รูปที่ 107 ตัวอย่าง test_preview_num_faces

scene3

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

test_edge_enhancement

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

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

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

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

  • EDGE_MODE

test_edge_enhancement_edge=0

รูปที่ 108 ตัวอย่าง test_edge_enhancement edge=0

ตัวอย่าง test_edge_enhancement edge=1

รูปที่ 109 ตัวอย่าง test_edge_enhancement edge=1 (โหมดเร็ว)

ตัวอย่าง test_edge_enhancement edge=2

รูปที่ 110 ตัวอย่าง test_edge_enhancement edge=2 (โหมดคุณภาพสูง)

test_flip_mirror

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

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

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

ตัวอย่างแพตช์ฉาก test_flip_mirror

รูปที่ 111 ตัวอย่างแพตช์ฉาก test_flip_mirror

test_imu_drift

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

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

บัตร:

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

ตัวอย่างความคลาดเคลื่อนของไจโรสโคป test_imu_drift

รูปที่ 112 ตัวอย่างความคลาดเคลื่อนของไจโรสโคป test_imu_drift

ตัวอย่างความคลาดเคลื่อนของเวกเตอร์การหมุน test_imu_drift

รูปที่ 113 ตัวอย่างความคลาดเคลื่อนของเวกเตอร์การหมุน test_imu_drift

test_landscape_to_portrait

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

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

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

ตัวอย่าง test_landscape_to_portrait

รูปที่ 114 ตัวอย่าง test_landscape_to_portrait

test_lens_movement_reporting

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

ควรระบุ Flag การเคลื่อนไหวของเลนส์ในทุกเฟรมที่ความคมชัดอยู่ระหว่างปานกลางถึงคมชัดในเฟรมแรกๆ ที่เลนส์ไม่เคลื่อนไหวที่ระยะโฟกัสที่เหมาะสม และเฟรมสุดท้าย 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

รูปที่ 115 ตัวอย่างผัง test_reprocess_edge_enhancement

scene4

scene4 ประกอบด้วยวงกลมสีดําบนพื้นหลังสีขาวภายในสี่เหลี่ยมจัตุรัส

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

scene4 example

รูปที่ 116 ตัวอย่าง 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 คือค่าการออกแบบ ไม่ใช่ข้อมูลการปรับเทียบจริง
  • ระบบกล้องไม่เหมาะกับการตั้งค่าการทดสอบ เช่น การทดสอบระบบกล้องแบบกว้างและแบบ Ultra Wide ด้วยแท่นทดสอบ RFoV ดูข้อมูลเพิ่มเติมได้ที่คำถามที่พบบ่อยเกี่ยวกับ ITS-in-a-box ของกล้อง Q1

test_preview_aspect_ratio_and_crop

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

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

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

test_preview_stabilization_fov

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

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

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

test_video_aspect_ratio_and_crop

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

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

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

scene5

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

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

scene5 example

รูปที่ 117 ตัวอย่างการจับภาพ scene5

test_lens_shading_and_color_uniformity

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

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

ผ่าน: ที่รัศมีที่ระบุของรูปภาพ ค่าความแปรปรวนของค่าสีแดง-เขียวและน้ำเงิน-เขียวต้องน้อยกว่า 20% จึงจะผ่านการทดสอบ

scene6

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

scene6

รูปที่ 118 ตัวอย่าง scene6

test_in_sensor_zoom

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

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

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

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

test_zoom

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

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

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

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

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

test_low_latency_zoom

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

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

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

test_preview_video_zoom_match

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

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

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

HD_1280x720_key_frame.png

รูปที่ 120 HD_1280x720_key_frame.png (ก่อนซูม)

preview_1280x720_key_frame.png

รูปที่ 121 preview_1280x720_key_frame.png (ก่อนซูม)

HD_1280x720_key_frame_zoomed.png

รูปที่ 122 HD_1280x720_key_frame.png (หลังจากซูม)

preview_1280x720_key_frame_zoomed.png

รูปที่ 123 preview_1280x720_key_frame.png (หลังจากซูม)

test_preview_zoom

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

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

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

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

รูปที่ 124 รูปภาพ test_preview_zoom ที่แสดงเครื่องหมายที่เลือกซึ่งอยู่ใกล้กับจุดศูนย์กลางมากที่สุด

test_session_characteristics_zoom

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

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

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

scene7

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

scene7

รูปที่ 125 scene7

test_multi_camera_switch

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

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

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

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

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

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

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

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

test_multi_camera_switch_gray_uw_y

รูปที่ 126 แพตช์สีเทาที่ถ่ายด้วยเลนส์ UW

test_multi_camera_switch_gray_w_y

รูปที่ 127 แพตช์สีเทาที่ถ่ายด้วยเลนส์ W

scene8

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

scene8 example

รูปที่ 128 ตัวอย่าง 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 รายการ

test_ae_awb_regions_dark_region

รูปที่ 129 การวัดแสงเฟรมในพื้นที่มืดโดยเพิ่มการเปิดรับแสง

test_ae_awb_regions_light_region

รูปที่ 130 การวัดเฟรมบริเวณที่สว่างขึ้นโดยมีการเปิดรับแสงลดลง

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

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

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

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

test_color_correction_mode_cct

การทดสอบ COLOR_CORRECTION_MODE กับอุณหภูมิสีและสีต่างๆ โดยตรวจสอบการเปลี่ยนแปลงสัดส่วน RGB เทียบกับฉากการจับภาพ scene8

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

ผ่าน: อัตราส่วน RGB แสดงการเพิ่มขึ้นหรือลดลงที่คาดไว้เมื่อเทียบกับอุณหภูมิสีและสีที่เลือก

ทดสอบเกณฑ์การข้าม

ระบบจะข้ามการทดสอบ test_color_correction_mode_cct หากเป็นไปตามเกณฑ์ข้อใดข้อหนึ่งต่อไปนี้

scene9

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

scene9 example

รูปที่ 132 ตัวอย่าง scene9

test_jpeg_high_entropy

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

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

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

test_jpeg_quality

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

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

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

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

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

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

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

scene_video

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

รูปที่ 135 ตัวอย่าง scene_video

test_preview_frame_drop

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

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

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

scene_extensions

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

scene_hdr

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

scene_hdr

รูปที่ 136 ตัวอย่าง scene_hdr

test_hdr_extension

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

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

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

scene_low_light

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

ตัวอย่าง scene_low_light

รูปที่ 137 ตัวอย่าง scene_low_light

test_night_extension

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

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

สำหรับอุปกรณ์ที่ใช้ Android 16 ขึ้นไป คำขอจับภาพจะมีขอบเขตที่วัดได้ซึ่งสอดคล้องกับสี่เหลี่ยมผืนผ้าที่กั้นตารางสี่เหลี่ยมจัตุรัส การเพิ่มนี้จะเปลี่ยนเกณฑ์การผ่านเกณฑ์

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

บัตร:

  • สำหรับอุปกรณ์ที่ใช้ Android 16 ขึ้นไป ค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกต้องไม่ต่ำกว่า 80 และค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัสติดต่อกันจนถึงสี่เหลี่ยมจัตุรัสที่ 5 และ 6 ต้องไม่ต่ำกว่า 18.75
  • สำหรับอุปกรณ์ที่ใช้ Android 15 หรือต่ำกว่า ค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกต้องเท่ากับหรือมากกว่า 85 และค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัสติดต่อกันจนถึงสี่เหลี่ยมจัตุรัสที่ 5 และ 6 ต้องเท่ากับหรือมากกว่า 17

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

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

รูปที่ 138 ตัวอย่างภาพกลางคืนที่มีแสงน้อยที่ผ่านการทดสอบ

test_low_light_boost_extension

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

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

สำหรับอุปกรณ์ที่ใช้ Android 16 ขึ้นไป คำขอจับภาพจะมีขอบเขตที่วัดได้ซึ่งสอดคล้องกับสี่เหลี่ยมผืนผ้าที่กั้นตารางสี่เหลี่ยมจัตุรัส การเพิ่มนี้จะเปลี่ยนเกณฑ์การผ่านเกณฑ์

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

บัตร:

  • สำหรับอุปกรณ์ที่ใช้ Android 16 ขึ้นไป ค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกต้องไม่ต่ำกว่า 54 และค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัสติดต่อกันจนถึงสี่เหลี่ยมจัตุรัสที่ 5 และ 6 ต้องไม่ต่ำกว่า 17

  • สำหรับอุปกรณ์ที่ใช้ Android 15 หรือต่ำกว่า ค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัส 6 ช่องแรกต้องมากกว่าหรือเท่ากับ 70 และค่าความสว่างเฉลี่ยของสี่เหลี่ยมจัตุรัสติดต่อกันจนถึงสี่เหลี่ยมจัตุรัส 5 และ 6 ต้องมากกว่าหรือเท่ากับ 18

scene_tele

ข้อกำหนดสำคัญสำหรับการทดสอบ scene_tele คือระยะห่างของแผนภูมิต้องอย่างน้อยเท่ากับระยะโฟกัสขั้นต่ำของเลนส์เทเลโฟโต้ เนื่องจากระยะโฟกัสขั้นต่ำนี้อาจแตกต่างกันไปในแต่ละอุปกรณ์ คุณจึงต้องกำหนดค่าการตั้งค่าให้เหมาะกับกล้องเทเลโฟโต้แต่ละรุ่น

การตั้งค่า scene_tele อิงตามระยะโฟกัสของกล้องแบบไวด์และเทเล

รูปที่ 139 การตั้งค่า scene_tele ตามระยะโฟกัสของกล้องมุมกว้างและเทเล

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

scene6_tele

ฉาก scene6_tele ประกอบด้วยตารางกริดของตัวทำเครื่องหมาย ArUco บนพื้นหลังสีขาว

หากภาพ scene6_tele ที่ถ่ายในขาตั้งแบบโมดูลดูสว่างเกินไป ให้ถอดแผ่นด้านหน้าของขาตั้งแบบโมดูลออก

ถอดแท่นทดสอบ WFoV ออกจากส่วนขยายและถอดขายึดโทรศัพท์ออก

ถอดแท่นทดสอบ WFoV ออกจากส่วนขยายและถอดขายึดโทรศัพท์ออก

รูปที่ 140 ถอดแท่นทดสอบ WFoV ออกจากส่วนขยายและถอดขายึดโทรศัพท์ออก

remove_front_plate

รูปที่ 141 ถอดเพลตด้านหน้าออก

test_zoom_tele

ทดสอบลักษณะการซูมของกล้องจากเลนส์มุมกว้างเป็นเลนส์เทเลโฟโต้ การทดสอบนี้เหมือนกับ test_zoom แต่ทดสอบลักษณะการซูมกล้องจากเลนส์มุมกว้างเป็นเลนส์เทเลโฟโต้

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

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

test_preview_zoom_tele

ทดสอบลักษณะการซูมของกล้องสำหรับเฟรมตัวอย่างจากเลนส์มุมกว้างไปยังเลนส์เทเลโฟโต้ การทดสอบนี้เหมือนกับtest_preview_zoom แต่ทดสอบลักษณะการซูมกล้องสำหรับเฟรมตัวอย่างจากเลนส์มุมกว้างไปยังเลนส์เทเลโฟโต้

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

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

scene7_tele

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

test_multi_camera_switch_tele

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

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

ระบบจะวิเคราะห์เฟรมที่จับภาพ ณ และก่อนจุดตัดกันเพื่อหาค่า AE, AWB และ AF

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

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

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

  • การตรวจสอบ AE: การเปลี่ยนแปลงความสว่างระหว่างรูปภาพจากเลนส์ W กับเลนส์เทเลต้องน้อยกว่า 4%
  • การตรวจสอบ AWB: ในพื้นที่สี LAB ค่าเดลต้า C ระหว่างสีแดง-เขียวและน้ำเงิน-เขียวสำหรับเลนส์มุมกว้างและเทเลโฟโต้ต้องไม่เกิน 10
  • การตรวจสอบ AF: ความคมชัดของภาพเลนส์เทเลต้องสูงกว่าเลนส์มุมกว้าง

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 ไม่ทำให้รูปภาพมีสีจัดหรือมีสี

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

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

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

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

test_night_mode_indicator

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

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

  1. การเริ่มต้น: การทดสอบจะเริ่มต้น ItsSession และดึงข้อมูลพร็อพเพอร์ตี้กล้อง รวมถึงสร้างการเชื่อมต่อกับตัวควบคุมแสงสว่างด้วย
  2. เงื่อนไขการข้าม: ระบบจะข้ามการทดสอบหากอุปกรณ์ไม่รองรับระดับ API ที่จําเป็นหรือฟีเจอร์ตัวบ่งชี้โหมดกลางคืน
  3. เซสชัน Camera2:
    • การทดสอบจะเริ่มเซสชันการจับภาพตัวอย่างโดยใช้เซสชัน Camera2
    • ไฟจะเปิดขึ้นและจับเฟรมตัวอย่าง
    • การทดสอบยืนยันว่าตัวบ่งชี้โหมดกลางคืนอยู่ในสถานะ OFF
    • ระบบจะปิดไฟและจับเฟรมตัวอย่าง
    • การทดสอบยืนยันว่าตัวบ่งชี้โหมดกลางคืนอยู่ในสถานะ ON
  4. เซสชันส่วนขยายกล้อง:
    • การทดสอบจะทําตามขั้นตอนเดียวกับเซสชัน Camera2 ซ้ำ แต่ใช้เซสชัน CameraExtension ที่มีส่วนขยาย EXTENSION_NIGHT
  5. การล้างข้อมูล: การทดสอบจะปิด ItsSession และปล่อยตัวควบคุมแสง

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

บัตร:

  • เมื่อไฟเปิดอยู่ ไฟบอกสถานะโหมดกลางคืนควรอยู่ในสถานะ OFF
  • เมื่อไฟปิดอยู่ ตัวบ่งชี้โหมดกลางคืนควรอยู่ในสถานะ ON
  • มีผลกับทั้งเซสชัน Camera2 และ CameraExtension

test_preview_min_frame_rate

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

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

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

test_torch_strength

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

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

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

บัตร:

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

sensor_fusion

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

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

รูปที่ 142 แผนภูมิการผสานเซ็นเซอร์

แผนภูมิการรวมเซ็นเซอร์ในแท่นขุดเจาะ

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

test_lens_intrinsic_calibration

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

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

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

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

test_lens_intrinsic_calibration_example.png

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

test_multi_camera_frame_sync

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

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

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

test_preview_distortion

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

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

test_preview_distortion_example.jpg

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

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

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

test_preview_stabilization

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

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

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

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

รูปที่ 146 วิดีโอตัวอย่างที่มีการป้องกันภาพสั่นไหว

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

test_sensor_fusion

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

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

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

    ตัวอย่างเหตุการณ์ Gyroscope ของ test_sensor_fusion

    รูปที่ 148 ตัวอย่างเหตุการณ์ Gyroscope ของ test_sensor_fusion

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

    ตัวอย่างการหมุนผัง test_sensor_fusion

    รูปที่ 149 ตัวอย่างการหมุนผัง test_sensor_fusion

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

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

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

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

test_video_stabilization

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

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

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

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

รูปที่ 150 วิดีโอตัวอย่างที่มีการป้องกันภาพสั่นไหว

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

test_video_stabilization_jca

การทดสอบที่พบว่าวิดีโอที่ระบบกันภาพสั่นซึ่งบันทึกโดยใช้ JCA มีการบิดเบือนน้อยกว่าเมื่อใช้ตัววัดการหมุน ต้องติดตั้ง JCA ในอุปกรณ์ก่อนทำการทดสอบ

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

ผ่าน: การหมุนมุมสูงสุดของเฟรมที่ดึงมาจากวิดีโอที่บันทึกโดยใช้ JCA น้อยกว่า 70% ของการหมุนของไจโรสโคป

feature_combination

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

test_feature_combination

ทดสอบการผสมผสานสตรีมแบบต่างๆ, โหมดระบบกันภาพสั่น, ช่วง FPS เป้าหมาย, วิดีโอ HDR 10 บิต และ Ultra HDR ที่อุปกรณ์กล้องรองรับ

สำหรับ Android 16 ขึ้นไป การทดสอบจะเรียกใช้ชุดค่าผสมทั้งหมดของฟีเจอร์ที่รองรับ และบันทึกผลลัพธ์ลงในไฟล์โปรโต การยืนยันการทำงานผิดพลาดจะเรียกใช้เฉพาะสำหรับชุดค่าผสมของฟีเจอร์ที่ isSessionConfigurationSupported แสดงผลเป็น True

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

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

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

scene_ip

ใน Android 16 ขึ้นไป ฉาก scene_ip จะเปิดใช้การตรวจสอบความเท่าเทียมของรูปภาพระหว่างแอปกล้องเริ่มต้นกับแอปกล้อง Jetpack (JCA) เพื่อระบุความแตกต่างที่สำคัญระหว่างรูปภาพที่ถ่าย JCA จะจำลองการจับภาพของแอปโซเชียลมีเดียและแสดงรูปภาพพื้นฐานที่แอปโซเชียลมีเดียจะประมวลผลและปรับแต่ง

ข้อกำหนดในการตั้งค่าฮาร์ดแวร์

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

  • การทดสอบจะดำเนินการในกล้องรุ่นที่ 2 ITS-in-a-box
  • ใช้ตัวควบคุมแสงและเซอร์โวซึ่งเป็นส่วนหนึ่งของแท่นรุ่นที่ 2 เพื่อควบคุมสภาพแวดล้อมการทดสอบ
  • วางแผนภูมิฟีเจอร์ทดสอบไว้ในแท่น Gen2

test_chart_gen2

รูปที่ 152 ตัวอย่าง Gen2chart_sample

ทดสอบเกณฑ์การข้าม

ระบบจะข้ามการทดสอบ scene_ip หากเป็นไปตามเกณฑ์ข้อใดข้อหนึ่งต่อไปนี้

  • อุปกรณ์มี API ระดับแรก (first_api_level) ระดับ 35 หรือต่ำกว่า
  • อุปกรณ์ไม่ใช่โทรศัพท์ที่มีกล้องหลักด้านหน้าและด้านหลัง (เช่น แท็บเล็ตหรือทีวี)

test_default_jca_ip

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

  • FoV: ตรวจสอบว่าแอปกล้องเริ่มต้นและการจับภาพ JCA มี FoV เดียวกัน การตรวจสอบนี้ใช้ฟีเจอร์คิวอาร์โค้ดตรงกลางที่ดึงมาจากภาพแผนภูมิที่บันทึกไว้

  • ความสว่าง: ตรวจสอบว่าความแตกต่างของความสว่างที่วัดระหว่างแอปกล้องเริ่มต้นกับ JCA ไม่เกิน 10 การตรวจสอบนี้ใช้แพตช์ช่วงแบบไดนามิกสำหรับการวัดความสว่าง

  • สมดุลแสงสีขาว: ตรวจสอบว่าความแตกต่างของสมดุลแสงสีขาวระหว่างแอปกล้องเริ่มต้นกับ JCA ไม่เกิน 4 การตรวจสอบนี้ใช้แพตช์ช่วงแบบไดนามิกสำหรับการวัดความสว่าง

ผ่านส่วนพื้นฐาน: การทดสอบผ่านการตรวจสอบ FoV, ความสว่าง และสมดุลแสงสีขาว ใน Android 16 การทดสอบนี้ไม่บังคับ (NOT_YET_MANDATED)