Android 13 giới thiệu một thư viện tĩnh có thể định cấu hình cho nhà cung cấp có tên là libtonemap. Thư viện này 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 soạn phần cứng (HWC).
Tính năng này cho phép OEM xác định và chia sẻ các thuật toán ánh xạ tông màu cho 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à ứng dụng. Tuỳ thuộc vào đường 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, trong đó chiến lược kết hợp 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 chi tiết về việc tuỳ chỉnh và xác thực của thư viện libtonemap.
Giao diện cho thư viện ánh xạ tông màu
Thư viện libtonemap
chứa các cách triển khai được CPU hỗ trợ và các chương trình đổ bóng SkSL. Các chương trình này có thể được
SurfaceFlinger cắm vào để kết hợp phần phụ trợ GPU và HWC để
tạo bảng tra cứu ánh xạ tông màu (LUT). Điểm truy cập vào 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 khả năng sau:
Tạo LUT ánh xạ tông màu
Giao diện
ToneMapper::lookupTonemapGainlà một cách triển khai CPU của chương trình đổ bóng được xác định tronglibtonemap_LookupTonemapGain(). Giao diện này được các kiểm thử đơn vị trong khung sử dụng và đối tác có thể sử dụng để được hỗ trợ tạo LUT ánh xạ tông màu bên trong quy trình 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ả ở RGB tuyến tính và ở XYZ, đồng thời trả về một giá trị float 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 một không gian dữ liệu nguồn và đích. Chương trình đổ bóng SkSL được cắm vào cách triển khai Skia choRenderEngine, thành phần kết hợp được tăng tốc bằng GPU cho SurfaceFlinger. Chương trình đổ bóng cũng được cắm vàolibhwui, để có thể thực hiện ánh xạ tông màu từ HDR sang SDR một cách hiệu quả choTextureView. Vì chuỗi được tạo được đưa 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ó điểm truy cập với chữ ký
float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz), trong đólinearRGBlà giá trị của nits tuyệt đối của các pixel RGB trong không gian tuyến tính vàxyzlà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 biến đồng nhất đầu vào phải có tiền tố làin_libtonemap_.
- Chuỗi chương trình đổ bóng phải có điểm truy cập với chữ ký
Tạo các biến đồng nhất SkSL
Giao diện
ToneMapper::generateShaderSkSLUniforms()trả về những nội dung sau, cho một siêu dữ liệustructmô 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 biến đồng nhất được liên kết bởi một chương trình đổ bóng SkSL.
Các giá trị biến đồng nhất
in_libtonemap_displayMaxLuminancevàin_libtonemap_inputMaxLuminance. Các giá trị này được các chương trình đổ bóng của khung sử dụng khi mở rộng tỷ lệ đầu vào thànhlibtonemapvà chuẩn hoá đầu ra nếu có thể.
Hiện tại, quy trình tạo các biế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
Cách 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 cách 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 các vấn đề về chất lượng hình ảnh dành riêng cho nhà cung cấp như vậy.
OEM nên ghi đè cách triển khai libtonemap để
xác định lớp con ToneMapper của riêng họ. Lớp con này được getToneMapper() trả về.
Khi tuỳ chỉnh cách triển khai, đối tác dự kiến sẽ thực hiện một trong những việc sau:
- Sửa đổi trực tiếp cách triển khai
libtonemap. - Xác định thư viện tĩnh của riêng họ, biên dịch thư viện dưới dạng độc lập và thay thế tệp
.acủa thư việnlibtonemapbằng tệp được tạo từ thư viện tuỳ chỉnh của họ.
Nhà cung cấp không cần sửa đổi bất kỳ mã kernel nào, 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ạ 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 cách triển khai của bạn:
Phát video HDR trên màn hình của mọi tiêu chuẩn HDR mà hệ thống hiển thị của bạn hỗ trợ, chẳng hạn như HLG, HDR10, HDR10+ hoặc DolbyVision.
Chuyển đổi 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.
Sử dụng lệnh
adbsau để chuyển đổi 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 dải màu xảy ra khi mục tiêu 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 cho nội dung HDR. Ví dụ: hiện tượng dải màu có thể xảy ra khi một cách triển khai HWC hỗ trợ các định dạng 10 bit mờ đục 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 như RGBA8888 để hỗ trợ alpha.
Hiện tượng chuyển màu 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 tương đối về độ chính xác của phần cứng cơ bản. Một giải pháp khắc phục thường gặp là đảm bảo có bước làm mờ trong các đường dẫn có độ chính xác thấp hơn, giúp mọi sự khác biệt về độ chính xác ít được con người nhận thấy hơn.