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 enlibtonemap_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 paraRenderEngine
. el componente de composición acelerado por GPU para SurfaceFlinger. El sombreador también conectado alibhwui
, para que la asignación de tonos de HDR a SDR se pueda realizar de forma eficiente paraTextureView
. 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)
, dondelinearRGB
es el valor de los nits absolutos de los píxeles RGB en el espacio lineal. yxyz
eslinearRGB
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 prefijoin_libtonemap_
.
- La cadena del sombreador debe tener un punto de entrada con el
firma
Genera uniformes de SkSL
La interfaz
ToneMapper::generateShaderSkSLUniforms()
muestra a continuación, dado un metadatostruct
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
yin_libtonemap_inputMaxLuminance
Los sombreadores de framework usan estos valores cuando escalas la entrada alibtonemap
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
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 bibliotecalibtonemap
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:
Reproducir videos HDR en la pantalla en cualquier estándar HDR que admita tu sistema de visualización como HLG, HDR10, HDR10+ o DolbyVision.
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.