Asignación de tono de la luminancia HDR a un rango compatible con SDR

Android 13 presenta un entorno estático biblioteca llamada libtonemap, que define las operaciones de asignación de tono y se comparte con el proceso SurfaceFlinger y las implementaciones de Hardware Composer (HWC). Esta función permite a los OEM definir y compartir su asignación de tono de visualización. algoritmos entre el framework y los proveedores, lo que disminuye la falta de coincidencia de tono la asignación.

Antes de Android 13, asignación de tono específica de la pantalla las operaciones no se compartían entre HWC, SurfaceFlinger y apps. Según en la ruta de renderización, en el caso del contenido HDR, provocó discrepancias en la calidad de la imagen. en la que el tono del contenido HDR se asignó a un espacio de salida de diferentes maneras. Esta era perceptible en situaciones como la rotación de pantalla, donde la composición cambios de estrategia entre la GPU y la DPU, y en las diferencias en la renderización comportamiento entre TextureView y SurfaceView.

En esta página se describen la interfaz, la personalización y los detalles de validación de la libtonemap.

Interfaz con la biblioteca de asignación de tono

La libtonemap contiene implementaciones respaldadas por CPU y sombreadores SkSL, que se pueden por SurfaceFlinger para la composición del backend de GPU y por HWC Generar una tabla de consulta de asignación de tonos (LUT) El punto de entrada a libtonemap es android::tonemap::getToneMapper(), que devuelve un objeto que implementa la interfaz ToneMapper.

La interfaz ToneMapper admite las siguientes funciones:

  • Cómo generar una LUT de asignación de tonos

    La interfaz ToneMapper::lookupTonemapGain es una CPU implementación del sombreador definido en libtonemap_LookupTonemapGain(). Esta se utiliza en las pruebas de unidades del framework, y los socios pueden usarlo para asistencia para generar una LUT de asignación de tonos dentro de su canalización de color.

    libtonemap_LookupTonemapGain() toma los valores de color en valores absolutos, espacio lineal no normalizado, tanto en RGB lineal como en XYZ, y muestra un número de punto flotante con el que se describe cuánto se deben multiplicar los colores de entrada en un espacio lineal.

  • Genera un sombreador SkSL

    La interfaz ToneMapper::generateTonemapGainShaderSkSL() muestra un String de sombreador SkSL, según un espacio de datos de origen y destino. El sombreador SkSL Se conectó a la implementación de Skia para RenderEngine. el componente de composición acelerado por GPU para SurfaceFlinger. El sombreador también conectado a libhwui, para que la asignación de tonos de HDR a SDR se pueda realizar de forma eficiente para TextureView. Debido a que la cadena generada está intercalada en otros sombreadores de SkSL que usa Skia, el sombreador debe cumplir con las siguientes reglas:

    • La cadena del sombreador debe tener un punto de entrada con el firma float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz), donde linearRGB es el valor de los nits absolutos de los píxeles RGB en el espacio lineal. y xyz es linearRGB convertido en XYZ.
    • Todos los métodos auxiliares que use la cadena del sombreador deben tener el prefijo la cadena libtonemap_ para que las definiciones del sombreador de framework no entren en conflicto. Del mismo modo, los uniformes de entrada deben tener el prefijo in_libtonemap_.

  • Genera uniformes de SkSL

    La interfaz ToneMapper::generateShaderSkSLUniforms() muestra a continuación, dado un metadato struct que describe metadatos de diferentes HDR estándares y condiciones de visualización:

    • Una lista de uniformes que vincula un sombreador SkSL.

    • Los valores uniformes in_libtonemap_displayMaxLuminance y in_libtonemap_inputMaxLuminance Los sombreadores de framework usan estos valores cuando escalas la entrada a libtonemap y normalizas la salida como que corresponda.

    Actualmente, el proceso de generación de uniformes es independiente de la entrada y espacio de datos de salida.

Personalización

La implementación de referencia de la biblioteca de libtonemap produce resultados aceptables. Sin embargo, ya que el algoritmo de asignación de tonos que usa la composición de la GPU puede diferir de este que usa la composición de la DPU, el uso de la implementación de la referencia puede causar parpadeo en algunas situaciones, como en la animación de rotación. La personalización puede resolver los problemas de calidad de la imagen específicos del proveedor.

Se recomienda a los OEM que anulen la implementación de libtonemap para definen su propia subclase de ToneMapper, que muestra getToneMapper(). Cuando personalizan la implementación, se espera que los socios realicen una de las siguientes acciones: lo siguiente:

  • Modifica la implementación de libtonemap directamente.
  • Definir su propia biblioteca estática, compilarla como una biblioteca independiente Reemplaza el archivo .a de la biblioteca libtonemap por el que se generó a partir de su archivo personalizado biblioteca.

No es necesario que los proveedores modifiquen ningún código de kernel, pero varios proveedores deben hacerlo. información detallada sobre los algoritmos de asignación de tonos de la DPU para para implementarlos.

Validación

Sigue estos pasos para validar la implementación:

  1. Reproducir videos HDR en la pantalla en cualquier estándar HDR que admita tu sistema de visualización como HLG, HDR10, HDR10+ o DolbyVision.

  2. Activa o desactiva la composición de la GPU para asegurarte de que no haya ningún parpadeo perceptible para el usuario.

    Usa el siguiente comando de adb para activar o desactivar la composición de la GPU:

    adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
1 to force GPU composition>

Problemas comunes

Con esta implementación, pueden ocurrir los siguientes problemas:

  • Las bandas se producen cuando el objetivo de renderización que usa la composición de la GPU es menor más precisa que el valor típico del contenido HDR. Por ejemplo, las bandas pueden se produce cuando una implementación HWC admite formatos opacos de 10 bits para HDR, como RGBA1010102 o P010, pero requiere que la composición de la GPU escriba en un formato de 8 bits. como RGBA8888 para admitir alfa.

  • Un cambio de color sutil se debe a diferencias de cuantización si la DPU funciona con una precisión diferente a la de la GPU.

Cada uno de estos problemas está relacionado con las diferencias de precisión relativas de los el hardware subyacente. Una solución alternativa típica es asegurarse de que haya una interpolación paso en las rutas de menor precisión, lo que hace que las diferencias de precisión sean menos humanas perceptible.