Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Á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 thư viện tĩnh do nhà cung cấp có thể định cấu hình có tên là libtonemap, xác định các thao tác ánh xạ tông màu và được chia sẻ với quy trình SurfaceFlinger và các cách triển khai Trình kết hợp phần cứng (HWC). Tính năng này cho phép các OEM xác định và chia sẻ các thuật toán ánh xạ tông màu màn hình giữa khung và nhà cung cấp, giảm sự không khớp trong ánh xạ tông màu.

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

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

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

Thư viện libtonemap chứa các phương thức triển khai dựa trên CPU và các chương trình đổ bóng SkSL. SurfaceFlinger có thể cắm các chương trình này để tạo thành phần phụ trợ GPU và HWC để tạo bảng tra cứu (LUT) ánh xạ tông màu. Điểm truy cập vào libtonemap là android::tonemap::getToneMapper(). Điểm này 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 bảng tra cứu màu ánh xạ tông màu

Giao diện ToneMapper::lookupTonemapGain là một cách triển khai CPU của chương trình đổ bóng được xác định trong libtonemap_LookupTonemapGain(). Các bài kiểm thử đơn vị trong khung này sử dụng thông tin này và các đối tác có thể sử dụng thông tin này để được hỗ trợ tạo LUT ánh xạ tông màu trong quy trình xử lý màu của họ.

libtonemap_LookupTonemapGain() nhận các giá trị màu trong không gian tuyến tính tuyệt đối, chưa được chuẩn hoá, cả trong RGB tuyến tính và trong XYZ, đồng thời trả về một số thực mô tả mức độ nhân 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, cho trước một nguồn và không gian dữ liệu đích. Chương trình đổ bóng SkSL được cắm vào quá trình triển khai Skia cho RenderEngine, thành phần tổng hợp được tăng tốc bằng GPU cho SurfaceFlinger. Chương trình đổ bóng này cũng được cắm vào libhwui, để có thể thực hiện hiệu quả việc ánh xạ tông màu từ HDR sang SDR cho TextureView. Vì chuỗi được tạo được nội tuyến hoá vào các chương trình đổ bóng SkSL khác mà Skia sử dụng, nên 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 nhập bằng chữ ký float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz), trong đó linearRGB là giá trị của nits tuyệt đối của các pixel RGB trong không gian tuyến tính và xyz là linearRGB được 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 phải có tiền tố là chuỗi libtonemap_ để các định nghĩa chương trình đổ bóng của khung không xung đột. Tương tự, các giá trị đồng nhất đầu vào phải có tiền tố là in_libtonemap_.
Tạo các đối tượng đồng nhất SkSL

Giao diện ToneMapper::generateShaderSkSLUniforms() sẽ trả về những nội dung sau, cho trước một siêu dữ liệu struct mô tả siêu dữ liệu từ các tiêu chuẩn HDR và điều kiện hiển thị khác nhau:
- Danh sách các đối tượng đồng nhất được liên kết bằng 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 các chương trình đổ bóng khung hình dùng khi mở rộng quy mô đầu vào thành libtonemap và chuẩn hoá đầu ra nếu có thể.
Hiện tại, quy trình tạo các thành phần đồng nhất không phụ thuộc vào không gian dữ liệu đầu vào và đầu ra.

Tuỳ chỉnh

Phương thứ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 mà thành phần GPU sử dụng có thể khác với thuật toán mà thành phần DPU sử dụng, nên việc sử dụng quy trình triển khai tham chiếu có thể gây ra hiện tượng nhấp nháy trong một số trường hợp, chẳng hạn như ảnh động xoay. Việc tuỳ chỉnh có thể giải quyết những vấn đề về chất lượng hình ảnh dành riêng cho nhà cung cấp như vậy.

Các OEM nên ghi đè việc triển khai libtonemap để xác định lớp con ToneMapper của riêng họ, được trả về theo getToneMapper(). Khi tuỳ chỉnh việc triển khai, các đối tác phải thực hiện một trong những việc sau:

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

Các nhà cung cấp không cần sửa đổi bất kỳ mã nhân nào, nhưng nhiều nhà cung cấp phải trao đổi thông tin chi tiết về thuật toán ánh xạ tông màu DPU để triển khai đúng cách.

Xác nhận kết quả

Hãy làm theo các bước sau để xác thực việc triển khai:

Phát video HDR trên màn hình có 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.
Bật/tắt thành phần GPU để đảm bảo không có hiện tượng nhấp nháy mà người dùng có thể nhận thấy.

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:

Hiện tượng phân dải xảy ra khi đích kết xuất mà thành phần GPU sử dụng có độ chính xác thấp hơn giá trị thông thường đối với nội dung HDR. Ví dụ: hiện tượng sọc màu có thể xảy ra khi một chế độ triển khai HWC hỗ trợ các định dạng 10 bit mờ cho HDR (chẳng hạn như RGBA1010102 hoặc P010), nhưng yêu cầu thành phần GPU ghi vào định dạng 8 bit (chẳng hạn như RGBA8888) để hỗ trợ kênh alpha.
Sự thay đổi màu sắc tinh tế là do sự khác biệt về lượng tử hoá nếu DPU hoạt động ở độ chính xác khác với GPU.

Mỗi vấn đề này đều 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ấy là đảm bảo có một bước làm giảm độ chính xác trong các đường dẫn có độ chính xác thấp hơn, giúp mọi khác biệt về độ chính xác ít được con người nhận thấy hơn.