ES2728053T3

ES2728053T3 - Métodos y aparatos para crear funciones de mapeo de códigos para codificar una imagen HDR, y métodos y aparatos para el uso de tales imágenes codificadas

Info

Publication number: ES2728053T3
Application number: ES14734799T
Authority: ES
Inventors: Der Vleuten Renatus Josephus Van; Jeroen Hubert Christoffel Stessen; Mourik Johannes Gerardus Rijk Van
Original assignee: Koninklijke Philips NV
Current assignee: Koninklijke Philips NV
Priority date: 2013-07-18
Filing date: 2014-06-30
Publication date: 2019-10-22
Anticipated expiration: 2034-06-30
Also published as: TR201906704T4; HUE043587T2; PT3022895T

Abstract

Un método de codificación de un vídeo de rango dinámico alto de imágenes, que comprende las etapas de: - introducir colores de píxel de una imagen de rango dinámico alto 5 de entrada, en donde los colores de píxel tienen información de una luminancia y una cromaticidad; - aplicar una inversa de una función de mapeo para obtener un código de luma (v) de la luminancia de un color de píxel, función de mapeo que está predeterminada como que comprende una primera función parcial que se define como **Fórmula** en la que ρ es una constante de ajuste, y v es el código de luma que corresponde a una luminancia que codificar, y un segundo mapeo parcial definido como L = LmPv en la que Lm es una luminancia máxima de una pantalla de referencia predefinida, y γ es una constante que es preferiblemente igual a 2,4, - emitir una matriz de píxeles que tiene una codificación de color que comprende los códigos de luma.

Description

DESCRIPCIÓN

Métodos y aparatos para crear funciones de mapeo de códigos para codificar una imagen HDR, y métodos y aparatos para el uso de tales imágenes codificadas

Campo de la invención

La invención se refiere a la codificación de una imagen de rango dinámico alto (es decir, una fija) pero preferiblemente más imágenes de rango dinámico alto (es decir, de vídeo), o bien de forma nativa, lo que significa que solo se necesita una codificación para una imagen de apariencia de brillo HDR (habitualmente una imagen óptima para visualización en pantallas con un brillo máximo alto como, por ejemplo, 5000 nit, y con objetos significativos a través de muchos brillos, es decir, hasta negro intenso), o bien en una codificación doble: en donde además de la apariencia de imagen HDR, se codifica la apariencia de imagen LDR correspondiente. Además, preferiblemente la codificación es para que pueda encajar en los marcos de trabajo de codificación de imagen o vídeo actuales de la tecnología existente, como, por ejemplo, almacenamiento en disco Blu-ray, conexiones de cable HDMI u otros sistemas de almacenamiento o transmisión de imagen. La codificación de vídeo (o incluso de imagen fija) HDR ha sido hasta la fecha una tarea desalentadora, y la creencia típica es que o bien se necesita avanzar hacia significativamente más bits, para codificar los brillos por encima del rango LDR de objetos de escena (por ejemplo, codificaciones que codifican luminancias de escena directamente), o bien se necesita un cierto enfoque de dos capas, en donde, por ejemplo, además de una imagen de reflectancia de objeto existe una imagen de refuerzo de iluminación, o estrategias de descomposición similares. Philips ha propuesto recientemente un enfoque de imagen única mucho más simple, que es una dirección totalmente nueva, y no solo difícil de imaginar a priori, sino también cuando hacerlo en realidad conduce a muchos problemas técnicos que resolver, que sin embargo funciona en la práctica, y en este marco de trabajo específico el texto de la presente solicitud de patente enseña algunas partes de la construcción de una tecnología de codificación de este tipo, y todo el marco de trabajo a su alrededor como una graduación artística para diferentes escenarios de reproducción (al menos una imagen de apariencia realista/óptima para una pantalla HDR y una pantalla LDR).

Con “rango dinámico alto” (HDR) pretendemos indicar que una cualquiera de la imagen/imágenes, según son captadas desde el lado de captación, tienen una relación de contraste de luminancia alta en comparación con la codificación LDR heredada (es decir, relaciones de contraste de 10.000:1 o más pueden ser logradas por la codificación, y todos los componentes de la cadena de manejo de imagen hasta la representación; y las luminancias de objeto captadas se pueden encontrar por encima de 1000 nit, o más en concreto, habitualmente se pueden reproducir por encima de 1000 nit para, dado el entorno de reproducción, generar una cierta apariencia deseada de, por ejemplo, una lámpara encendida o un exterior soleado), y/o la representación de tal imagen o imágenes es HDR (es decir, las imágenes han de ser convenientes en el sentido de que estas contengan información suficiente para una representación HDR de alta calidad y, preferiblemente, de una forma técnicamente fácil de usar), lo que significa que la imagen o imágenes se representan o se pretende representarlas en pantallas con un brillo máximo de al menos 2000 nit (sin implicar que estas no puedan representarse en pantallas LDR de, por ejemplo, un brillo máximo de 100 nit, habitualmente después de un mapeo de color conveniente).

Antecedentes de la invención

Recientemente se ha propuesto una serie de tecnologías de codificación HDR, como, por ejemplo, el método de doble capa de Dolby (el documento WO2005/1040035). El documento US2010/0226547A divulga, en un contexto relacionado, el mapeo de una imagen HDR en una imagen de menor profundidad de bits para la codificación, lo que da como resultado un error de cuantificación menor. F. Banterle et al., A framework forinverse tone mapping, publicado en The visual Computer 23, páginas 467-478, 2007, divulga un operador de mapeo de tonos inverso para una mejor representación de un contenido HDR en una pantalla heredada.

No obstante, en la actualidad la industria aún sigue buscando una tecnología de codificación de vídeo (/imagen) HDR pragmática que encaje con (un equilibrio de) todos los requisitos, tales como los factores muy importantes, como la cantidad de datos, pero también la complejidad computacional (el precio de los CI), la facilidad de introducción, la versatilidad para que los artistas creen lo que quieran, etc. En particular, un enfoque de doble capa es visto como complejo. Idealmente, a una persona le gustaría poder diseñar una codificación que encaje con la codificación heredada, tal como, por ejemplo, codificación de HEVC de MPEG basada en DCT. Un problema es que esto es algo contraintuitivo cómo se puede codificar una imagen HDR que, por definición, debería ser algo diferente de una imagen LDR, que tiene habitualmente una cantidad mayor de rangos de brillo/luminancia interesantes, en una tecnología optimizada para contener imágenes LDR particulares, es decir, para verse en pantallas con un brillo máximo de aproximadamente 100 nit y un entorno oscuro). Estos sistemas de manejo/codificación de imagen LDR heredada se diseñaron y optimizaron para trabajar con escenarios de formación de imagen LDR típicos, que normalmente están bien iluminados con, por ejemplo, una relación de iluminación de 4:1 dentro del estudio (o, por ejemplo, 10:1), dando para la mayor parte de los objetos (cuya reflectancia puede variar entre, por ejemplo, un 85 % para el blanco y un 5 % para el negro) en la vista una relación de contraste total de aproximadamente 68:1 (respectivamente, 170:1). Si se contempla una representación relativa de las luminancias partiendo de un blanco máximo, un monitor de LCD heredado típico sin atenuación de luminosidad local habría tenido algo así como el blanco de 100 nit y el negro de 1 nit que coincidiría con la relación de contraste de imagen, y habitualmente se pensaría que, como promedio, los sistemas de CRT que se podrían haber contemplado también durante el día tendrían algo así como una capacidad de 40:1. Tener una función gamma de asignación de código de luminancia convencional de 2,2 en estos sistemas parecía satisfactorio para la mayoría de escenarios de un contraste de escena incluso más alto. Aunque se cometieron algunos errores considerados aceptables en aquellos días, tales errores de representación de regiones de escena de luminancia alta con mala codificación (por ejemplo, recorte duro) también fueron aceptables debido a que, de todos modos, las pantallas LDR no podrían representar aquellas de forma físicamente precisa.

No obstante, hay escenarios para los cuales existe un deseo de mejorar la representación, como, por ejemplo, una escena de interiores en la que se puede ver simultáneamente la zona de exteriores soleada, caso en el que puede haber una relación de iluminación de 100:1 o incluso más. En LDR, esas regiones se mostrarán como sometidas a recorte (suave) (habitualmente ya en la imagen codificada que tiene códigos difíciles de discriminar en torno al máximo de 255 para esos píxeles) mientras que, en una pantalla h Dr , nos gustaría mostrarlas tanto brillantes como coloridas. Esto daría una representación mucho más natural y espectacular de tales escenas (como si se estuviera de vacaciones en Italia), pero incluso escenas en las que el contenido de brillo más alto solo está compuesto por algunas reflexiones especulares ya muestran una mejora de calidad visual importante. Si los artefactos como errores de cuantificación o recorte no parecen ya molestos en, por ejemplo, una pantalla de 5000 o de 10000 nit, al menos queremos poder accionar tales pantallas con el tipo correcto de imagen, de tal modo que las imágenes representadas serán tan hermosas como lo permita la pantalla.

No obstante, el pensamiento clásico era que, para codificar rangos de brillo excesivo adicionales, se necesitaría tener (muchos) más bits. Ello podría ocurrir o bien codificando de forma nativa, en palabras de código más grandes individuales (tales como OpenEXR con 16 bits, que son un bit de signo, un exponente de 5 bits y una mantisa de 10 bits, o una codificación de LogLuv de Ward, que intenta rigorosamente, desde un punto de vista matemático, captar la totalidad del universo de luminancias de objeto posibles con alta precisión), o bien usando una primera capa con códigos de rango LDR convencionales (por ejemplo, una aproximación de JPEG clásica de la imagen HDR), y una segunda capa para mejorar tales luminancias de píxel a un brillo más alto (por ejemplo, una imagen de refuerzo para reforzar cada píxel, si es necesario, a una luminancia más alta, es decir, siendo una multiplicación de dos imágenes de 8 bits de ese tipo equivalentes a un código de 16 bits lineal único).

Un problema práctico importante a resolver cuando se diseña una tecnología de codificación HDR práctica, además del hecho de que, por supuesto, ha de ser capaz de manejar un enorme rango de diferentes imágenes HDR, es que los fabricantes de hardware desean cantidades menores de bits por palabra de código (canal) no obstante, y aunque nuestra tecnología propuesta posteriormente también puede trabajar con palabras de bits mayores, llegamos a una solución que funciona correctamente bajo una limitación de 10 bits para al menos un canal de luminancias (o, más precisamente, uno de luma). Además, desarrollamos un marco de trabajo que puede realizar, en una filosofía doble, tanto la codificación de píxeles de color como la conversión de apariencia de color para varios escenarios de representación de una forma funcional, lo que significa que solo deben codificarse de forma conjunta las funciones en lugar de, para cada imagen, al menos una segunda imagen. Y, al investigar y desarrollar esta ruta, descubrimos lo que no sería trivial a primera vista y se divulga en esta solicitud de patente de que, realmente, podríamos hacer que el sistema funcionase con buena calidad al elegir la función o funciones apropiadas en un eje de luma, e incluso codificar las otras dos componentes en un plano de cromaticidad independiente de la luminancia, lo que ofrece, después del desarrollo, ventajas adicionales de esta codificación como la elección libre del plano de color (por ejemplo, para una gama amplia), cálculos fáciles dentro del propio espacio de códec, etc.

Sumario de la invención

Necesitamos tener una codificación mejorada de imágenes HDR y, en particular, comenzamos con la filosofía de que, en especial en el momento actual en el que sigue habiendo muchos sistemas LDR heredados presentes en el sector, son necesarios unos ciertos niveles de compatibilidad. Esto significa, por un lado, que nos gustaría seguir usando los CI de (des)codificador existentes, que implementan una funcionalidad como (I)DCT [= compatibilidad de primer nivel], pero también ha de haber una compatibilidad de segundo nivel con pantallas que necesitan imágenes LDR ya que solo pueden representar LDR (es decir, la apariencia correcta LDR bajo tal capacidad de rango dinámico de pantalla, por ejemplo, con las regiones oscuras siendo aún suficientemente visibles), debido a que además de las TV heredadas actualmente desplegadas, en el futuro lejano habrá un espectro de pantallas que varían desde las pantallas portátiles pequeñas de baja capacidad de brillo como ordenadores portátiles o de tipo tableta o incluso teléfonos móviles en los que un consumidor también desea ver una cierta representación de una película HDR, hasta las pantallas HDR más avanzadas que, en el futuro, pueden tener un brillo máximo de, por ejemplo, 10000 nit, y todas las pantallas entremedias o en torno a ellas. Entonces, aunque la pantalla aún puede ser heredada y simple, esta puede ser atendida por un nuevo CI de descodificación y de mapeo de color de alta complejidad en, por ejemplo, una unidad de adaptación multimedios u ordenador que suministre el contenido HDR por medio de, por ejemplo, una conexión HDMI o de otro tipo, ofreciendo esa unidad de adaptación multimedios cualquier combinación de las opciones que inventamos y describimos. Hemos convertido esto a un enfoque en el que, en el escenario ideal, se necesitarían (al menos) dos graduaciones para la misma película o imágenes procedentes del proveedor de contenidos, que simplemente denominaremos imagen LDR (a usar para escenarios de pantalla LDR, por ejemplo con pantallas con brillo máximo en torno a 100 nit) y una imagen de HDR (para las pantallas más brillantes), pero las siguientes realizaciones también son útiles incluso si se codifica solo una única imagen HDR (por ejemplo, en un disco Blu-ray, y entonces o bien solo atiende a un rango particular previsto de pantallas HDR, u obtiene un mapeo para pantallas fuera de rango de manera independiente), y presentamos las enseñanzas para que puedan encajar en cualquier estrategia prevista.

Por lo tanto, para varios escenarios a modo de ejemplo prácticos, tenemos como punto de partida para la codificación HDR novedosa, como entrada, una imagen graduada con HDR maestra (supongamos que esta se gradúa a voluntad de acuerdo con el que quiera que fuera el gusto del creador con cualquier software de procesamiento de color y, por ejemplo, se codifica en una codificación de color de partida como OpenEXR), y necesitamos codificar esto de una forma que sea utilizable en la práctica para las tecnologías actuales de vídeo o de imagen (es decir, que se modifique solo minoritariamente con respecto a la forma normal de uso de tales tecnologías de codificación, pero no que, por ejemplo, sea necesario cambiar todos los buses a 12 bits, es decir, nuestros métodos deberían funcionar con un hardware de 12 bits, pero también si solo se encuentran disponibles 10 bits por componente, o si se acepta una calidad un tanto más baja incluso en sistemas de 8 bits), para, por ejemplo, un reproductor de discos BD nuevo, o un CI de televisión que recibe vídeo transmitido por secuencias por Internet, o cualquier receptor conectado a cualquier fuente de imágenes esencialmente conforme con una variante de las tecnologías de codificación de imagen/vídeo actuales.

Hemos llegado a la conclusión de que una imagen HDR y alguna imagen "LDR" (ya sea una graduación que se use directamente para la representación LDR, o simplemente una "pseudo-imagen" cuyo fin no es ser vista, sino simplemente codificar una imagen que solo se representará de una forma HDR en una tecnología HDR después de un procesamiento de color adicional) pueden estar vinculadas a la imagen HDR mediante una transformación funcional sobre la componente de color que codifica las luminancias de los colores de píxel (una única función, o una de un conjunto habitualmente limitado de funciones útiles y acordadas previamente, acuerdo previo que debería ocurrir no más tarde que cuando un lado de creación de contenido se vincula funcionalmente con un lado de recepción de contenido, tal como, por ejemplo, al comienzo de una película y, posiblemente, un par de veces durante el tiempo de reproducción para, por ejemplo, un televisor que recibe una película: es decir, cuando no son fijas y se han acordado para codificar muchas películas completas, si son variables estas funciones pueden transmitirse a través de una ruta de comunicación de red, almacenarse en un dispositivo de memoria conectado, etc.).

Nuestra invención se puede realizar, por ejemplo, al menos de las siguientes maneras:

Un método de codificación de una imagen de rango dinámico alto, que comprende las etapas de:

- introducir colores de píxel de una imagen de rango dinámico alto de entrada, en donde los colores de píxel tienen información de una luminancia y una cromaticidad;

- aplicar una inversa de una función de mapeo para obtener un código de luma (v) de la luminancia de un color de píxel, función de mapeo que está predeterminada como que comprende una primera función parcial que se _{define como P= (} ôv _— - _p í _{), en la que rho (p) es una constante de ajuste de forma, y v es el código de luma que}corresponde a una luminancia (L) que codificar, y una segunda función parcial definida como L = LmPY que es una transformada de gamma, y en donde Lm es una luminancia máxima de una pantalla de referencia predefinida, y gamma (y) es una constante que es preferiblemente igual a 2,4,

- emitir una matriz de píxeles que tiene una codificación de color que comprende los códigos de luma (v).

Esta función se puede usar entonces para codificar al menos la imagen maestra HDR, con colores que tienen versiones normalizadas de luma de N bits Y', por ejemplo, [0-1023] códigos, en el intervalo [0, 1 ] dado el símbolo v, garantizando que se codifican con suficiente precisión todos los rangos de luminancia interesantes de los diversos objetos en la imagen o imágenes (que pueden ser muchos, por ejemplo, un zoco egipcio con una persona en la sombra, pero también una segunda persona iluminada por una luz solar intensa que brilla a través de agujeros en el techo, pero el vídeo también puede contener gráficos como, por ejemplo, un mapa meteorológico, o láseres en un reportaje dentro de una discoteca, o láseres simulados artificialmente, etc.). Por lo tanto, esta función se puede predeterminar o determinar inteligentemente sobre la marcha para que reasigne las luminancias a las lumas antes de una cuantificación uniforme. Al diseñar esta función de mapeo de luminancia (o, más precisamente como punto de partida, una función de transferencia electro-óptica EOTF correspondiente que mapea los códigos de luma en [0, 1] a luminancias representables en una pantalla de referencia), tuvimos en mente varios criterios técnicos de comportamiento. En primer lugar, aunque el comportamiento logarítmico (parcial) es una buena característica para poder codificar muchas décadas de luminancia, definitivamente este no es simplemente una representación logarítmica de un cierto rango lineal de luminancias (definitivamente, no solo para obtener únicamente una apariencia procesada de imagen deseada teniendo en cuenta solo razonamientos de procesamiento de imágenes, y asimismo no una mera función logarítmica adaptativa recortada, ya sea para una codificación óptima). Por el contrario, esta función se diseñó después de varias consideraciones surgidas de una experimentación prolongada y, dadas estas consideraciones, se vio como una función de comportamiento óptima para todos los criterios (al menos una buena precisión de cuantificación HDR) después de poder definir un rango de luminancia de referencia lineal y universal definido (por ejemplo, 0,0001-5000 nit) para representar de manera suficientemente realista las apariencias necesarias de todas las escenas HDR que ocurren en la práctica. Obsérvese que, formalmente, nuestras una o más EOTF de referencia tienen partes exponenciales en ellas, pero también se puede ver y describir eso como un comportamiento "logarítmico" a la inversa.

Teniendo ahora ese rango de referencia, es de lo más útil tener un cierto comportamiento "logarítmico" para las luminancias (o lumas) brillantes y un cierto comportamiento de gamma para las más oscuras. De hecho, aproximando matemáticamente exp(x) como 1+x, decimos que, en los oscuros, tenemos un comportamiento predominantemente de gamma, lo que significa que tenemos una función fácilmente controlable ya que podemos ajustar la precisión necesaria en los oscuros con el parámetro rho (siendo gamma el controlador de forma adicional dada una correlación de 1 a 1 como máximo ya que el código máximo que dirige la pantalla corresponde a la luminancia visualizable máxima). Ello no solo es útil para tener una sola EOTF maestra para una codificación de imagen solo HDR, sino que la gamma también es muy útil si tenemos diferentes clases de imágenes HDR. De hecho, si no decidimos aplicar una única función óptima razonable para todos los escenarios, podemos ajustar la EOTF (y la inversa correspondiente OETF). Por ejemplo, el experto puede imaginar que una imagen de un sótano oscuro, por un lado, hará que el ojo del espectador se adapte para ver valores de gris más oscuro, en particular en un entorno oscuro y, por otro lado, probablemente tendrá más valores de gris oscuro relevantes (ya que todos aquellos objetos con diversas reflectancias, mal iluminados, se encontrarán en la oscuridad), y los brillantes, en especial si solo son lámparas, pueden no necesitar una precisión máxima. Viceversa, si se está mirando una escena soleada con luminancias mayoritariamente muy brillantes (por ejemplo, entre 1000 y 3000 nit), puede que no se necesite la máxima precisión para los oscuros, que el sistema visual habitualmente ignorará en gran medida. Todo esto se puede ajustar fácilmente con nuestros parámetros de forma gamma y rho que controlan el comportamiento de la forma en los oscuros frente a los brillos, y también la cantidad de diferencias apenas perceptibles a las que corresponde cada escalón de luma en una región secundaria particular del rango de códigos de luma (que también se denomina resolución o precisión de codificación). Una función paramétrica preacordada fija no necesita que sus parámetros se comuniquen al lado de recepción ya que usará la función preacordada para descifrar lo que realmente significan los códigos recién inventados, pero en el caso más genérico de la adaptabilidad, los parámetros requeridos (al menos uno del brillo máximo Lm, rho y gamma) como son elegidos en el extremo de receptor, por ejemplo por un graduador humano o un programa de análisis de imágenes automático, se comunicará al lado de receptor mediante cualquiera de una serie de mecanismos posibles, tal como, por ejemplo, una codificación conjunta en una memoria como un disco BD, una transmisión conjunta como metadatos en una señal de imagen, una recuperación en tiempo de reproducción a través de otra ruta de comunicación de señal, etc.

Pero también ocurre otra cosa interesante con esta tecnología: al crear una codificación de la entrada HDR, esta función también crea una imagen de rango dinámico más bajo (lo que se podría decir que se puede codificar mejor en una cantidad menor de bits, pero una formulación técnica más precisa sería que al menos una cierta parte secundaria más importante de la escena, o un rango secundario del histograma de imagen, se ha de codificar con luminancias más cercanas al gris medio en comparación con la imagen HDR maestra original introducida), aunque, por otro lado, preferiblemente con al menos un alto grado de aproximación, la imagen LDR codificada sigue teniendo también toda la información para recuperar esa apariencia HDR maestra original, por lo que contiene todos los datos significativos de la imagen HDR. Por lo tanto, si los parámetros EOTF están bien elegidos, la imagen codificada resultante incluso se puede usar directamente sin optimizar adicionalmente el procesamiento del color para la representación en una pantalla LDR produciendo una apariencia LDR de calidad razonablemente buena, o al menos después de algunas transformaciones de optimización de segundo orden adicionales (por ejemplo, un mapeo a un conjunto diferente de colores primarios de pantalla LDR, etc.).

Al codificar con una sola función EOTF maestra (si usamos una sola en lugar de una seleccionada de entre una cantidad de las disponibles), podemos definir esa función genéricamente sin tener en cuenta las características específicas de lado de representación, es decir, aunque se define por medio de una pantalla de referencia, sigue refiriéndose mayoritariamente a la escena, teniendo únicamente en cuenta una codificación suficiente de las texturas de imagen de al menos la apariencia HDR. Pero preferiblemente también codificamos incluso una apariencia LDR, preferiblemente posicionando ya los diversos objetos de escena capturados a lo largo del eje de luma en los rangos secundarios de luma correctos, de modo que la apariencia LDR aparecerá, cuando se muestre directamente, como preferida por el creador de contenidos. Pero también podemos realizar ya una codificación para una aplicación de visualización particular, obteniendo, con una función de asignación de luma optimizada adicional como función maestra, los códigos de luma que dan la mejor calidad para la visualización en, por ejemplo, un entorno oscuro o poco iluminado caracterizado con una iluminancia de referencia, por ejemplo, 15 lux, o una luminancia de referencia ambiental de, por ejemplo, un entorno de gris medio (18 % de reflexión), supongamos, por ejemplo, 10 nit. Esto se puede hacer incorporando la función gamma adicional, por ejemplo, un 1,25 en algunas realizaciones. En última instancia, esto corresponde, cuando modelamos todas las gammas parciales deseadas como una gamma final óptima, a cambiar la gamma en nuestras realizaciones principales de la EOTF. Todas las variantes ofrecen la mejor calidad de textura de objeto de imagen para una cantidad particular de bits disponibles, o garantizan de otras maneras que podamos obtener una buena calidad para relativamente pocos bits, como, por ejemplo, solo 12 bits, al tiempo que también ofrecen capacidades de gama de colores amplia si usamos un plano de color grande en la dirección cromática como, por ejemplo, (u, v) de 1976 CIE de UCS, que resultó ser nuestra elección preferida.

También inventamos cómo esta EOTF inversa para mapear de luminancia a códigos de luma (también denominada función de transferencia optoelectrónica OETF que mapea las mediciones ópticas de luminancia de, por ejemplo, una cámara o software de procesamiento de color a códigos eléctricos resultantes que habitualmente son digitales, lo que puede verse como un intervalo unitario [0, 1] multiplicado por 2AN, donde N es la cantidad de bits) y su EOTF correspondiente puede funcionar mejor con una pantalla de referencia HDR (teórica) optimizada correspondiente (siendo capaz, una pantalla real que tenga las mismas características que la teórica, de representar directamente los códigos teóricos). Independientemente de la pantalla final en la que sea necesario representar el vídeo, el vídeo con sus códigos de luma debe definirse de una manera única y no confundible (en principio, el lado de creación de código puede usar entonces cualquier principio para asignar códigos, pero suponemos, por razones de simplicidad al esclarecerlo adicionalmente, que simplemente codifica un rango capturado lineal de luminancias directamente de la cámara con la inversa de la EOTF). En principio, se puede usar la función log gamma que inventamos con cualquier brillo máximo Lm deseado o también denominado blanco máximo o, más precisamente, luminancia máxima de la pantalla de referencia (por razones de compleción, lo que el experto denomina brillo máximo de una pantalla es el color más luminoso que una pantalla puede lograr, que es un blanco que se produce cuando los tres canales R, G, B se accionan al máximo, por ejemplo, 1023, y también forma un polo de partida para definir una gama de colores de pantalla a su alrededor), pero hallamos, después de muchos análisis, que 5000 nit es un valor práctico muy bueno si solo se debe usar un valor (entonces no es necesario transmitir conjuntamente con las imágenes de vídeo (codificación de color de píxel) a receptor alguno el valor de blanco máximo de referencia particular usado para la codificación, y por ejemplo, no puede haber confusión alguna). En un escenario como este, se pueden graduar las luminancias de entrada sin procesar por encima de 5000 nit para representar fielmente las luminancias de apariencia equivalentes para una visualización final dentro de, por ejemplo, el rango de luminancia de referencia de 0,0001-5000 nit y, donde se desee, si tales datos se van a visualizar en, por ejemplo, una pantalla real de 20000 nit, se pueden agregar funciones de aumento de grado como metadatos para optimizar esta apariencia dada toda su información en pantallas reales incluso más brillantes que la pantalla de referencia. No se debe confundir esta primera estrategia para redeterminar artísticamente los colores de escena de, por ejemplo, 25000 nit que están fuera de nuestro espacio de color maestro de base de luminancia de referencia para dar color dentro del espacio maestro, con las enseñanzas actuales acerca de cómo redeterminar los colores que ya están dentro de un espacio RGB particular (es decir, aún se puede hacer que dos gamas de colores con los mismos colores primarios pero diferente blanco máximo estén ubicadas conjuntamente una vez se renormalicen a [0, 1], y una de ellas sería habitualmente nuestro espacio RGB maestro definido por nuestro eje de luminancia maestro, y el otro espacio R'G'B' codificado, cualquiera que sea, con cualquiera de las funciones log gamma actuales). T ambién se pueden codificar, en este rango de luminancia maestro de [0-5000], imágenes graduadas para pantallas de rango dinámico más bajo (por ejemplo, 1200 o 100 nit) o escenas nebulosas y oscuras que solo llegan a 50 nit, y entonces, lo que no debe confundirse, convertirse a nuestra codificación de luma universal (es decir, aún debe ocurrir una asignación de código de luma, con una EOTF de asignación de código o bien fija o bien variable). Enseñamos un espacio de cromaticidad de (u, v) de luma que desacopla los aspectos de rango dinámico de los aspectos cromáticos, y que permite mucha versatilidad en ambos sentidos y, en particular, a lo largo del eje de luma, por ejemplo, en lo que respecta a qué función de asignación de luma ha de usarse, pero también funciones de reasignación, por ejemplo, al realizar un mapeo para pantallas de otro brillo máximo dentro de este espacio de color de codificación.

Los valores óptimos de gamma 2,4 y rho 25 se han hallado después de varias consideraciones y experimentos en caso de que se desee usar una única función de asignación de luma para todos los escenarios (por ejemplo, imágenes con, al mismo tiempo, algunas regiones brillantes, regiones de brillo medio y regiones oscuras), en particular, si se desea codificar solo HDR (es decir, aunque podemos codificar conjuntamente funciones de mapeo adicionales como metadatos para obtener una apariencia LDR deseable a partir de la codificación de imagen de píxeles HDR, no es necesario que en todas las realizaciones se obtenga una buena apariencia LDR visualizando directamente la imagen resultante de aplicar esta función de log gamma única óptima).

Se podrían usar varias representaciones de cromaticidad con nuestros enfoques de definición de luma, pero hemos hallado que el espacio (u, v) en particular funciona bien. También podemos definir (u', v') cuáles son referencias definidas a un blanco elegido, por ejemplo, como: (u', v') = (u, v)-(u_D65,v_D65), etc.

Cuando afirmamos que un color de entrada comprende información de una luminancia y una cromaticidad, no implicamos que dicho color esté, de por sí, representado en una representación de color de este tipo, sino que esta información se puede obtener matemáticamente, lo cual se cumple, por ejemplo, si la imagen de entrada se representa en XYZ o en un cierto RGB definido de manera única, etc. Aunque llegamos a una forma fundamentalmente nueva de definir luma que es útil para la tecnología de codificación HDR emergente, el experto entenderá, a partir de nuestras enseñanzas, cómo puede definir, por ejemplo, a partir de coordenadas RGB, las lumas, ponderando en primer lugar las coordenadas r Gb dado un equilibrado de punto blanco deseable definido como Y=a1*R+a2*G+a3*B, con a1, a2, a3 constantes que aún se pueden elegir dados unos colores primarios particulares R, G, B y una elección de punto blanco. Entonces esas luminancias Y se procesan con nuestra EOTF.

Además, el experto comprenderá cómo podemos obtener la información de una imagen para su emisión final, a la que podemos denominar Rec_HDR (una reconstrucción cercana de una entrada maestra HDR deseada), y esto puede hacerse ventajosamente, por ejemplo, como XYZ_salida (obsérvese que usamos el carácter Y, o también L, para la luminancia, e Y' para la luma, o también v, si la luma está normalizada [0,0, 1,0]). Pero también podemos convertir Rec_HDR a otra representación de color como, por ejemplo, un R'G'B' particular u otra codificación dependiente del dispositivo para accionar una pantalla particular. Además, Rec_HDR también puede ser una imagen HDR adicional, por ejemplo, podemos mapear o bien directamente a una imagen RGB de accionamiento requerida para representar la apariencia deseada en una pantalla de 1200 nit, o bien como alternativa mapear una primera Rec_HDR1 (por ejemplo, para nuestra pantalla de referencia de 5000 nit) a Rec_HDR2 a través de una etapa intermedia, para accionar, por ejemplo, una pantalla real de 1200 nit.

Que estos metadatos (rho, gamma y, si se desea, Lm) sean nuevos significa que también podemos, por supuesto, definir una nueva señal de imagen, no relacionada con tecnología previa alguna, que comprende estos metadatos (aunque se puede usar con cualquier estrategia heredada usada para codificar las componentes de color de la matriz de píxeles, con lo que imponemos unas coordenadas Yuv en, por ejemplo, una estructura MPEG-HEVC que espera YCrCb, pero no importa que el resto del (des)codificador realice, por ejemplo, DCT o codificación por longitud de ejecución, etc., siempre que tengamos una parte de un CI o software que realiza las conversiones de acuerdo con nuestras realizaciones). Entonces, aunque esa parte de "formateo" puede ser, de hecho, cualquier tecnología de imagen heredada similar a una codificación de MPEG o JPEG u otra codificación de imagen o vídeo, las texturas de imagen reales al cargar los códigos de píxeles de acuerdo con nuestra nueva estrategia ya serán fundamentalmente diferentes (de forma verificable) (sin la comprensión adecuada de lo que ocurrió, esta imagen parece técnicamente tan diferente que una codificación heredada generará una apariencia de imagen totalmente incorrecta, aunque técnicamente podría realizar todas las etapas de descodificación). De hecho, esta comprensión de los varios inventores de Philips que trabajan en este proyecto de codificación de imágenes futuro fue que, para el futuro, sería necesario algún sistema que fuera algo similar al modelo OSI de comunicación. Al avanzar la tecnología, en muchas áreas se vuelve tan compleja que debe definirse de una manera más estructurada, pero la pregunta era cómo hacerlo. En la tecnología de manejo de imágenes, ya existían soluciones para colocar la imagen en un contenedor externo (por ejemplo, describir qué componente de audio y vídeo, que usa qué estrategia de codificación, están comprendidas, o dividir esto en grandes fragmentos de datos para, por ejemplo, una transferencia IP o un carrusel de radiodifusión), que es la correlación simple de la OSI clásica, pero una capa seguía siendo completamente rígida, usando su codificación directa específica como, por ejemplo, Rec. 709 (todo lo definido para un único sistema totalmente definido previsto, de colores primarios RGB particulares, un entorno de visualización típico previsto, etc.). Con que la señal "comprenda" los parámetros de metadatos (o los metadatos de las funciones de definición y/o transformación de color que están asociadas con una imagen de color de píxeles) queremos decir que, de cualquiera de las maneras, los metadatos se transmiten al lado de recepción, ya sea, por ejemplo, al mismo tiempo en una misma señal, o haciendo que la matriz de colores de píxeles llegue en un primer momento a través de un primer canal de comunicación, y los metadatos más tarde a través de otro, en última instancia todos estos datos requeridos se juntan en el descodificador. Por lo tanto, podemos colocar la señal (colores de píxel metadatos de función) en el mismo disco Blu-ray, o comunicarla a través de una red como radiodifusión o Internet a través de alguna tecnología de comunicación de vídeo o imagen previamente existente o futura, etc.

Se puede determinar una función óptima para las imágenes HDR solo en la señal de imagen (por ejemplo, solo una apariencia HDR en el disco, y no una matriz de píxeles LDR, solo potencialmente algunas funciones de mapeo de color para obtener una imagen de apariencia LDR) con Lm = 5000, rho = 25 y gamma = 2,4. En lugar de Lm = 5000, el método también se puede usar cuando un creador de contenido desea un valor de Lm más alto (por ejemplo, 10000 nit) o uno más bajo (por ejemplo, 2000 o 1500).

También se pueden diseñar valores de gamma adicionales y, por ejemplo, se puede determinar una gamma teniendo en cuenta parcialmente una representación ambiental deseada, por ejemplo, definiendo la gamma final compuesta por una gamma equivalente de una gamma de codificación de Rec. 709 y la gamma 2,4. Con una gamma equivalente, el experto entenderá que este no es el valor de gamma en la fórmula que también tiene una parte lineal, sino que la gamma que mejor se aproxima a esa OETF de codificación de Rec. 709 cuando se empieza en los negros como una gamma en lugar de una parte lineal.

Un método de codificación de una imagen de rango dinámico alto en la que los parámetros rho y gamma se optimizan adicionalmente para producir una imagen codificada con buena apariencia de acuerdo con un graduador de color humano en una pantalla de 100 nit, por lo que el al menos uno de los parámetros rho y gamma es optimizado preferiblemente por un graduador humano. Aunque existirá cierta variabilidad, claramente existe un rango de parámetros que, dependiendo de la escena, dará un homólogo LDR de apariencia razonable para la imagen HDR, por lo que este es un método que puede definirse e identificarse ciertamente. Debido a la variabilidad y complejidad de las imágenes, por lo general, en el proceso un graduador de color humano determinará la imagen LDR con mejor apariencia y, por lo tanto, los parámetros rho y gamma correspondientes. Sin embargo, los algoritmos de análisis de imagen al menos parcialmente automáticos pueden llegar a valores con buena apariencia, y entonces, por ejemplo, habitualmente el graduador solo tiene que verificar que la apariencia LDR producida sea, de hecho, de su agrado, por ejemplo, simplemente pulsando un botón de aceptar antes de que todos los datos (píxeles de imagen metadatos funcionales que describen una o más transformaciones de color a una o más apariencias) se escriban en una codificación de señal de imagen. Para las curvas que favorecen más las imágenes/escenas oscuras que se pueden tomar (por ejemplo, una escena nocturna, sin luces o quizá unas pocas luces pequeñas, como la luna en el fondo), se facilitará habitualmente una parte mayoritaria de los códigos para los colores más oscuros en la escena, que pueden ocurrir al elegir, por ejemplo, un valor mayor de gamma, por ejemplo, alrededor de 2,55 (y se puede elegir un rho óptimo para esto). Para las imágenes que tienen, proporcionalmente, una mayor cantidad de objetos más brillantes (por ejemplo, cuando solo hay un par de zonas más pequeñas con luminancias mucho más oscuras que la luminancia de objeto máxima en la imagen o Lm), se pueden usar valores más pequeños de gamma, por ejemplo, 2 - 2,2 (siendo 2,15 un buen ejemplo), o incluso menor que 2 y mayor que 1, por ejemplo, 1,2.

En correspondencia con el método, puede haber varias variantes de un aparato de codificación de imagen para codificar una imagen de rango dinámico alto, que comprende: una entrada para obtener colores de píxel de una imagen de rango dinámico alto de entrada, en donde los colores de píxel tienen información de una luminancia y una cromaticidad;

- una unidad de gestión de graduación (202) dispuesta para aplicar una inversa de una función de mapeo para obtener un código de luma (v) de la luminancia de un color de píxel, función de mapeo que está predeterminada _{como que comprende una primera función parcial que se define como P=} ov- í _{en la que p es una constante de}ajuste, y v es el código de luma que corresponde a una luminancia que codificar, y un segundo mapeo parcial definido como L = LmPY que es una transformada de gamma, y en donde Lm es una luminancia máxima de una pantalla de referencia predefinida, y gamma es una constante que es preferiblemente igual a 2,4,

- un codificador (210) conectado a una conexión de transmisión de vídeo (221), conectable a una red o memoria de vídeo, dispuesto para codificar y transmitir una señal de imagen S_im que comprende una imagen de matriz de píxeles con colores de píxel codificados con una componente de color que es el código de luma, y asociados con ella unos metadatos que comprenden al menos uno del parámetro rho y gamma. Una variante típica puede ser un conjunto de programas de graduación (el software que el graduador aplica para determinar al menos una imagen HDR, pero ahora con nuestras tecnologías particulares incorporadas para obtener codificaciones y/o apariencias graduadas), pero el aparato también puede estar, por ejemplo, dentro de una cámara, caso en el cual, por ejemplo, rho y gamma se pueden cambiar o bien de forma conjunta o bien simultáneamente con uno o dos botones de mando giratorios. El experto entenderá cómo se puede materializar habitualmente una conexión de transmisión de vídeo 211, ya que esta puede ser, por ejemplo, una salida de cable de vídeo normalizada, un protocolo para encapsular vídeo en, por ejemplo, paquetes de Internet, un hardware protocolizado para escribir en un disco Bluray, etc.

En correspondencia con el codificador, puede haber varios descodificadores que funcionan en gran medida de manera similar, es decir, aunque pueden seguir existiendo algunas variaciones adicionales en el lado tanto de codificador como de descodificador, la esencia de la asignación de código como se describe actualmente debería, una vez codificada, ser entendida de manera única por cualquier receptor.

Un aparato de descodificación de imágenes (301) para descodificar una codificación de imagen de rango dinámico alto (S_im) que comprende:

- una unidad de recepción y formateo (388) dispuesta para recibir la codificación de imagen de rango dinámico alto (S_im) y obtener de ella una codificación de imagen (Im_1) que comprende códigos de luma, que resulta de un método de codificación como se define en la reivindicación 1, que procesar;

- una unidad de mapeo de color (305) dispuesta para aplicar una estrategia de mapeo de color para obtener de la codificación de imagen Tm_1 una imagen de rango dinámico alto (REC_HDR), en donde la unidad de mapeo de color está dispuesta para aplicar en las lumas de píxeles v en la codificación de imagen (Im_1) una función de _{mapeo predeterminada definida como que comprende una primera función parcial que es P= (} ôv _— - _p í _{), en la que rho}es una constante de ajuste, y v es el código de luma correspondiente a una luminancia que codificar, y un segundo mapeo parcial definido como L = LmPY en donde Lm es una luminancia máxima de una pantalla de referencia predefinida, y gamma es una constante que es preferiblemente igual a 2,4 para obtener luminancias L de píxeles de la imagen de rango dinámico alto (REC HDR).

Por supuesto, como una variación, en lugar de o además de la descodificación a un rango de luminancia de referencia [0-5000] y el espacio de color construido a partir de este (por ejemplo, XYZ), varios descodificadores también pueden descodificar a otra imagen como salida. Por ejemplo, además de una salida para emitir una reconstrucción Rec_HDR de una apariencia HDR, el aparato de descodificación puede tener una segunda salida (o la misma salida, dependiendo de lo que un sistema conectado, como una pantalla, solicite como imagen de salida) para una imagen LDR.

Inventamos adicionalmente algunas realizaciones interesantes como:

- determinar una función de mapeo para obtener una imagen de rango dinámico inferior (LDR_CONT) a partir de una imagen de rango dinámico alto de entrada (HDR_ORIG), en donde una correlación de luminancia (L) de un píxel de la imagen de rango dinámico alto (HDR_ORIG) se convierte en una luma (Y) de un píxel de la imagen de ^{rango dinámico inferior (LDR_CONT) aplicando una función determinada como Y = c * log}10^{(a * L1/Y b) d, en}donde los coeficientes se especifican de modo que la función se normalice de tal manera que, para los valores de L e Y en un intervalo [0, 1], un valor L = 0 se mapea con Y = 0, y L = 1 se mapea con Y = 1, y existe una restricción adicional especificada implementando, cerca de un valor de Y en el medio del rango de Y, un cierto comportamiento de la función, de modo que la forma de la función sea controlable con un solo parámetro a, y,

- transmitir a una conexión de transmisión de vídeo (221), conectada a una red o memoria de vídeo, una de la imagen de rango dinámico inferior (LDR_CONT) y la imagen de rango dinámico alto (HDR_ORIG), y al menos el parámetro a.

Esta función logarítmica bien elegida permite generar un mapeo óptimo que entonces puede cuantificarse uniformemente con un error visible mínimo, en particular si se cuenta con solo 10 bits para la componente de luma (y, por ejemplo, 8 bits para las cromaticidades u y v).

La imagen resultante LDR CONT puede denominarse imagen LDR, ya que es un tipo de versión de contraste suavizado de la imagen HDR con efecto de brillo en varias regiones secundarias de luminancia. Si se elige la función de asignación de código correcta, incluso se puede usar este LDR_CONT para la representación directa del programa en una pantalla LDR, pero eso no es necesario para todas las realizaciones de nuestra invención, ya que algunas pueden simplemente usar LDR CONT como un elemento intermedio ficticio para una codificación solo HDR.

Un método de codificación de una imagen de rango dinámico alto en el que la restricción adicional define para un valor de Y en o cerca del medio del rango de Y, una relación funcional entre el valor de L resultante obtenido al aplicar la función exponencial (L1/Y) que es la inversa de la función en la reivindicación 1 y el parámetro a, tal como, por ejemplo, LA1/y(Y = 1/2) = K/a en la que K es una constante. Ventajosamente, se define una suavidad particular de la curva en las regiones en las que se produce la acción más interesante.

Un método de codificación de una imagen de rango dinámico alto en el que el parámetro a tiene un valor por defecto, valor que puede depender de un brillo máximo de una pantalla de referencia típica de una pantalla que usará la señal. Habitualmente, un graduador puede imaginar esta graduación para 1 o quizá un par de rangos de pantallas, por ejemplo, la imagen reconstruida HDR es óptima (es decir, con la menor cantidad de artefactos como aparición de bandas) para, por ejemplo, pantallas de brillo máximo de 5000 nit o cercanas a esa cantidad. En algunas realizaciones, el mapeo funcional FH2L también es interesante entonces ya que la imagen LDR_CONT proporciona una imagen adecuada para, por ejemplo, pantallas alrededor de 200 nit, y puede incluso haber una función adicional, por ejemplo, por escena (o para todo el programa) codificada conjuntamente para obtener una imagen óptima para representarse, por ejemplo, en una pantalla de 15000 nit o 50 nit.

Un método de codificación de una imagen de rango dinámico alto en el que un graduador de color humano determina un valor óptimo de a que transmitir a la conexión de transmisión de vídeo (221).

Preferiblemente, nuestra tecnología en el lado de creación permite seleccionar valores de a óptimos, por ejemplo, para la menor cantidad de artefactos en regiones críticas, o una buena apariencia de color global, etc. El lado de recepción no necesita conocer el algoritmo particular para asociar un valor de a con cualquiera que sea la característica o características físicas de la imagen o imágenes codificadas y/o la pantalla o pantallas deseadas, sino que más bien solo necesita saber qué función (inversa) aplicar, es decir, con qué forma funcional se corresponde el valor de a.

Un método de codificación de una imagen de rango dinámico alto en el que una unidad de análisis de imagen automática (227) determina el valor de a dependiendo de al menos un valor de resumen que caracteriza las luminancias de los píxeles en la imagen de rango dinámico alto (HDR_ORIG), tal como, por ejemplo, una mediana de esas luminancias, o una luminancia delimitadora de un rango de luminancia que se producen. También el graduador humano puede especificar dónde se encuentran los valores interesantes en la imagen, por ejemplo, puede garabatear sobre una imagen, y la unidad 227 puede establecer entonces que estos son, mayoritariamente, colores brillantes, por ejemplo, encontrándose el 95 % por encima del código 0,7.

Puede haber varios algoritmos de decisión diseñados previamente en la unidad de codificación.

Un método de codificación de una imagen de rango dinámico alto en el que las coordenadas cromáticas (u, v) de la codificación de color se obtienen de las coordenadas XYZ CIE de los colores de los píxeles en la imagen de rango ^{dinámico alto (HDR ORIG) mediante ecuaciones fraccionarias del tipo: u= aX+bY+cZ y v= s^+hY+iz, con a}...1 ^constantesy, preferiblemente, con valores: a = 4, b = c = 0, d = 1, e = 15, f = 3, h = 9, g = i = 0, j = 1, k = 15, 1 = 3.

Un aparato de codificación de imágenes para codificar una imagen de rango dinámico alto, que comprende:

- una unidad de gestión de graduación (202) dispuesta para determinar una función de mapeo para obtener una imagen de rango dinámico inferior (LDR_CONT) a partir de una imagen de rango dinámico alto de entrada (HDR_ORIG), en donde una correlación de luminancia (L) de un píxel de la imagen de rango dinámico alto (HDR_ORIG) se convierte en una luma (Y) de un píxel de la imagen de rango dinámico inferior (LDR_CONT) ^{aplicando una función determinada como Y = c * log}10^{(a * L1/Y b) d, en donde los coeficientes se especifican de}modo que la función se normalice de tal manera que, para los valores de L e Y en un intervalo [0, 1], un valor L = 0 se mapea con Y = 1, y L = 1 se mapea con Y = 1, y existe una restricción adicional especificada implementando, cerca de un valor de Y en el medio del rango de Y, un cierto comportamiento de la función, de modo que la forma de la función sea controlable con un solo parámetro a, y,

- un codificador (210) conectado a una conexión de transmisión de vídeo (221), conectable a una red o memoria de vídeo, dispuesto para codificar y transmitir una señal de imagen S_im que comprende una de la imagen de rango dinámico inferior (LDR_CONT) y la imagen de rango dinámico alto (HDR_ORIG), y al menos el parámetro a.

Un aparato de codificación de imágenes que comprende una unidad de interfaz de usuario (203) que permite a un graduador humano seleccionar un valor particular de a.

Un aparato de codificación de imagen que comprende una unidad de análisis de imagen automática (227) dispuesta para determinar un valor particular de a, por ejemplo, basándose en parámetros tales como el brillo máximo de una pantalla para la cual se realiza la codificación y/o estadísticas de luminancia de la imagen de rango dinámico alto (HDR_ORIG).

Un aparato de codificación de imágenes en el que la unidad de gestión de graduación (202) está dispuesta para determinar las componentes cromáticas de los píxeles de la imagen de rango dinámico alto (HDR_ORIG) que, debido a la independencia de la luma, también serían las cromaticidades de la codificación de rango dinámico inferior ^{(LDR CONT) de la entrada HDR original como: u = aX+bY+cZ y v= s^+hY+iz, con a}...1 ^{constantes y, preferiblemente,}con valores: a = 4, b = c = 0, d = 1, e = 15, f = 3, h = 9, g = i = 0, j = 1, k = 15, 1 = 3.

Una señal de codificación de imagen HDR que comprende una codificación de una imagen de valores de píxel y, al menos, un valor del parámetro a de la función de la reivindicación 1.

Aunque algunas realizaciones pueden transferir definiciones de función completas (por ejemplo, para un receptor que puede no tener un conocimiento de la función previamente acordada, o si convencionalmente solo se ha acordado una curva, pero el extremo de creación quiere usar otra curva, que entonces debe indicar a cualquier lado de recepción), si las funciones son simples como en algunas de nuestras realizaciones, la comunicación de meramente uno o unos pocos coeficientes puede ser suficiente para recrear su forma funcional.

Un producto de memoria, como un disco Blu-ray o una tarjeta de memoria, etc., que comprende la señal de codificación de imagen HDR.

- una unidad de recepción y formateo (388) dispuesta para recibir la codificación de imagen de rango dinámico alto (S_im) y obtener de ella una codificación de imagen (Im_1) que procesar;

- una unidad de mapeo de color (305) dispuesta para aplicar una estrategia de mapeo de color para obtener de la imagen Tm_1 introducida una imagen de rango dinámico alto (REC_HDR), en donde la unidad de mapeo de color está dispuesta para aplicar en las lumas de píxeles Y en la codificación de imagen (Im_1) una inversa de la función ^{de mapeo Y = c * log}10^{(a * L1/Y b) d para obtener luminancias L de píxeles de la imagen de rango dinámico alto}(REC_HDR), y a, b, c, d, y y son constantes conocidas por el aparato de descodificación de imágenes.

Como mínimo, un aparato de descodificación (que, en realidad, puede ser una pequeña parte de un CI, y esto puede incluirse en cualquier aparato de consumo o profesional mayor, como, por ejemplo, un televisor, un teléfono, un proyector de cine, un sistema de arranque de visualización durante la producción de un programa, etc.) debe disponerse de modo que pueda seguir nuestro principio de codificación para tener una imagen de rango dinámico alto con potencialmente muchos rangos de luminancia hasta una luminancia muy alta, teniendo todos ellos su información en una imagen empaquetada inteligentemente como si fuera una imagen normal, es decir, debe ser capaz de aplicar la inversa de cualquiera de nuestras funciones de asignación de código convencionales propuestas para la componente acromática, es decir, la luminancia o luma de los colores de objeto HDR como se codifican en lo que es una señal de imagen HDR pero parece una señal de imagen LDR, y entonces hacer una cierta transformación de color compatible con esa definición de luminancia para posibilitar la colocación de luminancias posiblemente altas en una gama de codificación de color convencional. Por lo tanto, puede ser que realmente no sea necesario comunicar nada, por ejemplo, si ciertos sistemas de, por ejemplo, una norma X de tipo MPEG futura usan solo 1 curva de asignación de luma convencional, entonces cualquier receptor conocerá ya los parámetros y los tendrá almacenados en memoria, por ejemplo, en los algoritmos de procesamiento almacenados en esa memoria o, de manera equivalente, en conjuntos de circuitos de tipo CI. Sin embargo, en realizaciones en las que algunas de las curvas pueden variar (por ejemplo, para una escena oscura en una película que usa una curva distinta de la del resto de la película), puede ser el caso que el extremo receptor pueda, con un cierto algoritmo, determinar de forma única qué curva de asignación de código se hubo usado durante la codificación, pero preferiblemente, alguna información se comunica a través de cualquier método para que el extremo receptor también esté absolutamente seguro de qué definición de los códigos de luma Y se usó en esta imagen Im_1. Entonces la unidad o aparato de descodificación esencial mínimo simplemente

Un aparato de descodificación de imágenes (301) para descodificar una codificación de imagen de rango dinámico alto (S_im) según la reivindicación 13, en donde:

- la unidad de recepción y formateo (388) está dispuesta para obtener de la codificación de imagen de rango dinámico alto (S_im) al menos un parámetro que define la forma de la función de mapeo, tal como un valor de parámetro a y, posiblemente, también un valor de gamma y para obtener la inversa de la función de mapeo.

El extremo de creación puede transmitir los parámetros y, debido a que algunas de nuestras realizaciones pueden determinar los otros parámetros si solo se envía 1 parámetro, esta es una manera muy útil de enviar 1 de entre una familia de curvas con un comportamiento diferente con respecto a la asignación de determinadas regiones secundarias del intervalo de luminancia de la imagen HDR a la gama del espacio de códigos. Por ejemplo, gamma puede ser fija y estar acordada previamente, y se envía solo un valor de a, por ejemplo, en alguna parte dentro de o adjunta a los datos de imagen o imágenes, o por medio de una ruta de comunicación separada (por ejemplo, una estación de televisión podría indicar que estará, de ahora en adelante, usando un cierto valor de a, y comunicar esto con regularidad), etc.

Un aparato de descodificación de imágenes (301) para descodificar una codificación de imagen de rango dinámico alto (S_im) según la reivindicación 13 o 14, en el que la unidad de mapeo de color (305) está dispuesta para aplicar una transformación para mapear las componentes u y v de los colores de píxel de la imagen introducida Tm_1 a una representación de color universal como, por ejemplo, un espacio XYZ CIE.

Como se describe en el texto, preferiblemente aplicamos la asignación de dirección de luminancia con una asignación inteligente de los colores en la dirección cromática, de modo que el error total (por ejemplo, deltaE2000) de los colores cuantificados no sea demasiado grande para uso final alguno de la imagen, es decir, al menos el REC_HDR reconstruido, y puede ser incluso una versión procesada adicionalmente del mismo que, por ejemplo, realizan un refuerzo desde el nivel de referencia 5000 nit de la pantalla de referencia para la cual se codificó la seña1HDR a una pantalla de 10000 nit real. Entonces, el descodificador necesita hacer la inversa de este mapeo del espacio de color, que habitualmente se implementará al mapear los colores Yuv a un cierto espacio de color universal como XYZ lineal.

Un aparato de descodificación de imágenes (301) para descodificar una codificación de imagen de rango dinámico alto (S_im) según cualquiera de las reivindicaciones de descodificador anteriores en el que la unidad de mapeo de color (305) está dispuesta adicionalmente para aplicar una segunda estrategia de mapeo de color para obtener una imagen de rango dinámico alto (REC_HDR) una imagen con un rango dinámico de luminancia mayor o menor que el rango dinámico de referencia. Descodificar la imagen codificada al rango de referencia [0-5000 nit] es útil ya que entonces tenemos una imagen real físicamente factible. Por supuesto, habitualmente la pantalla real conectada puede ser, por ejemplo, una pantalla de 1200 nit. Por lo tanto, lo ideal es que, en lugar de simplemente ajustar a escala la pantalla de [0-5000 nit] al blanco máximo de 1200 nit al accionar directamente la pantalla, sea deseable una cierta optimización adicional de la apariencia (esto podría hacerse como una segunda etapa a partir de la imagen de referencia Rec_HDR, o ya inmediatamente como transformación de color algorítmica de una etapa a partir de la codificación de color Yuv). Habitualmente, habrá al menos una imagen derivada, cuyo rango dinámico dependerá de qué rango dinámico típico pudiera asociarse del mejor modo con la apariencia particular codificada en la imagen pixelizada. Si, por ejemplo, LDR se escribió en la señal S_im, puede ser típico que se realice algún aumento de grado, para obtener de la apariencia LDR (de blanco máximo de 100 nit típico) una imagen de accionamiento final HDR para, por ejemplo, una pantalla de 1500 nit. Por supuesto, si la apariencia era HDR, puede estar implicado el descenso de grado para las pantallas LDR y, en general, podrían estar implicadas varias regraduaciones. Para obtener estas nuevas imágenes, en realidad todos los datos (constantes de función para funciones paramétricas como transformaciones de color, tablas de consulta, etc.) para estas diversas funciones de mapeo de luminancia/color (por ejemplo, de HDR a LDR y una apariencia MDR de rango dinámico medio entremedias) pueden en realidad codificarse conjuntamente como varios conjuntos de metadatos pero, por supuesto, el receptor también puede obtener algunos de los mapeos por sí mismo (por ejemplo, si una regraduación de HDR a LDR se codificó conjuntamente como metadatos, el receptor puede obtener su propia estimación de un buen mapeo intermedio para obtener MDR).

En algunos sistemas más simples, nuestra tecnología puede usarse para un solo tipo de sistema "cerrado", y la pantalla HDR (de referencia) óptima prevista puede ser, por ejemplo, de 5000 nit. Sin embargo, puede haber instrucciones funcionales adicionales acerca de cómo mapear una imagen de accionamiento para, por ejemplo, una pantalla de 2000 nit, lo que se hará habitualmente partiendo del REC_HDR, pero podría hacerse de manera diferente, por ejemplo, teniendo también en cuenta los valores en la imagen LDR_CONT/Im_1.

Un aparato de descodificación de imágenes (301) para descodificar una codificación de imagen de rango dinámico alto (S_im) según cualquiera de las reivindicaciones anteriores de descodificador en el que la unidad de recepción y formateo (388) está dispuesta para recibir al menos un brillo máximo de una pantalla de referencia para la cual se codificó la imagen introducida Im_1 y, posiblemente, también un valor de gamma, y obtener de ello la inversa de la función de mapeo.

Hay formas indirectas de definir de forma única una función de asignación de código, por ejemplo, se puede preacordar una serie de funciones que usar para los rangos de brillo máximo de la pantalla (de referencia) prevista. Una pantalla real con otro brillo máximo puede entonces mapear adicionalmente el REC_HDR para que parezca óptimo por sus características, pero al menos necesita saber qué definición de código se usó.

Un aparato de descodificación de imágenes (301) para descodificar una codificación de imagen de rango dinámico alto (S_im) según cualquiera de las reivindicaciones anteriores de descodificador 13 hasta 16 inclusive, en el que la unidad de recepción y formateo (388) está dispuesta para recibir un código tal como un número secuencial que indica cuál de una serie de funciones de mapeo inverso preacordadas debe ser usada por la unidad de mapeo de color (305) para obtener de la imagen introducida Im_1 la imagen de rango dinámico alto (REC HDR).

La codificación y transmisión reales pueden realizarse de varias maneras, por ejemplo, una norma que solo permite 3 curvas diferentes puede transmitir que, para este programa o una parte de una función de programa, se usa "2".

Una pantalla que comprende el aparato de descodificación de imágenes según cualquiera de las reivindicaciones anteriores de descodificador.

Un método de descodificación de imágenes de una imagen de rango dinámico inferior recibida (LDR_CONT) que comprende:

- recibir una codificación de imagen de rango dinámico alto (S_im) y obtener de ella una codificación de imagen (Im_1) que procesar, y

- un mapeo de color al aplicar una estrategia de mapeo de color para obtener de la imagen Im_1 introducida una imagen de rango dinámico alto (REC_HDR), en donde la unidad de mapeo de color está dispuesta para aplicar en ^{las lumas de píxeles Y en la codificación de imagen (Im_1) una inversa de una función de mapeo Y = c * log}10^{(a *}L1/Y b) d para obtener luminancias L de píxeles de la imagen de rango dinámico alto (REC_HDR), y a, b, c, d, y y son constantes conocidas por el método de descodificación de imágenes.

Un método de descodificación de imágenes de una imagen de rango dinámico inferior recibida (LDR_CONT) según la reivindicación 20, en el que la recepción comprende recibir cualquier información que defina de manera única la inversa ^{de una función de mapeo Y = c * log}10 ^(a ^{* L1/Y b) + d.}

La invención se puede realizar de muchas otras formas (parciales) como con elementos intermedios que contienen los requisitos técnicos esenciales de las diversas realizaciones como los parámetros de definición materializados en señales, y se pueden obtener como resultado muchas aplicaciones de la misma, como diversas formas de comunicar, usar, realizar procesamientos de color, etc., las diversas señales posibles, y diversas formas de incorporar los diversos componentes de hardware, o usar los diversos métodos, en sistemas de consumo o profesionales.

Breve descripción de los dibujos

Estos y otros aspectos del método y aparato de acuerdo con la invención serán evidentes a partir de y se explicarán con referencia a las implementaciones y realizaciones descritas en lo sucesivo en el presente documento, y con referencia a los dibujos adjuntos, que sirven meramente como ilustraciones específicas no limitantes que ilustran el concepto más general.

La figura 1 muestra esquemáticamente un ejemplo de una familia de tales curvas de asignación de código de luma utilizables para asociar lo que denominamos genéricamente código de luma, con una luminancia de un objeto que se va a representar, que debe ser usada por el creador de contenido obligatoriamente, para crear una graduación LDR correspondiente a una graduación HDR maestra (graduación HDR que significa habitualmente un ajuste fino de apariencia de color humano después de la captura de cámara, ya sea con una película de celuloide o con una cámara HDR o de alta calidad LDR habitualmente potenciada como una cámara RED, sin embargo, también se podría generar pseudo-HDR de luminancia mejorada en la graduación o el procesamiento de efectos especiales a partir de una captura de cámara LDR, en donde un profesional humano de la coloración mejora los colores, para eliminar limitaciones físicas de la cámara como, por ejemplo, saturación reducida, pero también para mejorar la apariencia artística de los colores según sus preferencias con, por ejemplo, unos corredores apropiadamente oscuros, y esta graduación maestra puede ser bastante compleja y cuidadosamente elaborada);

la figura 2 muestra esquemáticamente una realización de aparatos posibles para graduar y codificar una imagen o imágenes HDR de acuerdo con la presente invención;

la figura 3 muestra esquemáticamente algunos aparatos posibles para usar una imagen o imágenes codificadas de acuerdo con esta invención;

la figura 4 muestra esquemáticamente cómo se puede seleccionar un número (siendo 3 suficiente a menudo) de diferentes funciones de asignación de código de entre el conjunto, dependiente de las características de luminancia de la imagen;

la figura 5 muestra esquemáticamente cómo se puede definir una codificación de componentes cromáticas que pertenece a cualquiera de nuestras posibles codificaciones de luma;

la figura 6 muestra esquemáticamente algunas realizaciones ilustrativas adicionales de cómo nuestra función puede ya incorporar requisitos específicos de sistemas de representación particulares, tales como una iluminancia de entorno de habitación promedio típica;

la figura 7 muestra esquemáticamente algunas definiciones matemáticas ilustrativas para tales funciones;

la figura 8 muestra esquemáticamente algunas de forma equivalente para las curvas elegidas de la figura 6, las etapas DY/Y de las luminancias representadas que ocurren a lo largo del rango de códigos cuando se realiza una etapa de código, lo que está relacionado con las diferencias apenas perceptibles (JND) de los errores de cuantificación de color, en este ejemplo cuando se usa un valor típico de 10 bits para los códigos de luma; la figura 9 muestra esquemáticamente un posible sistema de codificación con codificador y descodificador en caso de que nuestras realizaciones se usen de tal manera que la imagen pixelizada en S_im sea una imagen HDR o, más precisamente, cuando se usan directamente tiene una apariencia mayoritariamente semejante a HDR; la figura 10 muestra esquemáticamente un posible sistema de codificación en caso de que nuestras realizaciones se usen de tal manera que la imagen pixelizada en S_im tenga una apariencia más semejante a LDR o, más precisamente, mayoritariamente semejante a LDR, adecuada para una representación sustancialmente directa en pantallas LDR de un brillo máximo de alrededor de 100 nit, por ejemplo, un brillo máximo de 500 nit, y la figura 11 muestra esquemáticamente solo una posible codificación en una señal de imagen de una imagen HDR, y una imagen LDR correspondiente obtenible paramétricamente de la imagen HDR.

Descripción detallada de los dibujos

Las imágenes/vídeo de rango dinámico alto (HDR_) tienen habitualmente una distribución de luminancia diferente a la de las imágenes/vídeo usados actualmente. En especial, la relación de luminancia de máximo a promedio de los datos de imagen de rango dinámico alto puede a menudo ser mucho más alta ya que, por ejemplo, existen los colores relativamente más oscuros de los objetos reflectantes en la habitación, y luego existen un par de objetos muy brillantes como lámparas o efectos de luz. Mientras que las imágenes LDR se construyen habitualmente con, más o menos, una iluminación única (al menos en las partes importantes de la escena) cuya iluminancia sobre los objetos no varía demasiado (por ejemplo, 4:1), la tecnología de formación de imagen HDR maneja el mundo real que también tiene escenas con iluminación altamente variable, encontrándose algunos objetos bajo un foco brillante y encontrándose otros en las sombras de pasillos oscuros. Pero en el lado de representación, esto también significa que, mediante un mapeo de color, se debe redefinir la apariencia de la imagen HDR para que sea más adecuada para los sistemas LDR, lo que significa especificar lo que denominaremos una graduación o grado LDR. Además, cuando meramente se codifica solo una imagen HDR, la estadística de las luminancias deja de coincidir bien con las asignaciones de código de luminancia de tipo gamma 2,2 conocidas a partir de las diversas tecnologías de codificación LDR.

En la realización no limitante de la figura 2 suponemos que un graduador ya ha preparado una graduación maestra de un HDR_ORIG, que suponemos que es, por ejemplo, una imagen XYZ lineal de 3x16 bits pero, en lo sucesivo, nos centramos en primer lugar en una correlación de luminancia de la codificación de color de píxel (por ejemplo, un código de luma o valor de luminancia), y suponemos que este valor es un valor flotante [0, 1] (el experto entiende cómo hacer realizaciones alternativas en, por ejemplo, una codificación 0...1024, etc.). Suponemos que las funcionalidades de graduación y codificación están en un aparato de graduación 201 pero, por supuesto, también pueden ser aparatos separados (en esencia, estamos enseñando simplemente una unidad de codificación, como una parte de un CI). Una unidad de interfaz de usuario 203 maneja el control de graduación (entrada de usuario USRINP) por un graduador humano (como todas las unidades descritas en el presente caso, esto puede ser, por ejemplo, un C i dedicado, o un software que se ejecuta en un procesador genérico, etc.), y puede conectarse a, por ejemplo, un teclado con selectores o esferas para cambiar valores, en particular pueden ser seleccionables el valor de a de nuestras curvas a continuación, o los valores de rho y gamma, e incluso el valor de Lm. La unidad de gestión de graduación 202 está dispuesta para determinar una curva de mapeo como se explica a continuación, así como para aplicarla a una imagen o imágenes HDR de entrada HDR_ORIG, para llegar, por ejemplo, a una salida LDR de apariencia óptima según el graduador LDR_CONT que puede codificarse de manera convencional, por ejemplo, con una codificación de tipo MPEG como AVC, o similar como VC1, etc. El graduador puede estar mirando habitualmente sus resultados en monitores calibrados conectados, por ejemplo, si está determinando una codificación HDR como una apariencia LDR en S_im, puede estar mirando directamente a la imagen LDR (descodificada a partir de la codificación o, incluso aún antes de la codificación DCT, solo la imagen recoloreada) en un monitor LDR, y simultáneamente en la imagen Rec_HDR que se puede recuperar de la imagen LDR LDR_CONT en un monitor HDR de referencia de un color blanco de habitualmente 5000 nit. El graduador determina una función de mapeo de correlación de luminancia (esto también podría, en principio, ser un mapeo entre R_HDR y R_LDR, etc.) FH2L mediante la cual las luminancias (o lumas) de la imagen HDR se convierten en valores de luma de la imagen LDR (o viceversa, siendo habitualmente reversible esta función, esta función inversa FL2H se puede usar para reconstruir Rec_HDR a partir de LDR_CONT y, habitualmente, una función de aumento de grado FL2H de este tipo se almacena en S_im). En otras realizaciones de nuestro codificador, esto se puede hacer automáticamente, por ejemplo, con una única curva de asignación de código fija (por ejemplo, a medio camino en esta familia de curvas, para ser usada para la película o programa de vídeo actual), o analizando la imagen o un número de imágenes sucesivas (por ejemplo, una toma, una escena o incluso todo el programa) y usando por ejemplo la mediana o una luminancia promedio ponderada o un recuento de apariciones de luma dentro de al menos un rango secundario del rango de luma para seleccionar una curva a través de un conjunto de reglas: cuando X <= mediana <= Y, usar entonces la curva n.° Z. Esta función de mapeo permite por lo tanto obtener la imagen LDR de apariencia óptima como la prefiere el creador de contenidos, una vez que se cuenta, por ejemplo, un el lado de recepción, con una codificación de la imagen HDR o, viceversa, una imagen HDR óptima de una imagen LDR codificada. El mapeo inverso también se puede determinar fácilmente (ya que nuestros mapeos de luminancia son habitualmente invertibles), ya sea en el lado de creación, por ejemplo, en el aparato de graduación 201 o en un lado de recepción, y esta función permite entonces recrear una aproximación cercana (después de los efectos de cuantificación y aproximación de DCT) de la graduación maestra original HDR_ORIG en función de una codificación LDR disponible LDR_CONT. Para el almacenamiento en un extremo receptor o la transmisión al mismo, se podría codificar cualquier combinación de la función de mapeo de HDR a LDR FL2H, su inversa FH2L, la imagen LDR LDR cont y la imagen HDR correspondiente HDR_ORIG (y cualquier aproximación cercana de esas imágenes, por ejemplo, después de una transformación matemática de ahorro de bits). Sin embargo, por razones de presupuesto de bits, tiene sentido almacenar/transmitir solo una de las imágenes. Supondremos que el codificador 210 codifica y formatea (es decir, realiza, por ejemplo, una DCT clásica de tipo codificación MPEG y una codificación por longitud de ejecución, etc.) la primera (serie de) imagen(es) Im_1DR que definen las texturas de los objetos de imagen fija o película, siendo Tm_1 LDR_CONT. También realiza un formateo previamente fijado de la función o funciones de mapeo particulares elegidas FR2R [por ejemplo, una función diferente por escena de la película, o una única para toda la película], por ejemplo, FR2R = FL2H en una señal de imagen total S_im (el experto debe entender que hay varias formas de codificar metadatos en o asociados a una imagen o imágenes, como, por ejemplo, a través de mensajes SEI, en un encabezado de alguna imagen, como una pista de datos separada en un disco, como una señal comunicada por la red que puede obtenerse por separado, y puede haber datos de sincronización como, por ejemplo, un instante de tiempo en la película a partir del cual o en el momento en el que aplicar una función, etc.). El codificador 210, por ejemplo, almacena entonces este Im_1 y metadatos en una memoria 299, como un producto de memoria, como un disco Blu-ray o un dispositivo de memoria de estado sólido, etc., o transmite la señal a través de alguna tecnología de red 211, como, por ejemplo, si la graduación ocurre en un estudio de televisión para una transmisión por secuencias (casi) en tiempo real de una señal de televisión DVB-T, etc. Mostramos una posible conexión de transmisión de vídeo (221) que puede ser, por ejemplo, un bus o cable que va a un disco BD maestro, o un almacenamiento de memoria temporal en un servidor que pertenece al proveedor de contenidos, etc., pero puede haber varias conexiones de este tipo para emitir la señal o señales a través de varios sistemas técnicos, por ejemplo, la antena también puede tener una segunda conexión de salida S_im de este tipo (no dibujada), etc.

Inventamos un par de variantes de una función o funciones de asignación de código OETF (o, viceversa, EOTF) para ser aplicadas preferiblemente, habitualmente en una serie de escenarios normalizados (al menos si no como un mapeo único, entonces una primera etapa en una sucesión de luminancia, y habitualmente también mapeos de color, como mapeo de saturación) para ir entre correlaciones de luminancia HDR (que, por simplicidad, supondremos que son simplemente luminancias, pero también podrían ser, por supuesto, cualquier codificación de tales luminancias) a lumas "LDR". Ventajosamente, estas funciones podrían, por ejemplo, realizar, no necesariamente de forma obligatoria, lo siguiente:

1. El efecto de aplicar las curvas puede percibirse como un cambio de brillo (siendo el brillo el efecto psicovisual de una luminancia representada física).

2. El cambio de brillo debe ser posible en dos sentidos (un brillo tanto más bajo como más alto) y, preferiblemente, debe perderse ninguna o poca información/detalles (es decir, las curvas deben ser invertibles al menos en un espacio de color continuo).

3. Las imágenes resultantes de la aplicación de las curvas deben ser perceptualmente agradables, es decir, el graduador de color humano debería poder crear imágenes agradables o relativamente agradables con ellas (en particular, las relaciones de contraste en los rangos de brillo perceptualmente relevantes deben conservarse razonablemente).

Pero al menos en algunas realizaciones queremos hacer las funciones para que codifiquen óptimamente aquella información en la imagen o imágenes que sea importante (y estamos hablando de imágenes capturadas habitualmente a partir de escenas HDR), en particular no generan un error de cuantificación demasiado grande a lo largo de la mayoría o todos los rangos secundarios del rango de luminancia que codificar. Con esto queremos decir, si realizamos un mapeo a la codificación LDR, y entonces realizamos un mapeo inverso para obtener una aproximación de la graduación HDR maestra original Rec_HDR, no deberíamos haber usado una función de mapeo tal que, por ejemplo, las áreas brillantes se cuantifiquen ahora demasiado burdamente después de un estiramiento de brillo, de modo que, por ejemplo, sea visible una aparición (excesiva) de bandas en las nubes brillantes. Esto se puede determinar habitualmente calculando una medida de error como deltaE2000 para una serie de imágenes de prueba críticas, e indica cuánta diferencia de color verá un ser humano, si ve una pantalla con la graduación maestra no codificada original junto a nuestra representación HDR descodificada Rec_HDR (lo que será habitualmente más crítico que únicamente ver una película HDR descodificada).

Para una buena realización de una familia de funciones de asignación de código de luminancia, tuvimos la idea de que, dado que un fotógrafo o director de fotografía pretende mantener las partes de imagen/vídeo relevantes en la parte media de la escala de exposición o eje de valores de luma para minimizar el riesgo de una excesiva sobreexposición de texturas relevantes (causando pérdida de detalle al recortar en las partes brillantes) o subexposición (causando pérdida de detalle debido a ruido excesivo, es decir, una relación señal-ruido baja), podemos aprovechar esto en el diseño de una tecnología de codificación HDR/lDR. Por lo tanto, el efecto de cambio de brillo (/luminancia) deseado debe actuar/ocurrir alrededor de la mitad de la escala (es decir, en un valor "logarítmico" de 0,5 en el rango normalizado) para proporcionar del mejor modo el resultado deseado sobre los datos de imagen más relevantes. Además, para la formación de imagen h Dr puede ser útil observar críticamente la calidad de al menos las regiones más oscuras, pero también posiblemente algunas regiones más brillantes. Hemos encontrado que los requisitos mencionados anteriormente pueden ser cumplidos por una familia de curvas de naturaleza "logarítmica" que tiene un control lineal en la mitad de la escala.

La parte de la curva logarítmica que podemos aplicar para relacionar la correlación de luminancia LDR y la correlación de luminancia HDR para disminuir el rango dinámico en el mapeo de tonos se puede iniciar desde una primera forma ^{general v = c * log}10 ^(a ^{* x b) + d en donde x es el valor de entrada "lineal" normalizado al rango de 0...1 y v es el}valor de salida "logarítmico", también normalizado al rango 0...1. Para aumentar el rango dinámico, se usan las curvas inversas, que están dadas por

v-d

x = - ¹-⁰- ^~ -- _a - -- ^b --Debe quedar claro que si las luminancias HDR están en el eje x, entonces deberíamos iluminar las regiones oscuras, o comprimir, es decir, usar la forma logarítmica, para obtener valores de luma LDR_CONT en el eje y.

Imponemos restricciones para especificar adicionalmente las curvas. Las primeras dos restricciones vienen dadas por el rango normalizado 0...1 donde los valores de entrada 0 y 1 se mapean a valores de salida idénticos, es decir, cuando v es igual a 0, x también debe ser igual a cero y, cuando v es igual a 1, también x debe ser igual a 1:

-d

0= 10 de lo que se deduce que b = 10-d/c

y

i-d

1= — ^{10 c}-— ^—b que ahora se puede reescribir como 10c ^— * 10c ^—- 10c ^—= a

Por último, imponemos la restricción de que, en la mitad de la escala logarítmica, en v = 1/2, la función debe ser lineal 1/2-d con a (proporcionando un cambio de luminancia lineal en esta posición cuando se varía a), lo que implica que 10 c l d d

^{b = K,} ^{donde K es una constante, que puede reescribirse como 10^}

d 1 1 ^*10^{“ “ - 10“ “ = K. Al combinar las dos últimas}1 ^{restricciones eliminamos el término 10“ c, obteniendo K * (10c-}1^{) = a *(10c-1) que resolvemos sustituyendo y = 10c,}dando K * (J y - 1) = a * (^y-1) con la solución

K 2- 2 * K * a a 2

y = ------ ^ ------La solución es válida para a > 2 * K. Al elegir un valor para K, las curvas se especifican entonces mediante el parámetro único a, que actúa de forma similar a un parámetro de sensibilidad a la luz o de velocidad de película y, por lo tanto, denominamos a al parámetro de índice de exposición para nuestras curvas. El valor que elegimos para K es

K = 8 * V2

ya que este valor de K da como resultado valores para a que corresponden aproximadamente a valores de índice de exposición usados en la práctica.

En la Tabla 1 se da la implementación en código C de las curvas logarítmicas y su inversa, donde los nombres de las variables corresponden a los usados en las ecuaciones anteriores.

T abla 1. Implementación de código ANSI C de las funciones logarítmicas propuestas y su inversa.

En la figura 1 se han representado gráficamente varias curvas ilustrativas de una familia de curvas logarítmicas propuestas, comenzando en a = 32 y aumentando hasta a = 2048 en escalones de un tamaño de escalón de 1/3 (21/3), donde este tamaño de escalón se puede observar fácilmente en la posición intermedia (valor 0,5) de la escala logarítmica.

Así que ahora tenemos un conjunto de funciones controlables mediante un parámetro a. El graduador puede obtener fácilmente el valor de a óptimo para, por ejemplo, una toma/serie de imágenes, por ejemplo, ajustando un botón de mando, y un algoritmo automático de análisis de imágenes puede elegir de manera similar un valor de a óptimo. Y también podemos codificar fácilmente esta relación en una codificación de señal de imagen o vídeo S im, definiendo un tipo de datos que sea, por ejemplo, un valor flotante o entero (ya que no necesitamos muchos valores, podemos codificar nuestros valores de a como, por ejemplo, A * a B para que diferentes valores de a se asignen a, por ejemplo, valores de palabra de código de 8 bits) para almacenar el valor de a seleccionado por el graduador. Entonces, como una alternativa a codificar la curva completa en la señal como, por ejemplo, una LUT, algunas realizaciones de nuestra tecnología pueden (una vez o un par de veces, con el mismo valor por razones de seguridad frente a la corrupción de datos, o diferentes valores de a por razones de adaptabilidad) simplemente codificar el valor de a, y entonces, si las funciones usadas no se han acordado previamente en tiempo de ejecución, sino que se encuentran en una norma, el extremo receptor sabrá inmediatamente qué función real está asociada con el valor de a. En un extremo de recepción, este valor se puede usar entonces para mapear la imagen recibida Im_1DR a una imagen final para ser representada en una TV particular.

Una forma aún mejor de proponer una familia de curvas log gamma es:

L = Lm O v

donde L es la luminancia en cd/m2, v es el valor eléctrico normalizado al rango de 0...1 y Lm es el valor de luminancia máximo de la pantalla en cd/m2. Los valores propuestos de las constantes óptimas p y y en el caso de que se pueda definir solo una curva de asignación de código HDR maestra son p = 25 y y = 2,4.

Podemos corresponder con esa EOTF unas funciones de OETF inversas, que al menos a lo largo del rango se aproximan a este comportamiento con un alto grado de precisión (pero alguien podría desviarse ligeramente para adaptarlas más a cómo se han definido clásicamente las OETF, por ejemplo, haciendo lineal una parte de luminancia más baja), por ejemplo:

donde E es un voltaje normalizado por el nivel de blanco de referencia y proporcional a la intensidad de luz implícita que se detectaría con un canal de color de cámara de referencia R, G, B, es decir, se puede suponer que estos son voltajes lineales resultantes de cargar los contenedores de píxeles R, G y B con fotoelectrones, y E' es la señal no lineal resultante, es decir, el código de luma. Y:

p = 25, a = 1,099 y p = 0,018 para sistemas de 10 bits

p = 25, a = 1,0993 y p = 0,0181 para sistemas de 12 bits

Si se compara con la primera variante, podemos identificar rho con a como:

P = ^ - D 2

Algún razonamiento adicional para obtener funciones de asignación de luma óptimas particulares OETF anteriores: Los sistemas de televisión actuales tienen una característica de transferencia no lineal de extremo a extremo (óptica a óptica). Esta característica de transferencia proporciona la intención de representación correcta para el entorno de visualización de televisión de entorno oscuro típico; véanse, por ejemplo, las secciones 11.9, 19.13 y 23.14, de "The Reproduction of Colour' de R. W. G. Hunt (Sexta ed., Wiley, 2006).

Philips ha investigado la característica de transferencia de sistemas de televisión de extremo a extremo para sistemas de televisión de rango dinámico alto futuros con pantallas de luminancia máxima alta (concretamente, en los experimentos de Philips se aplicó una pantalla con una luminancia máxima de 5 000 cd/m2) y se halló que la característica de transferencia de extremo a extremo actual también es aplicable a estos sistemas futuros. La explicación para esta observación es que la característica de transferencia está determinada por el entorno de visualización de televisión que, para una televisión de rango dinámico alto, será el mismo que para una televisión actual.

La característica de transferencia de extremo a extremo para los sistemas de televisión actuales se determina mediante la concatenación de la OETF (Rec. BT.709 de UlT-R y Rec. BT.2020 de UIT-R) y la EOTF (Rec. BT.1886 de ITU-R) recomendadas.

Por ejemplo, la OETF de la Rec. BT.709 de UIT-R viene dada por:

V= 1,099 L0,45 - 0,099 para 1 > L > 0,018

V = 4,500 L para 0,018 > L > 0

La combinación de esta OETF con la EOTF de gamma 2,4 de la Rec. BT.1886 de UIT-R da como resultado la característica de transferencia de extremo a extremo:

(1,099 L045-0,099)2,4 para 1 > L > 0,018

(4,500 L)24 para 0,018 > L > 0

Philips propone conservar completamente la característica de transferencia de extremo a extremo para sistemas de televisión de rango dinámico alto usando la EOTF propuesta. Esta EOTF tiene la forma normalizada

x = t(— ó v )v

Puede verse que es una concatenación de la función x = ( ^D ^ ^V — ^~ p ^Í )v y la EOTF de gamma 2,4 de acuerdo con la Rec. BT.1886 de UIT-R. Por lo tanto, para conservar la característica de extremo a extremo, la OETF usada con la EOTF propuesta debe ser la concatenación de la OETF actualmente recomendada (Rec. BT.709 de UIT-R y Rec. BT.2020 _{de UIT-R) y la función inversa de x =} ov- _p í _{)v, que es:}

v = ¡Qfl(*'(p-1)+1)

íop(p)

Esta concatenación da como resultado la siguiente OETF (tomando como ejemplo la OETF de la Rec. BT.709 de UIT-R):

V= ¡°fl(l,099 L0,45 — 0,099)(p—l)+l)

íop(p) para 1 > L > 0,018

^{¡Ofl(4.500L(p-l)+l)}

^V=íop(p) ^{para 0,018> L > 0}

Completando el valor propuesto de 25 para p, la OETF se puede simplificar adicionalmente a:

V= ¡Ofl(23.376L°'4S-l,376)

_log( ₂₅₎para 1 > L > 0,018

V_ ¡og(108L+l)

_log( ₂₅₎para 0,018 > L > 0

De forma equivalente, para la Rec. 2020 de UIT-R, la OETF propuesta es:

log(4,5E - ( p - 1 ) 1 )log{p), 0 < E < $

E _•

log {{aE 0AS - {a - 1)) • {p - 1) 1 )/log {p ),p < E < 1

donde E es el voltaje normalizado por el nivel de blanco de referencia y proporcional a la intensidad de luz implícita que se detectaría con un canal de color de cámara de referencia R, G, B; E' es la señal no lineal resultante. Donde:

p _ 25, a _ 1,099 y p _ 0,018 para sistemas de 10 bits

p _ 25, a _ 1,0993 y p _ 0,0181 para sistemas de 12 bits

La forma más sencilla es simplemente aplicar el mapeo para obtener la imagen complementaria (por ejemplo, si el HDR_ORIG se codificó con coordenadas de color de N bits en el disco, la imagen LDR_cont para accionar cualquier TV con un brillo máximo sustancialmente inferior se puede usar simplemente aplicando nuestra función log gamma elegida con el valor de a codificado conjuntamente), pero también se pueden obtener graduaciones intermedias para la representación final como, por ejemplo, se enseña en el documento WO2012/127401.

Nuestra invención se puede usar de varias maneras en varias realizaciones. Por ejemplo, si al graduador no le importa elegir una curva óptima para la imagen/vídeo particular en cuestión, se selecciona una curva por defecto con, por ejemplo, a _ 1100 (y, si el tipo de datos de valor de a en la señal no se ha cargado con valor alguno, el extremo de recepción usará por defecto este valor. Pero, de lo contrario, el graduador puede encontrar que, por ejemplo, una curva de a _ 550 daría mejores resultados, y entonces escribir este valor en al menos una copia del tipo de datos de valor de a en el disco. Si hay más copias, habitualmente habrá también datos de especificación adicionales, como datos de referencia que indican a qué parte de un conjunto de imágenes pertenece esta curva, como, por ejemplo, una marca de tiempo de presentación asociada, etc.

Nuestros métodos se pueden usar cualquiera que sea el formato de la codificación de textura de imagen (Im_1DR) pero, por ejemplo, puede funcionar bien con codificaciones de luma de 10 bits e incluso con codificaciones de luma de 8 bits, como se usa clásicamente (algunas aplicaciones de codificación de imágenes necesitan menos calidad).

Habitualmente, el valor de a elegido que define la forma de la curva dependerá de las características de la pantalla de representación prevista y, habitualmente, de su brillo máximo. Por ejemplo, el graduador puede considerar que, durante la mejor parte de la vida útil de su película, habitualmente se verá en pantallas HDR con un brillo máximo de alrededor de 2000 nit. Entonces, puede usar una curva que puede dar una apariencia óptima en tales pantallas (es decir, cuando se reconstruye el h Dr ) y, posiblemente, también una apariencia razonable en pantallas de brillo máximo más bajo, como un televisor de 600 nit. Por supuesto, si dentro de 20 años la mayoría de los espectadores vieran esta película codificada en HDR en, por ejemplo, pantallas de 15000 nit, aunque todavía puede ocurrir una representación razonable, puede que no sea óptima con esa curva. El creador de contenido puede entonces realizar una nueva codificación con una curva diferente con un valor de a diferente para esas pantallas. Lo que también es posible es no generar una nueva imagen LDR LDR_CONT para ella, sino solo crear ya una nueva curva FL2H para reconstruir la imagen HDR que sea la más apropiada para la categoría de pantallas de aproximadamente 15000 nit.

El graduador o el algoritmo automático también pueden decidir tomar una curva de asignación de código de luma particular de entre la familia en función de las características de la imagen HDR que codificar basándose en características de la imagen que codificar (es decir, el tipo de escena capturada). Si, por ejemplo, contiene solo regiones oscuras (o quizá solo una lámpara brillante pequeña), se podría considerar usar una curva que sacrifique cierta precisión de cuantificación en el extremo brillante, por un aumento de precisión para los colores más oscuros. Esto se puede hacer mediante varios algoritmos de análisis de imágenes, partiendo de los más simples, como determinar la mediana de las luminancias en la imagen y decidir a partir de ella qué valor de a se corresponde con la misma, para verificar rangos de las luminancias disponibles (y, más allá de eso, ningún píxel o pocos píxeles), y determinar curvas dependiendo del tamaño y/o la ubicación del rango de luminancia de objeto actuales (y, por ejemplo, considerando una medida de gradiente de la curva a lo largo de ese rango, que se puede usar en el caso de que una asignación sea realizada por un algoritmo si bien, por lo general, tal conocimiento se asignará al definir el conocimiento humano en un conjunto de reglas: por ejemplo, el diseñador ha creado tres categorías: una para las imágenes que tienen todas las luminancias por debajo de 50 nit, una para las imágenes "de exteriores" en donde todas las luminancias están por encima de 500 nit, y una categoría intermedia y, cuando los algoritmos de decisión encuentren entonces un rango disponible de, por ejemplo, 30-200 nit en la graduación maestra, puede, basándose en un criterio de superposición, seleccionar la curva de asignación de código de rango intermedio)

La figura 4 da un ejemplo de una realización de este tipo. La curva de asignación de luma es ahora una combinación de una función logarítmica y exponencial, con gamma preferiblemente no igual a 1,0:

v -d .

X = (10~ ~ fe)Y

_a

Obsérvese que los códigos de luma (eje horizontal E) se han ajustado a escala a [0, 1] y las luminancias correspondientes en una pantalla de referencia correspondiente se dan de forma logarítmica en escalones (eje y). Por ejemplo, si se desea una única curva para una luminancia máxima de 5000 cd/m2, se puede usar a = 48 * V2 y obtener de ella, por ejemplo, valores de a = 67,8823, b = 2,8284, c = 0,7153, d = -0,3230 y el coeficiente gamma y = 2,35 (para diferentes valores de gamma, los coeficientes a...d serán habitualmente diferentes).

En este ejemplo, suponemos que podemos codificar imágenes HDR con una curva de asignación de luma de referencia 401, que funcionará bien en todas las imágenes HDR posibles, como, por ejemplo, una zona de interiores más oscura con, simultáneamente en la misma imagen, una zona de exteriores soleada. Sin embargo, si ahora tenemos un programa o escena que se desarrolla en un sótano oscuro con solo un par de lámparas brillantes (que solo necesitan representarse brillantes y no precisas de por sí), podemos optar por otra curva ligeramente diferente, que se comporte con una precisión mejor para tales áreas oscuras, es decir, tiene más códigos disponibles en el rango secundario oscuro de las luminancias HDR/eje x. La curva 403 sería adecuada en un caso de este tipo. El otro escenario también puede ocurrir cuando haya muchos píxeles brillantes de zona de exteriores soleada y tal vez un par de píxeles más oscuros que, debido a que la visión humana se ha adaptado a la gran imagen brillante, puede no necesitar cuantificarse con una precisión absoluta. Un escenario de este tipo puede ocurrir, por ejemplo, cuando se filma en exteriores en Tailandia y se puede ver a través de un pequeño portal un poco dentro de un templo (obsérvese que la TV de representación podría decidir iluminar un poco estos interiores oscuros, por lo que nos gustaría, no obstante, que se codificaran de manera razonable). En ese caso, el graduador humano o el aparato/algoritmo de codificación pueden decidir que la curva 402 es una curva mejor para su uso para la codificación LDR_CONT de esa imagen o imágenes HDR.

La figura 6 muestra el mismo razonamiento de EOTF de log gamma total pero ahora al incluir un entorno de visualización previsto, y la figura 7 muestra dos ejemplos que definen cómo calcular esas funciones. La parte en la que reza "LDR" son los valores de código de luma (v) cuantificados en [0, 1], es decir, para una reconstrucción solo HDR habitualmente aplicaríamos simplemente nuestra función exponencial de dos partes como en la reivindicación 1 (es decir, la parte de rho y, entonces, la parte de gamma). La "parte de gamma 2,4" se cambia ahora a una cadena de mapeo pre-gamma, pero incluyendo ahora también un factor que tiene en cuenta la luminancia de entorno oscuro, y la parte inferior de la figura 7 es un resumen equivalente de los mapeos secundarios de gamma superiores, a una OETF de 2,4 y de la Rec. 709:

v = 4,5 L si L < 0,018 y, de lo contrario, v = 1,099L045 - 0,099

(mapeo descendente o determinación de luma a partir de luminancias). LC(a) es nuestra primera parte del mapeo, es decir, la división con rho sin la gamma de 2,4. Las flechas muestran una transformación de tipo aumento de grado con una flecha hacia arriba, es decir, una transformación que, por ejemplo, habitualmente estira los objetos brillantes lejos de los más oscuros y el gris medio, y viceversa. Q es, por ejemplo, una imagen LDR cuantificada de 10 bits normal de acuerdo con la rec. 709. El segundo descenso de grado de Rec. 709 reformatea (redistribuye correctamente a lo largo del eje de luma) la entrada correctamente determinada, de acuerdo con lo que espera como entrada nuestra EOTF maestra de la reivindicación 1. Entonces, el resultado de la cadena superior o inferior de la figura 7 se enviaría habitualmente a un monitor de referencia, es decir, una pantalla real especificada de acuerdo con una gamma de 2,4.

La figura 8 muestra un acercamiento sobre los colores de objeto oscuros, cuando las funciones de la figura 6 se convierten a DY'/Y'.

La figura 3 muestra un ejemplo de un sistema de lado de recepción posible en el hogar o la ubicación profesional de un consumidor, como, por ejemplo, un cine digital. Existen muchas aplicaciones y tipos de aparato que pueden usar nuestra tecnología de descodificación, y pueden comprender una unidad de descodificación como, por ejemplo, un fragmento de un CI, sin embargo, pero solo dilucidamos uno del mismo, ya que el experto puede entender, teniendo nuestras enseñanzas, cómo mapearlo a otros escenarios. Un desformateador 388 desempaqueta y descodifica la señal S_im a partir de cualquiera que sea el formato en el que se registró/transmitió y recibió. En este ejemplo no limitante suponemos que la recepción y el procesamiento inicial son realizados por un cierto aparato de manejo de imágenes 301 (que podría ser una unidad de adaptación multimedios, un reproductor de Blu-ray, un ordenador personal, etc.), que transmite una imagen final correctamente creada - según la desearían las características específicas de la pantalla y, posiblemente, el entorno - que representar en una pantalla 302 (en este ejemplo, la pantalla no tiene capacidad adicional alguna de optimización de color, sino simplemente algunas características colorimétricas determinadas por hardware). Pero, por supuesto, si esta pantalla es más inteligente y, por ejemplo, un televisor, puede ella misma realizar la mayoría o la totalidad de las acciones descritas en el aparato de manejo de imágenes 301. Supondremos, para una explicación simple, que la pantalla es una pantalla HDR (por ejemplo, con un brillo máximo de 5000 nit) y hace que la imagen se represente a través de la tecnología de comunicación de imagen 398, por ejemplo un cable HDMI, etc. Cuanto menos inteligentes sean las pantallas, más parecerá la imagen a través del cable una imagen convencional, como totalmente optimizada en XYZ, o incluso una imagen RGB de accionamiento directo, pero cuanto más inteligente sea la pantalla, más paramétrica puede hacer la imagen, tal como, por ejemplo, cualquiera que sea la imagen codificada LDR_CONT, y los parámetros para obtener la imagen de accionamiento óptima deseada por la propia pantalla. La pantalla (y los metadatos S_im) podrían materializarse para aplicar diferentes estrategias de mapeo de color para diferentes tomas en una película. La señal de imagen S_im presentarse a través de diversas tecnologías de transmisión, por ejemplo, en una memoria portadora física como un disco BD, o mediante una suscripción de tienda de vídeo conectada a la red, cableada o inalámbrica, etc.

En algunas realizaciones, el aparato de manejo de imágenes 301 generará también, o incluso únicamente, una imagen LDR para una segunda pantalla LDR 330 (imagen que puede ser, por ejemplo, directamente la imagen LDR_CONT o una mera transformación colorimétrica de la misma a RGB sin ajustes de rango dinámico o de entorno de visualización, pero también puede ser una segunda imagen, óptima según el graduador, obtenida de la imagen codificada LDR_CONT), que se transmite por secuencias, por ejemplo, a través de una conexión de imagen/vídeo/datos inalámbrica a través de la antena 399, pero la esencia de nuestra invención se puede usar también para crear solo una imagen HDR.

Una unidad de mapeo de color 305 toma, por ejemplo, una imagen codificada LDR CONT a partir de S_im y convierte esta a Rec_HDR, leyendo la función de mapeo f L2H a partir de la señal, o leyendo una función de mapeo FH2L y convirtiéndola internamente a su función de mapeo FL2H inversa.

Debe entenderse que muchos aparatos o sistemas de este tipo pueden construirse a partir de nuestra invención, y esta puede residir en cámaras profesionales o de consumo, cualquier tipo de pantalla (por ejemplo, puede residir en un dispositivo portátil como un teléfono móvil), software de gradación de color, transcodificadores tales como, por ejemplo, dispositivos de mejora de vídeo, sistemas de gestión de vídeo, pantallas publicitarias en, por ejemplo, supermercados, etc.

Hasta ahora solo hemos discutido acerca de qué hacer en el eje de luminancia del espacio de color, pero los colores necesitan una definición tridimensional. Lo que hemos hecho en la dirección Y de luma es estirar y comprimir las coordenadas de color a través de la función de asignación de color, de modo que, en todas partes, escalones iguales sean, visualmente, aproximadamente igual de importantes. Esto significa que, si cuantificamos entonces, tenemos aproximadamente un número igual de códigos para cada región de luminancia que parece similar en contraste, es decir, reducimos la aparición de bandas en todas partes a aproximadamente el mismo grado. Pero el espacio de color es altamente no lineal, y los espacios de color típicos como XYZ o xyY no están bien mapeados a la métrica natural de la visión humana. Por lo tanto, necesitamos hacer un truco similar en la dirección del color.

El inventor ya se dio cuenta antes (véase la solicitud aún no publicada EP12187572) de que se puede descomponer el espacio de codificación en una dirección Y y una dirección cromática de los planos de color (en cualquier caso, este espacio no se usa necesariamente para hacer, por ejemplo, un procesamiento de color de imagen, sino que puede usarse únicamente como un "contenedor de valores" intermedio y, cualquiera que sea la coordenada de color, puede ser suficiente si solo podemos recuperar el original, por ejemplo, XYZ_16 bits de1HDR maestro a través de un mapeo inverso). Vemos esto esquemáticamente en la figura 5. La gama 502 de todos los colores RGB codificables (y es posible que queramos usar un espacio como xyY, de modo que pueden codificarse todos los colores posibles que pueden presentarse físicamente hasta una luminancia máxima definida por la definición del punto blanco de la parte superior de la gama, por ejemplo, 5000 nit) es determinada por el triángulo de color xy y el eje Y de luma 501. Y, más concretamente, qué lumas Y o luminancias L correspondientes define este eje Y mediante su función de asignación de código usada. Conceptualmente, el uso de una función de asignación de código diferente se puede ver como un estiramiento de tipo armónica de todos los colores en la gama de acuerdo con la función de asignación de código. Por ejemplo, si consideramos que la precisión alrededor del medio (Y = 0,5) es insuficiente, podemos elegir otra función logarítmica que estire los valores allí y se comprima en los otros rangos secundarios del eje Y. Si se cuantifica entonces, por ejemplo, cada 1/100 de valor, esta región estirada de luminancias entre, por ejemplo, 500 y 800 nit, puede estirarse entonces a lo largo de 6 códigos de luma en lugar de, por ejemplo, 4. Lo mismo ocurrirá para otras cromaticidades, por ejemplo, el documento EP12187572 define una realización de cómo hacer esto siguiendo la forma funcional logarítmica elegida pero ahora no a lo largo del intervalo de Y de [0, 1], sino a lo largo del intervalo de valores de Y posibles en la gama para esa cromaticidad (x, y) particular. Ahora queremos hacer el mismo truco en la dirección cromática. Se sabe que, aunque sea deseable, la cromaticidad xy universal tiene unas elipses de MacAdam bastante pequeñas en la región azul (B) y unas grandes en la región verde (G). Eso significa cometer un gran error de codificación (cambiar (x, y)_1 a (x, y)_2 en la región verde no tendrá un efecto perceptible tan grande), pero la cuantificación en el área azul se observa más fácilmente. Para poder codificar en todas partes con pequeños errores, queremos asegurarnos de que nuestra codificación finalmente cuantificada distribuye los errores de cuantificación de manera más uniforme. Podemos determinar esto mediante una función de error a lo largo del triángulo (mostrada esquemáticamente en una dimensión a lo largo de una ruta de color en el gráfico 503), y podemos cambiar esto cambiando nuestra función de asignación de cromaticidad (en 504 se muestra esquemáticamente que la ruta H definida como una función de coordenadas uv nuevas es definible también como una función G de x e y), es decir, si una elipse es demasiado larga para una región del espacio de color, podemos estirar el espacio de color en esa región de manera similar, lo que es el equivalente inverso de comprimir la elipse. Esta redefinición puede ser una función altamente no lineal, pero preferiblemente definimos nuestra codificación con una simple. En concreto, se pueden deformar las elipses con una transformada de perspectiva:

u = - a-x-+--b--y+c

d x+ ey—+ f

V = gx+ hy+ i

jx+ ky+ l

En estas ecuaciones, x, y y u, v son triángulos de color, y a...1 son constantes.

Se puede demostrar matemáticamente que esto corresponde a una transformación base en 3D entre el espacio de color definido por los vectores XYZ y el espacio de color como se define por los vectores UVW, que se puede definir mediante una matriz de transformación lineal.

Encontramos útil definir las cromaticidades con un mapeo conocido de la técnica anterior (pero nunca investigado para usarse para la codificación HDR) que tiene una uniformidad razonable:

u = ■ ^4X

X 1SY 3Z

V . 9Y

X 1SY 3Z

En el presente caso, las coordenadas del plano de cromaticidad se determinan directamente a partir de las coordenadas lineales del espacio de color XYZ, por lo que podemos graduar ese espacio y entonces proceder directamente a la codificación de color.

Por lo tanto, lo que hacemos a continuación es que usamos cualquiera de las funciones de asignación de código de luma logarítmicas anteriores, y la usamos como la definición de Y (luma no lineal) de la definición de color Yuv, y usamos la definición anterior para la componente cromática de los colores. Así es como se pueden definir ahora los colores HDR en contraposición a los esquemas de codificación de color LDR clásicos.

Pero, dado que todos esos colores tienen valores en el rango MATEMÁTICO de lo que se esperaría normalmente para las imágenes LDR (por ejemplo, 10 bits para Y', así como u y v) (en particular, el YUV de tipo PAL, que no debe confundirse con Y'uv, o YCrCb como se usa, por ejemplo, en MPEG2), se puede generar la cadena de codificación de imagen adicional (cuantificación, realización de DCT, etc.) con una tecnología de codificación LDR normal. Tras un mapeo inverso en el lado de recepción, volvemos a obtener una imagen HDR real que, no obstante, no podría codificarse de lo contrario con tecnología heredada.

Por supuesto, siguiendo principios técnicos similares, se podrían diseñar espacios de color similares en los que el triángulo de la gama se defina mediante nuestra nueva definición del eje de luma, siempre que se definan de manera convencional de modo que el extremo de recepción de imagen o imágenes pueda recuperar e1HDR maestro original.

La figura 9 muestra esquemáticamente un primer sistema de codificación útil posible, en el que predomina una apariencia HDR, es decir, transferiremos una imagen LDR_CONT que sigue teniendo un rango dinámico relativamente grande (es decir, cuando se muestra directamente en una pantalla LDR, puede, por ejemplo, tener regiones oscuras que son demasiado oscuras para ser lo suficientemente reconocibles, pero se puede obtener una imagen HDR perfecta en el lado de receptor para una pantalla HDR en, por ejemplo, un monitor h Dr de 5000 nit 958, si se conecta). Nuestra EOTF es particularmente conveniente para este escenario, y entonces, por ejemplo, los parámetros rho = 25 y gamma = 2,4 pueden incorporarse a la señal de imagen S_im mediante la unidad de incorporación de parámetros 908.

Partimos de nuestra graduación HDR maestra HDR_ORIG (en el presente caso, la ref. n.° 901, no una unidad de hardware, sino una imagen). La unidad de conversión de color 902 puede realizar una transformación de color, por ejemplo, si el original reside con cromaticidades saturadas en una gama de colores relativamente amplia (como puede suceder, por ejemplo, con algunos colorantes en el material de película) y, por ejemplo, solo se contempla una porción de las pantallas de consumo de los colores primarios típicos de la Rec. 709, esta unidad de conversión de color 902 puede ya generar un mapeo de gama de colores a la gama de la Rec. 709. Un convertidor de rango dinámico 904 aplica algunas funciones, generalmente bajo el guiado artístico de un graduador a través de una unidad de interfaz 903, para obtener una imagen de apariencia LDR 905. Esta imagen LDR puede obtenerse a través de un mapeo de color reversible relativamente simple, pero también puede obtenerse mediante mapeos más complejos e irreversibles (destrucción de datos, el HDR maestro no se puede reconstruir perfectamente es decir, a partir de esa sola imagen). El HDR se mapea ahora de acuerdo con nuestras realizaciones, es decir, usando la inversa de la EOTF de la reivindicación 1, en nuestra codificación Y'u'v' mediante el codificador de color 906. Entonces, la codificación de vídeo ordinaria es realizada por el codificador de vídeo 907, que puede ser, por ejemplo, un codificador HEVC, o algo similar. Por último, en estas realizaciones ilustrativas, los parámetros de nuestras funciones de codificación colorimétrica (al menos uno de rho, gamma y Lm) se incorporan como metadatos en S_im para transmitirse, por ejemplo, como una señal de televisión HDR con formato DVB o ATSC. En el lado de recepción, un receptor realizará una descodificación de vídeo ordinaria con el descodificador 951, descodificador que también se amplía con nuestra tecnología, para obtener una imagen Rec_HDR 952, por ejemplo, en XYZ. Después de una segunda adaptación de gama por el segundo mapeador de color 959, podemos tener en cuenta que el monitor conectado tiene, por ejemplo, capacidades de gama amplia. La unidad de ajuste de pantalla 957 puede realizar ajustes de pantalla adicionales, como, por ejemplo, aplicar nuestras segundas funciones de mapeo de color para obtener una apariencia óptima respecto a la luminancia para la pantalla conectada que es, por ejemplo, una pantalla de 2400 nit, y también pueden manejarse detalles del entorno de visualización o incluso deseos de los espectadores (brillo preferido del espectador). Los diversos parámetros en S_im son extraídos por el extractor de parámetros 950, y algunos de ellos serán utilizables para obtener una buena apariencia LDR. Por lo tanto, en esta realización de sistema, el LDR se obtendrá de1HDR (no exactamente el HDR original, sino la aproximación, muy cercana, en el lado de receptor Rec_HDR), haciendo en primer lugar, por ejemplo, un mapeo de color adicional mediante la unidad de mapeo de color 953, y haciendo entonces la conversión de rango dinámico por el mapeador de luminancia 954, produciendo un vídeo LDR para cualquier monitor LDR conectable 956. Por supuesto, esta reconstrucción de la apariencia LDR a partir del Rec_HDR recuperado imita cómo el LDR se generó en el lado de transmisor, a través de los parámetros. De hecho, algunas realizaciones pueden usarse cuando se considera que ya es suficiente un mapeo con nuestra OETF, que es la EOTF inversa de acuerdo con nuestra reivindicación principal, por supuesto entonces con unos parámetros rho y gamma optimizados para la toma o escena particular, pero en general puede haber funciones adicionales implicadas y almacenadas en S_im, por ejemplo, un estiramiento de contraste de un rango LDR principal en la imagen HDR y un recorte duro fuera de ese rango, etc.

La figura 10 muestra un ejemplo particular de un sistema construido de acuerdo con otra filosofía de qué tipo de imagen LDR_CONT/Im_1 debería codificarse realmente, pero siguiendo aún nuestra tecnología de EOTF.

Los componentes en el lado de transmisor, como el convertidor de rango dinámico 1001 y el convertidor de color Y'u'v' 1002, son similares a los de la figura 9. Sin embargo, usaremos ahora un Tm_1 con una apariencia LDR en el disco. Por lo tanto, la función log gamma aplicada en 1001 para obtener el vídeo LDR puede tener una gamma equivalente (la gamma equivalente de nuestros parámetros rho, gamma convencionales, es decir, cuando se usa simplemente una función gamma plana L = vAgamma es aproximadamente 7) más alta que en la apariencia HDR en un escenario S_im de la figura 9, usando diferentes parámetros rho y gamma, pero para otras escenas también pueden ser inferiores. En cualquier caso, habitualmente ahora usaríamos solo funciones de mapeo de luminancia reversibles, y nuestra EOTF y su inversa OETF cumplen con este criterio. La imagen LDR (aunque habitualmente sigue siendo Y'u'v' en lugar de YCrCb) entra de nuevo en un codificador de vídeo ordinario. Ahora, sin embargo, en el lado de recepción, los parámetros incorporados no se usan para crear una apariencia LDR, sino para crear una apariencia HDR, y la imagen LDR puede enviarse directamente a un monitor LDR. Por lo tanto, para obtener HDR, el LDR a partir de S_im es procesado sucesivamente por un convertidor ascendente de rango dinámico 1050, un convertidor de color 1051 para obtener la apariencia cromática deseada y una unidad de ajuste de pantalla 1052 para obtener la apariencia adecuada para una pantalla particular partiendo de un HDR reconstruido en un rango de referencia como [0-5000]. El experto debe comprender que las realizaciones prácticas adicionales que partan de nuestras enseñanzas actuales pueden, por ejemplo, usar una OETF y EOTF que tiene principalmente la forma de log gamma (es decir, habitualmente tiene, por ejemplo, unos valores de salida según define una función de entre nuestra familia de curvas de rho, gamma para la mayoría valores de entrada a lo largo del rango de valores de entrada posibles [0, 1]), sin embargo, para algunos valores de entrada, el mapeo puede ser algo diferente, por ejemplo, implementando localmente una pendiente diferente y suavizándola gradualmente hasta que se alcancen las partes de log gamma convencionales de la EOTF. Tal desviación se puede hacer en un aparato codificador mediante un algoritmo de análisis de imagen automático, o un graduador que especifique explícitamente un cambio local en la curva, o cualquier manera semiautomática que obtenga cierta orientación del graduador y entonces realice algunos cálculos para llegar a la modificación parcial. Estas curvas pueden, por ejemplo, comunicarse entonces como LUT, aunque también podrían comunicarse de forma paramétrica, por ejemplo, con una forma de modificación local, codificada funcionalmente con uno o más parámetros adicionales (por ejemplo, una modificación de resalte gaussiana, etc.).

La figura 11 muestra un ejemplo de cómo se puede codificar una señal de imagen HDR 1100 teniendo en cuenta las enseñanzas de la presente solicitud. Suponemos que codificamos un conjunto de apariencias de rango dinámico en una escena HDR, para lo que necesitamos poder en el lado de receptor al menos una imagen de rango dinámico alto maestra con potencialmente objetos de luminancias que representar por todo un rango de luminancia de referencia de, por ejemplo, 0,005-5000 nit. Al mismo tiempo, queremos poder volver a determinar, en el lado de descodificación, al menos una imagen de rango dinámico bajo de la misma escena, que se va a determinar en función de la imagen HDR codificada 1101 y unas funciones de mapeo. Como se ha indicado, los bloques de codificación/descodificación serán convencionales como las funcionalidades en, por ejemplo, HEVC, por lo que nos centraremos en las nuevas enseñanzas colorimétricas para hacer posible la codificación HDR en este marco de trabajo.

Por lo tanto, la matriz de luma de píxeles de imagen de la imagen 1101 se determinará mediante una función de "log gamma" de nuestras enseñanzas principales, que define cómo los códigos de luma se relacionan con las luminancias en el rango de luminancia de referencia de, por ejemplo, 0,005-5000 nit. Es decir, la imagen 1101 codifica una imagen HDR. Independientemente de qué sean exactamente los códigos de luma (como quiera que se definan), se pueden transformar durante la descodificación en luminancias de píxeles (o, en la práctica, junto con las componentes cromáticas que, habitualmente, son colores de píxel (u, v) en, por ejemplo, RGB de dominio de gamma o lineal) que se pueden representar en una pantalla de brillo máximo de 5000 nit de referencia. Una pantalla con otras características seguirá entonces realizando una transformación de color de optimización dependiente de la pantalla, habitualmente basándose en las funciones de mapeo de color de metadatos e imagen en nuestra señal 1100. En caso de que se use una EOTF previamente acordada para definir los códigos de luma (con Lm, rho y gamma fijos), no es necesario de por sí codificar la información en ella en la señal de imagen 1100, ya que el descodificador sabe qué función usar. O, si se puede seleccionar una de entre unas pocas funciones fijas, se puede codificar un número de curva 1108 correspondiente (por ejemplo, la curva 3 previamente acordada). El marcador de posición de datos en la señal es complementario a especificar más exactamente la EOTF y no es necesario que se cargue en este último escenario. En un caso de este tipo, se pueden definir (habitualmente, por ejemplo, por escena después de un cambio de escena, es decir, puede ser válido entre dos números de imagen o instantes de tiempo) parcial o totalmente las lumas en la imagen 1101 al cargar un valor de rho 1102, un multiplicador Lm 1109 y/o un valor de gamma 1103. En algunos escenarios, se puede usar otro factor de ganancia 1104. Aunque a veces este podría codificarse con Lm, puede haber escenarios en los que se desea cargar Lm con el valor convencional 5000 para toda la película pero, por ejemplo, codificar una escena relativamente más oscura con un factor de ganancia 1104. En ese caso, si, por ejemplo, las luminancias típicas (que se van a representar en la pantalla de referencia) en la escena caen, por ejemplo, por debajo de 100 nit, con un par de valores atípicos que llegan a 1000, se puede decidir aparentar como si esta fuera una señal diferente hasta 5000 nit. Este estiramiento multiplicativo será realizado por el codificador antes de aplicar la cuantificación y la realización de DCT. El factor de ganancia 5 o 1/5 cargado en el marcador de posición 1104 para los metadatos en la señal sigue especificando entonces cómo el descodificador tiene que dividir, respectivamente multiplicar, la señal descodificada para llegar a la apariencia deseada.

Para algunas funciones de codificación más avanzadas, una desviación de la función log gamma también se puede codificar en el conjunto de números de desviación 1107. Este puede contener, por ejemplo, una especificación de una deformación aditiva o multiplicativa a lo largo de una parte de la función log gamma, creando en algunas regiones secundarias de esa parte un gradiente mayor, respectivamente menor, lo que da como resultado más o menos códigos asignados a varias regiones de objeto de la imagen. Estos números también pueden codificar una transformación funcional de nuestra función log gamma, por ejemplo, dos parámetros L1 y L2 que demarcan un rango secundario de la EOTF en la luminancia o luma, que se ajusta, y algunos parámetros que definen una transformación, por ejemplo, axA2 bx c, en donde x es una coordenada de ejecución en el rango secundario, y las constantes a, b, c están codificadas en los distintos marcadores de posición de números D3, D4,... El codificador sabrá lo que significa la función, ya que habrá algunos mecanismos de codificación preacordados para las deformaciones funcionales.

Entonces, otros metadatos definirán cómo obtener una imagen de apariencia LDR basándose en la imagen HDR 1100 codificada en la señal de imagen. Esta imagen LDR podría ser, por ejemplo, una imagen de menor contraste que muestre todos los códigos disponibles en la imagen HDR (mapeada a LDR con una función gamma adicional, por ejemplo), o una apariencia LDR con contraste que reserve muchos de los códigos de luma LDR disponibles para un rango secundario LDR importante de la escena HDR, y efectúa un recorte o un recorte suave fuera de esa región.

Habitualmente, para hacer un mapeo arbitrario en las lumas (manteniendo por ahora iguales las componentes (u, v)), habrá un marcador de posición de metadatos 1105 para, por ejemplo, contener una LUT suficientemente precisa que codifica la forma de la función de mapeo de lumas 1110 entre las lumas de la imagen HDR 1101 y las de la imagen LDR que se desea codificar conjuntamente de forma paramétrica. Esta función puede tener cualquier forma y ni siquiera es necesario que sea monótona (y, por supuesto, también puede definirse como un mapeo de luminancia, un mapeo máximo de RGB o cualquier mapeo de correlación de luminancia). Además, puede haber un procesamiento de color, por ejemplo, un mapeo de saturación, que puede realizarse con una LUT 1D 1106 definiendo, por luma, un factor de saturación multiplicativo (realizando una modificación de saturación dependiente de luma 1120 para la imagen LDR después del mapeo de tonos a partir de la imagen HDR), o estrategias más complejas, que pueden, por ejemplo, permitir que el graduador haga que algunos objetos que son menos brillantes en LDR sean al menos más coloridos, o de acuerdo con otra filosofía de cambio de saturación. Las versiones simples de la señal pueden tener solo una posición de número de saturación, u otras señales pueden tener una posición adicional en los metadatos para cargar un solo número de saturación, de modo que este único multiplicador se puede aplicar a todos los colores de píxel independientemente de sus luminancias. Este es simplemente un ejemplo de lo que se puede codificar habitualmente en una señal de imagen HDR LDR, y puede haber varios conjuntos de números de este tipo, por ejemplo, para procesar regiones segmentables locales de una imagen, pero debe dar una comprensión suficiente de cómo, de acuerdo con nuestras técnicas presentadas, se puede, de hecho, no solo codificar una imagen HDR de una escena, sino también codificar conjuntamente diversas nuevas apariencias de otro rango dinámico de esa escena, adecuadas para representarse en sistemas de visualización con unas capacidades de rango dinámico diferentes de las del monitor de referencia de, por ejemplo, 5000 nit.

Las componentes algorítmicas divulgadas en este texto pueden realizarse en la práctica (en su totalidad o en parte) como hardware (por ejemplo, partes de un CI para aplicaciones específicas) o como software en ejecución en un procesador de señales digitales especial, o un procesador genérico, etc.

Debería ser entendible para el experto en la materia a partir de nuestra presentación qué componentes pueden ser mejoras opcionales y pueden realizarse en combinación con otros componentes, y cómo las etapas (opcionales) de los métodos se corresponden con medios respectivos de aparatos, y viceversa. La palabra “aparato” en esta solicitud se usa en su sentido más amplio, en concreto un grupo de medios que permiten la realización de un objetivo particular, y puede ser, por ejemplo (una pequeña parte de) un CI, o un dispositivo especializado (tal como un dispositivo con una pantalla), o parte de un sistema en red, etc. También se tiene por objeto que “disposición” se use en el sentido más amplio, por lo que puede comprender, entre otros, un único aparato, una parte de un aparato, una colección de (partes de) aparatos cooperativos, etc.

Debería entenderse que una versión de producto de programa informático de las presentes realizaciones como indicación abarca cualquier realización física de una colección de comandos que posibilitan que un procesador genérico o de fin especial, después de una serie de etapas de carga (que pueden incluir etapas de conversión intermedias, tales como traducción a un lenguaje intermedio, y un lenguaje de procesador final) introduzca los comandos en el procesador, y ejecute cualquiera de las funciones características de una invención. En particular, el producto de programa informático puede realizarse como datos en un soporte tal como, por ejemplo, un disco o cinta, datos presentes en una memoria, datos que viajan mediante una conexión de red -alámbrica o inalámbrica-, o código de programa en papel. Aparte del código de programa, los datos característicos requeridos por el programa pueden materializarse también como un producto de programa informático. Debería ser evidente que, con ordenador, pretendemos indicar cualquier dispositivo capaz de realizar los cálculos de datos, es decir, este también puede ser, por ejemplo, un teléfono móvil. Asimismo, las reivindicaciones de aparato pueden cubrir versiones implementadas por ordenador de las realizaciones.

Algunas de las etapas requeridas para la operación del método, tales como etapas de entrada y de salida de datos, pueden encontrarse ya presentes en la funcionalidad del procesador en lugar de describirse en el producto de programa informático.

Debería observarse que las realizaciones anteriormente mencionadas ilustran en lugar de limitar la invención. El alcance de la invención se define por las reivindicaciones adjuntas.

No se tiene por objeto que signo de referencia alguno entre paréntesis en la reivindicación limite la reivindicación. La expresión “comprendiendo/que comprende” no excluye la presencia de elementos o aspectos no enumerados en una reivindicación. La palabra “un” o “una” precediendo a un elemento no excluye la presencia de una pluralidad de tales elementos.

Claims

REIVINDICACIONES

1. Un método de codificación de un vídeo de rango dinámico alto de imágenes, que comprende las etapas de:

- aplicar una inversa de una función de mapeo para obtener un código de luma (v) de la luminancia de un color de píxel, función de mapeo que está predeterminada como que comprende una primera función parcial que se define como P= en la que p es una constante de ajuste, y v es el código de luma que corresponde a una luminancia que codificar, y un segundo mapeo parcial definido como L = LmPY en la que Lm es una luminancia máxima de una pantalla de referencia predefinida, y y es una constante que es preferiblemente igual a 2,4,

- emitir una matriz de píxeles que tiene una codificación de color que comprende los códigos de luma.

2. Un método de codificación de un vídeo de rango dinámico alto de imágenes de acuerdo con la reivindicación 1, en el que Lm es igual a 5000 nit.

3. Un método de codificación de un vídeo de rango dinámico alto de imágenes según la reivindicación 1 o 2 en el que p es igual a 25.

4. Un método de codificación de un vídeo de rango dinámico alto de imágenes de acuerdo con la reivindicación 1 o 2 en el que la función de y está compuesta por una y equivalente de una y de codificación de Rec. 709 y una función de Y 2,4.

5. Un método de codificación de un vídeo de rango dinámico alto de imágenes de acuerdo con una de las reivindicaciones anteriores en el que los parámetros p y y se optimizan adicionalmente para producir una imagen codificada con buena apariencia de acuerdo con un graduador de color humano en una pantalla de 100 nit, por lo que el al menos uno de los parámetros p y Y es optimizado preferiblemente por un graduador humano.

6. Un método de codificación de un vídeo de rango dinámico alto de imágenes según cualquiera de las reivindicaciones anteriores, en el que las coordenadas de cromaticidad (u, v) de la codificación de color se definen con referencia a una representación XYZ CIE de los colores de los píxeles en la imagen de rango dinámico alto (HDR_ORIG) mediante ecuaciones fraccionarias del tipo:

^{u = a x b Y c z y v = g x h Y iz con a nst es y} _{Y fZ 1 JX kY lZ} ...1 ^{co ant} ₁ ^, _r ^{preferiblemente, con valores: a = 4, b = c = 0, d = 1, e = 15, f = 3, h} _{d X e}

= 9, g = i = 0, j = 1, k = 15, l = 3.

7. Un método de codificación de un vídeo de rango dinámico alto de imágenes según cualquiera de las reivindicaciones anteriores, en el que las coordenadas de cromaticidad (u, v) se definen en relación con un punto blanco predeterminado tal como, preferiblemente, D65.

8. Un método de codificación de un vídeo de rango dinámico alto de imágenes de acuerdo con una de las reivindicaciones anteriores, en el que se forma una señal de imagen (S_im) que comprende una imagen de matriz de píxeles con colores de píxel codificados con una componente de color que es el código de luma, y asociados con ella unos metadatos que comprenden al menos uno del parámetro p y Y.

9. Un aparato de codificación de vídeo para codificar un vídeo de rango dinámico alto de imágenes, que comprende:

- una entrada para obtener colores de píxel de una imagen de rango dinámico alto de entrada, en donde los colores de píxel tienen información de una luminancia y una cromaticidad;

- una unidad de gestión de graduación (202) dispuesta para aplicar una inversa de una función de mapeo para obtener un código de luma (v) de la luminancia de un color de píxel, función de mapeo que está predeterminada como que comprende una primera función parcial que se define como P= (^ —^ ) en la que p es una constante de ajuste, y v es el código de luma que corresponde a una luminancia que codificar, y un segundo mapeo parcial definido como L = LmPY que es una transformada de gamma, y en donde Lm es una luminancia máxima de una pantalla de referencia predefinida, y Y es una constante que es preferiblemente igual a 2,4,

- un codificador (210) conectado a una conexión de transmisión de vídeo (221), conectable a una red o memoria de vídeo, dispuesto para codificar y transmitir una señal de imagen S_im que comprende una imagen de matriz de píxeles con colores de píxel codificados con una componente de color que es el código de luma, y asociados con ella unos metadatos que comprenden al menos uno del parámetro p y Y.

10. Un aparato de codificación de vídeo según la reivindicación 9, que comprende una unidad de interfaz de usuario (203) que permite a un graduador humano seleccionar un valor particular de p y/o y.

11. Un aparato de codificación de vídeo según la reivindicación 9, que comprende una unidad de análisis de imagen automática (227) dispuesta para determinar un valor particular de p y/o y basándose en un análisis estadístico de las luminancias de los objetos presentes en al menos una de las imágenes de rango dinámico alto (HDR_ORIG).

12. Un aparato de codificación de vídeo según cualquiera de las reivindicaciones de aparato de codificación en el que la unidad de gestión de graduación (202) está dispuesta para determinar componentes cromáticas de los píxeles de la imagen de rango dinámico alto (HDR ORIG) como: u = aX+bY+cZ y v = gX+hY+lZ con a...1 constantes y, preferiblemente, con valores: a = 4, b = c = 0, d = 1, e = 15, f = 3, h = 9, g = i = 0, j = 1, k = 15, l = 3.

13. Un aparato de descodificación de vídeo (301) para descodificar un vídeo de rango dinámico alto de codificación de imágenes (S_im) que comprende:

- una unidad de mapeo de color (305) dispuesta para aplicar una estrategia de mapeo de color para obtener de la codificación de imagen Im_1 una imagen de rango dinámico alto (REC_HDR), en donde la unidad de mapeo de color está dispuesta para aplicar en las lumas de píxeles v en la codificación de imagen (Im_1) una función de _{mapeo predeterminada definida como que comprende una primera función parcial que es P=} ov- í _{en la que p es}una constante de ajuste, y v es el código de luma correspondiente a una luminancia que codificar, y un segundo mapeo parcial definido como L = LmPY en donde Lm es una luminancia máxima de una pantalla de referencia predefinida, y y es una constante que es preferiblemente igual a 2,4 para obtener luminancias L de píxeles de la imagen de rango dinámico alto (REC HDR).

14. Un aparato de descodificación de vídeo (301) para descodificar un vídeo de rango dinámico alto de codificación de imágenes (S_im) según la reivindicación 13, en donde:

- la unidad de recepción y formateo (388) está dispuesta para obtener de la codificación de imagen de rango dinámico alto (S_im) al menos uno de los parámetros rho, gamma o Lm.

15. Un aparato de descodificación de vídeo (301) para descodificar un vídeo de rango dinámico alto de codificación de imágenes (S_im) según una de las reivindicaciones anteriores de aparato de descodificación de imágenes, en el que la unidad de mapeo de color (305) está dispuesta adicionalmente para recibir coordenadas de cromaticidad (u, v) para los colores de píxel, y para aplicar una transformación para mapear, junto con la información de las luminancias, las componentes u y v de los colores de píxel de la imagen T m_1 a una representación de color universal como, por ejemplo, una representación de color XYZ CIE, o a una representación de color dependiente del dispositivo como RGB.

16. Un aparato de descodificación de vídeo (301) para descodificar un vídeo de rango dinámico alto de codificación de imágenes (S_im) según cualquiera de las reivindicaciones de descodificador anteriores en el que la unidad de mapeo de color (305) está dispuesta adicionalmente para aplicar una segunda estrategia de mapeo de color usando parámetros de mapeo de color adicionales codificados conjuntamente como metadatos que especifican un mapeo de color a una imagen con un rango dinámico diferente del rango dinámico definido por la imagen de rango dinámico alto (REC_HDR).

17. Una pantalla que comprende el aparato de descodificación de vídeo según cualquiera de las reivindicaciones anteriores de aparato de descodificación.

18. Un método de descodificación de vídeo que comprende:

- recibir un vídeo de rango dinámico alto codificado de imágenes (S_im) y obtener de él una codificación de imagen (Im_1) que procesar, y

- mapear en color aplicando una estrategia de mapeo de color para obtener de la codificación de imagen (Im_1) una imagen de rango dinámico alto (REC_HDR), en donde la unidad de mapeo de color está dispuesta para aplicar en las lumas de píxeles v en la codificación de imagen (Im_1) una función de mapeo predeterminada definida como _{que comprende una primera función parcial que es P= (} ôv _— - _^ í _{-) en la que p es una constante de ajuste, y v es el}código de luma correspondiente a una luminancia, y un segundo mapeo parcial definido como L = LmPY que es una transformada de gamma, y en donde Lm es una luminancia máxima de una pantalla de referencia predefinida, y y es una constante que es preferiblemente igual a 2,4 para obtener luminancias L de píxeles de la imagen de rango dinámico alto (Re C HDR).