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

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

До Android 13 операции отображения тонов для конкретных дисплеев не использовались HWC, SurfaceFlinger и приложениями. В зависимости от пути рендеринга для HDR-контента это приводило к несоответствию качества изображения, когда HDR-контент по-разному преобразовывался в выходное пространство. Это было заметно в таких сценариях, как поворот экрана, когда стратегия композиции меняется между GPU и DPU, а также в различиях в поведении рендеринга между TextureView и 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 для правильной реализации.

Проверка

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

  1. Воспроизведение HDR-видео на экране любого стандарта HDR, который поддерживает ваша система отображения , например HLG, HDR10, HDR10+ или DolbyVision.

  2. Переключите композицию графического процессора, чтобы гарантировать отсутствие ощутимого пользователем мерцания.

    Используйте следующую команду 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.

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