Ánh xạ độ sáng HDR theo tông màu tới phạm vi tương thích với SDR

Android 13 giới thiệu một ảnh tĩnh có thể định cấu hình cho nhà cung cấp thư viện có tên là libtonemap, xác định các hoạt động ánh xạ âm thanh và được dùng chung với quy trình SurfaceFlinger và triển khai Hardware Composer (HWC). Tính năng này cho phép OEM xác định và chia sẻ thông tin liên kết âm thanh trên màn hình các thuật toán giữa khung làm việc và nhà cung cấp, giảm bớt sự không nhất quán về giọng điệu ánh xạ.

Trước Android 13, tính năng liên kết âm báo dành riêng cho màn hình hoạt động không được chia sẻ giữa HWC, SurfaceFlinger và các ứng dụng. Tuỳ thuộc vào đối với nội dung HDR, điều này dẫn đến chất lượng hình ảnh không khớp, trong đó nội dung HDR được ánh xạ đến không gian đầu ra theo nhiều cách. Chiến dịch này có thể nhận biết được trong các tình huống như xoay màn hình, trong đó bố cục thay đổi về chiến lược giữa GPU và DPU cũng như sự khác biệt về quá trình kết xuất giữa TextureView và SurfaceView.

Trang này mô tả giao diện, tuỳ chỉnh và xác thực chi tiết của Thư viện libtonemap.

Giao diện đến thư viện ánh xạ tông màu

libtonemap thư viện này chứa các hoạt động triển khai dựa trên CPU và chương trình đổ bóng SkSL, có thể được được SurfaceFlinger cắm vào để kết hợp phần phụ trợ GPU và HWC cho tạo một bảng tra cứu ánh xạ âm (LUT). Điểm truy cập đến libtonemap là android::tonemap::getToneMapper(), trả về một đối tượng triển khai giao diện ToneMapper.

Giao diện ToneMapper hỗ trợ các chức năng sau:

• Tạo một LUT ánh xạ âm điệu

  Giao diện ToneMapper::lookupTonemapGain là một CPU phương thức triển khai chương trình đổ bóng được xác định trong libtonemap_LookupTonemapGain(). Chiến dịch này được sử dụng bởi các bài kiểm thử đơn vị trong khung, đồng thời có thể được các đối tác sử dụng để hỗ trợ tạo LUT ánh xạ sắc độ trong quy trình màu.

  libtonemap_LookupTonemapGain() lấy các giá trị màu theo giá trị tuyệt đối, không gian tuyến tính chưa chuẩn hoá, cả ở RGB tuyến tính và XYZ và trả về một số thực mô tả mức độ nhân của các màu đầu vào trong không gian tuyến tính.

• Tạo chương trình đổ bóng SkSL

  Giao diện ToneMapper::generateTonemapGainShaderSkSL() trả về một Chuỗi chương trình đổ bóng SkSL, dựa trên không gian dữ liệu nguồn và đích. Chương trình đổ bóng SkSL cắm vào quy trình triển khai Skia cho RenderEngine, thành phần kết hợp được tăng tốc GPU cho SurfaceFlinger. Chương trình đổ bóng cũng đã cắm vào libhwui, để có thể thực hiện hiệu quả ánh xạ âm thanh HDR--SDR cho TextureView. Vì chuỗi được tạo cùng dòng với các chương trình đổ bóng SkSL khác mà Skia sử dụng, chương trình đổ bóng phải tuân thủ các quy tắc sau:

  • Chuỗi chương trình đổ bóng phải có một điểm truy cập chứa phần tử Chữ ký float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz), trong đó linearRGB là giá trị của số nit tuyệt đối của pixel RGB trong không gian tuyến tính và xyz được linearRGB chuyển đổi thành XYZ.
  • Mọi phương thức trợ giúp mà chuỗi chương trình đổ bóng sử dụng đều phải được thêm tiền tố chuỗi libtonemap_ để các định nghĩa của chương trình đổ bóng khung không xung đột với nhau. Tương tự, dữ liệu đồng nhất đầu vào phải có tiền tố là in_libtonemap_.

• Tạo đồng phục SkSL

  Giao diện ToneMapper::generateShaderSkSLUniforms() trả về giá trị sau đây, cung cấp một siêu dữ liệu struct mô tả siêu dữ liệu của các HDR khác nhau chuẩn và điều kiện hiển thị:

  • Danh sách các loại đồng phục chịu sự ràng buộc của chương trình đổ bóng SkSL.

  • Các giá trị đồng nhất in_libtonemap_displayMaxLuminance và in_libtonemap_inputMaxLuminance. Các giá trị này được chương trình đổ bóng khung sử dụng khi điều chỉnh tỷ lệ đầu vào thành libtonemap và chuẩn hoá đầu ra dưới dạng có thể áp dụng.

  Hiện tại, quy trình tạo đồng phục không phụ thuộc vào đầu vào và không gian dữ liệu đầu ra.

Tuỳ chỉnh

Việc triển khai tham chiếu của thư viện libtonemap tạo ra kết quả chấp nhận được. Tuy nhiên, vì thuật toán ánh xạ tông màu được thành phần GPU sử dụng có thể khác với thuật toán đó được sử dụng trong cấu trúc DPU, việc sử dụng cách triển khai tham chiếu có thể khiến nhấp nháy trong một số trường hợp như ảnh động xoay. Tuỳ chỉnh có thể giải quyết các vấn đề về chất lượng ảnh của riêng nhà cung cấp như vậy.

Nhà sản xuất thiết bị gốc nên ghi đè phương thức triển khai libtonemap để xác định lớp con ToneMapper của riêng chúng do getToneMapper() trả về. Khi tuỳ chỉnh phương thức triển khai, đối tác cần thực hiện một trong những việc sau sau:

• Trực tiếp sửa đổi phương thức triển khai libtonemap.
• Xác định thư viện tĩnh của riêng mình, biên dịch thư viện dưới dạng một thư viện độc lập và thay thế tệp .a của thư viện libtonemap bằng tệp được tạo từ tệp tuỳ chỉnh thư viện của bạn.

Nhà cung cấp không cần sửa đổi mã hạt nhân nhưng nhiều nhà cung cấp phải trao đổi thông tin chi tiết về các thuật toán ánh xạ âm DPU để trong quá trình triển khai.

Xác nhận kết quả

Hãy làm theo các bước sau để xác thực quá trình triển khai của bạn:

1. Phát video HDR trên màn hình theo bất kỳ tiêu chuẩn HDR nào mà hệ thống hiển thị của bạn hỗ trợ, chẳng hạn như HLG, HDR10, HDR10+ hoặc DolbyVision.

2. Bật/tắt thành phần GPU để đảm bảo người dùng không nhận thấy hiện tượng nhấp nháy.

   Sử dụng lệnh adb sau đây để bật/tắt thành phần GPU:

   adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
   1 to force GPU composition>
   
   

Các vấn đề thường gặp

Các vấn đề sau có thể xảy ra với cách triển khai này:

• Băng tần xảy ra khi mục tiêu kết xuất mà thành phần GPU sử dụng thấp hơn so với giá trị thông thường của nội dung HDR. Ví dụ: tạo dải có thể xảy ra khi quá trình triển khai HWC hỗ trợ các định dạng 10 bit mờ cho HDR như RGBA1010102 hoặc P010, nhưng yêu cầu thành phần GPU ghi ở định dạng 8 bit như RGBA8888 để hỗ trợ alpha.

• Sự dịch chuyển màu tinh tế là do sự khác biệt về lượng tử nếu DPU hoạt động ở độ chính xác khác so với GPU.

Mỗi vấn đề này liên quan đến sự khác biệt về độ chính xác tương đối của phần cứng cơ bản. Một giải pháp thông thường là để đảm bảo có sự phối màu vào các đường dẫn có độ chính xác thấp hơn, nhờ đó giảm bớt sự chênh lệch về độ chính xác dễ nhận biết.