Эта страница переведена с помощью Cloud Translation API.

Тональное преобразование яркости HDR в диапазон, совместимый с SDR

В Android 13 представлена настраиваемая поставщиком статическая библиотека под названием libtonemap , которая определяет операции отображения тонов и используется совместно с процессом SurfaceFlinger и реализациями Hardware Composer (HWC). Эта функция позволяет OEM-производителям определять и обмениваться алгоритмами отображения тонов дисплея между платформой и поставщиками, уменьшая несоответствие в отображении тонов.

До Android 13 операции тональной компрессии, специфичные для дисплея, не использовались HWC, SurfaceFlinger и приложениями. В зависимости от пути рендеринга для HDR-контента это приводило к несоответствию качества изображения, когда HDR-контент по-разному отображался в тональном пространстве выходного пространства. Это было заметно в таких сценариях, как поворот экрана, когда стратегия композиции меняется между графическим процессором и DPU, а также в различиях в поведении рендеринга между TextView и SurfaceView.

На этой странице описываются интерфейс, настройки и детали проверки библиотеки libtonemap .

Интерфейс к библиотеке тональной компрессии

Библиотека libtonemap содержит реализации на базе ЦП и шейдеры SkSL, которые можно подключить с помощью SurfaceFlinger для композиции серверной части графического процессора и с помощью HWC для создания таблицы преобразования тонов (LUT). Входной точкой в libtonemap является android::tonemap::getToneMapper() , который возвращает объект, который реализует интерфейс ToneMapper .

Интерфейс ToneMapper поддерживает следующие возможности:

Создайте LUT с тональным отображением
Интерфейс ToneMapper::lookupTonemapGain — это реализация шейдера, определенного в libtonemap_LookupTonemapGain() на процессоре. Это используется модульными тестами в рамках и может использоваться партнерами для помощи в создании LUT для отображения тонов внутри их цветового конвейера.
libtonemap_LookupTonemapGain() принимает значения цвета в абсолютном, ненормализованном линейном пространстве, как в линейном RGB, так и в XYZ, и возвращает число с плавающей запятой, описывающее, на сколько нужно умножить входные цвета в линейном пространстве.
Создайте шейдер SkSL
Интерфейс ToneMapper::generateTonemapGainShaderSkSL() возвращает строку шейдера SkSL, учитывая исходное и целевое пространство данных. Шейдер SkSL подключен к реализации Skia для RenderEngine , компонента композитинга с графическим ускорением для SurfaceFlinger. Шейдер также подключен к libhwui , так что преобразование тонов HDR в SDR может эффективно выполняться для TextureView . Поскольку сгенерированная строка встроена в другие шейдеры SkSL, используемые Skia, шейдер должен соответствовать следующим правилам:
- Строка шейдера должна иметь точку входа с сигнатурой float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) , где linearRGB — это значение абсолютных нит пикселей RGB в линейном пространстве, а xyz — это linearRGB преобразованный в XYZ.
- Любые вспомогательные методы, используемые строкой шейдера, должны иметь префикс строки libtonemap_ чтобы определения шейдеров платформы не конфликтовали. Аналогично, входные формы должны иметь префикс in_libtonemap_ .
Создать униформу SkSL
Интерфейс ToneMapper::generateShaderSkSLUniforms() возвращает следующее, учитывая struct метаданных, описывающую метаданные из различных стандартов HDR и условий отображения:
- Список униформ, привязанных к шейдеру SkSL.
- Унифицированные значения in_libtonemap_displayMaxLuminance и in_libtonemap_inputMaxLuminance . Эти значения используются шейдерами платформы при масштабировании входных данных в libtonemap и нормализации выходных данных, если это применимо.
В настоящее время процесс создания униформ не зависит от пространства входных и выходных данных.

Кастомизация

Эталонная реализация библиотеки libtonemap дает приемлемые результаты. Однако поскольку алгоритм отображения тонов, используемый композицией графического процессора, может отличаться от алгоритма, используемого композицией DPU, использование эталонной реализации может вызвать мерцание в некоторых сценариях, таких как анимация вращения. Настройка может решить такие проблемы с качеством изображения, специфичные для конкретного поставщика.

OEM-производителям настоятельно рекомендуется переопределить реализацию libtonemap , чтобы определить свой собственный подкласс ToneMapper , который возвращается методом getToneMapper() . При настройке реализации партнеры должны выполнить одно из следующих действий:

Измените реализацию libtonemap напрямую.
Определите свою собственную статическую библиотеку, скомпилируйте ее как отдельную и замените файл .a библиотеки libtonemap файлом, созданным на основе их пользовательской библиотеки.

Поставщикам не нужно модифицировать какой-либо код ядра, но несколько поставщиков должны сообщить подробную информацию об алгоритмах преобразования тонов DPU для правильной реализации.

Валидация

Выполните следующие шаги, чтобы проверить свою реализацию:

Воспроизводите HDR-видео на экране любых стандартов HDR, которые поддерживает ваша система отображения , например HLG, HDR10, HDR10+ или DolbyVision.
Переключите композицию графического процессора, чтобы гарантировать отсутствие заметного пользователю мерцания.
Используйте следующую команду adb для переключения состава графического процессора:
```
adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
1 to force GPU composition>
```

Общие проблемы

При такой реализации могут возникнуть следующие проблемы:

Полосы возникают, когда цель рендеринга, используемая композицией графического процессора, имеет меньшую точность, чем типичное значение для HDR-контента. Например, полосатость может возникнуть, когда реализация HWC поддерживает непрозрачные 10-битные форматы для HDR, такие как RGBA1010102 или P010, но требует, чтобы композиция графического процессора записывала в 8-битный формат, такой как RGBA8888, для поддержки альфа.
Незначительный сдвиг цвета вызван различиями в квантовании, если DPU работает с другой точностью, чем GPU.

Каждая из этих проблем связана с относительными различиями в точности базового оборудования. Типичный обходной путь — обеспечить наличие шага дизеринга в путях с более низкой точностью, что делает любые различия в точности менее заметными для человека.

До Android 13 операции отображения тонов, специфичные для дисплея, не использовались HWC, SurfaceFlinger и приложениями. В зависимости от пути рендеринга для HDR-контента это приводило к несоответствию качества изображения, когда HDR-контент по-разному отображался в тональном пространстве выходного пространства. Это было заметно в таких сценариях, как поворот экрана, когда стратегия композиции меняется между графическим процессором и DPU, а также в различиях в поведении рендеринга между TextView и SurfaceView.