MX2015003030A - Proceso para la formacion de imagenes de alto rango dinamico acordado por el propietario de contenido. - Google Patents
Proceso para la formacion de imagenes de alto rango dinamico acordado por el propietario de contenido.Info
- Publication number
- MX2015003030A MX2015003030A MX2015003030A MX2015003030A MX2015003030A MX 2015003030 A MX2015003030 A MX 2015003030A MX 2015003030 A MX2015003030 A MX 2015003030A MX 2015003030 A MX2015003030 A MX 2015003030A MX 2015003030 A MX2015003030 A MX 2015003030A
- Authority
- MX
- Mexico
- Prior art keywords
- image
- data
- transformation apparatus
- dynamic range
- allocation algorithm
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 28
- 230000008569 process Effects 0.000 title description 3
- 230000009466 transformation Effects 0.000 claims abstract description 62
- 241000023320 Luma <angiosperm> Species 0.000 claims abstract description 19
- 238000009795 derivation Methods 0.000 claims abstract description 8
- 238000009877 rendering Methods 0.000 claims description 42
- 230000015654 memory Effects 0.000 claims description 16
- 238000012360 testing method Methods 0.000 claims description 14
- 238000004891 communication Methods 0.000 claims description 11
- OSWPMRLSEDHDFF-UHFFFAOYSA-N methyl salicylate Chemical compound COC(=O)C1=CC=CC=C1O OSWPMRLSEDHDFF-UHFFFAOYSA-N 0.000 claims description 9
- 238000013479 data entry Methods 0.000 claims description 8
- 238000012512 characterization method Methods 0.000 claims description 3
- 230000003287 optical effect Effects 0.000 claims description 3
- 238000002716 delivery method Methods 0.000 claims description 2
- 238000012795 verification Methods 0.000 claims description 2
- 230000001131 transforming effect Effects 0.000 claims 1
- 238000013507 mapping Methods 0.000 abstract 4
- 239000003086 colorant Substances 0.000 description 15
- 235000019557 luminance Nutrition 0.000 description 15
- 230000006870 function Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 238000009826 distribution Methods 0.000 description 4
- 230000005284 excitation Effects 0.000 description 4
- 230000000007 visual effect Effects 0.000 description 4
- 230000015572 biosynthetic process Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 238000001228 spectrum Methods 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 238000013144 data compression Methods 0.000 description 2
- 238000007667 floating Methods 0.000 description 2
- 230000001788 irregular Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- PEDCQBHIVMGVHV-UHFFFAOYSA-N Glycerine Chemical compound OCC(O)CO PEDCQBHIVMGVHV-UHFFFAOYSA-N 0.000 description 1
- 241001085205 Prenanthella exigua Species 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 239000000654 additive Substances 0.000 description 1
- 230000000996 additive effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 230000001815 facial effect Effects 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T5/00—Image enhancement or restoration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/254—Management at additional data server, e.g. shopping server, rights management server
- H04N21/2541—Rights Management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
- H04N21/440218—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4627—Rights management associated to the content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/91—Television signal processing therefor
- H04N5/913—Television signal processing therefor for scrambling ; for copy protection
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Technology Law (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Image Processing (AREA)
- Television Signal Processing For Recording (AREA)
Abstract
Para permitir mayor seguridad para vender películas de HDR (o por los menos experiencias de HDR) incluso cuando algunos de los datos de la película son pirateados, se dispone un aparato de transformación de imágenes (201) para derivar, por ejemplo, una imagen de alto rango dinámico (HDR_PRED) a partir de una imagen de bajo rango dinámico (LDR_CONT) o imagen de cualquier rango dinámico (por ejemplo, una imagen de excitación de pantalla) de una imagen de entrada de cualquier rango dinámico, en donde la derivación comprende la asignación de tonos de lumas de píxeles en la imagen de bajo rango dinámico a lumas de píxeles de la imagen de alto rango dinámico aplicando por lo menos un algoritmo de asignación predefinido (gam), el aparato de transformación de imágenes comprende: una entrada (204) a un sistema de suministro de datos (205) que comprende la imagen de bajo rango dinámico; una entrada de datos segura (206) al por lo menos un dato del algoritmo de asignación predefinido (gam); y una unidad de control (202) dispuesta para administrar el acceso a los datos del algoritmo de asignación predefinido bajo el control de un propietario de contenido artístico en la imagen de bajo rango dinámico, lo cual permite mejor control de la regularidad autorizada del contenido cuando va a renderizarse, lo cual es posible gracias a nuestra estrategia especial de codificación de imágenes de HDR.
Description
PROCESO PARA LA FORMACIÓN DE IMÁGENES DE ALTO RANGO DINÁMICO
ACORDADO POR EL PROPIETARIO DE CONTENIDO
Campo de la Invención
La invención se relaciona con aparatos y métodos y productos resultantes como productos de almacenamiento de datos o de transmisión o señales codificadas, para permitir una provisión segura mejorada de imágenes o video de alto rango dinámico.
Antecedentes de la Invención
Recientemente la captura, visualización y particularmente la codificación de imágenes se ha mejorado desde la denominada formación de imágenes de bajo rango dinámico (LDR, por sus siglas en inglés) (tales como los sistemas clásicos como PAL o MPEG2) a la formación de imágenes de alto rango dinámico (HDR, por sus siglas en inglés). Las iluminancias en la naturaleza pueden variar desde 100,000 lux en luz solar, pasando por iluminaciones típicas de oficinas o cuartos de aproximadamente 500 lux, hasta por ejemplo 0.05 lux bajo la luz de luna en cuarto menguante. Las luminancias (L) en el mundo varían desde mil millones de candelas por metro cuadrado del disco solar, hasta decenas de miles de candelas por metro cuadrado para lámparas, hasta un par de decenas de miles de candelas por metro cuadrado para objetos en la luz solar (como un
Ref.253523
edificio, bordes de nubes, o un papel blanco), hasta centenas o decenas de candelas por metro cuadrado para objetos bajo cielos (bastante) nublados o interiores, hasta 0.1 candelas por metro cuadrado para un papel blanco bajo la luz de la luna, etc. Esto no significa necesariamente que deban representarse estas luminancias en una pantalla exactamente en la misma forma, más bien, la imagen debe verse artísticamente bien, lo que significa que deben haber diferencias de apariencia aproximadas para las luminancias regionales de objetos cuando son representados en la pantalla de visualización. Debe entenderse que la asignación de tonos para la representación en una pantalla particular es con las muchas pantallas que existen hoy en día desacopladas de la captura o la codificación, dando lugar a tres representaciones vinculadas. En general, un requerimiento de la formación de imágenes de HDR para poderla renderizar, por ejemplo una pared blanca brillante a diferencia de una lámpara brillante adyacente, es que sus respectivos píxeles también estén codificados con diferentes valores de lumas (Y). Los sensores o cámaras se hacen cada vez más poderosos porque de hecho pueden capturar la mayoría de muchas de esas luminancias diferentes en el mundo de manera fiel (ya sea con mayor número de electrones dentro del pocilio de un píxel, imágenes expuestas de diferente manera, etc.), y por simplicidad consideraremos su representación de colores
nativos como una codificación de luminancia lineal en [Lmín, Lmáx] + información cromática. Entonces podemos utilizar una definición especificada por completo de manera arbitraria (de acuerdo con los requerimientos deseados, tales como, por ejemplo procesabilidad posterior de la información codificada como abrillantamiento local, o lo relacionado con compresión de datos, etc.) para nuestro códec de transmisión. Finalmente estos datos codificados (Y_C1C2, o similar) de nuevo pueden convertirse de muchas maneras a una representación del lado del renderizado, lo cual por simplicidad podemos igualar con valores de excitación para, por ejemplo, colores de píxeles de LCD. Las pantallas están adquiriendo mayor rango dinámico de renderizado, de tal manera que primeramente pueden representar regiones más brillantes, y en segundo lugar simultáneamente o sucesivamente regiones más oscuras. Esto permite colocar todos estos varios objetos de luminancia a lo largo de la gama representable con colores de salida renderizados óptimos.
Un problema considerable para creadores de sonido es que, a pesar de sus esfuerzos por proteger su contenido de tal manera que puedan venderse legalmente en lugar de ser copiados ilegítimamente, todo tipo de piratas distribuyen el contenido y algunas veces en grandes cantidades. Cuando se diseña un nuevo estándar de codificación de imágenes, además de buscar cómo representar colores de píxeles, por ejemplo,
desde un punto de vista de compresión de datos, se puede tener como objeto diseñar simultáneamente nuevos requerimientos, tales como la capacidad de protección del estándar. Hemos conseguido una manera de codificar imágenes de HDR de tal manera que éstas sean representadas en realidad como imágenes de LDR, más un conjunto de estrategias de transformación para recuperar de nuevo toda la información de efectos de HDR incluidos en ellas de la imagen de HDR original. Por tanto podemos relajar en cierta medida la restricción de protección de contenido. Los datos de imágenes (textura/píxel) pueden piratearse, pero entonces el pirata obtiene una pésima imagen y no la gradación maestra de HDR. La estrategia de transformación, que en nuestra estructura principal es al mismo tiempo una co-codificación de la imagen de gradación de HDR maestra, y una variante de LDR antigua utilizable, puede por lo tanto protegerse fuertemente, por ejemplo, esta otra mitad de la información de HDR en nuestro nuevo códec puede transmitirse con seguridad solo durante la reproducción (y por ejemplo, nunca sale del hardware de un IC procesador de imágenes si nunca se mueve a través de conexiones de datos descifrados, y se borra de la memoria temporal dentro del IC tan pronto como es posible). Esto podría permitir aplicaciones con mejor control cuando el creador de contenido desea vender películas de HDR, por ejemplo puede vender de hecho solo las funciones o algoritmos
de recuperación de HDR.
Breve Descripción de la Invención
Los objetos se realizan por medio de un aparato de transformación de imágenes (201) dispuesto para derivar una primera imagen que comprende lumas que son codificadas para producir en una pantalla de un primer rango dinámico las luminancias correctas deseadas (por ejemplo, colores faciales no muy brillantes, o mayores realces, etc.), la primera imagen siendo, por ejemplo, una imagen de alto rango dinámico (HDR_PRED) para una pantalla de 4000 candelas por metro cuadrado, o por ejemplo, una imagen blanca de pico de referencia de 2000 candelas por metro cuadrado cuando se inicia desde una imagen de entrada definida con respecto a un blanco de pico de referencia más alto, el blanco de pico de referencia definiendo lo que significan estas lumas, porque las luminancias renderizadas deben ser correctas si se visualizan en una pantalla que tiene en realidad una referencia física de blancos de pico de unas 6000 candelas por metro cuadrado que corresponden al blanco de pico de referencia que corresponde al cual se definieron los datos de imagen de entrada, a partir de una segunda imagen de bajo rango dinámico (LDR_CONT), por ejemplo siendo una imagen de menor rango dinámico de, por ejemplo, 100 candelas por metro cuadrado en el caso de un escalamiento de la luminancia desde una imagen de entrada definida de menor rango dinámico, pero
ésta podría ser también una imagen de entrada definida de mayor rango dinámico, por ejemplo, una señal de gradación maestra con brillo de pico de referencia de 6000 candelas por metro cuadrado, en el caso de que la asignación sea una asignación inferior a una imagen óptima para, por ejemplo, una pantalla de blanco de pico de referencia de 2000 candelas por metro cuadrado, en donde la derivación comprende la asignación de tonos de lumas de píxeles en la imagen de bajo rango dinámico a lumas de píxeles de la imagen de alto rango dinámico aplicando por lo menos un algoritmo de asignación (gam) predefinido, el aparato de transformación de imágenes comprende:
- una entrada (204) a un sistema de suministro de datos (205) que comprende la imagen de bajo rango dinámico;
- una entrada de datos segura (206) para el¾por lo menos un dato del algoritmo de asignación predefinido (gam); y
- una unidad de control (202) dispuesta para administrar el acceso a los datos del algoritmo de asignación predefinido bajo el control de un propietario de contenido artístico en la imagen de bajo rango dinámico.
Puede desearse que la existencia de los datos de algoritmo de asignación predefinido (gam) sea lo más estrecho e intermitente posible, de tal manera que sean de difícil acceso, e incluso cuando son copiados, las modalidades harán que sea difícil utilizar en realidad esos datos durante el
renderizado, dado que la segunda fase también estará siempre presente. Pueden haber varios escenarios en los cuales la segunda imagen sea (aunque puede contener la misma información que la textura de píxeles) de menor calidad que el impacto del renderizado de brillo. Por ejemplo, puede tenerse una situación en la cual se hace la conversión con los parámetros de asignación de una imagen de LDR de menor calidad (por ejemplo, de acuerdo con cualquier estándar que hace referencia a códigos de lumas con un blanco de pico de 100 candelas por metro cuadrado) a una imagen de HDR de alta calidad, en la cual, por ejemplo los rayos láser pueden tener un alto brillo, las reflexiones sobre el agua pueden destellar cuando son renderizadas en pantallas de mayor rango dinámico. Pero también cuando la segunda imagen ya es una imagen de alta calidad, por ejemplo, una codificación de colores con referencia a un blanco de pico de referencia maestro de 6000 candelas por metro cuadrado (es decir, teóricamente óptimo para el renderizado en una pantalla real de un blanco de pico de 6000 candelas por metro cuadrado, pero no mucho mayor ni menor), entonces los parámetros de asignación pueden ser para asignar a una pantalla de, por ejemplo, 2000 candelas por metro cuadrado o alrededor de ese blanco de pico, y, por ejemplo, pueden usarse segundos parámetros de asignación para derivar una imagen de renderizado (más) óptima en pantallas en un rango de 2500-
3500 candelas por metro cuadrado de blanco de pico, es decir de aproximadamente 3000 candelas por metro cuadrado. A continuación describiremos los principios no limitantes con un ejemplo de conversión de LDR a HDR, la persona con experiencia en la téenica entenderá desde luego cómo funciona la misma tecnología al intercambiarla en la otra dirección de la asignación de colores/lumas. Es decir, varias modalidades siempre pueden comprobarse para ver si todo es regular y está autorizado, al utilizar cada dato de asignación. Es decir, este sistema hace que el uso no regular sea muy difícil, a menos que desde luego se construyan sistemas enteros, pero los usuarios típicamente compran un aparato de transformación de imágenes regular, o una pantalla, que entonces puede hacerse que se comporte estrechamente de acuerdo con el método autorizado. Mediante esto se puede incluso relajar el sistema, porque en algunas modalidades los datos del algoritmo de asignación predefinido (gam) pueden estar disponibles de manera relativamente libre, pero la regularidad de la situación aún es comprobada por el aparato de transformación de imágenes (201) durante o antes de cada renderizado. El control del propietario puede hacerse de varias maneras (de hecho no es necesario que el propietario sea el propietario de derechos de autor por sí mismo, porque el control puede haberse delegado, pero alguien o algún aparato que funciona para el beneficio de alguien tiene que
dar el consentimiento de que los datos de asignación para hacer el HDR pueden liberarse), pero la unidad de control tiene que comprobarlo. Por ejemplo, el propietario puede indicar que este contenido es gratis (esto puede ser, por ejemplo, información que previamente se difundió, y se almacenó en una memoria del aparato de transformación de imágenes), en cuyo caso los datos de asignación podrían recuperarse de cualquier servidor o fuente (en tales escenarios puede ser solo necesario para hacer una conexión con el servidor estándar de la compañía de producción fílmica para ver que este título de película es gratis (y cualquier información adicional relacionada con ella puede obtenerse gratis, sin ninguna interferencia adicional, después de esta comprobación)). Desde luego, el servidor también puede especificar especificaciones más complicadas de qué derechos tiene alguien independientemente del contenido de imágenes (por ejemplo, qué servidores o entidades tienen permitido proveer datos de asignación), o, por ejemplo, los deseos del propietario previamente guardados en la memoria del aparato de transformación de imágenes de una sesión de comunicación anterior. Por ejemplo, podría especificarse un conjunto de reglas de manipulación para copiar datos de asignación precargados a otro dispositivo de un usuario en el mismo dominio (por ejemplo, cuando se conecta para comprobar sobre la marcha aspectos con el aparato de transformación de
imágenes), por ejemplo que este segundo aparato también debe hacer algunas comprobaciones con el servidor, ya sea en sincronía con una comunicación del aparato de transformación de imágenes o no, etc.
Ventajosamente, un aparato de transformación de imágenes (201) tiene la unidad de control (202) dispuesta para obtener el por lo menos un dato del algoritmo de asignación predefinido a través de la entrada de datos segura (206) en un intervalo de tiempo de aproximadamente el tiempo de renderizado en una pantalla de la imagen de alto rango dinámico (HDR_PRED). La remoción de todo rastro del algoritmo de asignación, incluso de la memoria localizada en lo profundo del hardware, puede aumentar la seguridad para algunos escenarios. Por ejemplo, nadie puede hacer ingeniería inversa en ningún dispositivo.
Ventajosamente, un aparato de transformación de imágenes (201) tiene la unidad de control (202) dispuesta para formar una conexión privada segura en una red tal como la Internet, con un servidor (207) del propietario del contenido artístico. A pesar de que muchos sistemas no necesitarán la seguridad rigurosa, alguien podría implementar medidas de comunicación que eviten la intercepción, incluso si otras medidas hacen que los datos de asignación robados sean menos útiles o sean inutilizables, por ejemplo, debido a que son compatibles con cierta pantalla o aparato de transformación
de imágenes.
Ventajosamente, un aparato de transformación de imágenes (201) tiene la unidad de control (202) dispuesta para enviar datos de identificación de contenido (id_rend) que identifica por lo menos aspectos de la imagen de bajo rango dinámico (LDR_C0NT) tal como por ejemplo, un número de versión o en dónde se compró, y opcionalmente además de datos de identificación del aparato de transformación de imágenes (201) o una pantalla de HDR (290) o un propietario de los aparatos. Al identificar cada vez la situación del renderizado, el servidor 207 ha aumentado la oportunidad para valorar la situación. Por ejemplo, si de pronto el usuario, y el contenido, y/o los aparatos ya no concuerdan, quizás el contenido fue copiado de alguna manera, y está siendo utilizado de manera irregular. Desde luego, si el usuario revendió regularmente su contenido a un usuario nuevo, puede haberlo registrado en el servidor (pero entonces, por ejemplo, pueden comprobarse las especificidades del aparato en una primera reproducción de ese contenido, y sobrescribirse de tal manera que la siguiente vez la situación no se juzgará como inapropiada).
Ventajosamente, un aparato de transformación de imágenes (201) tiene la unidad de control (202) dispuesta para almacenar el por lo menos un dato del algoritmo de asignación predefinido en una memoria (270) de manera cifrada, cuya
memoria puede ser fija o removible. Algunos usuarios o escenarios no querrán comprobar la regularidad en cada renderizado, sino, por ejemplo, una sola vez, en lo que se conoce como inicialización del contenido. Esto puede disponerse, por ejemplo, guardando los datos de asignación, de nuevo de una manera lo más segura o deseable posible.
Ventajosamente, un aparato de transformación de imágenes (201) tiene la unidad de control (202) dispuesta para obtener información de caracterización de un usuario de la imagen de alto rango dinámico (HDR_PRED), tal como, por ejemplo, un código personal o información biométrica. Para hacer más seguro el sistema, por ejemplo, permitiendo que el servidor 207 realice investigaciones más a profundidad, algunas modalidades pueden obtener, e incluso solo trabajar si obtienen varios datos adicionales con respecto a la situación del renderizado.
También, se dispone un servidor que provee datos del algoritmo de asignación predefinido (gam, gam_enc) (207) para recibir una abertura de conexión de datos de cualquier variante del aparato de transformación de imágenes (201), y se dispone para realizar una prueba con base en datos de identificación de contenido transmitidos (id_rend) desde el aparato de transformación de imágenes (201) que prueba si la imagen de bajo rango dinámico (LDR_C0NT) se compró o se obtuvo regularmente, y se dispone para proveer por lo tanto
los datos de algoritmo de asignación predefinido (gam, gam_enc) al aparato de transformación de imágenes (201). El servidor hará una prueba simple o una más compleja antes de liberarlos, para un solo uso o un uso permanente para esa situación de renderizado de hardware, de los datos de asignación.
Típicamente por lo menos desea realizar pruebas simples de cómo se obtuvo el contenido, por ejemplo, puede verificar que contiene un identificador que establece que este contenido se obtuvo masivamente de manera gratuita, o se consideró que ya no estaba regido bajo derechos de autor. Pero el contenido también puede haberse distribuido (como un avance, por ejemplo) de tal manera que después la gente compraría los datos de asignación para la experiencia de HDR. 0 el contenido puede haberse transmitido por medio del servidor 207, o de un servidor conocido, etc. En variantes más complejas el servidor puede hacer más pruebas para evaluar la situación, y no suministrar los parámetros de asignación si juzga que la situación es irregular, o iniciar un proceso en donde ofrece al usuario regularizar la situación, por ejemplo, proporcionar más información haciendo que el servidor confíe en que es un usuario regular y/o que hizo una compra regular, por ejemplo con base en un cuestionario predefinido mostrado en la pantalla.
Ventajosamente un servidor que provee datos del
algoritmo de asignación predefinido (gam, gam_enc) (207) se dispone para realizar pruebas adicionales, específicamente si el aparato de transformación de imágenes (201) es un aparato regular o uno que se comporta inapropiadamente. Esto puede hacerse de varias maneras. Por ejemplo, el servidor puede probar si está liberando los datos de asignación a un dispositivo diseñado por el pirata, emulando un aparato de transformación de imágenes regular (201) de un fabricante de aparatos electrónicos de consumo. Una manera simple de hacer esto es acordar códigos secretos que identifican, por ejemplo, que el aparato fue construido por Philips, cuyo código es enviado entonces por la unidad de control. Pueden hacerse varias pruebas adicionales, que permiten estimar si alguien está hablando con un emulador de PCB recientemente soldado, o con algún software de emulación, etc., por ejemplo, el servidor podría comprobar si sus comunicaciones entran a un IC particular, etc.
Ventajosamente un servidor que provee datos del algoritmo de asignación predefinido (gam, gam_enc) (207) se dispone para mantener una comunicación temporal precisa con el aparato de transformación de imágenes (201) de información parcial de los datos del algoritmo de asignación predefinido (gam, gam_enc). Si los datos de asignación se envían a intervalos, esto no solo permite que el copiado sea más difícil, sino también permite pruebas adicionales. Por
ejemplo, un copiador puede requerir que los datos se envíen con más rapidez, ya sea que tenga prisa de no ser descubierto y bloqueado, o si tiene especificidades insuficientes acerca del orden temporal acordado del suministro de datos (por ejemplo enviar los datos para las primeras tres escenas, y después nada hasta que justo antes de la cuarta escena, o no más de 10 segundos antes de la cuarta escena). Ya sea que esto se mantenga en secreto o no, no todos los piratas pueden molestarse en construir un sistema que emule todos los aspectos posibles, lo cual significaría que pueden tener una experiencia de HDR para parte de la película, haciendo posible que puedan crear buenos avances publicitarios.
Ventajosamente, se dispone un servidor que provee datos del algoritmo de asignación predefinido (gam, gam_enc) (207) para analizar una situación en el lado del renderizado con base en información de por lo menos un aspecto de: la imagen de bajo rango dinámico (LDR_CONT), el aparato de transformación de imágenes (201), una pantalla de HDR conectada (290) para renderizar la imagen de alto rango dinámico (HDR_PRED), características ópticas de un ambiente de la pantalla de HDR (290), y un usuario del aparato de transformación de imágenes (201), y a partir de ello determinar cuál dato, si lo hubiere, del algoritmo de asignación predefinido (gam, gam_enc) enviar al aparato de transformación de imágenes (201). Dependiendo de todos los
aspectos deseados, algunas modalidades podrían enviar varios datos, para por lo menos monitorear o registrar cuán regular o irregularmente se distribuye el contenido, incluso si la provisión de datos de asignación es simple.
Aspectos de nuestra invención pueden realizarse además mediante un método de derivación de una imagen de alto rango dinámico (HDR_PRED) a partir de una imagen de bajo rango dinámico (LDR_CONT), en donde la derivación comprende asignación de tonos de lumas de píxeles en la imagen de bajo rango dinámico a lumas de píxeles de la imagen de alto rango dinámico aplicando por lo menos un algoritmo de asignación predefinido (gam), el método comprende:
- obtener de un sistema de suministro de datos (205) la imagen de bajo rango dinámico; y
- administrar el acceso a los datos del algoritmo de asignación predefinido obtenidos a través de una entrada de datos segura (206) bajo control de un propietario del contenido artístico en la imagen de bajo rango dinámico, y un método de suministro de datos del algoritmo de asignación predefinido (gam, gam_enc) para transformar una imagen de bajo rango dinámico (LDR_C0NT) óptima solo para renderizado de una pantalla de LDR a una imagen de alto rango dinámico (HDR_PRED) óptima para renderizar una pantalla de HDR, mediante una fuente de los datos del algoritmo de asignación predefinido (gam, gam_enc) conectable a un aparato de
transformación de imágenes (201) que tiene una unidad de control (202) dispuesta para administrar el acceso a los datos del algoritmo de asignación predefinido bajo el control de un propietario de contenido artístico en la imagen de bajo rango dinámico, el método realizado por la fuente prueba si el aparato de transformación de imágenes (201) está utilizando una imagen de bajo rango dinámico autorizada (LDR_C0NT), y bajo verificación positiva transmite al aparato de transformación de imágenes (201) los datos del algoritmo de asignación predefinido (gam, gam_enc).
Ventajosamente el método de derivar una imagen de alto rango dinámico (HDR_PRED) hace una conexión privada segura en una red a un servidor (207) en un intervalo de tiempo de aproximadamente el tiempo de renderizado en una pantalla (290) de la imagen de alto rango dinámico. Especialmente si los datos de asignación entran profundamente en los IC (protegidos contra alteración), y son destruidos tan pronto como ya no sean necesarios, podrían hacerse sistemas muy seguros. Pero desde luego alguien podría variarlos de acuerdo con los diferentes componentes y medidas protectoras, para hacer menos estrictos los sistemas de administración para los datos de asignación, y las formas resultantes en las que pueden hacerse o no la imagen o las imágenes de HDR.
Ventajosamente el método de derivar una imagen de alto rango dinámico (HDR_PRED) tiene una unidad de control (202)
en el sitio del renderizado de la imagen de alto rango dinámico (HDR_PRED) que envía datos de identificación de contenido (id_rend) que identifica la imagen de bajo rango dinámico (LDR_CONT) al servidor (207). Cuanto más datos se comuniquen acerca de qué especificidades están en el lado del renderizado, más interferencia puede hacer el propietario del contenido, tal como permitir cierta información bajo ciertas condiciones, suministrar otros datos de asignación más adecuados, etc.
Ventajosamente el método de suministrar datos del algoritmo de asignación predefinido (gam o gam_enc) para transformar una imagen de bajo rango dinámico (LDR_CONT) óptima solo para renderizado de pantalla de LDR a una imagen de alto rango dinámico (HDR_PRED) analiza aspectos de la situación del renderizado como identificables a partir de información acerca de la situación del renderizado recibida a través de una unidad de control (202) en el lado del renderizado. Como se dijo, el servidor puede inferir varias cosas con base en los tipos de información que obtiene por ejemplo, tratar de rastrear cómo obtuvo un usuario, por ejemplo, ciertos datos pirateados (por ejemplo si aparece un lote de las mismas películas pirateadas, el servidor puede probar si también puede descargarlas, por ejemplo si el aparato de transformación de imágenes había almacenado (temporalmente) el sitio web desde el cual se descargó la
película ésta puede comunicarse a el servidor). Desde luego otras variantes del aparato no querrán guardar o revelar tanta información. La información transmitida puede determinarse en gran medida a iniciativa del aparato de transformación de imágenes, o a solicitudes del servidor.
Los datos del algoritmo de asignación comunicados pueden proveerse (y según aplique venderse) con base en varias señales o codificaciones de especificación, almacenadas en varios medios físicos, etc.
Breve Descripción de las Figuras
Éstos y otros aspectos del método y aparato de conformidad con la invención serán evidentes y se entenderán con referencia a implementaciones y modalidades descritas de aquí en adelante, y con referencia a las figuras adjuntas, las cuales sirven simplemente como ilustraciones específicas no limitantes que ejemplifican el concepto más general, y en los cuales se utilizan sombreados para indicar que un componente es opcional, no siendo necesariamente esenciales los componentes no sombreados. El sombreado también puede usarse para indicar que los elementos, que se explican como esenciales, están ocultos en el interior de un objeto, o para cosas intangibles tales como por ejemplo selecciones de objetos/regiones (y la manera en la que pueden mostrarse en una pantalla).
La figura 1 ilustra esquemáticamente cómo codificamos una imagen de HDR como realmente una imagen de LDR, la cual es utilizable en un LDR, pero sin calidad visual suficiente en una pantalla de HDR, a menos que se obtengan los datos del algoritmo de asignación de nuestro método de codificación; y la figura 2 ilustra esquemáticamente uno de los varios aparatos de transformación de imágenes dispuesto para comunicarse, preferentemente en aproximadamente el momento de renderizar la imagen de HDR, típicamente con un servidor del propietario del contenido, que provee los datos del algoritmo de asignación requeridos bajo las condiciones seguras correctas.
Descripción Detallada de la Invención
La figura 2 muestra esquemáticamente un sistema de renderizado que permite el renderizado de imágenes de HDR bajo mayor control del propietario de contenido artístico. Como ejemplo hemos explicado el aparato de transformación de imágenes 201 de nuestra invención reivindicada, por ejemplo, como un decodificador o cualquier aparato del lado del consumidor con capacidad de procesamiento de imágenes. El lector entenderá desde luego que, dependiendo principalmente de qué grado de seguridad es deseable para cualquier aplicación particular, esta configuración puede conformarse de diferentes formas. Por ejemplo, en un sistema estrechamente seguro puede incluirse todo en la pantalla
(desde la unidad de manejo de la comunicación que se comunica con la memoria que almacena el algoritmo de asignación a través de la entrada .de datos seguros 206, incluyendo la unidad de asignación de tonos reales 280, e incluso posiblemente formateadores de señales para calcular las señales de excitación de pantalla reales), incluso en una solo IC. La entrada de datos segura puede ser, por ejemplo, una clavija o un bus de ese IC, por ejemplo conectado a una antena. Si un pirata, por ejemplo, toma señales de excitación de pantalla provenientes de algunas de las clavijas del IC, esta información sería bastante inutilizable para él en vista de la dependencia con la pantalla. Pero desde luego cuando sea suficiente una seguridad menos estrecha, podrían enviarse la imagen de HDR HDR_PRED, por ejemplo, en una codificación estandarizada, ya sea en un bus interno de la pantalla, o como el ejemplo explicativo de la figura 1, un enlace de comunicación de video genérico 291, como, por ejemplo, una conexión HDMI. En tal caso la imagen de HDR puede desde luego cifrarse por medio de un algoritmo acordado entre el decodificador y la pantalla. De hecho, el aparato de transformación de imágenes 201 puede incluso ser un aparato profesional, el cual puede, por ejemplo, usarse en una tienda que ofrece un servicio de compra de películas, o en un lado del servidor de un sistema de distribución de imágenes/videos, etc.
Comenzaremos primero con la figura 1 explicando cómo trabaja nuestro método de codificación de imágenes/video de HDR. El creador de contenido, por ejemplo un estudio fílmico de Hollywood, ha realizado una señal de HDR original de grado maestro HDR_0RIG, la cual puede codificarse por ejemplo con un códec que tiene una representación de lumas de 20 bits lineales. Esta imagen es HDR porque está gradada así para que se vea óptima en pantallas que tienen por lo menos mayor luminancia (típicamente un blanco de pico de más de 1000 candelas por metro cuadrado), y usualmente también negros más profundos, mayor precisión de renderizado de colores, etc. (nos enfocaremos por simplicidad en el componente de luma/luminancia de los píxeles de imágenes, pero desde luego típicamente un sistema también realizará la asignación de colores para arribar a los colores óptimamente renderizados). La señal simplemente no es utilizable en una pantalla de LDR antigua. Primeramente porque está inapropiadamente codificada. En nuestro enfoque típicamente codificamos imágenes, también las imágenes en una forma compatible con sistemas antiguos, es decir con lumas de 10 bits e incluso de 8 bits. Ignorando los colores de píxeles reales, la imagen puede comprimirse entonces y manipularse por medio de un sistema clásico de transmisión de imágenes, por ejemplo, por codificación de MPEG2, AVC, VP8, JPEG, etc. Pero, los colores de píxeles reales también son importantes, y es aquí en donde
nuestro método de codificación añade una segunda fase, de otra manera no funcionaría correctamente. Codificamos la imagen de HDR de tal manera que pueda renderizarse directamente en una pantalla antigua, en otras palabras, se vería de suficiente calidad visual en la pantalla (los colores de los objetos de imagen se aproximan razonablemente como se verían en una escena original, o por lo menos mejor de lo que que podría renderizar una pantalla de HDR, no obstante dada una restricción importante de no perder en esa señal la información de efecto de imagen de HDR). Por lo tanto aplicamos transformaciones que en principio son reversibles (es decir puede deshacerse la asignación de HDR_ORIG a LDR_CONT para obtener HDR_PRED a partir de LDR_0RIG aplicando la estrategia de asignación inversa de lumas/colores), o por lo menos, de tal manera que de nuestra codificación de LDR obtenida LDR_C0NT, podemos recuperar perfectamente (o por lo menos con un error mínimo) como una imagen de HDR estimada asignada HDR_PRED, el grado maestro original HDR_ORIG. Esto significa que los algoritmos que efectúan la asignación de lumas (y colores) deben ser tales que no destruyan la información de HDR. Para enfatizar con más precisión este punto importante: que la información de
HDR, aunque no perfectamente renderizable (por ejemplo, se pueden reunir algunas partes más oscuras de la imagen de tal manera que ya no puedan ser discriminadas por el ojo en una
pantalla de LDR de brillo de bajo pico bajo condiciones típicas de los alrededores), es aún recuperable aplicando algoritmos de asignación (las lumas 10, 11, 12, ... 15 podrían, por ejemplo, asignarse a lumas de HDR 25, 30, 48, ... 100, especialmente si con ello no son visibles muchos artefactos como bandas en la imagen de HDR estimada/reconstruida por asignación. Por lo que aunque podemos decir que LDR_C0NT es una gradación/imagen de LDR, es especial porque aún contiene (debido a que utilizamos la asignación apropiadamente restringida para vincular HDR_ORG y LDR_C0NT) (por lo menos aproximadamente) toda la información de HDR_0RIG de grado maestro.
Si no se aplica la asignación de lumas correctiva a una codificación de incluso 8 bits de HDR_0RIG, se obtendrían imágenes inutilizables para dispositivos antiguos, porque se verían muy distorsionadas colorimétricamente. Por ejemplo, se podría tener una escena de un sótano oscuro con realces brillantes. Dado que la pantalla de HDR de luminancia de pico alto puede renderizar códigos de píxeles de lumas menores con luminancia de salida relativamente alta, podemos asignar lumas de píxeles bajas a todos estos píxeles (por ejemplo, 0...10), y después no tener píxeles con lumas intermedias, y valores (250-255) para las luces brillantes (si fuéseamos a codificar un grado de HDR en una representación de 8 bits). Sin embargo al mostrar esta señal en una pantalla de LDR ésta
se hace binaria. Todos los valores oscuros se ven típicamente como el mismo negro. De esta manera necesitamos aplicar una asignación de lumas F_TMI que previamente abrillanta las lumas oscuras (por ejemplo, 0...5 se convierte a 10...20, con una asignación aditiva y multiplicativa), de tal manera que el cuarto oscuro es aún visible en la pantalla de LDR cuando esta codificación de HDR es renderizada directamente como si fuera una imagen de LDR. Por lo que codificamos la imagen de HDR como si fuese una imagen de LDR, o en otras palabras, codificamos la imagen de HDR y LDR con la misma representación de imagen. Pero, esta imagen de LDR_C0NT no es directamente utilizable para renderizar HDR_0RIG de grado maestro correcto en una pantalla de HDR. Dado que, por ejemplo, hemos abrillantado las partes oscuras del cuarto de tal manera que se verán discriminables en una pantalla de LDR, éstas se verán muy brillantes en una pantalla de HDR, y perderán todo el ambiente sombrío pretendido por el creador de contenido. La solución para corregirlas de nuevo, está en el algoritmo de asignación de lumas inversa FL2H.
Este algoritmo gam puede en algunos escenarios ser tan simple como aplicar una función gamma simple (por ejemplo, luma de HDR Y_HDR = a*Y_LDRAg), incluso para una escena o película completa, o puede ser más sofisticado tomando en cuenta también la optimización local de colores dado que el sistema visual ve apariencias de color de manera relativa.
Por ejemplo, una estrategia de segmentación tosca puede definir algunos umbrales antes que conjuntos de bloques en una imagen. En un escaneo en zigzag antes del bloque (X,Y) se utiliza una primera función de asignación de lumas, después antes del bloque (X,Y) se especifican dos umbrales de lumas de HDR g_l y g_h, indicando que para regiones en posiciones de (X,Y) en adelante que tienen lumas de píxeles entre estos límites, deben tratarse de manera diferente, por ejemplo, una segunda estrategia o un segundo algoritmo de asignación de lumas. Por ejemplo, si una luma de LDR Y_LDR igual a 128 se asignó a Y_HDR = 2099 (en alguna representación acordada, por ejemplo de 20 bits; por simplicidad en la figura hemos realizado el intervalo de lumas de HDR un intervalo flotante [0, 1]) mediante la primera función de asignación de lumas, ahora puede asignarse mediante el segundo algoritmo de asignación a Y_HDR = 200. Por ejemplo, pueden procesarse los blancos de una camisa de tal manera que no brillen mucho. Posteriormente sobre esa misma imagen después del bloque (X+K, Y+L), puede haber el mismo intervalo de valores de Y_LDR en la representación de imágenes de LDR LDR_C0NT, pero esto puede ser una lámpara muy brillante. Puede procesarse de manera diferente para producir lumas Y_HDR muy brillantes por medio de un tercer algoritmo de asignación local.
En cualquier caso, toda la información de los algoritmos de asignación (parámetros funcionales, números de imágenes
tales como, por ejemplo, tiempos de presentación, información de definición de forma local, etc.), son la clave para obtener de nuevo HDR_ORIG de grado maestro original, o por lo menos un HDR_PRED de grado de HDR que se ve (muy) cercano a él. Este grado se verá como se pretende, óptimo en una pantalla de HDR de referencia, o cualquier pantalla brillante que tenga características físicas cercanas a la pantalla de HDR de referencia, y no, por ejemplo, muy brillante en ciertas posiciones, o en general de color incorrecto.
Ahora nuestro sistema permite al creador de contenido especificar qué algoritmos de asignación se utilizarán para obtener la mejor vista, de hecho su grado maestro. Podrían especificar, por ejemplo, diferentes algoritmos de asignación para diferentes pantallas de HDR, como se podría imaginar puede usarse una asignación diferente para asignar un exterior soleado brillante a través de una ventana en una pantalla de 1000 candelas por metro cuadrado versus una pantalla de 25000 candelas por metro cuadrado. Por lo que de esta manera el renderizado puede ajustarlo el propietario de contenido (esto hace que la piratería sea menos fácil, dado que el pirata debe acumular todas las versiones de la asignación, dado que de otra manera si envía la incorrecta a una pantalla nueva, el resultado final aún estará lejos del óptimo, no obteniéndose la experiencia de calidad total pretendida por el creador de contenido). Y esto permite
incluso que el creador especifique algunas vistas diferentes por algunas razones (por ejemplo, podría contemplarse una vista más barata, la cual es como medio HDR). Pero adicionalmente, tener toda esta calidad visual en estos algoritmos de asignación le permiten al creador implementar mucha mayor protección de contenido además de las medidas existentes, y por lo tanto obtener un valor de retorno justo por su esfuerzo. Desde luego el usuario puede optar por ver una versión de baja calidad al poner una versión de LDR pirata (por ejemplo, un LDR_C0NT extraído de algún lugar de un sistema regular) en su pantalla de HDR, y de hecho lo hará si se piden precios excesivos por la experiencia de HDR. Pero si desea la experiencia óptima, con nuestro presente sistema la obtendrá bajo acuerdo del propietario de contenido, habiendo varias variantes que equilibran la seguridad con la facilidad de uso.
Ahora volviendo a la figura 2, explicaremos algunas de las modalidades posibles. El aparato de transformación de imágenes básico 201 inherente en todas las modalidades tiene en primer lugar acceso a través de una entrada 204 a un sistema de suministro de datos 205 que comprende la imagen o las imágenes de LDR_C0NT. Como ejemplo hemos mostrado un disco de blu-ray comprado. De manera interesante, a pesar de que el usuario haya comprado este disco, en algunas modalidades aún no posee toda la información para el
renderizado de HDR, aunque el disco afirma que es un disco de HDR (desde luego siempre puede verlo en un modo antiguo, por ejemplo en una pantalla de LDR). La unidad de control se encarga de esto, por ejemplo, cada vez que se inserta el disco. El lector experto entenderá que el sistema de suministro de datos puede tener muchas otras formas, por ejemplo, puede ser una conexión de red a un servidor proveedor de video. Ésta identifica que el disco es un disco (permitido, comprado regularmente), y puede, por ejemplo, extraer un código de identificación único. Opcionalmente un dispositivo (móvil) 260 (conectado o que puede conectarse) con capacidades de entrada de datos se puede usar para introducir, por ejemplo un código único que actualmente ya está presente en el software. Este dispositivo podría incluso tener mayores medidas de protección, por ejemplo, comunicándose a través del servidor 207 del propietario de contenido para reconocer que es un dispositivo de un usuario regular (y bloquear dispositivos que están, por ejemplo, asignados de forma única a la pantalla en caso de un uso inapropiado, como intentos de piratería). La unidad de control se comunica con el servidor 207 del propietario de contenido, y transmite esta información. Este servidor puede determinar entonces si el usuario desea renderizar un producto debidamente comprado (por ejemplo, desde otro servidor del propietario de contenido, o de alguna
organización permitida para distribuir copias, tal como por ejemplo, versiones de LDR en youtube), o uno obtenido de una fuente de video pirata 210. De hecho, algunas modalidades del aparato también permitirían legitimar contenido inapropiado. Incluso si el usuario obtuvo la imagen o las imágenes de la fuente de video pirata 210 (por ejemplo, a través de otra entrada de datos de imágenes 222), el servidor puede ofrecer reproducir los algoritmos de asignación (gam) antes de ver, por ejemplo el dispositivo móvil que puede ser un teléfono móvil o una computadora portátil, después de lo cual los algoritmos de asignación se envían de cualquier manera. Algunas modalidades de la unidad de control y/o el servidor pueden identificar adicionalmente comprobando cuál LDR_CONT tiene el usuario, ya sea que le envíen una versión de mejor calidad (por ejemplo, si el contenido proviene de la captura de una cámara analógica de cierto renderizado, el comportamiento de colores estará fuera de los valores deseados). Pero si la imagen de HDR no hubiese sido debidamente pagada, el aparato no proporcionará los algoritmos de asignación requeridos, e incluso puede realizar adicionalmente algunas acciones, como investigar la situación y acumular datos del sistema, notificando al usuario de su comportamiento inapropiado, etc.
Después de haber recibido los datos del algoritmo de asignación, ya sean sin procesar (gam) o cifrados (gam_enc)
de acuerdo con algún algoritmo acordado, la unidad de asignación de tonos 280 puede transformar la imagen de LDR LDR_C0NT a la imagen de HDR HDR_PRED, y comenzar el renderizado en la pantalla 290. La conexión 217 puede ser de varias formas dependiendo de los requerimientos. Una variante interesante es cuando el aparato (por ejemplo, incorporado en una pantalla, tal como una televisión) solicita el algoritmo de asignación aproximadamente en el momento que se desea ver, es decir en un intervalo de tiempo de aproximadamente el tiempo del renderizado. Este intervalo de tiempo puede especificarlo el sistema, por ejemplo, confirmarse a solicitud de la unidad de control 202 por medio del servidor 207, y por ejemplo, puede ser un par de días por adelantado. Pero en un sistema de seguridad más estricto, la unidad de control será informada de que el intervalo de tiempo es, por ejemplo, de 10 minutos por adelantado, y que en caso de que no se utilice, tiene que borrar los datos del algoritmo en 2 horas. Por lo que en algunas modalidades, cada vez que se desea renderizar, debe hacerse contacto con el servidor 207, por ejemplo mediante una conexión de Internet de la televisión. Se pueden hacer tales conexiones de varios niveles de seguridad, por ejemplo, incluso puede hacerse una conexión de https (Protocolo Seguro de Transferencia de Hipertexto) o un mecanismo de comunicación similar seguro, de nuevo minimizando en cualquier parte las oportunidades de
piratería. En su lugar, también los parámetros del algoritmo de asignación pueden precargarse todos antes de comenzar la película, descargarse para redes de baja latencia 207 poco antes de que se necesiten, por ejemplo, un par de segundos o minutos antes de un cambio de escena, necesitándose otra estrategia de asignación. Algunas modalidades del aparato de transformación de imágenes 201 pueden disponerse de tal manera que no solo necesitan estos datos de asignación en el tiempo correctamente programado, sino incluso a través de alguna conexión externa (posiblemente incluso de red a servidor de manera predeterminada), haciendo difícil la piratería (dado que no solo de requieren los diferentes algoritmos de asignación, sino también se necesita suministrarlos a través de un dispositivo pirateado agregado el cual emule la obtención correcta; y dado que éste necesita ser conectado a una clavija de un IC internamente en la pantalla en lugar de unirlo, por ejemplo, a un bus USB, las modalidades altamente seguras pueden ser bastante sofisticadas para que el usuario promedio lo realice en cantidades masivas. La persona experta entiende que las varias maneras en las que puede implementarse la correcta sincronización de tiempo de las imágenes de LDR y asignarse, por ejemplo, con los datos de imágenes almacenados y/o la señal (por ejemplo, un disco BD, una señal de una tarjeta de memoria o servidor de video remoto, etc.) puede comprender
códigos de tiempo que identifican y solicitan un algoritmo de asignación "justamente nuevo" o algoritmos de asignación específicos, con el servidor 207 típicamente conociendo (de, por ejemplo, estampas de tiempo de presentación transmitidas) cuáles datos de asignación son necesarios, o el servidor puede administrar todo esto de manera autónoma, e instruir activamente a la unidad de control y/o suministrarle nuevos algoritmos de asignación. Por lo que pueden ocurrir varias cosas vía la unidad de control. Por ejemplo, puede solicitar un nuevo tipo de estrategia de asignación después de que el usuario ha atenuado la luz de su cuarto para ver la película, o, del otro lado del espectro, simplemente puede mostrar un mensaje de que la visión de HDR no es posible o no está permitida, y típicamente sugiere pasos que pueden tomarse para finalizar con una imagen de HDR renderizable. Por lo que el control del propietario de contenido puede ser tan simple como un simple "continuar", típicamente realizado como alguna de muchas estrategias posibles de suministro de datos del algoritmo de asignación a la unidad de control, o puede implicar una situación de determinación compleja, en la cual el servidor 207 analiza las particularidades de la situación de visión del usuario (tal como por ejemplo, la iluminación en su cuarto para ver películas), y entonces propone algoritmos de asignación optimizados en tiempo real para el renderizado óptimo en la pantalla de HDR. Para ello, en las
varias modalidades la unidad de control puede enviar (por sí misma, pero típicamente con la intención del servidor 207), dependiendo también de lo que está acordado con base en consideraciones tales como, por ejemplo, privacidad, un número de valores de datos al servidor 207. Por ejemplo, la unidad de control puede analizar rápidamente el video, y comprobar si la distribución estadística de las lumas en LDR_CONT es como se supone que sebe ser (en una o en una de varias variantes existentes del contenido de imagen), o puede analizar una marca de agua en los datos, para obtener más información acerca de la fuente del contenido (por ejemplo si se copió de una distribución a un cine particular). Puede leer información administrativa almacenada o ingresada en el sistema como la dirección del vendedor, etc. Cuando sea deseable, pueden usarse varios métodos para identificar la compra con el renderizado presente, por ejemplo la unidad de control podría preguntar al usuario si la compra de la película de HDR (o en realidad LDR_C0NT) se hizo por medio de tarjeta de crédito (o solo recordarle que así se hizo), y pedir los últimos cuatro dígitos, algo que es difícil que un pirata haga, a menos que también monitoree esa compra, o que fue su propia compra (pero por lo menos evita robar la copia de alguien más cuya visión podría estar inhabilitada para el usuario regular en algunos sistemas). Nuestras modalidades restringen al mismo tiempo el uso renderizado de la película
(por ejemplo, puede no estar presente ninguna salida de señal, y el aparato 201 podría parar su funcionamiento si su caja es abierta o modificada), haciendo difícil hacer cualquier cosa sino una auto expectación si un pirata se enmascara como un usuario regular, y paga regularmente por una copia. Puede almacenarse todo tipo de información adicional que identifica cómo se obtuvo este contenido (solo para ser renderizado), lo cual podría dar lugar a resultados extraños si se copió, por ejemplo, por el monitoreo de alguna señal en alguna parte. Por ejemplo, puede registrarse que un LDR_CONT regularmente comprado debe residir con una pantalla particular (o varias de ellas, permitiendo por ejemplo ver en el lugar de un amigo conocido y registrado/identificable), y no en otro sitio. En muchos escenarios, por ejemplo, no será necesario que el usuario proporcione algún detalle de la compra (como dígitos de una tarjeta de crédito), dado que el sistema se configurará de tal manera que tenga suficientemente claro de que el contenido se compró regularmente, pero las modalidades pueden ser útiles en otros escenarios.
Pero en segundo lugar, el servidor 207 podría obtener (típicamente con acuerdo explícito del usuario) información del propio usuario, por ejemplo, su nombre almacenado en una memoria en el aparato de transformación de imágenes de la pantalla de HDR 290, o una contraseña para iniciar el
sistema, o el usuario insertando una tarjeta inteligente, etc. Los aparatos avanzados 201 podrían establecer por lo menos la identidad del usuario, por ejemplo usando un sensor de huella digital, el cual puede estar integrado. La unidad de control no necesita enviar en realizad todas las características de esta huella digital al servidor 207, sino solo un resumen de los datos tales como "el usuario usual está utilizando el sistema". Pero sistemas más avanzados podrían onitorear su alguien está viendo una película, por ejemplo, más de 20 veces, quien podría ser un pirata en lugar de alguien que en realidad le gusta la película, especialmente, si esa misma versión (si se identifica detalladamente por usuario o grupo de usuarios) está siendo vista en otras ubicaciones físicas, e incluso también al mismo tiempo. Es decir, el servidor 207 puede implementar algunas estrategias de monitoreo en algunas modalidades además de proporcionar una distribución de datos estrechamente segura, y solicitar los datos necesarios del aparato 201. En tercer lugar, el servidor puede obtener todo tipo de información con respecto a detalles del sistema de renderizado (por ejemplo, brillo o una función de transferencia electroóptica de la pantalla, características de iluminación de los alrededores), etc. Los primeros datos son típicamente para registrar y/o permitir el renderizado de HDR (o aspectos de monitoreo de qué no va de acuerdo con el
uso regular del sistema), mientras que el tercer tipo de parámetros puede ayudar en la optimización de la experiencia del renderizado de HDR mediante la transmisión de los parámetros del algoritmo de asignación más apropiados, si existen varias variantes (que incluso podrían calcularse sobre la marcha). Desde luego en cuarto lugar, todo tipo de información puede comunicarse si el servidor 207 o el aparato 201 son regulares, por ejemplo para evitar que un proveedor de videos piratas emule todo un servicio de validación del propietario de contenido, y esto puede hacerse, por ejemplo, por codificación difícil de un número de direcciones de la Internet en los aparatos 201.
Otras modalidades de menor seguridad ofrecen más libertad a los usuarios. Aunque muchos aparatos como, por ejemplo, televisiones pueden tener acceso a por lo menos una red como, por ejemplo, una conexión de Internet, puede ser que algunos usuarios (por ejemplo, los menos sofisticados), solo quieran algún contenido final, por ejemplo en un BD que también pueden reproducirse (en HDR) en un sistema de pantalla que no tiene una conexión de red (por ejemplo en la parte posterior de su automóvil) . Para ello, algunas modalidades pueden permitir almacenar los algoritmos de asignación en alguna memoria 270 (si en lo profundo del aparato 201 o la pantalla o en una memoria portátil removible), por ejemplo en una parte escribible del BD o
tarjeta de memoria segura, típicamente desde luego de manera estrechamente cifrada. Por ejemplo, pueden usarse claves en contraseñas, o incluso tiempos de descarga de los datos del algoritmo. Un sistema típico puede conectar, por ejemplo, la pantalla portátil (ya sea que en realidad esté presente vía un cable conectado, o por el intercambio de datos posteriormente vía una tarjeta de memoria) al aparato de transformación de imágenes 201, y después definir una estrategia de cifrado para el disco y la pantalla portátil en ese momento. Por ejemplo, los datos del algoritmo de asignación en el disco pueden estar cifrados con base en una clave generada la cual solo se encuentra en el hardware de esa pantalla portátil. Al tener una clave única para una pantalla particular (y medios para su administración y generación (por ejemplo puede generarse parcialmente con base en un identificador en la pantalla)) nuevamente hace muy difícil la piratería, dado que incluso si se copian los datos de asignación, puede ser inutilizable. Dependiendo de cuán fuerte desee un propietario de contenido que sea la protección de datos (usualmente de acuerdo con el fabricante del aparato, y quizás alguna representación de los usuarios), el sistema puede incluso solo funcionar si se proporciona la contraseña correcta (de otra manera inclusa una pantalla HDR o un aparato de transformación de imágenes compatible no lee, dado que no puede utilizarlos, los datos del algoritmo de
asignación), pero del otro lado del espectro podría considerarse también que el sistema está suficientemente protegido con un cifrado mínimo incluso sin cifrado para usuarios regulares, por ejemplo si los parámetros son escritos en el tiempo de inicialización simple directamente en una memoria interna de la pantalla portátil, típicamente con un identificador de las imágenes o la película a la cual se suscribe). De esta manera este acto de regularización puede suceder una sola vez, por ejemplo, en el momento en el que un usuario compra un disco, él inmediatamente lo regulariza en casa, en donde tiene todos los componentes téenicos necesarios (y contraseñas escritas u otras cosas) disponibles. Algunos usuarios pueden sin embargo no desear eso, por ejemplo, cuando compran contenido en vacaciones que desean ver inmediatamente, o cuando poseen un sistema insuficiente (por ejemplo, sin Internet en casa), etc. Para estos usuarios puede disponerse en una tienda una modalidad del aparato de transformación de imágenes. Durante la compra, por ejemplo, se regulariza un BD "blanco" (es decir uno con solo la codificación de LDR LDR_C0NT, pero no los datos del algoritmo de asignación), lo cual puede hacerlo el vendedor de la tienda por medio de su aparato conectando al servidor 207, y almacenar los datos del algoritmo, por ejemplo, en un sector escribible de la memoria portátil que contiene la película. La modalidad del aparato 201 puede, por ejemplo
estar conectado o conectarse a un teclado para ingresar un código privado de usuario, etc. Algunas variantes pueden solicitar alguna identificación del hardware del usuario, por ejemplo, la televisión escribe su código cifrado en una tarjeta de memoria, la cual está unida al aparato 201 en la tienda. Ventajosamente, si la tienda envía inmediatamente alguna información de la compra al servidor 207, éste puede ayudar en la regularización una segunda vez (quizás en la casa del usuario y no de nuevo en la tienda), por ejemplo, si el usuario ha olvidado su contraseña.
Por simplicidad podemos llamar gam al algoritmo, dado que no existe confusión con los datos que lo especifican (por ejemplo, por lo menos un coeficiente de una baja energía, o un código de software que predefine alguna transformación de color, etc.). Asimismo el lector experimentado entenderá que la unidad de control 202 puede comprender (o conectarse a) varias otras unidades, tales como una unidad de comunicación dispuesta para aplicar el protocolo de comunicación requerido, formatear y proteger datos, etc., o una unidad de interfaz de usuario que le permite comunicarse con el usuario, y por ejemplo, mostrar una ventana para asegurar la entrada de información financiera en su pantalla portátil para regularizar un LDR_CONT irregular, etc. Debe estar claro cómo puede hacerse el procesamiento de imágenes (asignación de colores, (DCT), (des)compresión, etc.), y sin necesidad de
ahondar en detalles de la excitación de la pantalla, etc. Nótese que desde luego el aparato 201 puede conectarse a varios servidores, para permitir a varios propietarios, de manera coordinada o independientemente, para especificar los datos de asignación para subpartes de, por ejemplo, una película o un programa. Puede pensarse, por ejemplo, en material en el cual el material de otro proveedor está intercalado, o incluso, aunque algunos productores de Hollywood pueden poseer la película, la asignación para los gráficos en algunas escenas puede suministrarse desde un servidor del estudio de efectos especiales directamente, mientras que otros datos de asignación pueden, por ejemplo, provenir de un servidor centralizado de Disncy o Paramount. También debe estar claro a lo que nos referimos con lumas de asignación desde una primera hasta una segunda representación de colores. Un luma es un código téenico (por ejemplo, Y= [0,255]) el cual tiene una asociación a través de una curva de definición de tonos con una luminancia final, ya sea, por ejemplo, capturada por cámara o un renderizado de pantalla referido. Pueden existir varias realizaciones técnicas alternativas, por ejemplo, en una representación lineal esta tercera coordenada de color podría ser la propia luminancia, pero un lector con suficiente experiencia técnica debe entender perfectamente lo que es (por simplicidad pretendemos que los intervalos de lumas sean flotantes (excepto para
LDR_CONT que suponemos de 8 bits clásicos con gamma 2.2, etc.), pero desde luego también puede, por ejemplo, asignarse desde 10 bits hasta unos 15 bits de definición de lumas).
Los componentes algorítmicos descritos en este texto pueden (completamente o parcialmente) realizarse en la práctica como hardware (por ejemplo, partes de un IC de aplicación específica) o como software en un procesador de señales digitales especial, o un procesador genérico, etc. Pueden ser semiautomáticos en un sentido en el que por lo menos puede estar presente o ha estado presente alguna entra del usuario (por ejemplo, en fábrica, o entrada del consumidor, u otra entrada humana).
Debe entenderse por parte de aquellos con experiencia en la téenica a partir de nuestra presentación que los componentes pueden ser mejoramientos opcionales y pueden realizarse en combinación con otros componentes, y cómo corresponden pasos (opcionales) de métodos con medios respectivos de aparatos y viceversa. El hecho de que algunos componentes se describan en la invención en cierta relación (por ejemplo, en una sola figura en cierta configuración) no significa que no sean posibles otras configuraciones como modalidades bajo el mismo pensamiento inventivo como se describe para fines de patente en la presente. También, el hecho de que por razones pragmáticas solo se haya descrito un espectro limitado de ejemplos, no
significa que otras variantes no puedan ubicarse dentro del alcance de las reivindicaciones. De hecho, los componentes de la invención pueden conformarse en diferentes variantes a lo largo de cualquier cadena de uso, por ejemplo, todas las variantes de un lado de creación como un codificador puede ser similar o corresponder a aparatos correspondientes en un lado del consumo de un sistema descompuesto, por ejemplo, un decodificador y viceversa. Varios componentes de las modalidades pueden codificarse como datos de señal específica en una señal para transmisión, o uso adicional como coordinación, en cualquier teenología de transmisión entre el codificador y el decodificador, etc. La palabra "aparato" en esta solicitud se usa en su sentido más amplio, es decir, un grupo de medios que permiten la realización de un objetivo particular, y por lo tanto pueden ser, por ejemplo, (una pequeña parte de) un IC, o un aparato dedicado (tal como un aparato con una pantalla), o parte de un sistema de red, etc. También se pretende que "disposición" o "sistema" se utilice en el sentido más amplio, de tal manera que puede comprender entre otras cosas un solo aparato físico que puede comprarse, una parte de un aparato, una colección de (partes de) aparatos en cooperación, etc.
La denotación de producto de programa de cómputo debe entenderse que incluye cualquier realización física de una
colección de comandos que permiten que un procesador genérico o de propósito especial, después de una serie de pasos de cargado (que pueden incluir conversión intermedia, tales como traducción a un lenguaje intermedio, y un lenguaje de procesador final) ingrese los comandos en el procesador, para ejecutar cualquiera de las funciones características de una invención. En particular, el producto de programa de cómputo puede realizarse como datos en un portador tal como, por ejemplo, un disco o una cinta presente en una memoria, datos que viajan a través de una conexión de red, física o inalámbrica, o un código de programa o en papel. Además del código de programa, los datos característicos requeridos para el programa también pueden conformarse como un producto de programa de cómputo. Los datos pueden suministrarse (parcialmente) de cualquier manera .
La invención o cualquier dato utilizable de acuerdo con cualquier filosofía de las presentes modalidades como datos de video, también puede conformarse como señales en portadores de datos, que pueden ser memorias removibles como discos ópticos, memorias flash, discos duros removibles, dispositivos portátiles que pueden escribirse por medios inalámbricos, etc.
Algunos de los pasos requeridos para la operación de cualquier método presentado pueden estar ya presentes en la
funcionalidad del procesador o cualquier modalidad de aparato de la invención en lugar de describirse en el producto de programa de cómputo o en cualquier unidad, aparato o método descrito en la presente (con detalles de las modalidades de la invención), tales como pasos de entrada y salida de datos, pasos de procesamiento típicamente incorporados bien conocidos tales como excitación de pantalla estándar, etc. También deseamos la protección para productos resultantes y similares resultantes, como, por ejemplo, las señales novedosas específicas involucradas en cualquier paso de los métodos o en cualquier subparte de los aparatos, así como también cualquier nuevo uso de tales señales, o cualquier método relacionado.
Debe apreciarse que las modalidades antes mencionadas ilustran en lugar de limitar la invención. Cuando la persona experimentada pueda realizar con facilidad una asignación de los ejemplos presentados a otras partes de las reivindicaciones, por concisión no hemos mencionado todas estas opciones a profundidad. Además de combinaciones de elementos de la invención combinados en las reivindicaciones, son posibles otras combinaciones de los elementos. Puede realizarse cualquier combinación de elementos en un solo elemento dedicado.
Cualquier signo de referencia entre paréntesis en una reivindicación pretende limitar la reivindicación, ni
cualquier símbolo particular en las figuras. La palabra "comprende" no excluye la presencia de elementos o aspectos no enumerados en una reivindicación. La palabra "un" o "una" que antecede a un elemento no excluye la presencia de una pluralidad de tales elementos.
Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.
Claims (16)
1. Un aparato de transformación de imágenes dispuesto para derivar una primera imagen con lumas para un primer rango dinámico de luminancia desde una segunda imagen con lumas para un segundo rango dinámico de luminancia, uno de los rangos dinámicos de luminancia es por lo menos el doble de grande que el otro, en donde la derivación comprende la asignación de tonos de lumas de píxeles en la segunda imagen a lumas de píxeles de la primera imagen aplicando por lo menos un algoritmo de asignación predefinido, caracterizado porque comprende: - una entrada a un sistema de suministro de datos que comprende la segunda imagen; - una entrada de datos segura para recibir por lo menos un dato del algoritmo de asignación predefinido; y - una unidad de control dispuesta para administrar el acceso a los datos del algoritmo de asignación predefinido bajo el control de un servidor a través de una red.
2. Un aparato de transformación de imágenes de conformidad con la reivindicación 1, caracterizado porque la unidad de control está dispuesta para obtener el por lo menos un dato del algoritmo de asignación predefinido a través de la entrada de datos segura en un intervalo de tiempo predefinido antes del tiempo de renderizado en una pantalla de la primera imagen.
3. Un aparato de transformación de imágenes de conformidad con la reivindicación 2, caracterizado porque el intervalo de tiempo predefinido es de un par de segundos.
4. Un aparato de transformación de imágenes de conformidad con una de las reivindicaciones anteriores, caracterizado porque la unidad de control está dispuesta para enviar al servidor datos de identificación de contenido que identifican por lo menos aspectos de la segunda imagen.
5. Un aparato de transformación de imágenes de conformidad con la reivindicación 4, caracterizado porque la unidad de control está dispuesta además para enviar al servidor datos de identificación del aparato de transformación de imágenes o de una pantalla de alto rango dinámico.
6. Un aparato de transformación de imágenes de conformidad con una de las reivindicaciones anteriores, caracterizado porque la unidad de control está dispuesta para almacenar el por lo menos un dato del algoritmo de asignación predefinido en una memoria de manera cifrada.
7. Un aparato de transformación de imágenes de conformidad con una de las reivindicaciones anteriores, caracterizado porque la unidad de control está dispuesta para obtener información de caracterización de un usuario de la primera imagen.
8. Un aparato de transformación de imágenes de conformidad con la reivindicación 7, caracterizado porque la información de caracterización incluye por lo menos un código personal o datos biométricos.
9. Un servidor que provee datos del algoritmo de asignación predefinido, caracterizado porque es dispuesto para recibir una abertura de conexión de datos de un aparato de transformación de imágenes de conformidad con una de las reivindicaciones 1 a 8, y dispuesto para realizar una prueba con base en datos de identificación de contenido transmitidos desde el aparato de transformación de imágenes que prueba si la segunda imagen está autorizada, y dispuesto para proveer los datos del algoritmo de asignación predefinido al aparato de transformación de imágenes.
10. Un servidor proveedor de datos del algoritmo de asignación predefinido de conformidad con la reivindicación 9, caracterizado porque está dispuesto para realizar pruebas adicionales, específicamente si el aparato de transformación de imágenes es un aparato autorizado.
11. Un servidor proveedor de datos del algoritmo de asignación predefinido de conformidad con la reivindicación 9 ó 10, caracterizado porque está dispuesto para mantener una comunicación con el aparato de transformación de imágenes de información parcial de los datos del algoritmo de asignación predefinido.
12. Un servidor proveedor de datos del algoritmo de asignación predefinido de conformidad con una de las reivindicaciones 9 a 11, caracterizado porque está dispuesto para recibir del aparato de transformación de imágenes información en por lo menos un aspecto de - la segunda imagen, - el aparato de transformación de imágenes, - una pantalla de alto rango dinámico conectada para renderizar la primera imagen, - características ópticas de un ambiente de la pantalla de alto rango dinámico, y - un usuario del aparato de transformación de imágenes, y determinar con él cuáles, si lo hubiere, datos del algoritmo de asignación predefinido se enviará al aparato de transformación de imágenes.
13. Un método de derivación de una primera imagen de lumas para un primer rango dinámico de luminancia a partir de una segunda imagen de lumas para un segundo rango dinámico de luminancia, uno de los rangos dinámicos de luminancia es por lo menos el doble de grande que el otro, en donde la derivación comprende la asignación de tonos de lumas de píxeles en la segunda imagen a lumas de píxeles de la primera imagen aplicando por lo menos un algoritmo de asignación predefinido, caracterizado porque comprende: obtener de un sistema de suministro de datos la segunda imagen; y - administrar el acceso a los datos del algoritmo de asignación predefinido obtenidos a través de una entrada de datos segura bajo el control de un servidor a través de una red.
14. Un método de derivación de una primera imagen de conformidad con la reivindicación 13, caracterizado porque hace una conexión privada segura en una red a un servidor en un intervalo de tiempo antes del tiempo de renderizado en una pantalla de la primera imagen.
15. Un método de derivación de una primera imagen de conformidad con la reivindicación 14, caracterizado porque una unidad de control en el sitio del renderizado de la primera imagen envía al servidor datos de identificación de contenido que identifican a la segunda imagen.
16. Un método de suministro de datos del algoritmo de asignación predefinido, caracterizado porque comprende transformar una segunda imagen gradada para renderizado en una pantalla de un segundo rango dinámico de luminancia, a una primera imagen gradada para renderizado en una pantalla de un segundo rango dinámico de luminancia, por medio de una fuente de los datos del algoritmo de asignación predefinido conectable a un aparato de transformación de imágenes que tiene una unidad de control dispuesta para administrar el acceso a los datos del algoritmo de asignación predefinido bajo el control de un propietario de contenido artístico en la segunda imagen, el método es realizado por la fuente que prueba si el aparato de transformación de imágenes está utilizando una segunda imagen autorizada, y bajo verificación positiva que transmite al aparato de transformación de imágenes los datos del algoritmo de asignación predefinido.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201261699935P | 2012-09-12 | 2012-09-12 | |
| PCT/IB2013/058384 WO2014041471A1 (en) | 2012-09-12 | 2013-09-08 | Making hdr viewing a content owner agreed process |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| MX2015003030A true MX2015003030A (es) | 2015-06-10 |
| MX352598B MX352598B (es) | 2017-11-30 |
Family
ID=49620245
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| MX2015003030A MX352598B (es) | 2012-09-12 | 2013-09-08 | Proceso para la formación de imágenes de alto rango dinámico acordado por el propietario de contenido. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US9641894B2 (es) |
| EP (1) | EP2898474A1 (es) |
| JP (1) | JP6243912B2 (es) |
| CN (1) | CN104620281B (es) |
| BR (1) | BR112015005153A2 (es) |
| MX (1) | MX352598B (es) |
| RU (1) | RU2651225C2 (es) |
| WO (1) | WO2014041471A1 (es) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6471752B2 (ja) * | 2014-05-12 | 2019-02-20 | ソニー株式会社 | 通信装置及び通信方法、並びにコンピューター・プログラム |
| US20150350641A1 (en) * | 2014-05-29 | 2015-12-03 | Apple Inc. | Dynamic range adaptive video coding system |
| CN111212251B (zh) * | 2014-09-10 | 2022-05-27 | 松下电器（美国）知识产权公司 | 再现装置以及再现方法 |
| WO2016040906A1 (en) * | 2014-09-11 | 2016-03-17 | Grundy Kevin Patrick | System and method for controlling dynamic range compression image processing |
| EP3205082B1 (en) | 2014-10-10 | 2018-04-04 | Koninklijke Philips N.V. | Saturation processing specification for dynamic range mappings |
| US20180005357A1 (en) * | 2015-01-30 | 2018-01-04 | Thomson Licensing | Method and device for mapping a hdr picture to a sdr picture and corresponding sdr to hdr mapping method and device |
| EP3051488A1 (en) * | 2015-01-30 | 2016-08-03 | Thomson Licensing | A method and apparatus for inverse-tone mapping a picture |
| WO2017049013A1 (en) | 2015-09-18 | 2017-03-23 | Flir Systems, Inc. | High dynamic range radiometric thermal video over low bitrate interface |
| JP2019512953A (ja) | 2016-03-14 | 2019-05-16 | コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． | ダイナミックレンジマッピングのための飽和処理仕様 |
| US10699391B2 (en) | 2016-04-29 | 2020-06-30 | Disney Enterprises, Inc. | Dynamic range expansion highlight information restoration |
| GB2558234B (en) * | 2016-12-22 | 2020-05-13 | Apical Ltd | Image processing |
| US10630934B2 (en) * | 2017-12-11 | 2020-04-21 | Disney Enterprises, Inc. | High dynamic range enhancement authorization |
| EP3525463A1 (en) * | 2018-02-13 | 2019-08-14 | Koninklijke Philips N.V. | System for handling multiple hdr video formats |
| US11587526B2 (en) * | 2018-12-20 | 2023-02-21 | Dolby Laboratories Licensing Corporation | Luminance adaption to minimize discomfort and improve visibility |
| CN109509406A (zh) * | 2018-12-29 | 2019-03-22 | 深圳市奥拓电子股份有限公司 | Led箱体及影院led显示屏 |
| CN110197144B (zh) * | 2019-05-20 | 2021-10-19 | 厦门能见易判信息科技有限公司 | 盗录视频识别方法及系统 |
| JP7395418B2 (ja) | 2020-04-21 | 2023-12-11 | 株式会社サンテック | 接地金具 |
| CN114463191B (zh) * | 2021-08-26 | 2023-01-31 | 荣耀终端有限公司 | 一种图像处理方法及电子设备 |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000339852A (ja) * | 1999-06-02 | 2000-12-08 | Kowa Co | 情報再生システム、情報変換装置、情報再生装置、情報再生方法並びに記録媒体 |
| AU2001274962A1 (en) * | 2000-05-25 | 2001-12-03 | Wind-Up Entertainment, Inc. | Prerecorded media authentication and download system |
| US7503059B1 (en) * | 2001-12-28 | 2009-03-10 | Rothschild Trust Holdings, Llc | Method of enhancing media content and a media enhancement system |
| US20080002776A1 (en) * | 2004-04-30 | 2008-01-03 | British Broadcasting Corporation (Bbc) | Media Content and Enhancement Data Delivery |
| US8520851B2 (en) * | 2004-04-30 | 2013-08-27 | Blackberry Limited | Wireless communication device with securely added randomness and related method |
| US8050512B2 (en) | 2004-11-16 | 2011-11-01 | Sharp Laboratories Of America, Inc. | High dynamic range images from low dynamic range images |
| JP2007018646A (ja) * | 2005-07-11 | 2007-01-25 | Hitachi Ltd | 記録再生装置 |
| KR100736080B1 (ko) * | 2005-10-27 | 2007-07-06 | 삼성전자주식회사 | 다 계층으로 구성된 멀티미디어 스트림의 저작권을 계층별로 관리하는 방법 및 장치 |
| US8014445B2 (en) * | 2006-02-24 | 2011-09-06 | Sharp Laboratories Of America, Inc. | Methods and systems for high dynamic range video coding |
| US20080043832A1 (en) * | 2006-08-16 | 2008-02-21 | Microsoft Corporation | Techniques for variable resolution encoding and decoding of digital video |
| US8395993B2 (en) * | 2006-12-13 | 2013-03-12 | Viasat, Inc. | Video and data network load balancing with video placeholder |
| US8665942B2 (en) * | 2007-01-23 | 2014-03-04 | Sharp Laboratories Of America, Inc. | Methods and systems for inter-layer image prediction signaling |
| WO2008121755A1 (en) * | 2007-03-30 | 2008-10-09 | Rite-Solutions, Inc. | Methods and apparatus for distributing media content for the purpose of enhancing existing media |
| US8237776B2 (en) * | 2007-10-19 | 2012-08-07 | Warner Bros. Entertainment Inc. | Method and apparatus for generating stereoscopic images from a DVD disc |
| US8432968B2 (en) * | 2007-10-15 | 2013-04-30 | Qualcomm Incorporated | Scalable video coding techniques for scalable bitdepths |
| JP5624062B2 (ja) * | 2009-03-06 | 2014-11-12 | コーニンクレッカ フィリップス エヌ ヴェ | 入力画像データを出力画像データに変換するための方法、入力画像データを出力画像データに変換するための画像変換ユニット、画像処理装置、ディスプレイデバイス |
| TW201039170A (en) * | 2009-04-28 | 2010-11-01 | Thomson Licensing | System and method for detecting genuine copies of pre-recorded digital media |
| JP5752133B2 (ja) * | 2009-10-08 | 2015-07-22 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | デジタル画像を低ダイナミック・レンジ（ｌｄｒ）画像から高ダイナミック・レンジ（ｈｄｒ）画像に変換するための方法およびシステム |
| CN102783132B (zh) | 2010-03-03 | 2016-08-03 | 皇家飞利浦电子股份有限公司 | 用于定义颜色状态的装置和方法 |
| US9271052B2 (en) * | 2010-05-10 | 2016-02-23 | Comcast Cable Communications, Llc | Grid encoded media asset data |
| JP6202330B2 (ja) * | 2013-10-15 | 2017-09-27 | ソニー株式会社 | 復号装置および復号方法、並びに符号化装置および符号化方法 |
-
2013
- 2013-09-08 RU RU2015113395A patent/RU2651225C2/ru active
- 2013-09-08 US US14/427,019 patent/US9641894B2/en active Active
- 2013-09-08 JP JP2015531666A patent/JP6243912B2/ja active Active
- 2013-09-08 WO PCT/IB2013/058384 patent/WO2014041471A1/en active Application Filing
- 2013-09-08 EP EP13792747.1A patent/EP2898474A1/en active Pending
- 2013-09-08 CN CN201380047495.7A patent/CN104620281B/zh active Active
- 2013-09-08 BR BR112015005153A patent/BR112015005153A2/pt not_active Application Discontinuation
- 2013-09-08 MX MX2015003030A patent/MX352598B/es active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| EP2898474A1 (en) | 2015-07-29 |
| JP6243912B2 (ja) | 2017-12-06 |
| CN104620281B (zh) | 2018-08-14 |
| RU2015113395A (ru) | 2016-11-10 |
| US9641894B2 (en) | 2017-05-02 |
| BR112015005153A2 (pt) | 2017-07-04 |
| RU2651225C2 (ru) | 2018-04-18 |
| WO2014041471A1 (en) | 2014-03-20 |
| CN104620281A (zh) | 2015-05-13 |
| JP2015534114A (ja) | 2015-11-26 |
| MX352598B (es) | 2017-11-30 |
| US20150245096A1 (en) | 2015-08-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9641894B2 (en) | Making HDR viewing a content owner agreed process | |
| US11700342B2 (en) | System and method for creating a temporal-based dynamic watermark | |
| CA2503835C (en) | Techniques of imperceptibly altering the spectrum of a displayed image in a manner that discourages copying | |
| CN1906882B (zh) | 内容到可写介质的安全传输 | |
| CA2465282C (en) | A system and method for secure distribution and evaluation of compressed digital information | |
| JP7453214B2 (ja) | マルチレンジｈｄｒビデオコード化 | |
| US20040091110A1 (en) | Copy protected display screen | |
| BR112014023535B1 (pt) | Codificador de imagem para codificar uma imagem de uma cena de alto alcance dinâmico, decodificador de imagem para decodificar uma representação de imagem codificada de uma cena de alto alcance dinâmico, método de codificação de imagem para codificar uma imagem de uma cena de alto alcance dinâmico e método de decodificação da imagem para decodificar uma representação de imagem codificada de uma cena de alto alcance dinâmico | |
| US10298552B2 (en) | Digital broadcast methods using secure meshes and wavelets | |
| KR101564421B1 (ko) | 동영상 처리 장치 및 방법 | |
| US10630934B2 (en) | High dynamic range enhancement authorization | |
| Chammem | Robust watermarking techniques for stereoscopic video protection | |
| KR101997036B1 (ko) | 동영상 처리 장치 및 방법 | |
| CN117751378A (zh) | 数字水印的系统和方法 | |
| Upenik et al. | High dynamic range image sharing with privacy protection | |
| JP2024021961A (ja) | 動画用電子透かし方法 | |
| JPH10289276A (ja) | 著作物利用制限処理方法及び装置 | |
| WO2001054345A1 (en) | Security systems for motion picture, video, program, and datafile transmission, viewing, access control and usage control | |
| Sterling | Using LED Backlight Display Technology to Provide Passive Forensic Marking for High Value Content | |
| KR20150126220A (ko) | 동영상 처리 장치 및 방법 | |
| Lin | CERIAS Tech Report 2005-128 VIDEO AND IMAGE WATERMARK SYNCHRONIZATION |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG | Grant or registration |