Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .

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

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

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

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

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

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

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

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

Создание LUT-таблицы тональной компрессии
Интерфейс ToneMapper::lookupTonemapGain — это реализация шейдера, определённого в libtonemap_LookupTonemapGain() , на уровне процессора. Он используется модульными тестами фреймворка и может использоваться партнёрами для помощи в создании таблицы преобразования тонов в рамках их цветового конвейера.
libtonemap_LookupTonemapGain() принимает значения цвета в абсолютном, ненормализованном линейном пространстве, как в линейном RGB, так и в XYZ, и возвращает число с плавающей точкой, описывающее, на сколько следует умножить входные цвета в линейном пространстве.
Генерация шейдера SkSL
Интерфейс ToneMapper::generateTonemapGainShaderSkSL() возвращает строку шейдера SkSL, заданную исходным и конечным пространствами данных. Шейдер SkSL подключен к реализации Skia для RenderEngine , компонента композитинга с ускорением на GPU для 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 даёт приемлемые результаты. Однако, поскольку алгоритм тональной компрессии, используемый при компоновке на GPU, может отличаться от алгоритма, используемого при компоновке на 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>
```

Распространенные проблемы

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

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

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