El soporte de HDR en Linux es un tema que poco a poco está preocupando cada vez más entre los desarrolladores de escritorios y compositores. Red Hat fue quien abrió el melón con la intención de introducir la característica en la sesión de GNOME sobre Wayland, luego llegó Weston con su soporte inicial, el hackfest organizado por Red Hat y ahora es KDE quien empieza a mostrar sus planes para soportar el HDR.
Al igual que en los demás frentes, el plan es introducir el soporte de HDR en KDE a través de la sesión de Wayland proporcionada por el compositor Kwin. El último capítulo del recorrido para que Kwin tenga soporte de HDR ha sido narrado por Xaver Hugl, posiblemente la persona de KDE que más está contribuyendo a Wayland. De hecho, la introducción del “soporte de tearing” en el protocolo lleva su firma.
Xaver Hugl ha publicado en su blog personal una entrada llamada “HDR y gestión de color en Kwin”, en la cual ha explicado qué es el HDR y la gestión del color, el antiguo enfoque empleado por KDE para lidiar con los espectros de color y el nuevo enfoque que se pretende introducir con Wayland, muy posiblemente con las miras puestas en Plasma 6 viendo las fechas en las que estamos.
Ciñéndonos a los aspectos más importantes, ya que la entrada de Xaver Hugl es bastante extensa, el desarrollador explica que “el espacio de color más común se denomina ‘sRGB’ y lo utilizan la mayoría de los contenidos y pantallas.”
“Esta forma de manejar los colores es relativamente simple y útil, pero también presenta algunos problemas importantes. Las pantallas no se adhieren y a menudo no pueden adherirse al espacio de color sRGB. Debido a restricciones de fabricación, una pantalla puede tener un rojo un poco más ‘rojizo’, otra puede tener un azul menos ‘azulado’, por lo que el mismo contenido inevitablemente se verá diferente en distintas pantallas”.
Hugl señala que no es conveniente limitarse a sRGB debido a que, al final, solo es capaz de mostrar “un pequeño subconjunto de todos los colores visibles”, lo que puede derivar en algunos problemas como algunos colores que se ven sobresaturados o que el contenido creado para una pantalla capaz de mostrar un mayor rango de colores se vea mal. Con el fin de corregir eso, aquí es donde entra la gestión del color. Otro aspecto interesante es que “sRGB define un rango de brillo de 0 a 80 nits, que está muy por debajo de los miles de nits que pueden soportar algunas pantallas HDR”.
KDE Plasma 5 emplea colord
para establecer un perfil de color ICC para una pantalla, que se encarga de “la colorimetría de la pantalla y contiene curvas de corrección de color que ajustan el balance de blancos y la función de transferencia electro-óptica (EOTF)”. Sobre X11, protocolo implementado en Xorg, esto funciona en pantallas que soportan un amplio espectro de color y con aplicaciones que usan el perfil, pero las aplicaciones que ignoran dicho perfil terminan por verse mal y además está limitado en la práctica a 8 bits por canal de color. Sí, Xorg puede usar 10 bits por canal de color, pero eso puede romper ciertas aplicaciones.
Wayland, por su parte, puede ser usado sobre el papel de la misma manera, pero el protocolo no cuenta con ninguna API que permita emplear el perfil empleado por la pantalla, por lo que en consecuencia ninguna aplicación usa realmente el perfil. El resultado de esto es que, si se quiere usar una amplia gama de colores, no queda otra que usar X11, con todos los errores que arroja en la reproducción del color y su carencia de soporte para HDR.
Ante las limitaciones de X11, el nuevo enfoque introducido a través de Wayland es que el compositor haga las conversiones necesarias de forma automática para mostrar los colores correctamente cuando las aplicaciones etiquetan su contenido con un espectro de color y algunos metadatos adicionales, utilizando para ello shaders o apoyándose en la GPU. De esta manera se obtienen una mayor gama de colores y un mayor rango dinámico en las aplicaciones que los soportan, sin que el usuario tenga que preocuparse por esas otras aplicaciones que no lo hacen.
Xaver Hugl expone que Wayland todavía no está totalmente listo, pero reconoce que se han producido muchos avances a nivel del propio protocolo, el kernel y los compositores para modernizar la pila encargada del despliegue de los gráficos en Linux. Por otro lado, el hackfest de HDR organizado por Red Hat y celebrado el ciudad checa de Brno le ha permitido conocer a otras personas involucradas en ese tema y ha podido discutir sobre otros como la gestión del color y la tasa de refresco variable (Variable Refresh Rate o VRR).
Sobre la situación del HDR en Kwin, este todavía no se encuentra implementado realmente y su desarrollo parece estar en una fase muy inicial, pero como siempre con estas cosas, todo camino se empieza a recorrer dando el primer paso. El desarrollador explica que ha empezado a pulir el código de Kwin, ha corregido muchos efectos del compositor para que sean capaces de hacer las conversiones de color y ha introducido soporte básico para la gestión del color y HDR.
El soporte de HDR y el abarcar un mayor rango del espectro de color puede ayudar en aspectos como la experiencia con los videojuegos, con los contenidos multimedia e incluso a la hora de trabajar con aplicaciones como Krita, pero Hugl avisa que queda mucho trabajo por delante en Kwin para empezar a tener resultados reales, y a eso hay que sumar que tampoco se atreve a pronosticar cuando el protocolo Wayland estará plenamente listo.
El trabajo para dotar a Linux de soporte de HDR está en marcha, pero todo parece indicar que el camino, como siempre por estos lares, será recorrido con lentitud.
La entrada El soporte de HDR para Kwin está en camino, pero todavía queda mucho por delante es original de MuyLinux