BR112014023535B1

BR112014023535B1 - 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

Info

Publication number: BR112014023535B1
Application number: BR112014023535-0A
Authority: BR
Inventors: Mark Jozef Willem Mertens
Original assignee: Koninklijke Philips N.V
Priority date: 2012-03-26
Filing date: 2013-03-25
Publication date: 2022-06-14
Also published as: KR102014127B1; JP6262198B2; WO2013144809A3; MX2014011418A; US20150117791A1; RU2643663C2; EP2880624A2; US9420288B2; EP2880624B1; PL2880624T3; KR20140146628A; CN104541301B; US20170208344A1; RU2014142986A; CN104541301A; ES2737993T3; JP2015517250A; JP6526776B2; MX337444B; JP2018061288A

Abstract

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, MÉTODO DE DECODIFICAÇÃO DA IMAGEM PARA DECODIFICAR UMA REPRESENTAÇÃO DE IMAGEM CODIFICADA DE UMA CENA DE ALTO ALCANCE DINÂMICO, PRODUTO DE PROGRAMA DE COMPUTADOR, SINAL DE IMAGEM CODIFICANDO AS CORES DAS REGIÕES DE UMA CENA DE ALTO ALCANCE DINÂMICO, MEMÓRIA E SISTEMA DE DISTRIBUIÇÃO DE VÍDEO ATRAVÉS DE QUALQUER TECNOLOGIA EM REDE. O codificador de imagem (549) para codificar uma imagem de uma cena de alto alcance dinâmico, compreendendo: - uma unidade de codificação da textura do pixel (552) disposta para codificar as cores dos pixels da imagem com uma representação da imagem (Im_1) compreendendo N palavras de codificação do bit; - uma unidade de análise da imagem (550) disposta para determinar e gerar um valor de cinza diferenciador da região (gTS), que é um valor de luminância demarcando abaixo dele as luminâncias de todos os pixels de um primeiro objeto em pelo menos um bloco da imagem, e acima dele as luminâncias de todos os pixels de (...).

Description

CAMPO DA INVENÇÃO

[001] A invenção se refere a aparelhos e métodos e produtos resultantes como produtos de armazenamento de dados e sinais codificados para codificação melhorada de pelo menos uma imagem ou vídeo, em particular a codificação de imagem(s) com um alcance dinâmico aumentado comparado às imagens legadas (chamadas de imagens de alto alcance dinâmico HDR, e as imagens legadas são chamadas de imagem de baixo alcance dinâmico LDR), e codificação das informações da imagem com uma quantidade aumentada de informações da luminosidade (também conhecida como alto alcance dinâmico) para ou a partir de diversas representações de imagem.

HISTÓRICO DA INVENÇÃO

[002] Recentemente, novos desenvolvimentos têm ocorrido em relação à codificação de imagens/vídeo (ou de cenas capturadas ou computação gráfica), a saber, é desejável capturar melhor todo o alcance das luminâncias do objeto e cores ocorrendo naturalmente, até grandes valores de luminância como, por exemplo, 25000 nit (por exemplo, nuvens iluminadas pelo sol) e frequentemente também baixos valores, como 0,01 nit, o que é chamado de codificação HDR (alto alcance dinâmico). Até agora, os sistemas de captura de imagem clássicos (isto é, a corrente começando na câmera - e ainda a iluminação apropriada da cena que era tipicamente relativamente uniforme - seguida pela codificação, por exemplo, transmissão ou armazenamento de imagem, até a exibição da imagem) têm manipulado as cenas de alto alcance dinâmico (isto é, cenas nas quais existem regiões escuras importantes simultaneamente com baixas luminâncias e objetos significantes nestas, e regiões de brilho com altas luminâncias, em particular se existirem também diversas regiões importantes de luminâncias intermediárias (cinzas diversos), em particular se diversas destas luminâncias de cena não puderem mapear facilmente o que é utilizável por um componente na cadeia, tal como, por exemplo, uma renderização com base no mapeamento linear em um display) de uma maneira gravemente distorcida. Por exemplo, se a ação estivesse acontecendo dentro de um volume fechado de um primeiro nível de luz (iluminância), tal como um carro ou sala, as regiões de iluminação mais brilhante, tal como o ambiente visto através da janela, pode ter sido capturada, ou pelo menos representada no sinal com qualidade muito baixa (a saber, cores pastéis, lavadas ou recortadas). Isto é especialmente verdade para câmeras com base em CMOS mais baratas, comparadas ao comportamento mais indulgente, por exemplo, da película de celuloide. Em particular, somente alguns valores de código dificilmente representativos podem ter sido associados aos objetos nestas regiões de brilho, o que pode resultar na má representação das texturas do objeto, ou ainda recorte atenuado para o valor máximo do espaço de cor usado para codificação. Ter tão poucos dados nestas regiões do eixo de luminância da imagem capturada também significa que as funções de processamento, por exemplo, otimização do contraste da imagem exibida, podem ter problemas para produzir bons dados finais de pixel. Ter displays ainda melhores disponíveis atualmente e no futuro próximo (por exemplo, com brilho máximo de diversos 1000s de nits), ou pelo menos tecnologias de processamento de imagem mais inteligentes, pode-se desejar melhorar esta situação, para ser capaz de criar imagens renderizadas de qualidade superior.

[003] Por diversos motivos, pelo menos para um número de anos no futuro, pode-se desejar alguma forma de compatibilidade com versões anteriores, o que significa que os dados de uma então chamada codificação de baixo alcance dinâmico (LDR) deve estar disponível ou pelo menos facilmente determinável a partir da codificação disponível, de forma que, por exemplo, uma nova caixa de processamento de vídeo melhorada pode levar um sinal LDR para um display de alcance dinâmico inferior (por exemplo, um display móvel). Também a partir de um ponto de vista do armazenamento, pode ser útil armazenar um sinal de imagem em uma versão mais versátil possível, isto é, não somente com a quantidade máxima de dados úteis sobre a cena, mas também de uma maneira que estes dados servirão muitas potenciais aplicações futuras, especialmente se de uma maneira simples. Tipicamente, a gravação de um filme, por exemplo, toma tanto esforço que o sinal bruto é altamente valioso, e codifica-se melhor este da melhor maneira possível que uma tecnologia permite. Para não cair em uma armadilha de que mesmo a codificação mestre de um programa é para uma geração posterior dos sistemas de exibição de melhor qualidade abaixo, o que poderia ter sido realizável se os dados tivessem sido codificados de forma diferente. Isto evita não somente ter que fazer uma manobra cara, mas o leitor pode imaginar que alguns eventos a serem gravados, como o casamento de um casal real ou um vídeo de casamento de um casal normal, não serão feitos novamente. E tentar remasterizar tal vídeo para uma nova geração de tecnologia de exibição é, se não muito difícil, pelo menos demorado. É preferível que a codificação permita a captura da cena de forma ótima em primeiro lugar, e ainda permita facilmente melhoras posteriores, por meio desta mesma estrutura de codificação. Independente de como é renderizado em um display particular mais o ambiente de visualização, as informações presentes nas atuais codificações LDR, tal como JPEG (dependendo, entre outros, da cena capturada em particular e o sistema de câmera utilizado), são atualmente vistas como (limitadas a) aproximadamente 11 bits ou paradas lineares. Obviamente, se a codificação é para ser usada diretamente para renderização (por exemplo, referente ao display) alguns dos bits de informação podem não ser visíveis. Por outro lado, um codec pode conter informações da cena original ou composição gráfica (referente à cena), que pode se tornar relevante, por exemplo, quando um display está mudando sua gama visível aos olhos humanos por meio do processamento da imagem. Assim, é importante ter pelo menos os objetos da imagem mais importantes bem representados na imagem codificada.

[004] Uma cadeia de captura HDR é mais que somente apontar uma câmera em uma cena com uma grande proporção de contraste de luminância entre o objeto mais escuro e mais brilhante e registrar linearmente o que existe na cena. Isto relaciona-se com o que exatamente os valores de cinza intermediários para todos os objetos são, desde que transmita, por exemplo, o clima de um filme (já escurecendo alguns dos objetos na cena pode transmitir um clima sombrio). E este é um processo psicológico complexo. Pode-se, por exemplo, imaginar que psicologicamente não tão importante se uma luz brilhante é renderizada em um display exatamente em tal proporção ao resto dos valores de cinza renderizados como a luminância da cena daquela luz era para o resto das luminâncias do objeto de cena. Preferencialmente, ter-se-á uma impressão fiel de uma lâmpada real, se os pixels são renderizados com “alguma” alta luminância de saída do display, contanto que seja suficientemente superior ao resto da fotografia. Mas esta distribuição entre os objetos refletores e auto luminosos (nas diversas regiões de iluminação da cena) também é uma tarefa dependendo da gama de exibição e condições de visualização típicas. Também pode imaginar que a codificação das regiões mais escuras é preferencialmente feita de forma que possam ser facilmente utilizadas em diferentes cenários de renderização, tal como diferentes níveis médios de iluminação ao redor, tendo diferentes níveis de visibilidade para o teor da imagem mais escura. Em geral, devido a isto ser uma tarefa psicológica difícil, os artistas serão envolvidos na criação de imagens ótimas, o que é chamado de gradação de cor. Em particular, é muito útil quando os artistas fazem uma gradação LDR separada, mesmo se isto é feito em uma “estratégia de codificação HDR pura”. Em outras palavras, em tal cenário, ao codificar um único sinal bruto da câmera HDR, ainda iremos gerar também uma imagem LDR, não necessariamente devido a ser usada para uma grande fração LDR do mercado consumidor de vídeo no futuro, mas devido a transmitir importantes informações sobre a cena. A saber, sempre haverá regiões e objetos mais importantes na cena, e colocando estes em uma subestrutura LDR (o que pode conceitualmente ser visto como uma contrapartida artística de um algoritmo de exposição automática, ainda após a captura completa, e em relação às luminâncias capturada fora daquele alcance), isto torna mais fácil fazer todos os tipos de conversões para representações de alcance intermediário (MDR), adequadas para conduzir displays com características de visualização e renderização particulares. Por meio do uso de tal estrutura de trabalho técnica, podemos ainda com uma única imagem codificada, ao mesmo tempo feita para, por exemplo, displays LDR como um display móvel com um brilho máximo de 50 nit (em ambiente fechado, ou um brilho superior, mas competindo contra a alta iluminância de ambientes a céu aberto), um display MDR de brilho máximo de alcance médio de 1200 nit, e um display HDR de brilho máximo de 8000 nit. Em particular, pode-se sintonizar esta parte LDR de acordo com diversos critérios, por exemplo, que renderiza com boa qualidade em um display LDR de referência padrão (as cores parecem mais familiares possíveis àquelas no display HDR), ou transmite certa porcentagem das informações capturadas totais (por exemplo, certa quantidade da imagem é visível), etc. Implementaremos no nosso codec proposto abaixo que tal display de recebimento pode, a partir daquela codificação única (ou gradação) da cena abrangente, identificar facilmente o que, por exemplo, são as regiões escuras, de forma que possa fazer otimamente a visibilidade incorporada deste dadas suas características conhecidas do sistema de exibição.

[005] Não existem tantas maneiras de codificar um sinal HDR. Normalmente na técnica anterior, codifica-se somente nativamente o sinal HDR, isto é, mapeia-se (linearmente) os pixels para, por exemplo, 16 bits flutuantes, e então o valor de luminância máxima capturado é o branco HDR em uma filosofia similar à codificação LDR (apesar de psicovisualmente este normalmente não ser algum branco refletivo na cena, mas, ao invés disso, uma cor clara de uma lâmpada) . Esta é uma codificação referente à cena natural das luminâncias do objeto de cena original conforme capturada pela câmera. Pode-se também mapear um sinal HDR de alcance máximo para o alcance LDR de 8 bit por meio de alguma função de transformação da luma “ótima”, o que tipicamente seria uma função gama ou similar. Isto pode envolver a perda da precisão da cor (em vista do equilíbrio entre o alcance e a precisão para tais codificações) com problemas da qualidade da renderização correspondentes, especialmente se no processamento da imagem lateral recebida, tal como o brilho local, é expectável, no entanto, a gradação do valor de cinza dominante dos objetos de imagem (por exemplo, a média sobre um objeto) é mais ou menos preservada (isto é, seus relacionamentos de luma percentuais/relativos).

[006] A técnica anterior também ensinou algumas técnicas de codificação HDR usando dois conjuntos de dados de fotografia para cada imagem HDR, tipicamente com base em um tipo de conceito de codificação escalonável, no qual por meio de alguma função de previsão, a precisão de uma textura local codificada “LDR” é refinada, ou estabelecida mais precisamente, isto é, projetada para uma versão HDR daquela textura, tipicamente escalonando as luminâncias LDR (o LDR nestas tecnologias normalmente não é um grau LDR de boa aparência já adequado para renderização ótima em um display LDR (de referência) típico, mas tipicamente um processamento simples na entrada HDR). Então a segunda fotografia é uma fotografia de correção para aproximar a imagem HDR à imagem HDR original a ser codificada. Existe alguma similaridade com a codificações da imagem HDR única, através das funções de previsão servindo como algum critério de definição da precisão/alcance, somente nestas tecnologias a codificação é realizada com duas fotografias.

[007] O escalonamento das lumas de uma imagem com base em banda envolve a aplicação de uma transformação, e esta transformação de previsão é frequentemente definida por bloco, para reduzir a quantidade de dados a serem codificados. Isto já pode ser um desperdício em relação aos dados, já que muitos blocos conterão o mesmo objeto, e consequentemente necessitam da mesma transformação.

[008] Conforme dito, a diferença da imagem HDR original com a previsão pode ser co-codificada como uma fotografia de melhora para o grau desejado, ainda o máximo possível, dado o alcance e a definição da imagem de melhora. Por exemplo, pode-se representar um valor de cinza HDR de 1168 com uma divisão por 8 para um valor 146. Este valor HDR poderia ser recriado multiplicando por 8 novamente, mas considerando que um valor 1169 quantizaria para o mesmo valor da camada de base 146, necessitar-se-ia de um valor de melhora igual a 1 para ser capaz d recriar um sinal HDR de alta qualidade. Um exemplo de tal tecnologia é descrito na patente EP2009921 [Liu Shan et al. Mitsubishi Electric: Method for inverse tone mapping (by scaling and offset)]. Uma questão interessante sobre tais métodos é sempre o que o método de melhora realmente proporciona como melhora da informação visual. É normalmente aplicado de forma cega, e pode, por exemplo, para regiões texturizadas, algumas vezes não contribuir com informações adicionais relevantes, especialmente para vídeo de mudança rápida.

[009] Outra codificação de duas fotografias é descrita no pedido de patente atualmente ainda não publicado US61/557461 do qual todos os ensinamentos são incorporados aqui como referência.

[010] Agora, existem problemas com todas as codificações HDR existentes. Somente aplicar transformações globais pode ser muito geral de acordo com o que o criador do conteúdo deseja após ter investido tanto, por exemplo, em um filme (efeitos especiais). Outras aplicações podem ser menos críticas, como uma criação de programa de televisão, mas ainda um bom controle sobre a aparência final é desejável. Isto ficaria pelo menos no custo da necessidade de muitos bits de dados codificados. Por outro lado, especificar as transformações intrincadas por pixel também envolve uma grande quantidade de dados a serem codificados. Isto se aplica, por exemplo, a necessidade de codificar uma segunda imagem sendo um mapa de aumento da luminosidade, para os reflexos de textura do objeto sendo codificado em uma primeira imagem. Também, aqui codifica-se de forma cega qualquer coisa possivelmente ocorrendo na entrada, não sabendo muito sobre o que está realmente na imagem (isto é, não permitindo o uso versátil), ainda não percebendo que pode haver uma grande quantidade de redundância na imagem aumentada. Sem mencionar que estes dados cegos são fáceis de usar para algoritmos inteligentes como, por exemplo, algoritmos de otimização ou melhora no lado do display.

[011] Trabalhar em uma base de bloco reduz a quantidade de dados, mas ainda não é ótimo. Em particular, esta estrutura em bloco também sendo preferencialmente cega ao teor da imagem real, e mais importunamente, impondo uma nova estrutura geométrica sendo a grade de bloco, que não está relacionada à imagem subjacente, e pode consequentemente corresponder mais ou menos convenientemente às características da imagem (em particular, a geometria da imagem), significa que diversos artefatos relacionados à codificação em bloco podem ocorrer. Na verdade, um bloco não é muito mais que somente um grande pixel, e realmente não é uma estrutura inteligente relacionada ao conteúdo (nem com relação à estrutura geométrica da cor daquele objeto ou região, nem seu significado semântico, tal como, por exemplo, sendo um objeto que deveria estar substancialmente escondido no escuro).

[012] As realizações abaixo objetivam prover medidas técnicas fáceis para diminuir pelo menos alguns dos artefatos.

SUMÁRIO DA INVENÇÃO

[013] Uma codificação facilmente utilizável e simples das imagens HDR pode ser realizada por meio dos conceitos da realização apresentada aqui seguindo princípios relacionados a um codificador de imagem (549) para codificar uma imagem de uma cena de alto alcance dinâmico, compreendendo:

[014] - uma unidade de codificação da textura do pixel (552) disposta para codificar as cores dos pixels da imagem com uma representação da imagem (Im_1) compreendendo N palavras de codificação do bit;

[015] - uma unidade de análise da imagem (550) disposta para determinar e gerar um valor de cinza diferenciador da região (gTS), que é um valor de luma demarcando abaixo dele as lumas de todos os pixels de um primeiro objeto em pelo menos um bloco da imagem, e acima dele as lumas de todos os pixels de um segundo objeto em pelo menos um bloco da imagem; e

[016] - um formatador (554) disposto para co-codificar em um sinal de imagem de saída (S(Im_1, MET(gTS)) a representação da imagem (Im_1) e o valor de cinza diferenciador da região (gTS)).

[017] Somente com um ou alguns valores de cinza diferenciadores da região, pode-se já transmitir a característica essencial de uma cena HDR, tal como aquela em que existe uma região “above_white” ou “overbright” na imagem. “Above white” significa as luminâncias da cena acima do branco na região iluminada normalmente, por exemplo, o branco que seria gravado a partir de um papel branco iluminado (como de acordo com o designer da iluminação do conjunto, por exemplo), na parte principal da cena. Os diferenciadores são uma boa maneira de co-codificar o conteúdo semântico de uma cena. Por exemplo, não existe somente um branco em uma cena real, como a codificação de imagem clássica sugere. Na codificação de imagem LDR clássica, ilumina-se de fato a cena onde a ação ocorre aproximadamente uniformemente, e então o objeto refletor mais branco (na iluminação mais clara da região da imagem principal) tipicamente determinará o ponto branco da codificação da imagem. Ao invés de recortar, por exemplo, objetos ao ar livre, pode-se também incluir alguns objetos acima do branco, por exemplo, pelo operador de câmera especificando um ponto de curvatura para a curva da gama de reprodução, mas isto ainda é ligado ao branco principal (por exemplo, 6x sobre aquele branco).

[018] Em uma cena real, pode haver, por exemplo, um ambiente a céu aberto ensolarado muito brilhante.Mesmo ao sobrepor estas duas regiões juntas em uma quantidade inferior de codificação de bit (por exemplo, representando-a como uma fotografia clássica de 8 bits), desejar-se-ia duas regiões/alcances separados uma da outra sobre o eixo da luma. Isto significa que posteriormente (ou, por exemplo, intermediário na transcodificação ou consideração automática,etc.) pode-se tratar estas regiões de forma mais inteligente. Já falamos sobre objetos de lâmpada acima. O display de renderização pode querer renderizá-los de acordo com um critério definindo um ou mais de “o mais claro possível” e “não muito ofuscante para o visualizador”. Para fazer isto, no entanto, pode-se precisar tratar estas duas regiões da imagem (lâmpada vs. resto da cena) diferentemente e ainda descontinuamente, e, portanto, pode-se precisar saber o que na imagem é aquela lâmpada. As codificações com base na função gama clássicas tipicamente moverão a lâmpada durante o pós processamento para alguma posição de luminância renderizada, o que é dependente daquela gama usada, mas não a semântica da cena com “as especificações colorimétricas do sistema de renderização (tal como, capacidades de exibição, luz ao redor, etc.). Um raciocínio técnico similar pode ser feito para as regiões mais escuras, se alguém conhecer sua composição em função da região de luminância, isto é, por exemplo, um par de faixas, por exemplo, “escuro leve”, “escuro médio” e “super escuro”. Tais códigos (isto é, diferenciadores do valor de cinza) poderia significar algo numericamente, mas nosso método permite a gradação de cor, por exemplo, fazendo o HDR mestre final para armazenamento em um disco blu-ray, para colocá-los em regiões semanticamente significativas. Por exemplo, em um porão escuro de um filme de terror, um escuro médio pode ser as cores com as quais as paredes devem ser renderizadas (por último no display de renderização, de acordo com seu mapeamento de tom ótimo final para exibição ótima), em que o escuro leve (isto é, a ser o alcance de luminância renderizado entre o escuro médio e o escuro leve) pode ser ferramentas naquelas paredes, como facas e instrumentos de torturar para torná-los mais bem visíveis (dadas as especificações colorimétricas do lado de renderização), e super escuro, por exemplo, pode ser um canto escuro onde o criminoso pode estar escondido. A região do canto super escuro é então nosso primeiro objeto, e a região principal escuro médio nosso segundo, assim como em uma cena interna/externa, o ambiente externo ensolarado pode ser o segundo objeto, e o ambiente interno o primeiro/principal objeto.

[019] Também, estas duas sub-regiões (por exemplo, ação principal com iluminação média e ambiente externo ensolarado ou iluminado por lâmpada) podem estar tão próximas na representação da imagem codificada a estar realmente tocando a fim de não desperdiçar os códigos da luma entre estas, p que as torna extremamente difíceis de separar de modo cego no lado receptor. Ainda, existe esse valor de luminância particular que marca a ligação entre elas, que é consequentemente co-codificada como um valor de cinza diferenciador da região (gTS) para fácil entendimento (mais simples) da cena no lado receptor. E então isto permite diversões aplicações, tal como codificação HDR e fácil reconstrução de uma imagem de 8 bits no lado receptor, processamento de imagem, tal como o mapeamento de cor, etc.

[020] Vantajosamente, o codificador de imagem (549) compreende uma unidade de determinação do mapeamento da luma (553) disposta para determinar um mapeamento da luma (TOM) para pelo menos um do primeiro e segundo objeto definindo um mapeamento entre as lumas dos pixels conforme codificada na representação da imagem (Im_1) e lumas dos pixels em uma segunda representação de imagem (IM_RC_HDR), e disposto para prover um mapeamento da luma (TOM) para o formatador (554) que é disposto para co-codificar a luma no sinal da imagem gerada (S(Im_1, MET(gTS), TOM)). Tais mapeamentos da luma podem ser determinados de diversas maneiras, considerando tais princípios como, por um lado, a especificação ótima da informação na fotografia (por exemplo, a quantidade de códigos necessários para codificar relativamente fielmente uma textura de uma complexidade específica, como uma granulação de madeira), e, por outro lado, uma aparência, por exemplo, definindo uma posição da luminância em tipicamente um display de referência.

[021] O criador do conteúdo poderia deixar para lado receptor fazer seu processamento desejado, por exemplo, renderização final da exibição. Ter somente um gTS já atende muitas situações, considerando que o sistema lateral receptor então obviamente conhece quais são os objetos claros, já que têm lumas acima do gTS. No entanto, este sistema de co- codificação do(s) valor(es) de cinza diferenciador(es) permite tal codificação mais versátil da cena HDR (conhecimento sobre sua composição ou ainda o significado semântico nos metadados) e consequentemente, diversos usos destes dados. Por exemplo, o criador de conteúdo pode prover um ou mais cenários de como mapear as cores/lumas do pixel codificadas em Im_1 para diversos outros espaços de cor, tal como, para renderização de diferentes exibições. Pode-se codificar, por exemplo, diversos valores para (aproximadamente) um tipo de display (por exemplo, tendo um brilho máximo próximo a 4000 nit, isto é, destinado para displays de LCD ou OLED com brilho máximo real entre 3000 e 5000 nit), de forma que o display possa finalmente escolher uma estratégia de renderização final a partir de todo o conhecimento da transformação codificada (codificar como o criador de conteúdo deseja que suas imagens pareçam no final). Por exemplo, nos displays com um alcance dinâmico menos exibível, um único diferenciador para as regiões mais claras pode já atender, considerando que não têm uma alta capacidade de renderização das regiões claras. No entanto, um display de 8500 nit pode fazer uso muito mais vantajoso do conteúdo se este contiver mais valores gTS indicando diferentes tipos de região clara, considerando-se conhecer sua sub gama renderizável física das luminâncias claras alocam um sub alcance de luminância diferente, por exemplo, para objetos iluminados pelo sol ao ar livre como, por exemplo, objetos de lâmpada de um primeiro tipo, e uma região ainda mais clara próxima ao brilho máximo para uma classe mais clara de objetos de lâmpada.

[022] Um criador de conteúdo com um interesse menor em investir muito tempo na gradação pode, por exemplo, especificar somente duas gradações, por exemplo, ele pode começar da Im_1 ou alguma transformação automática desta, com sendo “suficientemente boa” para a renderização LDR e então levar algum tempo para ajustar os mapeamentos para obter uma imagem HDR melhorada (por exemplo, com regiões em ambiente ao ar livre de extra brilho, luzes ou janelas), e então levar algum tempo para ajustar os mapeamentos para obter uma imagem HDR melhorada (por exemplo, com regiões ao ar livre de extra brilho, luzes ou janelas). Assim, ele pode especificar, por exemplo, uma imagem LDR de 8 bits (que chamamos de suporte LDR), e então algumas funções, primeiramente as funções de mapeamento para recuperar aproximadamente a imagem HDR mestra original (por exemplo, em uma codificação de 16 bits de flutuação natural) a partir do LDR_container, bem como, secundariamente, algumas funções permitindo uma ou mais sintonizações daquela imagem HDR. Por exemplo, ele pode especificar um mapeamento das regiões claras acima, por exemplo, de 90% para exibição em um segundo display de referência de 14000 nits (o primeiro display de referência pode ser o display para o qual o grau HDR mestre original foi graduado antes de codificá-la com um suporte LDR por meio do mapeamento descendente, por exemplo, um display de 5000 nit). Similarmente, estas funções podem ser usadas para limitar a potência para displays MDR de cerca de 2000 nit, por exemplo, invertendo seu comportamento de mapeamento. Nas variantes mais simples, o graduador investindo menos tempo pode somente especificar um ou mais valores gTS para pelo menos algumas cenas no filme, e deixar para o display ou renderizador (por exemplo, impressora) descobrir qual seria uma boa transformação para suas características de renderização.

[023] Um aparelho de processamento de imagem do lado receptor pode então, por exemplo, determinar seu grau final a partir destes dois ou mais conjuntos de informações (a fotografia do suporte LDR codificado em Im_1 e a pelo menos um gTS do valor de cinza diferenciador, e se disponível, qualquer informação da função de mapeamento que o graduador especificar está de acordo com seu desejo). Por exemplo, olhando na fig. 2b, o criador de conteúdo pode prescrever no sinal que para a renderização de HDR do objeto muito escuro, o mapeamento parcial PD_BLCK(i+2,j) deve ser usado (explicado em detalhes abaixo), e que para a renderização de LDR, o mapeamento mais claro PD_BLCK(i,j) pode ou deve ser usado (isto é, o objeto muito escuro é então tratado como as escadas). Agora, um display receptor de dito brilho máximo de 1500 nit pode decidir usar uma destas duas estratégias (por exemplo, o mais próximo ao seu brilho máximo, o mapeamento/gradação de LDR sendo, no máximo, 750 nit (então mais provavelmente para 400 nit) e o HDR para pelo menos, por exemplo, 2000 nit), ou pode interpolar entre eles de alguma maneira, o que para estas duas funções lineares, por exemplo, a aplicação média da função linear equidistante entre eles. O sistema permite que o criador de conteúdo veja a HDR como “efeitos HDR”, por exemplo, aumentar a luz do brilho, como uma bola de plasma emitida a partir da mão de um mago.

[024] Nosso método pode ser usado quando a codificação de Im_1 é uma codificação de menos bits (que não é a mesmo que o alcance dinâmico menor) que a imagem original (HDR mestre), por exemplo, com uma codificação de luma de 8 ou 10 bits. Neste caso, esta imagem Im_1 pode ser definida para um display de referência de um alcance dinâmico menor (e brilho máximo tipicamente, por exemplo, 500 nit) e gTS diferenciadores pode ser útil para determinar automaticamente as gradações para alcances dinâmicos superiores do display (por exemplo, para um display com brilho máximo de 2000 nits). Mas, similarmente, é claro, a única imagem codificada Im_1 pode ser especificada, por exemplo, para que o display de referência de 2000 nits (isto é, diretamente utilizável para conduzir aquele display, ou pelo menos necessitar de modificações colorimétricas menores antes da renderização), e em tal cenário os valores gTS (e outros dados como as especificações das funções de transformação) pode ser útil, entre outros, para obter imagens conduzidas para displays de alcance dinâmico inferior como, por exemplo, um display portátil.

[025] Isto é, vantajosamente o codificador de imagem (549) opera em um cenário de uso e configuração técnica de forma que uma da primeira e segunda representações de imagem seja uma representação de alto alcance dinâmico, a representação HDR sendo codificada, por exemplo, para um display de referência com brilho máximo pelo menos acima de 750 nit. Isto é, será utilizável sem outra modificação maior para conduzir um display HDR para renderizar a imagem aproximadamente como o artista pretendia. Tal representação HDR pode ser, por exemplo, um número de 3x32 bits ou representação de flutuação de 3x16 bits (RGB ou YC1C2, etc.), etc. Apesar de esta estratégia de codificação poder ser usada em diversos cenários entre diversas representações de espaço de cor (por exemplo, uma primeira representação HDR de 16 bits com a primeira função de gama branca alocando os códigos de luma etc. e uma segunda representação de HDR, por exemplo, de 12 bits), é especialmente útil se pelo menos uma das imagens (entrada ou saída) ou pelo menos parte das imagens é de alto alcance dinâmico (isto é, se assim codificada ou assim obtida, utilizável com alta qualidade colorimétrica conduzindo um display de renderização de HDR, etc.), e em particular, é útil quando o HDR é codificado com palavras da luma de poucos bits (isto é, por exemplo, 8 ou 10 bits ao invés, por exemplo, de 14 ou 20), em cujo caso pode ser usado nos sistemas de capacidades legadas ou capacidades próximas a este. Par plenitude da explicação, o termo técnico recente comumente conhecido de alta faixa dinâmica tipicamente significa brilho superior na cena original ou renderização, mais alta que nos cenários de obtenção de imagem de LDR atuais clássicos, ou ainda mais exato conforme descrito abaixo: um alcance maior de aparências da luminosidade (por exemplo, de acordo com o sistema visual humano de um espectador, mas, é claro, incorporado nos códigos técnicos como lumas). Apesar de poder-se definir bem tal display de sinal dito com referência a um display de ponta de capacidades que são máximas para tecnologias esperáveis em um futuro razoavelmente distante, idealmente a imagem HDR é definida pelo menos parcialmente com referência à cena (já que não dá para saber o que um display futuro fará para explorar o conteúdo codificado, e aficionados na matéria diriam que a imagem precisa armazenar pelo menos o que uma câmera de qualidade potencialmente muito alta ou programas de gráfico podem capturar ou produzir), mas mesmo assim, ao invés de usar um modelo de câmera de referência, pode-se ainda codificar isto como a cena que é aproximada por um display de qualidade muito alta destes. Na verdade, qualquer codificação entre 0 e Lmax, com qualquer função de alocação de código, pode também ser vista como renderizável em tal display teórica tendo um brilho máximo de Lmax, e mesmo no futuro distante, dadas as limitações fixas da visão humana, nunca precisar-se-ia renderizar a luminância do sol fielmente, não em displays englobando grandes paredes, e especialmente, não para displays menores nos quais todo o conteúdo da imagem é visto em um pequeno ângulo sólido. Assim, o graduador pode escolher codificar a imagem com qualquer display de referência que desejar, se um brilho máximo de 500.000 nits teóricos de ponta, ou um mais pragmático como 10.000 nits, contanto que se co-especifique esta colorimetria definindo metadados na sua definição do codec.

[026] Vantajosamente, o codificador de imagem (549) é disposto de forma a codificar diversos valores de cinza diferenciadores de região (gTS_D_Loc_1, gTS_D_Loc_2) entre seções compreendendo diversas das palavras de código de N bits codificando as cores do pixel a partir da representação da imagem (Im_1). Isto permite que o criador (ou mesmo o software de processamento automático) pode alocar, por exemplo, diferentes valores de, por exemplo, “partes sombreadas mais escuras” para diferentes partes da imagem, e assim ter controle superior sobre a capacidade de ajuste da imagem. Por exemplo, em uma região geométrica central na imagem pode-se (des)ocultar os objetos mais escuros que são definidos como, por exemplo, valor de código abaixo de 10, e em um canto os objetos mais escuros estão abaixo do valor de código 5. Isto pode manipular diversas situações físicas, como, por exemplo, mudar geometricamente a iluminação, em que o relacionamento entre os pixels do objeto escuro e mais escuro podem mudar diversas vezes para blocos sucedendo uma redefinição de um gTS local. A codificação real dos valores de cinza diferenciadores de região na relação física (por exemplo, uma memória carregável) com os dados de textura da imagem (Im_1) pode ser feita de diversas maneiras, mas é vantajoso se os metadados necessários são codificados intercalados com os dados do bloco de cor do pixel, precisamente nestes locais onde é aplicável, isto é, tipicamente antes do primeiro bloco em uma fotografia que tem um relacionamento duplo de valores de cinza abaixo e acima do gTS (a ser usado para segmentação ou processamento dos blocos seguidos tipicamente).

[027] Vantajosamente, o codificador de imagem (549) é disposto de modo a codificar um valor de cinza diferenciador da região antes de uma execução de diversas imagens sucessivas, está sendo um valor de cinza diferenciador da região para todas as imagens sucessivas. É claro, os valores de cinza diferenciadores de região mais importantes podem ser codificados em intervalos menos regulares, já que podem ser aplicáveis, por exemplo, a toda uma gravação ou cena. Por exemplo, pode codificar diversas estratégias para codificação das áreas mais escuras para diferentes ambientes de renderização para uma parte sombria de horror de um filme. Posteriormente no filme, em uma cena diurna externa, pode-se codificar separadamente uma estratégia de clareamento a ser usada predominantemente para o céu, antes da primeira imagem daquela cena. Isto permite especificar o processamento em uma gravação ou cena, por exemplo, definindo as partes mais escuras de um porão, e tal definição pode ocorrer novamente após uma gravação intermitente do dito lado externo entre as duas gravações do porão escuro.

[028] Vantajosamente, o codificador de imagem (549) é disposto de modo a codificar pelo menos um valor de cinza diferenciador da região em uma memória não fisicamente adjacente a uma memória armazenando a representação da imagem (Im_1), com “um código de associação geométrica permitindo a associação de cada respectivo pelo menos um valor de cinza diferenciador da região com uma região geométrica da representação de imagem (Im_1) a qual é aplicável, o código de associação geométrica tipicamente compreendendo pelo menos as coordenadas de um bloco da representação de imagem (Im_1). Isto permite, por exemplo, os serviços de visualização ou remasterização. Uma empresa pode, por exemplo, assumir um filme legado (ou mesmo um jogo ou programa etc. já processado de acordo com os presentes princípios), e deixar os graduadores fazerem uma nova análise das imagens. Pode-se então alvas os valores de cinza diferenciadores da região e novas funções de mapeamento, etc., por exemplo, em um servidor na internet. O espectador pode então escolher, por exemplo, ver o filme sob o “Artist_X new grade” fazendo o download a partir daquele servidor (potencialmente sobrescrevendo qualquer demarcação e/ou metadados de gradação existentes). Esta opção poderia, por exemplo, ser oferecida através da interface do usuário após iniciar o filme. Diversos gTS diferenciadores de cinza permitem a co- especificação de diversas funções de processamento pretendidas, e esta estrutura pode ser manipulada parametricamente para nova especificação fácil, por exemplo, mapeamentos colorimétricos do dispositivo de renderização final, ou novas gradações dos dados (que não precisem mudar o código da Im_1) etc. Por exemplo, três códigos gTS nos sub alcances das luminâncias mais escuras podem não ser necessários para uma primeira estratégia de processamento, o que pode ser somente um alongamento linear ou não linear sobre todas as luminâncias entre gTs1 e gTs3, mas uma segunda especificação de gTS2 de uma região intermediária pode ser usada nas estratégias de mapeamento mais complicadas. Por exemplo, o display lateral de renderização pode escolher processar as luminâncias entre gTS2 e gTS3 dando bom contraste visual, mas quase limita os valores abaixo de gTS2. Um transcodificador ou aparelhos intermediários similares podem, por exemplo, aplicar uma limitação leve sobre as luminâncias entre gTS1 e gTS2 que ainda contém alguma informação da captura original, apesar de com pouca precisão já que estas serão as regiões escuras pouco visíveis na maioria dos displays, isto é, necessitando de menor qualidade de codificação. O criador tem, desta forma, usado o gTS2 para especificar informações semânticas adicionais sobre a cena da qual foi obtida a imagem, a saber, cujas partes mais escuras da imagem são menos relevantes. Estruturas separadas podem ser mais complexas que os metadados intercalados com os blocos de dados de pixel e manipuladas mais livremente.

[029] Vantajosamente, o codificador de imagem (549) é disposto de modo a codificar um primeiro valor reservado de um valor de cinza diferenciador da região no sinal de imagem de saída (S(Im_1, MET(gTS)), indicando que para pelo menos uma região geométrica da representação da imagem (Im_1), situada de acordo com uma direção do escâner através da imagem além de um local identificável com o primeiro valor reservado, uma transformação dos valores de pixel conforme codificado na representação da imagem (Im_1) as valores de pixel em uma segunda representação de imagem (IM_RC_HDR), é realizado de acordo com um algoritmo predefinido.

[030] Valores especiais para o valor de cinza diferenciador da região como, por exemplo, “0” ou “-1” (claramente não sendo uma luma válido sobre o alcance [0,255]) pode indicar que a região seguinte da cena deve ser tratada de maneira diferente. Por exemplo, em uma codificação, o decodificador pode se referir a uma parte muito diferente do sinal de imagem (por exemplo, um setor diferente de uma memória destacável conectada), que agora deve ser consultada para obter o sinal de saída final (por exemplo, algumas imagens podem ser codificadas para alguma tecnologia de duas camadas por alguma razão, como, por exemplo, características de sinal diferentes, ou origem, etc.). Neste caso o codificador pode, por exemplo, copiar tal bloco daquele segundo setor de memória para a posição local, por exemplo, na Im_1 potencialmente antes de fazer outra modificação acerca deste, ou alternativamente como valores de luma finais. Ao processar a imagem, as lumas de saída poderiam ser obtidas parcialmente aplicando um algoritmo de renderização de computação gráfica. Ou tal código pode indicar que outra transformação de imagem deve ser aplicada para mudar as lumas do pixel local ou aparência da textura. A região poderia ser qualquer coisa, provido que a via de escaneamento (colocando os algoritmos para algum local inicial (x, y) na imagem, isto é, que é o local identificável) é complementado por algum outro metadado especificando a região, por exemplo, pode ser uma elipse iniciando ou tendo seu centro em uma posição configurada a partir de (x, y). Tipicamente, no entanto, as realizações serão usadas vantajosamente em um sistema com base em bloco, em cujo caso, por exemplo, (algum dos) blocos de 16x16 pixels sucessivos são a região geométrica.

[031] Vantajosamente, o codificador de imagem (549) é disposto de modo a codificar um segundo valor reservado (gTR) de um valor de cinza diferenciador da região no sinal de imagem de saída (S(Im_1, MET(gTS)), indicando que para pelo menos uma imagem sucessiva, um display deve renderizá-lo com uma luminância de saída máxima abaixo de um valor predeterminado. Por exemplo, um valor 255 ou 260 pode indicar que uma parte de uma imagem, ou diversas imagens sucessivas, deve ser renderizada com brilho diminuído para economizar energia.

[032] Vantajosamente, o codificador de imagem (549) tem a unidade de determinação do mapeamento da luma (553) disposta para determinar diversos mapeamentos de luma (TOM) diferentes para pelo menos uma do primeiro e segundo objeto através das regras de ligação da transformação, ou é disposto para indicar com um indicador de processamento (PROC_IND) que diversos mapeamentos da luma diferentes podem ser usados para transformar as cores do pixel de pelo menos um do primeiro e segundo objeto para uma nova representação de cor da segunda representação de imagem (IM_RC_HDR). Devido à agora os diversos objetos relevantes (brilho diferente) serem facilmente identificáveis na cena conforme codificado em qualquer representação de imagem, também é fácil transformá-los de qualquer maneira desejável. Por exemplo, diferentes estratégias de transformação de cor poderiam ser aplicadas ao dito um objeto altamente brilhante, para diversos displays de renderização diferentes pretendidos, ou iluminação circundantes do ambiente de visualização, ou configurações de preferência do usuário, etc. Por exemplo, alguns displays com alto brilho máximo, isto é, capacidades de alto nível na renderização de sub-regiões mais brilhantes da imagem podem usar um mapeamento final próximo ou inspirado por uma primeira estratégia tendo uma aparência contrária para as regiões mais claras conforme definido por uma primeira estratégia de mapeamento, em que os displays de brilho máximo de menor qualidade podem seguir exatamente ou aproximadamente uma segunda estratégia de mapeamento que tem um efeito de diminuição nas distâncias de interluminância de pelo menos alguns dos pixel de tal região clara. E estas transformações poderiam ser (parcialmente) co-codificadas com ou no sinal da imagem, ou (parcialmente) deixadas para qualquer lado receptor (se final ou intermediário), em cujo último caso poderia ser útil se o sinal de imagem contiver algumas indicações brutas de cujos tipos de transformações são desejáveis ou não, etc. Perceba que dependendo do uso, um ou mais dos mapeamentos podem especificar transformações a serem exatamente seguidas, versus as transformações que são uma indicação bruta do que o display de renderização final deve fazer. O último caso tipicamente ocorrerá, por exemplo, no caso do mapeamento realmente codificar alguma gradação precisa (como, por exemplo, um grau mestre a partir de uma codificação do suporte LDR de 8 bits desta), e o último caso pode-se aplicar quando a transformação é outra transformação indicando como aqueles dados da luma de pixel mestre podem ser otimizados ainda para diversos tipos de display. Por exemplo, um display de brilho máximo inferior pode estudar a curva funcional de uma estratégia de limitação leve (que pode ser especificada entre diversos valores gTS semânticos) e então usar um mapeamento de tom de ponta que mantém aproximadamente a aparência visual prescrita.

[033] No lado receptor pode-se construir uma tecnologia amplamente refletida do lado codificador, sendo um decodificador de imagem (605) para codificação de uma representação da imagem codificada (Im_1, MET) de uma cena de alta alcance dinâmico, compreendendo: - uma unidade de decodificação da textura de pixel (608) disposta para obter a partir da representação da imagem codificada (Im_1) dados inclusivos das cores de pixel representando as luminâncias dos pixels de uma imagem decodificada (IM_INTRM); e - um desformatador (607) disposto para extrair da representação da imagem codificada (Im_1, MET) um valor de cinza diferenciador da região (gTS).

[034] Este pelo menos um valor de cinza diferenciador da região gTS pode então ser usada para processamento posterior da imagem, tal como, por exemplo, a determinação do mapeamento de cor ótimo final para p dado display e renderização e ambiente. Então, nosso método é uma boa maneira de lugar a codificação de cor independente do display original e a codificação de cor dependente do display final, que pode ter como propósito, por exemplo, que deve renderizar as cores no ambiente de visualização do display aproximadamente como teria parecido para um espectador humano na cena original. A codificação da imagem real pode ser muito diferente desta (já que tipicamente nós a codificamos com referência já a algum display de referência realistam, que, no entanto, pode ser muito diferente da situação de renderização real ainda: por exemplo, a imagem HDR mestre foi codificada para condições de visualização doméstica de entorno relativamente escuro, e que alguma televisão então a ajusta para as condições finais de alguma maneira mais claras; no entanto muito da complexidade já está feita no grau mestre em relação a um ou mais displays de visualização de referência realista, deixando uma estratégia de transformação de cor final mais simples para o display), no entanto, considerando que normalmente não haverá nenhuma inversão da ordem das luminâncias do pixel, uma boa maneira de caracterizar a cena conforme foi obtida a imagem, e permitir a fácil viabilidade da situação do display separando-o semanticamente em subpartes da luminância/luma, especialmente aquelas que tipicamente serão importantes e altamente variáveis conforme sua aparência nos diversos cenários do display como, por exemplo, as regiões mais escuras ou mais claras da imagem. Perceba que podemos usar a palavra luma para especificar todas as operações matemáticas como, por exemplo, segmentações, já que tal luma será relacionada à luminância real (por exemplo, quando a imagem é gerada no display de referência) através de alguma estratégia de mapeamento da codificação, o que é uma generalização — potencialmente descontínua - de um mapeamento gama como a gama 2.2.

[035] Vantajosamente, este decodificador de imagem (605) compreende uma unidade de segmentação da imagem (606) disposta para usar o valor de cinza diferenciador da região (gTS) para obter um segmento de luma inferior e um segmento de luma superior na imagem decodificada (IM_INTRM),isto é, a separação de entendimento da imagem com base no(s) valor(es) de cinza diferenciador da região, de forma que o processamento posterior como, por exemplo, o processamento de ruído otimizado possa ser feito de maneira diferente para regiões que são finalmente renderizadas de forma diferente (por exemplo, com menos visibilidade do ruído nas partes mais escuras).

[036] Vantajosamente, o codificador de imagem (605) compreende uma unidade de transformação da cor do pixel (609) disposta para aplicar uma primeira transformação de cor (PD_BLCK(i,j) transformando pelo menos os valores da luma das cores dos pixels para pixels, por exemplo, da imagem HDR mestre recuperada no segmento da luma inferior, e disposta para aplicar uma primeira transformação de cor (PM_BLCK(i,j)) transformando pelo menos os valores da luma das cores dos pixel para pixels no segmento da luma superior. Assim, pode- se determinar, por exemplo, uma fotografia de condução ótima a ser renderizada em um display de alcance dinâmico superior (baixo e alto e inferior e superior serão entendidos por um leitor técnico se referindo um ao outro, por exemplo, se uma codificação da cor dos pixels da imagem é para um display de referência de 350 nit, transformando-a em uma representação destinada a um display de referência de 2000 nits, o que significa que esta segunda imagem é para o brilho superior, ou colocado de forma diferente, alcance dinâmico superior à imagem original). Tal separação significa ainda qualidade muito superior uma qualidade muito superior da codificação simples. Se alguém precisar codificar toda a imagem com uma única estratégia, pode-se chegar somente em uma aparência próxima por meio do cálculo da média de todos os tipos de erros (por exemplo, um rosto precisa ser claro, mas então o brilho do porão escuro se torna muito alto, então escurecemos o rosto de alguma maneira abaixo do ideal, e o porão é somente um pouco mais claro). No entanto, agora podemos, por exemplo, escurecer o porão conforme desejarmos, e então corrigir localmente o rosto definindo-o com limites e uma estratégia de atualização. Esta definição parcial também torna fácil mudar somente alguns dos mapeamentos. Por exemplo, através de diversas imagens de uma gravação da cena do porão, devido às mudanças de luz e/ou movimento da câmera, o PM_BLCK(i,j) pode permanecer adequado para toda a cena, ainda a captura (ou aparência necessária) das partes mais escuras pode mudar conforme atravessamos fotografias sucessivas da filmagem. Podemos então carregar uma função PD_BLCK(i,j) diferente após, por exemplo, a quinta imagem da filmagem, contrapondo que o canto escuro, de agora em diante, deve se tornar mais claro de alguma maneira, e precisa de uma estratégia de mapeamento que o escureça opostamente de maneira apropriada, também, obviamente, usando o formato funcional apropriado do PD_BLCK(i,j) para manusear a visibilidade da textura, etc.

[037] Vantajosamente, o decodificador de imagem (605) é disposto para aplicar uma estratégia de transformação de cor específica para as cores do pixel de pelo menos um do primeiro e segundo objeto se o desformatador (607) extrair um valor de cinza diferenciador da região (gTS) de um valor reservado, tal como, por exemplo, um valor de 0 ou 255. Novamente estes valores reservados quando detectados em qualquer lugar no sinal inserido podem ser usados para reverter imediatamente para qualquer estratégia fallback de processamento. Tipicamente outros detalhes estarão disponíveis em qual fallback aplicar (apesar de não necessariamente, já que o receptor pode apenas realizar qualquer coisa sozinho com base, por exemplo, na análise de imagem). Por exemplo, se o sinal está armazenado em uma memória, pode existir um setor de sucessivas estratégias de fallback (por exemplo, código algorítmico definindo os métodos de processamento de imagem e seus dados necessários), e então cada vez que um código reservado de fallback especial é detectado, o aparelho de processamento de imagem receptor pula para o próximo método de fallback para aplicá-lo. Ou os códigos podem se referir a qual fallback aplicar (potencialmente muitas vezes), por exemplo, 260 indica que o primeiro algoritmo armazenado deve ser usado, 261 o segundo, etc.

[038] Vantajosamente, o decodificador de imagem (605) compreende uma unidade de determinação da transformação (610) disposta para selecionar a estratégia de transformação da cor do pixel a partir de uma fonte de memória não associada a nenhum dos dados da representação da imagem codificada (Im_1, MET). Desta maneira, o decodificar lateral receptor tem mais versatilidade para decidir o que vai usar para transformar as lumas do pixel. Por exemplo, o decodificador assume funções da sua própria memória e decide, por exemplo, dependendo das propriedades de um objeto identificado, tal como sua luma média. Ou poderia assumir funções sobre uma conexão de rede, potencialmente determinada em um momento de execução por meio de um servidor. O sinal pode ainda parcialmente guiar isto especificando que é desejável aplicar (qualquer) mapeamento de escurecimento, por exemplo, (isto é, uma transformação que tem como um resultado visual que o objeto pareça mais escuro de alguma maneira, por exemplo, brilho médio em conjunto com uma modificação de contraste e/ou uma área aumentada no objeto, por exemplo, de pixels limitados muito escuros para pixels pretos, etc.), em cujo caso o lado de renderização deve, preferencialmente, não aplicar um mapeamento que clareie o objeto muito escuro (considerando a visibilidade devido a iluminação em volta, etc.). Finalmente, o lado receptor, se sob controle específico do espectador ou não, pode, obviamente, decidir colaborar (parcialmente com estas diretrizes de co- codificação ou ignorar e atravessá-las. Tipicamente, apesar da codificação de imagem (por exemplo, o disco no qual está codificada) poder, por exemplo, prescrever qual transformação não deve ser ignorada nem mesmo relaxada, mas deve ser estritamente seguida ou, vice versa, estritamente não seguida.

[039] Vantajosamente, o decodificador de imagem (605) é caracterizado pela unidade de determinação da transformação (610) ser disposta para determinar a estratégia de transformação da cor do pixel com base em pelo menos um parâmetro do ambiente de renderização, tal como uma característica do display, ou um nível de iluminação do entorno, ou o padrão das cores conforme vistas refletidas na tela frontal do display por uma câmera, etc. Então, novamente, o aparelho lateral receptor pode pelo menos parcialmente otimizar os mapeamentos com base nas informações importantes somente definitivamente no seu lado. Um criador de conteúdo pode especificar seus mapeamentos a serem usados sob a suposição que um certo display e ambiente de visualização (por exemplo, a maioria das luzes da sala apagadas, com iluminação somente atmosférica que pode, na verdade, ser percebida na realidade com o espectador tendo, por exemplo, uma lâmpada de cores vivas no chão ao lado do espectador), mas finalmente o lado de renderização pode mudá- lo, sendo ainda menos ajustado (o que é o caso ideal). Apesar de tal quantidade de precisão ser normalmente não necessária, o criador de conteúdo poderia especificar no sinal que, por exemplo PD_BLCK(i+2,j) era destinado para o caso de haver uma luminância de 1 nit em torno do display, em tal caso se o display de renderização medir 2 nits, ele pode decidir mudar levemente a inclinação de PD_BLCK(i+2,j). Em qualquer caso, isto pode uma informação útil para processar os algoritmos no lado receptor.

[040] As realizações descritas podem ser realizadas de diversas maneiras, por exemplo, por meio de um método de codificação de imagem para codificar uma imagem de uma cena de alto alcance dinâmico compreendendo: - codificação das cores dos pixels da imagem com uma representação da imagem (Im_1) compreendendo N palavras de codificação do bit; - determinação e geração de um valor de cinza diferenciador da região (gTS), que é um valor de luma demarcando abaixo dele as lumas de todos os pixels de um primeiro objeto em pelo menos um bloco da imagem, e acima dele as lumas de todos os pixels de um segundo objeto em pelo menos um bloco da imagem; e - co-codificação em um sinal de imagem de saída (S(Im_1, MET(gTS)) a representação da imagem (Im_1) e o valor de cinza diferenciador da região.

[041] Ou por meio de um método de decodificação de imagem para decodificar uma representação de imagem codificada (Im_1, MET) de uma cena de alto alcance dinâmico, compreendendo: - obtenção a partir das cores de pixel da representação da imagem codificada (Im_1) dos pixels de uma imagem decodificada (IM_INTRM); e - extração da representação da imagem codificada (Im_1, MET) um valor de cinza diferenciador da região (gTS).

[042] Ou como um programa de computador compreendendo o código de software permitindo um processamento para executar qualquer um dos métodos correspondentes às realizações ensinadas, cujo software pode ser adquirido em um disco ou outro produto tangível, ou baixada através de uma rede, etc.

[043] Tipicamente o conhecimento codificado sobre a cena a ser obtida a imagem se deslocará de um aparelho/lócus para outro (se são unidades dentro de um mesmo aparelho ou sistema de aparelhos conectados do consumidor no mesmo local, por exemplo, uma caixa de processamento ou recebimento da imagem e uma televisão ou display conectado por meio, por exemplo, de HDMI, ou serviços executados em aparelhos em países diferentes), isto é, por meio de um sinal de imagem codificando as cores das regiões de uma cena de alto alcance dinâmico, compreendendo palavras de codificação de N bits que codificam pelo menos as luminâncias das cores das regiões, uma demarcação entre pelo menos uma região geométrica de pixel de luminância superior na cena de alto alcance dinâmico ou valores superiores das palavras de código de N bits codificando estas, e pelo menos uma região geométrica de pixels de luminância inferior na cena de alto alcance dinâmico ou valores inferiores das palavras de código de N bits codificando estas. O sistema de código é uma representação técnica-matemática definindo um derivativo de uma luminância da cena (através da captura da câmera) e finalmente uma luminância a ser renderizada, tipicamente através de uma quantidade física chamada luma, que é definida sobre um eixo, e tipicamente com um palavra de código digital cobrindo a extensão do eixo (por exemplo, entre 00000000 e 11111111), ou um número flutuante entre 0.0 e 1.0, e com uma função de alocação (tipicamente uma função gama) mapeando tais luminâncias não linearmente para a luma. Tipicamente, podem existir outras informações associadas ao sistema de código, tal como com o qual a luminância máxima a ser renderizada o valor de código máximo corresponde. Quando falamos sobre este sinal, significamos que as propriedades especificadas estão contidas de alguma maneira no sinal, mas podem ser contidas de qualquer maneira translacionada. Por exemplo, alguns dados poderiam ser misturados ou separados e estruturados de alguma maneira. Também podem haver transformações para outros códigos, tal como, por exemplo, uma modulação ou uma codificação redundante para compensar os potenciais danos de erro do bit, etc.

[044] A imagem HDR pode ser codificada (por exemplo, como uma imagem de textura de 8 bits LDR Im_1 chamada de suporte LDR, mais os metadados para mapear uma reconstrução do grau HDR mestre em pelo menos um mapeamento do tom global) em uma memória, tal como uma memória destacável, tal como, por exemplo, um disco blu-ray armazenando tal sinal.

[045] Na verdade, as realizações da invenção podem ser usadas em muitas realizações, cenários ou usos técnicos, tal como em um sistema de distribuição de vídeo através de qualquer tecnologia de rede, empregando qualquer codificador de imagem, decodificador de imagem, método, sinal de imagem ou outro produto ou implementação de qualquer uma das realizações descritas ou qualquer uso daquele sistema de distribuição de vídeo.

[046] Muitas outras variantes das realizações descritas abaixo são, obviamente, possíveis, e o técnico no assunto entenderá que podem ser realizadas, por exemplo, em aparelhos diferentes em diferentes regiões geométricas do mundo, aplicando sua funcionalidade parcial em diferentes momentos no tempo, ou diversas vezes após uma a outra, em diversos cenários de uso de negócios, etc.

BREVE DESCRIÇÃO DOS DESENHOS

[047] Estes e outros aspectos do método e aparelho de acordo com a invenção serão aparentes e elucidados com referência às implementações e realizações descritas aqui, e com referência aos desenhos acompanhantes, que servem meramente como ilustrações específicas não limitativas exemplificando o conceito mais geral, e em que traços são usados para indicar que um componente é ótimo, componentes não tracejados não sendo necessariamente essenciais. Os traços também podem ser usados para indicar aqueles elementos, que são explicados como essenciais, são ocultados no interior de um objeto, ou para coisas intangíveis, tal como, por exemplo, seleções de objetos/regiões (e como podem ser mostrados em um display). Nos desenhos: A Fig. 1 ilustra esquematicamente diversas representações de uma cena original de alto alcance dinâmico, já que serão renderizados em diferentes cenários, a saber: A Fig. 1a mostra as luminâncias de saída renderizadas absolutas comparadas entre si para um display de alto alcance dinâmico atual, uma exibição de cinema, um display e um display portátil usado ao ar livre, e a Fig. 1b mostra as renderizações em um eixo de aparência universal, cujo sistema de referência absoluto é definido por um espectador humano padrão; A Fig. 2 (isto é, a Fig. 2a + Fig. 2b) ilustra esquematicamente como diversas transformações de sub cor para transformação entre duas representações de cor, ambas definindo uma mesma vista da imagem em uma cena, serão aplicadas a pelo menos as lumas dos pixels de diversos objetos de luminância muito diferente (ou brilho), caindo em diversos blocos de uma decomposição de bloco de uma representação de imagem; A Fig. 3 ilustra esquematicamente uma maneira para codificar alguns metadados adicionais de acordo com algumas realizações em uma definição do sinal de imagem, em particular como codificar os valores de cinza diferenciadores da região perante os blocos de coloridos de pixel aos quais estes são aplicáveis; A Fig. 4 ilustra esquematicamente como um lado receptor pode obter segmentos de diferente luminância ou iluminação na imagem com base nos valores de cinza diferenciadores da região; A Fig. 5 ilustra esquematicamente um sistema lateral de codificação, que pode ser operado por um graduador de cor, em uma realização exemplar de um codificador correspondente aos ensinamentos da nossa invenção; A Fig. 6 ilustra esquematicamente um sistema lateral de decodificação, que pode, por exemplo, ser um sistema de exibição doméstico do consumidor compreendendo tais aparelhos como uma televisão principal, e um visualizador de imagem portátil, e um aparelho de processamento de imagem, tal como um computador central gerenciando a distribuição e o processamento ótimo para todo o vídeo para os diferentes displays; A Fig. 7 ilustra esquematicamente como a projeção das regiões para as quais faixas de luminância (ou luma) são mapeadas pode ser bem selecionada para diminuir os problemas como os erros de compressão; e A Fig. 8 ilustra esquematicamente como nosso sistema pode ser usado em um cenário em que o pixel ou cores do objeto devem ser mapeados para cores ótimos para um número de displays com características técnicas variáveis.

DESCRIÇÃO DETALHADA DOS DESENHOS

[048] A Fig. 1 (isto é, Fig. 1a e Fig. 1b) mostra esquematicamente como uma cena de HDR original (Orig_SCN) pode ser otimamente representada em 4 tipos de display (3 típicos e um hipotético para melhor ilustrar o ponto, a saber, um leitor eletrônico de baixo contraste sob iluminação solar, tendo somente uma pequena faixa R_ERDR_OUTS de luminâncias de saída reprodutíveis), e como uma tecnologia de codificação de imagem deve acomodá-los. Enfatizamos que é necessário dividir conceitualmente as ideias relacionadas a renderização final de uma cena (isto é, as luminâncias a ser fisicamente geradas por um display particular) a partir da codificação das lumas do objeto da imagem. Esta é uma filosofia tecnológica diferente das tecnologias de obtenção de imagem de televisão clássicas como MPEG2, que tem sempre equiparado estes dois espaços de cor correspondentes, de forma, por exemplo, que um sinal codificado de gama 2.2 possa ser diretamente aplicado a um display (padrão), dando a saída renderizada (aproximadamente) correta (lado do estúdio determinado de uma maneira calibrada). Isto somente é útil se existir uma cadeia fechada, isto é, calibrada para um cenário particular, mas a história muda se quisermos ter outro conteúdo como, em particular, imagens de alto alcance dinâmico (HDR), e/ou diversos displays e/ou ambientes de visualização como características fundamentalmente diferentes para renderizar estes sinais. Ainda, poder-se-ia similarmente gostar da simplicidade de ter somente um sinal de codificação da imagem (ou pelo menos alguns poucos), e não imagens codificadas diferentes para cada cenário (apesar de poderem ser grupadas novamente (por exemplo, transcodificadas, ainda transformadas em cor, etc.) e transmitidas através de canais técnicos diferentes), o que de outra forma significaria que um graduador Hollywood ou outro graduador teria que fazer, por exemplo, 20 gradações ao invés de 1 ou 2 conforme anteriormente (por exemplo, um grau de filme mestre e um grau de DVD).

[049] A definição das imagens HDR ou uma tecnologia de obtenção de imagem poderia levar a discussões. Obviamente, não é simplesmente o número de bits que é o critério, considerando que se, por exemplo, o comprimento máximo da palavra (por exemplo, 2A8 versus 2A10) é usado para um certo branco (por exemplo, 500 nits), então a diferença é principalmente ou parcialmente apenas uma da precisão (na verdade, displays com as proporções de contraste reivindicadas de 1.000.000:1 pode ainda não renderizar discriminadamente o mais baixo destes códigos, e em um sinal de gama 2.2 codificando tais pretos profundos também não pode ser codificado, exceto se o display fizer alguma transformação de escurecimento impressivo nos pretos).

[050] A definição usual de uma cena de alto alcance dinâmico é a luminância máxima dividia pela luminância mínima. Isto pode ser uma boa definição de um ponto de vista do hardware, por exemplo, para um display de renderização.

[051] Por exemplo, na cena original, determina quais as capacidades de um sensor de obtenção de imagem da câmera deve ser, também se este operar com, por exemplo, múltiplas tecnologias de exposição, pois qualquer coisa que não possa ser fielmente gravada é limitada em branco ou preto (e existe também o arredondamento e o ruído, obviamente). Também é uma boa maneira indicar o que um display pode renderizar fisicamente, provido é claro que é feito de uma maneira correta, incluindo, por exemplo, a dispersão na placa frontal de vidro da luz gerada pelo display, bem como os reflexos a partir do ambiente (por exemplo, a camiseta branca do espectador em frente à TV). Todos os tipos de dispersão e reflexos de luz são os motivos pelos quais o alcance dinâmico visualizado ou capturado real é frequentemente inferior aos números de mercado citados, independente se é devido aos vazamentos de luz através de todos os tipos de vias dos pontos mais claros da cena para os mais escuros (durante a iluminação da cena, exceto se alguém construí-la cuidadosamente e gerenciar as áreas sombreadas), vias ilegítimas nas câmeras (por exemplo, embaçamento das lentes, ou reflexos do corpo), ou visualização das questões ambientais (por exemplo, display ou dispersão da luz do entorno na placa frontal do display, ou reflexos dentro do display entrando no homogeneizador de luz, etc.) até o próprio olho do espectador (no entanto, apesar de o espectador pode começar a perder a precisão da discriminação escura ao ter fontes de luz mais fortes no seu campo visual, especialmente quando próximo às regiões escuras, poderíamos ignorar este fator já que um display pode precisar idealmente ser melhor que o espectador, e pelo menos uma codificação da imagem deve ser melhor, já que não sabemos antecipadamente como o lado receptor irá processá-la e influenciará a visibilidade das regiões da imagem). Consequentemente, com tal definição da proporção de contraste, dever-se-ia como o nível mínimo usar o na verdade finalmente ainda é discriminável no olho (dado ruído, etc.), e não, por exemplo, o valor teórico que um LED apagado dá luminância de saída (quase) zero (portanto, a imposição de padrões, por exemplo, padrões de xadrez para medir proporções de contraste mais corretas), já que nunca existe uma situação de iluminação zero.

[052] Uma proporção de luminância é, no entanto, tal critério de bom alcance dinâmico para a codificação das imagens HDR. O que deve ser codificado não é tanto uma questão do que é renderizável, mas o invés disso o que está em uma cena e o que pode pelo menos teoricamente ser percebido, isto é, o sinal de imagem precisa conter exatamente ou aproximadamente aqueles dados necessários a serem capazes de recriar a aparência desejada, e em todos os ambientes de exibição esperáveis a renderizarem a imagem, ainda talvez nos melhores displays em um futuro distante (brilhando diretamente no olho, por exemplo).

[053] Por exemplo, somente especificar uma proporção de contraste não considera o fato de que em um ambiente escuro como um cinema, o sistema visual precisa de mais contraste para ver a mesma cena aparecendo na imagem (em que um escalonamento multiplicativo puro no mínimo ou máximo produziria a mesma proporção de contraste). Os contrastes também são, na verdade, fenômenos, considerando que um objeto relativamente claro pode ser feito para ser percebido como muito mais escuro se o envolvido por objetos mais claros (contraste espacial). Na verdade, psicologicamente o espectador começa a analisar a fotografia e identifica as cores que ele acha que são preto, branco, acima de branco, etc. E o espectador pode considerar alguma coisa como preto ou branco, até que perceba um preto mais escuro ou branco mais claro. Então, quão branca uma fotografia parece não é somente uma função d “preto” e do “branco” na cena, mas também uma função de outras medidas de contraste locais que podem ser definidas com base no local dos valores de cinza (por exemplo, pode-se criar uma aparência diferente aumentando a distância da luminância de diferentes cinzas nas texturas - tornando as texturas mais rochosas mais ásperas, por exemplo, ou tornar as sombras mais escuras, ou ainda jogar nos inter-relacionamentos entre nitidez e contraste). Pode-se consequentemente imaginar se é desejado dar a um rosto uma aparência diferente (mais leve, mais contrastante, mais enrugada, etc.), que os códigos definindo as texturas faciais devem permitir tal operação, isto é, se uma imagem deveria ter somente dois valores de cinza definindo a textura facial, mudando o contraste facial seria uma operação muito diferente. Tal irregularidade das cores faciais pode ser um problema de diversas tecnologias de codificação de imagem atual.

[054] Para colocar o problema ainda mais claramente, mostrando um exemplo de que a partir de um ponto de vista da codificação do alcance dinâmico da visão não ser somente o preto mais escuro e o branco mais claro, mas sobre o que exatamente está na cena a ser obtida a imagem, um desenho em branco e preto (isto é, tendo somente dois valores de cinza diferentes) pode ser RENDERIZADO em um display HDR com 5000 nit de branco e 0,5 nit de preto (isto é, com um alto alcance dinâmico da luminância), mas poderíamos realmente chamar esta imagem de HDR? Podemos ainda apresentar outras questões, como se gostaríamos de exibir tal sinal simples com as características respectivamente pretas do branco máximo (branco máximo) do display. Isso não seria artificial, ou pelo desnecessariamente, deixar o precisar-se- ia codificar diretamente estes valores como aquilo (por exemplo, com o código 0 e 10000 e não somente como, por exemplo, 0 e 2). Na verdade, por exemplo, ao graduar as áreas mais brancas, em geral, um artefato da aparência que pode começar a acontecer é que a região branca texturizada começa a parecer pálida) que é diferente da textura física real que a região deveria ter. Chegaríamos a questão: O que é “preto” e “branco” novamente. Na verdade, sob uma iluminação solar, supondo que nosso exemplo seria um desenho em preto e branco, por exemplo, o branco pode ter uma luminância da cena real de 5000 nit, mas sob iluminação diferente poderia ser também somente 50 nit. E exceto se fosse necessário proteger rigorosamente as regiões pretas da iluminação da cena, elas normalmente estariam em algo em torno do 1% de branco, e não 1/10000°. Assim, ignorando que imagens renderizadas mais contrastes podem em algum grau ter uma aparência preferida, provavelmente gostaríamos de mostrar que aquela fotografia em preto e branco, por exemplo, com um alcance de luminância de aproximadamente 100:1 de alto brilho na sub faixa de alta luminância de um display HDR cria aquela aparência de desenho iluminado pelo sol. De outra maneira, de qualquer forma, mesmo se arriscarmos que a fotografia renderizada não pareça estranha. o olho desconsidera algumas da diferença na luminância de renderização, então com um graduador gostaríamos sempre de opcionalmente usar o alcance dinâmico do display disponível dado o que está presente como conteúdo na imagem, e em vista dos efeitos temporais mesmo nas imagens anteriores e sucessivas Também, perceba que apesar de imagens obscuras serem convencionalmente consideradas como um baixo alcance dinâmico, tal imagem com luzes também brilhantes nela precisa pelo menos ser mapeada para uma alta sub-região de um eixo de luminância das cores renderizáveis do display.

[055] Nossa filosofia de codificação é que uma codificação precisa considerar ambos estes fatores, a saber, por um lado, quão dinâmica uma imagem será finalmente tipicamente renderizada, mas por outro lado quais tios de objetos mais ou menos claros a cena da qual foi obtida a imagem continha. Assim, seria mais preciso para nossos propósitos (isto é, representação ou codificação da imagem) que uma imagem HDR seja uma imagem que contém: uma quantidade suficiente de valores de cinza ao longo de um número de faixas suficientes distantes ao longo de um eixo de aparência da iluminação (iluminação sendo uma quantidade psicológica a não ser confundida com a luminância ou luma codificada). Consequentemente, podemos explicar melhor as realizações técnicas necessárias e a física das imagens HDR com o conceito de “faixas de aparência aproximadas”, conforme elucidado com a Fig. 1.

[056] Na Fig. 1 vemos uma cena (Orig_SCN) a ser capturada tendo simultaneamente muitas luminâncias claras e escuras, isto é, detalhes de textura significantes sobre uma faixa da luminância em ambas as áreas iluminadas claras e escuras. Para a região/objeto claro (BR_obj) há ima janela de vidro embaçada, que tem muitas cores boas que deveriam ser precisamente codificadas ou renderizadas. No interior escuro do prédio, existe uma escadaria de madeira escura (DRK_obj), e um objeto ainda mais escuro (VDRK_obj). Isto é, um humano na cena original veria muitas luminâncias claras (e cores de fato) na janela de vidro embaçada, e muitas luminâncias escuras nas diferentes regiões de sombra nas escadas. Ao virar sua cabeça, seu processamento cerebral e da retina se adaptará a aparência na janela de vidro embaçada, ou vice versa tentando discriminar objetos com aparência escura nas regiões mais escuras. O quão escuro tudo parece depende, obviamente, de quão bem os construtores da cena isolaram as regiões mais escuras das regiões mais claras, mas pode-se, por exemplo, imaginar o exemplo de tentar ver através de um pequeno buraco de esgoto no pavimento em um dia muito ensolarado. Isto é, as regiões “mais escuras” podem variar de parecerem cinza escuro para indiscriminavelmente e finalmente preto (ou durante a noite indiscriminavelmente preto mais acinzentado). No display de renderização, gostaríamos de criar, dadas as capacidades, uma experiência de alguma forma similar (por exemplo, cores indiscriminavelmente escuras, com uma luminância baixa o suficiente para que pareçam razoavelmente escuras), isto é, ponderando ambos os fatos de que um número significante de luminâncias de saída por sub faixa de luminância ainda renderizam as texturas do objeto de todos os objetos, ambos claro e escuro, como boa qualidade visível, versus que a janela de vidro embaçada deve parecer significativamente mais clara que a média (dado o alcance dinâmico particular do display, isto pode ser mais de uma simulação usando efeitos “ilusionais” psicovisuais versus uma grande diferença fotométrica real para displays de alto brilho), e a escadaria mais escura que a média (média sendo, por exemplo, o nível de cinza de 18% do entorno da sala iluminada). Independente de como o display fará isto otimamente, a codificação da imagem deve pelo menos conter todas as informações, e preferencialmente de uma maneira mais facilmente gerenciável.

[057] Pode-se agora capturar e codificar esta cena com um único sinal de dados (por exemplo, 0-1023, com uma função de gama fixa para mapear as luminâncias de entrada ou saída para códigos; isto é, por exemplo, se a função gama definir as luminâncias de saída, pode-se primeiro converter a imagem capturada para um N-nit de referência, por exemplo, um display de 16 bits (linear ou outro, por exemplo, com brilho máximo de 4000 nits), e então codifica estes “novos valores da cena” para, por exemplo, uma representação de 10 bits, com a intenção de que neste display de referência ocorreria a reprodução exata e, por exemplo, um display de 2000 nit aproximaria a aparência). Ou pode-se otimizar diversos sinais codificados para diferentes cenários, por exemplo, aplicando uma função gama diferente para um sinal de cinema, para compensar o comportamento do ambiente escuro do sistema visual humano. Mas idealmente o processamento principal - que pode ser muito complexo em vista do comportamento linear e altamente local da visão humana - deve já estar amplamente presente na uma ou mais imagens graduadas codificadas (nas codificações de imagem HDR simples a gradação LDR sendo codificada simultaneamente dentro da gradação mestre HDR, usando o conceito de suporte LDR, isto é, por meio do princípio de que pode-se obter novamente a imagem HDR mestre daquela gradação codificada LDR (por exemplo, uma imagem MPEG-AVC codificada de maneira clássica), invertendo a estratégia do mapeamento de cor usada para fazê-la a partir da gradação HDR máster, usando metadados co-codificados codificando aquele mapeamento; mas, é claro, a codificação de imagem pode conter diversas gradações, se com diversas funções de mapeamento ou pelo menos outras imagens de pixel parciais), isto é a aparência já está determinada aproximadamente corretamente para um número de cenários de display típico. Neste caso, a otimização real do display com uma operação relativamente simples criará a aparência final aproximadamente certa, por exemplo, uma função gama simples final para aumentar o contraste para a visualização do entorno mais escuro, etc.

[058] Em qualquer caso, a aparência final parecerá conforme mostrado na Fig. 1b, e as luminâncias de saída mensurável fotometricamente serão como na Fig. 1a. O primeiro cenário é o sinal sendo mostrado em um display HDR (conforme dito, ou com eu próprio grau HDR otimizado com no máximo o processamento mínimo (por exemplo, algumas especificações do hardware como a simulação do comportamento do tipo CRT com uma compensação adicional para a física da válvula de LCD) diretamente utilizáveis para conduzir o display HDR, ou um sinal de condução derivado de um único sinal de imagem/vídeo HDR codificado). Este display é capaz de um brilho máximo (branco) de 5000 nit, e uma luminância de saída mínima de 0,5 nit. Perceba que o valor mais baixo é uma aproximação média, já que variará criticamente com diversos parâmetros do entorno. Mesmo em um ambiente controlado, as luzes de segurança do teatro podem vazar luz para a tela, e também o fator imprevisível de pessoas ligando seus telefones móveis (apesar de em geral o efeito ser limitado, mas especialmente nas luminâncias mais escuras, pode afetar a renderização). Em uma casa normal, as situações da iluminação podem ser muito variáveis.

[059] Mas ainda a questão é como um humano perceberá tais luminâncias, já que isso dependerá do estado do seu sistema visual, entre outros, determinado pela iluminação do ambiente, se ele pode ver, as vezes, através de uma janela, etc. Um espectador pode controlar este aspecto mudando as configurações da fotografia no seu controle remoto. Em qualquer caso, o display HDR tem um sub alcance relativamente grande de valores claros disponíveis para renderizar a janela de vidro embaçada (isto é, é mostrado relativamente grande, cobrindo uma parte superior da faixa R_D_HDR). Ao mesmo tempo, a escadaria pode ser suficientemente escura, isto é, bem abaixo de 50 nit. É suposto para o nosso exemplo que isto tem um impacto psicovisual que estas escadas pareçam mais escuras comparadas a estimativa visual da iluminação média (por exemplo, 18% de cinza), mas também que ainda os detalhes da textura significativamente facilmente podem ser vistos sobre os reflexos de iluminação do entorno do vidro frontal do display (por exemplo, um cenário no qual o espectador tiver ajustado sua iluminação em volta para um nível de visualização de cinema, e o cinza médio é principalmente determinado pela televisão e seu próprio conteúdo de imagem). Este display HDR (+ ambiente de visualização) é tão bom que pode até mostrar o objeto muito escuro com luminância de saída ainda mais escura e iluminação psicovisual correspondente.

[060] Se agora mostrarmos o mesmo sinal em um projetor de cinema digital em um cinema (novamente, se a gama otimamente corrigida ou não), sabemos que esta renderização do cinema não mostrará brancos acima de aproximadamente 50 nit, ainda sendo um ambiente escuro, pelo menos filmagens mais escuras podem mostrar luminâncias abaixo do dito 0,05 nit, isto é, muito mais escura que a renderização do display HDR do ambiente doméstico. Isto é, a faixa de luminância de saída do cinema R_CIN está entre 0,05 e 50 nit. Não podemos dizer que a janela de vidro embaçada, que estará alocada em uma sub faixa menor de luminâncias mais altas em R_CIN, parecerá igualmente escura como as escuras no display HDR que tem luminâncias de saída quase idênticas, já que o espectador adaptou à sala de cinema escura, consequentemente vê as luminâncias de saída mais baixas como (quase) brancas. Isto é, também no cinema podemos ter um alcance dinâmico relativamente grande, pelo menos entre as fotografias (e pelo menos pode ser codificada se não estiver no filme positivo ou sinal digital, então no negativo principal). Especialmente com alguma da simulação psicovisual, como, por exemplo, reproduzida em cores culturalmente estabelecidas como diurna ou noturna, também o espectador no cinema ainda tem a solução de que após uma cena de porão escuro alguém vai para o sol (sendo isto menos impressivo que no display HDR).

[061] O fato de que o sistema visual humano se adapta pode ser melhor visto na representação da aparência psicológica da Fig. 1b, onde colocamos diversas imagens de saída renderizadas em um eixo de aparência da iluminação (Appear_SCAL). Isto na verdade é o que o cérebro vê (com todo o seu processamento complexo), mas podemos mapeá-la aproximadamente para como os cones da retina se comportam (ou pelo menos com “as conexões das células ganglionares). De qualquer maneira, na nossa filosofia técnica esta complexidade pode ser manipulada pelo graduador humano, já que o criador do conteúdo sempre gosta de ser responsável pela aparência do seu conteúdo. Vemos na verdade que a renderização do display doméstico HDR (DISPL_HDR) e a renderização do cinema (MOV_THTR) são razoavelmente similares (pelo menos ambientes relativamente escuros podem ser simulados, bem como exteriores claros). No entanto, a renderização do cinema não é capaz de mostrar tais regiões muito claras, pelo menos precisamente sem nenhuma deformação de cor (que é mostrada pelo pictograma de alguma forma mais escuro da janela de vidro embaçada, se movendo da região super clara para aa região clara doo eixo de aparência) . Gostaríamos de enfatizar que este efeito também é devido a renderização separada em um cinema versus em um display HDR em casa, considerando que se renderizar-se simultaneamente em um display HDR em um cinema, a comparação se torna novamente diferente (já que agora as regiões claras na tela de projeção relativamente escurecida podem ser diretamente comparadas a aquelas do display HDR). No entanto, estando em uma escuridão relativamente profundo, a renderização do cinema pode simular cenas muito escuras, como, por exemplo, uma cena noturna, na qual lentamente o sol nasce em direção ao horizonte. Ao sentar em uma sala iluminada pela luz do sol, nunca será possível ter esta aparência. Qualquer ambiente tendo também regiões claras (por exemplo, um display HDR brilhando de forma clara co-alocado) destruirá em maior ou menor extensão aquela “ilusão” visual de uma cena noturna completamente escura. Mesmo ignorando que as cores escuras renderizadas no display estariam abaixo da luminância do reflexo do vidro frontal, todas as cores da luz entrando no olho em ângulos grandes a partir do ambiente impediriam essa ilusão (o que é ainda melhor ilustrado com o exemplo do leitor eletrônico). É claro, em princípio poder-se-ia tornar a sala ainda mais escura que no cinema já que em casa a segurança não é uma questão, o que significaria que então o display HDR também tivesse capacidades superiores para o preto mais escuro, mas usualmente as pessoas em casa gostam de ter algum nível de iluminação ambiente aconchegante (de qualquer forma, um aprovisionamento da imagem codificada para todas as situações de renderização também poderia facilmente ser otimizado por aquelas pessoas que realmente gostam de ver filmes de terror da forma mais assustadora em uma sala no breu, o que significaria que as regiões mais escuras da imagem precisariam ser codificadas com ambas a precisão suficiente e facilmente acessíveis para o processamento da otimização colorimétrica). Perceba também que em ambientes muito escuros, o contraste da cena conforme visto pelo sistema visual humano pode degradar seriamente (isto é, conforme poder-se-ia ver a cena original), então pode-se precisar simular isto (por exemplo, em um cinema onde este efeito ainda não é tão forte) renderizando os objetos mais escuros com um cinza escuro um par de paradas acima do breu, e os objetos brancos com um cinza claro um par de paradas abaixo da iluminação da zona de referência branca.

[062] Assim, existem regiões que não podem não ser precisamente renderizáveis em cada display possível, ainda gostaríamos de codificá-las, considerando que existem ou existirão displays que são capazes de renderizá-las (por exemplo, após um clareamento), este exemplo dando uma região ultra escura para o cinema, e uma região hiper clara para alguns displays HDR. Perceba que a região ultra escura do sistema visual humano pode terminar em algum lugar no lado inferior com um alto nível de adaptação visual humana, tal como, por exemplo, para codificar uma caverna iluminada muito vagamente onde alguma luz vaza através de uma rachadura na distância. No entanto, tal nível é irrelevante para o display mesmo nos cinemas mais escuros (teóricos), devido às partes mais claras do conteúdo da imagem/vídeo não permitirem que o sistema visual se adapte otimamente (ninguém assiste filmes de cavernas em uma caverna). No entanto, pode ser igualado ao nível onde o olho começa vendo de forma ruidosa e embaçada, tal como, por exemplo, quando alguém entra em uma sala escura após ter ficado no sol. Tal experiência visual é algo que poder-se-ia querer renderizar, pois transmite um novo nível de qualidade visual, exatamente como luzes ofuscantes no lado claro. Isto é, este é a rotina em que equilibra-se o que (somente) pode ser visto com o que não pode ser visto. Mas o ponto é que uma renderização do ambiente escuro pode mostrar melhor o objeto muito escuro, já que pode renderizá-lo abaixo da região escura do eixo de aparência, onde a região ultra escura começa.

[063] Um terceiro display é um display doméstico LDR (renderização do DISPL_LDR), por exemplo, uma televisão “clássica” com o dito brilho máximo contemporâneo de 300 nit (o que presumiríamos para nossos comportamentos da discussão relativamente similares aos displays mais antigos, por exemplo, de brilho máximo de 100nit). Supondo que o display possa mostrar de alguma forma pretos menos profundos (é claro, nos pretos poderia ser similar ao display HDR, mas para o bem da explicação digamos que tenha, por exemplo, a dimerização global ao invés da dimerização de LED 2D). O display também pode renderizar cores menos escuras, porque talvez em vista do brilho máximo inferior precise reservar uma sub faixa maior da sua faixa LDR R_D_LDR para luminâncias intermediárias e mais claras, então irá renderizar ambas a escadaria e o objeto muito escuto com pelo menos visualmente aproximadamente os mesmos cinzas escuros. Na verdade, o display reservará somente alguns poucos níveis de luminância para a escadaria, tornando-a texturizada menos detalhadamente, e o objeto muito escuro tipicamente será limitado em preto (e talvez ainda infelizmente invisível contra as partes limitadas em preto da escadaria). Outra propriedade típica do display LDR é que este não pode renderizar fielmente os objetos hiper claros, e tipicamente irá limitá-los (levemente) a uma faixa de muito curta de (quase) brancos, tudo isso dependendo, entre outros, de qual contraste é desejado para as faixas médias próximas ao cinza médio. As estratégias de limitação e aproximação podem ter um forte impacto psicovisual, já que o cérebro reconhece que algo especial está acontecendo.

[064] Assim, vemos que a renderização é na verdade uma alocação das luminâncias (ajustadas por meio da adaptação visual humana) (isto é, na verdade, as iluminações e brilhos correspondentes para o sistema visual humano) da cena em diferentes sub faixas da faixa de luminância renderizável do respectivo display. Alguns displays podem somente renderizar uma subparte da faixa total que está aninhada (a partir de pelo menos um lado) na faixa total, e alguns displays podem renderizar aproximadamente todas as aparências relativamente fielmente. Isto é, ao mapear para gerar luminâncias ou na verdade valores de imagem de condução do display (isto é, para conduzir, por exemplo, as válvulas do LCD e alguma condução de retroiluminação), dever-se-ia fazer alguma aproximação, mudando levemente a aparência exata de um objeto ou região da cena, em uma aparência que ainda é razoavelmente similar, e se não convincente, pelo menos aceitável. O exemplo do leitor eletrônico na luz do sul externa foi escolhido para enfatizar o ponto de distorção. Aqui, deve-se forçar a ampla faixa de luminâncias da cena quase em um único valor de luminância renderizável (sua faixa de luminância E_ERDR_OUTS sendo muito pequena), e deve-se deslocar as regiões da imagem em distâncias consideráveis do eixo de aparência (em qualquer caso, como a maioria dos pretos serão super reluzidos pelos reflexos do sol, pelo menos a faixa de aparência será menor, e o display pode também compensar isto usando somente os valores de condução físicos em uma pequena faixa de luminância de saída correspondente). Isto tem como consequência, por exemplo, que as regiões escuras podem não ser totalmente renderizadas, e dever-se-ia fazer escolhas gravemente distorcidas. Ao invés de mostrar, por exemplo, 10% de preto se 50% é o valor visível mais baixo, poder-se-ia também somente renderizar todos estes valores próximos a 50%, ou ainda melhor, com um mapeamento de tom para valores acima disto. Por exemplo, pode-se limitar toda a região mais escura para o que este display tem como seu “preto” (isto é, seu valor renderizável mais baixo), que com tal pequena faixa de luminância pode nem mesmo parecer preto, devido à alternativa de dispersar as luminâncias do objeto escuro sobre as luminâncias mais claras não é uma opção, já que podem então se tornar mais claros que alguns dos pixels da janela de vidro embaçado. De maneira similar, poder-se-ia abandonar o desejo de que algumas cenas podem ser fielmente renderizadas em uma impressão. Poder-se- ia fazer o melhor para usar os princípios de mapeamento e psicovisuais para pelo menos ter um bom equivalente (mas nenhuma janela brilhando exceto se alguém incorporar tintas fluorescentes ou similares e iluminar fortemente com uma fonte UV). Perceba que para a simplicidade, discutimos somente os princípios de um eixo de iluminação unidimensional simplificado. A natureza tridimensional das gamas reais (isto é, principalmente aquelas dos dispositivos de renderização) também tem um impacto interessante no processamento cromático das cores, por exemplo, sua saturação, que mesmo visualmente pode parcialmente ser confundida/equilibrada com o brilho em algumas situações.

[065] Perceba que para o bem da plenitude, também mostramos as aparências de saturação, já que estas ocorrem nas cenas naturais, por exemplo, ao olhar para lâmpadas ou, por exemplo, próximo ao sol. Isto é quando os níveis de opsina no cone da retina se tornam gravemente distorcidos (branqueamento) por um período curto de tempo e você vê pontos. Por exemplo, em uma cena de inverno você pode estar olhando para um sol baixo, e o ar em torno dele pode ser muito claro, e a luz solar refletindo sobre as partículas das nuvens em volta do sol podem ser ainda mais claras. Obviamente, não é desejável renderizar estas regiões em qualquer display HDR com cores brilhantes de saturação do pigmento visual, mas pode-se alocar duas sub faixas de luminância na região hiper clara, isto é, por exemplo, mostrar estas regiões pelo menos um pouco irritantemente claras. Por outro lado, pode-se considerar também que estas cores não são mais tão importantes (ninguém se importa com o brilho real ou cor de um filamento da lâmpada incandescente, apesar de a codificação de casas coloridas brilhantemente iluminadas, ou mesmo alguns reflexos especulares, ou placas comerciais de tubo TL colorido, etc. podem ainda serem importantes) e codificá-las com um valor similar à limitação, o que poder-se-ia chamar de hiper claro, ou uma região próxima aos códigos máximos (por exemplo, somente o valor 1023). O display pode então escolher se quer renderizar este brilho irritante, ou com uma luminância de saída um pouco menor, em cujo caso o cérebro pode estimar o brilho a partir da limitação. Também permite que o criador de conteúdo focalize no que ele precisa codifica precisamente, e que quando usado quase diretamente para conduzir, por exemplo, um display HDR produzirá boa qualidade (por exemplo, contraste) para todas estas regiões (por exemplo, ambos ambientes internos mais escuros e uma sala igualmente mais escura, e ambientes externos ensolarados), e quais regiões muito claras ele considera menos relevante e pode ser sempre limitada (potencialmente com uma luminância de saída abaixo do brilho máximo, por exemplo, em um modo de economia de energia mesmo nos displays HDR. Tais modos de economia de energia podem ser melhor realizados pelo display se o graduador definir um número de tais regiões “irrelevantemente claras”, tipicamente com diversos valores gTS, que o dispositivo de economia de energia pode usar para distorcer a imagem acima de todos tais valores para um número de modos de economia de energia elevados. Na verdade, o criador pode ainda usar artisticamente o um ou mais códigos de “saturação” para descer conteúdo importante da cana original conforme foi obtida a imagem, por exemplo para realizar uma aparência altamente de saturação.

[066] Agora pode-se querer transformar as representações de uma cena em uma primeira colorimetria - em particular um espaço de cor definindo os objetos da cena com as primeiras coordenadas ao longo de uma luma ou luminância ou valor de cinza similar relacionado ao eixo (supondo para a simplicidade as duas coordenadas de cor cromáticas são fixas em ambas as representações, por exemplo, uma tonalidade e uma saturação), de acordo com uma primeira regra de alocação (definindo uma luminância do arranjo do objeto de cena local codificada como um luma de pixel; e apesar de ao invés dos lumas poderíamos codificar também os pixels, por exemplo, com luminâncias em um sistema XYZ, para simplicidade chamaremos de lumas dos valores de cinza codificados) - para uma segunda colorimetria. Como somente um exemplo para descrever facilmente alguns conceitos e realizações abaixo da invenção, iremos supor que temos uma cena original com uma proporção de luminância de, por exemplo, 2097152:1, ou 21 bits se codificada linearmente. É claro, isto pode ainda ser complementado com um valor exato da luminância do ponto mais brilhante ao qual o valor de 2A21 corresponde (o que pode ser diferente para ambientes externos ensolarados que para uma cena interna ao entardecer escura). Na prática, considerando que nenhum display codifica o sol de nenhuma maneira, iremos supor para simplicidade que podemos codificar relativamente fielmente (isto é, como distorções psicovisualmente menos importantes, como baixar a luminância do sol na sua versão renderizada doo display) estas cenas HDR originais com uma codificação HDR mestre de 16 bits (pelo menos para luma Y, e não nos importamos por enquanto se flutuante ou interno). Isto é devido poder-se definir aquela codificação como não linear ao longo do seu eixo de luma, isto é, usando uma gama principal para mapear as luminâncias do objeto de cena para códigos de espaço de cor HDR.

[067] Outro exemplo é codificar, isto é, mapear aquela codificação de 16 bits em um novo espaço de cor/colorimetria, a saber, um código de 8 bit, por exemplo, com a gama 2.2 padrão. Existem diversos mapeamentos da gama para isto, por exemplo, pode-se somente comprimir linearmente a faixa de luma, mas considerando que isto dá maus resultados, normalmente usa-se uma curva sigmoidal, por exemplo, mais gradual, e pode-se usar modelos mais complexos, como, por exemplo, aplicação da compressão a uma versão filtrada de baixa passagem da imagem, e então adicionar mais fortemente o detalhe de alta passagem a esta. Ou o mapeamento pode modelar como o sistema visual humano veria aproximadamente (existindo, é claro, as impossibilidades descritas acima para fazer alguns tipos de renderizações no hardware limitado) a cena original, se vista na nova estrutura de trabalho, por exemplo, de um display com alcance dinâmico muito mais baixo, isto é, um display LDR. O sistema visual humano se comporta não linearmente, diminuindo os aspectos visuais menos importantes, e, por exemplo, uma sombra desagradável na cena original (pelo menos como algumas câmeras a veem) pode ser visto como acinzentado relativamente claro. Não se deve cometer o erro de mapeá-la em uma gama LDR de forma que muito da sombra se aproxime do preto mínimo deste display, porque então, obviamente, o sistema visual a interpretará como muito escura. Deve suavizá-la de alguma maneira diminuindo o contraste (local), de forma que pareça menos profunda, como na cena original. Em geral, o mapeamento da gama para a gama LDR pode usar todos os tipos de matemáticas aplicando a otimização local, etc.

[068] Então, em conclusão, uma função de transformação é aplicada aos pixels da representação de 16 bits para obter a representação de 8 bits. Por exemplo, primeiro uma transformação global e então algumas outras transformações espacialmente locais. E vice versa, pode-se transformar uma representação HDR (por exemplo, prever) (por exemplo, nossa representação de 16 bits) de uma codificação de 8 bits, por outro mapeamento de cor/luma. Um exemplo de tal sistema foi publicado em WO2012004709 (geração de imagens de alto alcance dinâmico a partir de imagens de baixo alcance dinâmico).

[069] Vamos novamente simplificar a explicação focando no mapeamento a partir de uma codificação LDR de 8 bits para uma representação HDR de 16 bits, utilizável para conduzir um display HDR de dito branco máximo de 5000 nit, e assim dando uma renderização artisticamente satisfatória (isto é, boa qualidade) da cena original (por exemplo, parece razoavelmente similar, em que as sombras ainda pareçam ameaçadoramente escura, etc.; n.b. se a codificação mestre de 16 bits original era uma gradação otimamente ajustada por um artista da computação de acordo com as direções do diretor e/ou DOP, por exemplo, tornando a região de sombra ainda mais lúgubre ou ameaçadoramente escura, então a intenção da qualidade pode ser ter o display HDR de renderização transmitindo esta aparência ameaçadora a melhor possível, isto é, conforme pretendido).

[070] Pode haver diferentes maneira de mapear os pixels a partir do seu valor de código de 8 bits em pixels (para a mesma posição espacial) com um novo valor de código de 16 bits diferente. Por exemplo, este mapeamento pode impulsionar o brilho renderizado da janela de vidro embaçada, considerando que o display HDR é capaz de renderizar tais regiões claras, que corresponderão a uma transformação correspondente para obter a luma do pixel da imagem HDR (suposto para a simplicidade que isto conduz diretamente o display HDR), com base em como o display HDR se comporta e o código HDR é definido. Perceba que quando descrevemos o comportamento do brilho dos objetos dos quais foram obtidas as imagens e falamos sobre, por exemplo, impulsionamento iremos comparar, para simplicidade, luminâncias de saída (por exemplo, luminância renderizada no display LDR = 400 de 500 vs. 3000 no display HDR), em que em um espaço de luma codificado real estas podem ser realizadas, por exemplo, escurecendo as regiões mais escuras (dando relativamente o mesmo resultado), e mantendo as janelas de vidro embaçadas altas ambos para a codificação HDR e LDR.

[071] Uma transformação pode ser global, isto é, sempre que o pixel está situado na imagem, a forma funcional da transformação é somente dependente do valor do pixel da imagem de 8 bits/LDR, isto é: Y_16b=f(Y_8b), em que Y_16b é a luma de 16 bits, que pode ser representada, por exemplo, como uma palavra de código binário, ou um valor flutuante entre 0 e 1, etc., e similarmente para Y_8b da luma de 8 bits. Um exemplo de tal função é uma gama global: Y_16b=g*. Y_8bAgamma, em que g é um fator de ganho, e gama o coeficiente de uma função de força.

[072] A vantagem de tal função global é que precisa-se codificar somente uma pequena quantidade de dados, por exemplo, pode-se transmitir e ganhar antes cada fotografia, ou ainda uma sessão de fotografias da mesma cena, tendo as mesmas características de imagem.

[073] A desvantagem é que se usá-la para ir de HDR/16 para LDR/8 (isto é, um sinal que é suposto a parecer bom em um display LDR de branco máximo de 200 nit), apesar de aproximadamente tornar a aparência correta (um comportamento dominante de comprimir linearmente uma fotografia HDR com regiões de alto brilho, é que comprime-se as partes mais escuras muito mais, tornando a fotografia uma aparência média nos displays LDR, mas uma função gama já pode manusear de maneira equilibrada aproximadamente duas regiões, uma região mais escura versus uma região mais clara), pois corrige-se nas partes mais escuras da fotografia fazendo isto menos com o formato gama apropriado. Mas é somente um único formato funcional simples. Ao ajustar criticamente algumas cores em um fundo, cores similares em um objeto do primeiro plano pode então mudar de uma maneira que é para este objeto menos desejável. Também ao mover de 8 para 16 bits, pode-se, por exemplo, colocar as luzes claras à direita da posição de luminância de saída do display HDR (isto é, o Y_16b direito), mas fazendo isto por meio do ajuste/alongamento da função gama, pode-se, por exemplo, tornar as regiões mais escuras mais claras que o desejado. Ou pode-se usar uma função de mapeamento mais complexa como uma ranhura com pontos de controle otimamente selecionados, mas ainda arriscar-se-ia deslocar alguns cinzas intermediários para lumas indesejáveis, para não falar que esta talvez não seja a maneira mais fácil de controlar a aparência da cor da imagem.

[074] O problema é agravado devido a poder ter sido feito, por exemplo, um mapeamento com perdas de dados da cena HDR original para a imagem HDR de 8 bits, o que pode acontecer, por exemplo, para a escadaria escura e o objeto muito escuro. Apesar de originalmente na cena a ser capturada, aquele objeto muito escuro era muito mais escuro que a escadaria, na imagem de 8 bits pode ter valores de luma que correspondem aos valores de pelo menos alguns dos pixels da escadaria. Isto é, os pixels que deveriam ter valores de luma (muito) diferentes agora tem os mesmos valores (ou pelo menos os histogramas dos conjuntos de pixels podem se sobrepor onde não deveriam), apesar de a boa notícia ser que podem estar em diferentes regiões espaciais da imagem. Uma única função operando nos valores de cinza codificados não pode mais discriminar estes dois casos. Isto é, se quiser transformar o objeto muito escuro para lumas do Y-16b que são muito baixas, o mesmo acontecerá erroneamente com alguns degraus da escadaria (resultando, por exemplo, em um escurecimento excessivamente contrastante de algumas partes dos degraus), ou vice versa. Isto é, o aparelho de transformação da cor ou do artista desejará ser capaz de aplicar uma transformação diferente para aqueles dois objetos.

[075] A outra classe de transformações são as transformações da luma local (ou na cor geral), que aplicam uma função diferente para cada pixel. Poder-se-ia, por exemplo, olhar uma área da máscara em torno do pixel, e impulsionar um pouco sua luma dependendo de quais são os valores em volta, por exemplo, se são quase o mesmo, ainda diferentes de alguma maneira. Um exemplo disto é atingir o ponto máximo em torno das bordas do objeto onde é desejado impulsionar as lumas de pixel local de alguma maneira acima vs. abaixo do valor do perfil da etapa na proximidade da borda. Um exemplo na transformação/codificação das imagens HDR é o princípio JPEG-HDR, no qual usa-se uma imagem JPEG- HDR normal para a textura, e então co-codifica uma imagem de impulso que tem um fator de impulsão para cada pixel. A vantagem é que poder-se-ia co-codificar qualquer desejo de transformação local algorítmica como realizado como um resultado final em tal imagem (por exemplo, aumentando o contraste da textura de uma primeira maneira, e um gradiente de iluminação semiglobal em outro, que o artista da gradação poderia otimizar para seu desejo), ainda que venha em um preço rigoroso de uma quantidade aumentada dos dados a serem codificados, já que agora para cada imagem HDR duas imagens LDR devem ser codificadas (versus, por exemplo, nossa única imagem do suporte LDR mencionado acima). Poder-se-ia perguntar se alguém codificar 8bit_texture*8bit_boost, se não é melhor codificar de maneira bruta o 16bit_HDR.

[076] Agora, existe uma maneira média, pois se um certo impulsionamento é desejável, será visualmente desejável para todo um objeto, por exemplo, a janela de vidro embaçada. Isto é, os valores de luma/impulsão do pixel na imagem de impulsão não serão totalmente espacialmente descorrelacionados, se processar/codificar de maneira inteligente, eles podem estar assim correlacionados pode-se representá-los de forma muito mais simplificada. Isto é, pode-se especificá-los parametricamente de uma maneira funcional, talvez ainda tão simples como com um único número de impulsão que pode ser armazenado nos metadados co- codificados.

[077] Isto necessitaria de objetos codificados, ou regiões de imagem mais genericamente geométricas.

[078] Um exemplo fácil desta segmentação em pedaços é definir uma grade de blocos, e então definir uma transformação ótima para cada sub área retangular. Por exemplo, poder-se-ia definir um multiplicador de ganho e estabelecer para cada e todos estes blocos conforme no documento de patente EP2009921 [Liu Shan et al. Mitsubishi Electric: Method for inverse tone mapping], ou co-codificar uma gama local para cada bloco diferente. Tais métodos normalmente sofrem rapidamente de artefatos de bloco. Por exemplo, pode-se vir para um ganho ou gama ótima diferente a ser aplicado ao bloco BLCK(i+1,j-1) (vide Fig. 2a) e talvez para blocos além deste como até o BLCK(i+1, j) que para o bloco BLCK(i+2,j). Isto é porque para o bloco anterior poder- se otimizar a transformação valorizando altamente uma aparência ótima da escadaria, em que para o último bloco pode-se otimizar, por exemplo, focando um critério de visibilidade do objeto muito escuro. Desvios ainda menores em uma parte da curva (isto é, para algumas lumas do pixel disponível de Y_8b) pode resultar em uma visibilidade de uma diferença das estatísticas das lumas Y_16b das partes/objetos de fundo nestes dois blocos, isto é, resultando na percepção de uma ligação visual, já que o cérebro é treinado para selecionar tais diferenças estatísticas, por isto pode significar detectar um tigre se escondendo na grama amarelada. Ao aplicar alguns algoritmos, pode-se ver uma grade grosseira, cuja visibilidade é aumentada pelas modulações temporais da estatística da cor da região subjacente após a transformação para Y_16b.

[079] Agora existe também uma possível solução para aquele problema, a saber, poder-se-ia codificar precisamente todos os objetos, e consequentemente garantir que todos os pixels do objeto do primeiro plano escuro obtenham sua transformação local ótima, e os pixels da região de fundo de todos os blocos naquela região obtenham a mesma transformação dando a ele a renderização ótima, e consequentemente sem as bordas do bloco visual.

[080] Mas todas as esperanças de fazer isto evaporariam em vista da eficiência da codificação, isto é, a quantidade de bits necessários novamente, conduzindo-nos para a obrigação de aceitar a codificação de duas imagens, ou provavelmente ainda a codificação Y_16b bruta (sendo que, talvez, para a compatibilidade com versões anteriores, outra codificação Y_8b seria adicionalmente necessárias).

[081] Além disso, não somente faz a codificação precisamente da ligação real, por exemplo das nossas escadas envolvem muitos dos dados a serem codificados, por exemplo, para uma função da ranhura, mas também os graduadores frequentemente como para tornar suas seleções de objetos menos precisas, especialmente ao necessitar fazer 100s ou 1000s de gravações em um filme.

[082] No passado, tais codificações orientadas para o objeto têm sido tentadas na estrutura de trabalho MPEG4-2, mas nunca foram bem sucedidas por diversas razões. Não se pode somente extrair estes objetos, já que não se sabe quais são suas definições de padrão da textura espacialmente variantes, então somos levados a codificar seus limites. Mas isto leva a estruturas de codificação complexas (comparadas a simplicidade universal da tecnologia de codificação com base no bloco), tal como, por exemplo, ranhuras ou serpentes, e secundariamente provavelmente a necessidade de intervenção humana para posicionar otimamente estas serpentes (já que o desalinhamento dos limites é uma praga de muitos algoritmos, por exemplo, faltando um pedaço do canto de um objeto), e em terceiro muitos valores de código adicionais para codificar estas curvas da limitação. Todos estes fatores complicadores não parecem favorecer a fácil adoção no vídeo prático ou ainda os padrões de codificação da fotografia.

[083] Mas o inventor percebeu que na situação de codificação HDR particular (isto é, ao transformar entre uma primeira dinâmica inferior e, por exemplo, uma segunda representação do alcance da luma dinâmica superior de uma cena) existe quase sempre uma propriedade particular da imagem que permite uma codificação com toda as vantagens da segmentação precisa, ainda com a vantagem de precisar também de somente de alguns poucos bits de dados adicionais. Em todas as renderizações (ou codificações da imagem subjacente) da Fig.1, existe sempre uma hierarquia do brilho da região (estendendo as faixas de luma ou luminância diferentes), por exemplo, a janela será sempre o objeto mais brilhante. E apesar de espacialmente existirem objetos mais escuros à esquerda, os objetos mais brilhantes no meio e novamente os objetos mais escuros à direita, tipicamente em cada região do local existe sempre alguma parte da fotografia que é mais escura, e alguma parte que é mais clara (na verdade, podem existir diversas classes, como também objetos escuros médios, mas pelo menos alguns pixels são os mais claros e alguns são os mais escuros, e normalmente ainda têm estruturas geométricas relativamente simples como a estrutura preenchida sólida convexa da janela de vidro). Mas perceba que mesmo se tivéssemos um padrão de barras de cela contra um céu claro em um bloco, isto não é um problema já que todas as barras de cela são facilmente discriminadas dentro do bloco como tendo pixels mais escuros. Também, a distribuição ao longo de diversos blocos é normalmente facilmente gerenciável, mesmo se incluir reiniciar alguns valores gTS em algumas vezes entre os blocos ao longo de uma via do escâner. Para um caso ímpar que incidentalmente aconteceria mais dificilmente, pode-se, obviamente, recorrer a métodos ou estratégias auxiliares.

[084] O princípio é explicado com a Fig. 2a e a Fig. 2b.

[085] Na Fig. 2a mostramos nossa imagem com a iluminação do vidro embaçado da escadaria de madeira escura com sua subdivisão de blocos sobreposta. É nestes blocos que, por exemplo, um algoritmo de análise automática da imagem analisaria as estatísticas da imagem local, tal como, por exemplo, o histograma da luma local (ou derivada deste o histograma de luminância, por exemplo, de uma representação da cena em uma colorimetria de referência da renderização do display) e chega a uma afirmação para criar uma imagem Y_16b HDR transformando uma imagem Y_8b LDR. Por exemplo, pode-se usar princípios estatísticos e conhecimento sobre como uma imagem típica pareceria (se os degraus já são relativamente escuros, um primeiro mapeamento particular pode tipicamente torná-los muito escuros em um display LDR, ou o graduador pode somente testar tal cenário verificando-o), e então selecionar uma gama de mapeamento, por exemplo, de 4.3. Um exemplo de tal transformação desejável é mostrado na Fig. 2b. Conforme dito acima, não é necessário ser uma função ou algoritmo de transformação completa (ao invés de uma função gama, poder-se-ia ter um conjunto de regras programadas, como, por exemplo, calcular uma medida de textura local em uma variação local da luma, etc., para chegar a um valor de luma final para um ou mais pixels locais) por pixel, mas desejamos a transformação otimizada semiglobal, isto é, uma transformação tipicamente por objeto ou classe. Na região da imagem coberta pelo bloco BLCK(i-1,j-4) vemos uma sub cena local na área selecionada com aquele bloco compreendido de dois objetos, a saber, uma parte da janela de vidro embaçada, e a parede em torno dela (que poderia ter, por exemplo, tijolos ou papel de parede, a textura dos quais também pode ter que ser renderizada com boa qualidade, mas para a simplicidade isto não é mostrado), que ocupa aqueles pixels do bloco que não estão na janela de vidro embaçada. Devido à estes objetos serem muito diferentes (uma obtenção de imagem contrária à luz dos pixels mais escuros contra o lado externo claro, não começando a explicar ainda que as cores saturadas luminosas da janela de vidro embaçada pode demandar tratamento especial), podemos desejar aplicar transformações muito diferentes para obter uma nova codificação da imagem, tal como, por exemplo, Y_16b, pelo menos para algumas categorias de displays aos quais o sinal é tipicamente destinado ou pelo menos útil). A janela e a parede são objetos muito diferentes, e em particular, são iluminados diferentemente. Não somente a parede é iluminada (com quaisquer propriedades físicas que ela mesmo tenha, tal como um BDRF, reflexo, etc.) por qualquer luz que esteja no interior da sala, mas tipicamente cria sua cor/luminância refletindo a luz do seu entorno, e em particular sua principal fonte(s) de iluminação. A janela, por outro lado, é uma cor translúcida, já que modula diretamente por meio da absorção de luz a partir de fora. Pelo menos gostar-se-ia de ver a janela como mais clara em qualquer renderização do display, mas poderiam existir critérios de qualidade de renderização adicionais, em vista do seu mecanismo de geração de cor diferente. Poderia ser aquele que quer mostrar no display HDR a parede com luminância de saída relativamente escurecida, não muito diferente do que um LDR mostraria, ou uma parede real refletiria estando no ambiente de visualização escurecido do display e do espectador. Por outro lado, poder-se-ia querer impulsionar a janela de vidro, que está codificada na imagem LDR com valores de luma não muito mais altos que aqueles da parede, já que, de outra forma, um display LDR não pode mostrá-las (relativamente fielmente) de nenhuma maneira, em lumas que estão em algum lugar próximas ao topo da gama realizável do display HDR, isto é, tendo uma alta coordenada Y_16b de luma. Isto é, uma imagem HDR apropriada deve ser construída com paredes mais escuras, e janelas muito claras.

[086] Na Fig. 2b mostramos outro exemplo mostrando o que fazer com os degraus, e uma função de mapeamento da luma de comportamento total TM_BLCK(i,j) é mostrada para o que é desejável: em caso de qualquer luma de entrada possível Luma_in estar presente para um pixel naquele bloco, o que é então a luma de saída transformada Luma_out da imagem Y_16b HDR. É claro, algumas cores não estão presentes na realidade (naquele bloco não existe nenhuma janela de vidro embaçada), então temos que mostrá-las tracejadas. O que é relevante são as funções de transformação para aquelas faixas da Luma_in que estão presentes. Então, o técnico no assunto entenderá que isto permite diversas realizações com base em uma versatilidade ou complexidade de codificação desejadas. Poder-se-ia armazenar toda a função TM_BLCK(i,j) com as partes tracejadas dados alguns valores (considerando que isto é facilmente alcançado se um codificar-se a transformação com uma forma funcional, tal como uma função gama, mas também se a transformação é codificada como uma tabela de consulta, e os valores intermediários podem se tornar úteis nas partes da(s) imagem(s) onde estão presentes), ou poder-se-ia armazenar em locais separados somente as subtransformações, tal como a transformação parcial PD_BLCK(i,j) necessária para a escadaria definida ao longa da faixa luma_in RNG_COD_DRK, unir tais transformações parciais tem muitas vantagens. Elas podem ser armazenadas em qualquer lugar e por qualquer motivo. Pode-se entender que a transformação parcial PD_BLCK(i,j) pode ser armazenada em algum lugar (por exemplo, no começo desta gravação de imagens, ou até mesmo no começo do filme) como uma transformação muito maior que codifica o comportamento do mapeamento do papel de parede, também em lugares onde é muito mais claro, devido a ser iluminado, por exemplo, por uma lâmpada local na sua proximidade. Mas então somente a parte dentro da faixa RNG_COD_DRK é tomada a partir desta (e, por exemplo, armazenada em uma memória temporária ao aplicar o algoritmo de mapeamento da luma para todos os pixels daquele bloco TM_BLCK(i,j). Tais transformações parciais poderiam ainda serem aplicadas, por exemplo, como um serviço de internet ou outro serviço em rede, por exemplo, em um serviço de proteção dos direitos autorais ou somente um serviço separado oferecendo uma renderização mais bonita de alguns objetos, ou em cenários rápidos, com em jogos, etc.

[087] Então o TM_BLCK(i,j) deste exemplo mostra dois mapeamentos da luma parciais relevantes, a saber, primeiramente, a parte PD_BLCK(i,j) para os degraus que é um alongamento linear com compensação que clareia os degraus de alguma maneira comparado a sua codificação de imagem LDR escura (isto é, Luma_in), e então impulsiona o contraste de alguma maneira, tornando os grãos na madeira mais visíveis. Secundariamente, existe a transformação parcial PM_BLCK(i,j) para o plano de fundo da sala (que pode neste caso ser o mesmo piso ao invés de papel de parede), que neste exemplo é um alongamento (curvado) variante. O mesmo mapeamento tipicamente seria aplicável a ambas as partes do bloco BLCK(i+1, j-1).

[088] No entanto, se agora chegarmos no bloco BLCK(i+2,j), esta estratégia de mapeamento poderia ainda fazer muito bem para a parte do plano de fundo, mas não para os pixels com luma_in na faixa RNG_COD_DRKm, já que agora codificam o objeto muito escuro. Este poderia ser mostrado muito mais escuro no display HDR, isto é, tendo luma_outs inferior Y_16b na imagem HDR mapeada a partir da imagem LDR. Isto é mostrado pela linha mais grossa que mostra a nova estratégia de transformação parcial PD_BLCK(i+2,j) para aquele bloco, isto é, aquele novo objeto diferente naquele bloco. Ele tem um fator de alongamento muito mais suave, já que deseja manter todas as cores do objeto muito escuro muitos escuras, e quase indiscrimináveis.

[089] Consequentemente, precisamos de um novo mecanismo técnico que permite mudar rapidamente tais estratégias de mapeamento parciais sobre as partes dos diversos blocos, que realmente correspondem aos objetos reais necessitando de renderizações ou graduações ótimas diferentes.

[090] Agora o inventor percebeu que no mundo da obtenção de imagem HDR (isto é, tipicamente envolvendo o mapeamento entre as diferentes representações de cor da mesma imagem(s), por exemplo, espaços de cor com base em Y_8b para Y_16b) existe quase sempre uma relação especial entre tais regiões ou objetos parciais dentro dos blocos, a saber, suas lumas representativas (ou luminâncias ou representações similares) são diferentes. Uma luma representativa poderia ser uma luma média, mas tipicamente uma propriedade mais firme é que a luma mais escura do primeiro objeto (no exemplo do bloco BLCK(i+2,j) o plano de fundo (piso) é mais claro/mais alto que a luma mais clara de um pixel na região parcial mais escura (neste exemplo de objeto muito escuro). Isto é, pode-se demarcar aqueles dois codificando meramente um “valor de cinza diferenciador da região” para pelo menos aquele bloco, e tipicamente um número de blocos além (supondo uma certa direção do escâner, por exemplo, um ziguezague da esquerda para a direita). O valor de cinza diferenciador da região é , consequentemente um limite da luma (ou coordenada de iluminação similar da representação de cor, na verdade, pode-se sempre recodificá-lo para definições diferentes das faixas de luminância das imagens, exatamente como pode-se redefinir as estratégias de mapeamento, por exemplo, a partir de uma codificação [0,255] para uma codificação [0.0, 1.0] dos mesmos dados de textura da imagem) abaixo do qual o primeiro objeto é codificado e acima do segundo objeto. E apesar de a escadaria no bloco BLCK(i+1,j-1) poder necessitar de outro valor de cinza diferenciador da região, devido a aqueles degraus conterem alguns valores mais claros na imagem LDR que o objeto muito escuro, o princípio permanece o mesmo. Para a janela de vidro embaçada contendo blocos, a ordem é revertida e agora o plano de fundo é a região parcial mais escura nestes blocos, mas o princípio permanece o mesmo. Tendo tal valor de cinza diferenciador da região simples, um aparelho receptor lateral pode perfeitamente reconstruir precisamente do pixel os objetos necessários. Isto não seria possível na codificação genérica orientada pelo objeto, já que um peixe poderia conter, por exemplo, cores azuis no seu interior também ocorrendo no oceano em torno dele, mas o problema da representação da imagem HDR é sempre ter regiões muito mais claras co-situadas em algum lugar na imagem com regiões mais escuras. Isto pode acontecer tipicamente devido, por exemplo, a estas regiões serem iluminadas de maneira diferente, ou até mesmo serem auto luminosas como lâmpadas. E outra propriedade é que tais regiões de luminância (muito) diferentes são de alguma maneira geometricamente separadas na imagem, isto é, frequentemente em diferentes blocos, o que permite outra otimização. Este é o exemplo de objeto muito escuro, que é, na verdade, escurecido como os degraus, e pode usar ainda (alguns) os mesmos códigos de luma na imagem LDR. Mas já que ocorre em um bloco diferente, a única coisa que é necessário otimizar são os metadados semânticos da representação, que podem ser tão simples quanto o valor de cinza diferenciador da região, que pode ser, por exemplo, neste exemplo o valor mais alto de RNG_COD_DRK. Isto é, um módulo de segmentação do objeto na extremidade de recebimento (que pode realmente ser o mesmo tipo de aparelho que na extremidade de envio ou existe na extremidade de envio, de fato, mas é módulo que tipicamente obtém a imagem LDR + metadados contendo os diversos um ou mais valores de cinza diferenciadores da região necessários) pode segmentar precisamente todos os objetos relevantes com base no valor do valor de cinza diferenciador da região que recebeu antes do primeiro bloco com degraus iniciado, e similarmente para todos os blocos consecutivos. Pelo menos esta codificação será usada para todos os blocos contendo degraus, isto é, até que a situação muito nova ocorra pela primeira vez, em BLCK(i+2,j), onde o objeto muito escuro está. Antes que este bloco comece, a nova situação é comunicada transmitindo um novo valor do valor de cinza diferenciador da região. Agora, também na extremidade de recebimento, o decodificar é então reiniciado e instruído com nos valores apropriados, para fazer novamente a segmentação corretamente, como teria sido verificado antes de finalizar o armazenamento na extremidade de transmissão. Tipicamente, o codificador pode ser conectado, por exemplo, ao software que permite facilmente o graduador a definir os valores gTS relevantes. Por exemplo, ele pode ter um controle deslizante para estabelecer um valor, e então ver nas pseudocores Por exemplo, vermelho vs. verde) quais partes da cena (talvez local para os blocos selecionados) são determinadas como abaixo ou acima do gTS. Ou ele pode selecionar grosseiramente as regiões, e o aparelho pode já semiautomaticamente auxiliar o graduador, analisar as estatísticas e, por exemplo, propor um primeiro valor do gTS com base em uma estimativa das regiões coerentes que variam consideravelmente em brilho. Ou o graduador pode rabiscar rapidamente sobre uma região, por exemplo, dentro da janela de vidro embaçada, e já selecionar pelo menos os valores iniciais para o gTS deste, que deveria então ajustar por meio de qualquer um dos diversos controladores da interface do usuário.

[091] E uma vez tendo estes segmentos, é uma tarefa fácil associá-los às transformações necessárias. O decodificador pode, por exemplo, marcar todos os pixels do plano de fundo como “objeto = 0”, e, por exemplo, aplicar uma cor global ou estratégia de mapeamento da luma conforme codificado antes do início da fotografia (ou ainda padrão para um tipo de display HDR de referência, tal como uma gama 4.0). Ou o decodificador (e codificador para emular primeiro a capacidade de decodificação) pode antes de uma atualização do bloco particular, o mapeamento a ser aplicado aos objetos do plano de fundo/objeto = 0. A escadaria pode ser marcada como “objeto = 1” e alguma regra de ligação associa um mapeamento à aqueles pixels (segmentados).Por exemplo, a regra padrão poder que se um novo mapeamento é codificado perante o bloco, esta função (ou algoritmo) de mapeamento deve ser aplicada às lumas do pixel que estão abaixo do “valor de cinza diferenciador da região” atual. Ou a função de mapeamento pode ser codificada tal como, por exemplo, aplicável ao longo (principalmente ou somente) de tal faixa da luma, que deve claramente ser usada para o objeto mais claro das duas (ou mais) regiões.

[092] Então precisamos somente de poucos dados adicionais para codificar os objetos, a saber, uma ou mais vezes, dependendo da complexidade da imagem, um valor de cinza diferenciador da região. Para as imagens mais simples, por exemplo, com somente uma janela para fora, um único gTS pode ser suficiente. Poderíamos ainda usar esta estratégia para ajustar os mapeamentos no vase de não haver descontinuidade clara da luma entre as duas regiões parciais, por exemplo, para gradientes de iluminação ao longo do papel de parede de fundo poder-se-ia usar este mecanismo com valores de cinza diferenciadores da região variantes para aplicar alguns mapeamentos diferentes de alguma forma, por exemplo, às partes iluminadas mais escuras, por exemplo, para modificar a visibilidade.

[093] Diversos cenários são possíveis. Para a maioria das cenas HDR, existirão apenas duas regiões de iluminação diferentes por bloco, e podem ser ainda somente um par de regiões de iluminação diferente, por exemplo, 2 (no caso de somente a janela de vidro embaçada necessária um mapeamento diferente comparado a um mapeamento global que é julgado satisfatoriamente para o resto da fotografia). Neste caso, necessitar-se-ia somente de um par de vezes para transmitir um valor de cinza diferenciador da região entre os códigos da cor do pixel dos blocos (ou codificações similares, como, por exemplo, os dados do pixel, em uma estrutura de dados que é co-monitorável com o escâner dos blocos). Na verdade, no cenário simples da janela de vidro embaçada, um único valor de cinza diferenciador da região pode ser suficiente, isto é, pode ser co-codificado antes da gravação de imagens no filme contendo aquela cena. Neste caso, o módulo de segmentação entenderá que cada luma acima do valor de cinza diferenciador da região é suposto a ser tratado/mapeado como uma janela clara. Em algumas ocasiões, podem existir mais de dois objetos sobreposto em um único local do bloco, em cujo caso teremos um objeto mais escuro, um objeto meio claro e um objeto mais claro. Neste caso, eles podem ser segmentados pelo mesmo princípio transmitindo dois valores de cinza diferenciadores da região, por exemplo, perante àquele bloco. Poder-se-ia fazer o mesmo também no caso de somente o objeto mais escuro estar no bloco atual (por exemplo, com o objeto meio claro), e o objeto mais claro ocorre somente em um par de blocos posterior, isto é, codifica-se estes dois valores de cinza diferenciadores da região, então para uma execução de 10 blocos consecutivos. Existe somente um cenário ocorrendo frequentemente onde dois objetos de brilho/luma similares ocorrem nos mesmos blocos, isto é, têm um número de pixels da mesma luma, significando que não podem ser definitivamente alocados para ambos os objetos, ou colocado de outra maneira, englobando a sobreposição das faixas (considerável, caso contrário não é frequentemente tão problemático). Este seria o caso se o objeto escuro é: Realmente codificado com códigos duplamente alocados (isto é, não reserva-se, por exemplo, somente três códigos, luma 0, 1 e 2 para somente nosso objeto escuro, cujos valores então não estão presentes nos degraus; e 2) estes dois objetos não são separados como no nosso exemplo, mas colocados no mesmo bloco, por exemplo, tipicamente se sobrepondo. Neste cenário e no caso do criador de conteúdo ainda se importar sobre ter tal codificação de alta qualidade destas regiões escuras, nosso codificados necessitaria usar um cenário reserva, por exemplo, em uma estratégia de codificação da imagem HDR, ao invés de prever toda a fotografia por meio dos mapeamentos locais de segmento com base na sua segmentação orientada por metadados presentemente ensinada, precisaríamos de uma codificação diferente, por exemplo, poder-se-ia adicionalmente co-codificar uma pequena imagem somente o tamanho daquele bloco contendo diretamente os valores Y_16b necessários, e então sobrepor estes na imagem HDR nos locais do pixel destes blocos. E poder-se-ia usar ainda o mecanismo do valor de cinza diferenciador da região para este por meio do uso de limites reservados particulares. Por exemplo, um valor de cinza diferenciador da região de zero ou -1 pareceria “não fazer sentido”, pois não há lumas abaixo disto, isto é, pode significar a estratégia de codificação fallback (por exemplo, sobreposição). Além da sinalização, uma estratégia de codificação HDR de substituição (ou outra imagem) como, por exemplo, codificar uma pequena parte de uma imagem a partir de um vídeo não como Y_8b LDR, mas uma imagem, por exemplo, Y_16b parcial, a ser substituída (também após a transformação apropriada tipicamente) para aquela região da imagem ao gerar uma imagem de alcance dinâmico superior, pode-se também usar valores reservados por outros motivos. Por exemplo, um valor de cinza diferenciador da região de 260 pode indicar que o bloco seguinte é tão difícil de segmentar, não será possível com base em um ou mais valores de cinza diferenciadores da região na faixa de luma codificada (por exemplo, 16, 200 e 240), mas preferencialmente outra estratégia de segmentação é necessária. Por exemplo, após a detecção deste valor reservado de 260, o lado de recebimento pode usar um mapa já segmentado para pelo menos o bloco atual ou blocos mais segmentados. Isto é, aparecerá então em uma imagem de pequeno segmento co-codificado, no qual para pelo menos os blocos sucessivos de pixels são marcados, por exemplo, ou como “0”, “1” ou “5”, no caso estes são os três tipos de objeto presentes. Após esta segmentação reserva não ser mais necessária, o algoritmo com base no “valor de cinza diferenciador da região” regular pode ser reiniciado, por exemplo, por meio da recodificação antes do primeiro bloco ao qual a segmentação regular aplicará os valores não reservados antigos novamente (por exemplo, 16, 200 e 240, ou outro código gTS reservado, como 270, poderia ser usado para indicar estes resumos da codificação de metadados da segmentação regular, e que os valores gTS anteriores (tipicamente armazenados na memória de trabalho no lado de recebimento) são novamente aplicáveis.

[094] Mas de qualquer maneira, mesmo quando ocasionalmente precisando de outra estratégia reserva para as raras situações muito complexas, temos uma codificação que é muito eficiente em relação aos dados (pois precisamos principalmente somente dos mapeamentos e dos valores de cinza diferenciadores da região demarcando em quais pixels qual mapeamento precisa ser aplicado, e normalmente alguns outros metadados para especificar precisamente aquela ligação (por exemplo, regra de ligação da transformação: objeto = 3 ^ usar o mapeamento = 5)) pois somente muito raramente precisamos de uma codificação reserva alternativa consumidora de mais bits. Mas, além disso, também é muito versátil nas aplicações de processamento, como, por exemplo, ajuste para renderização em diferentes displays. Devido à por meio do nosso método termos de uma maneira fácil a semântica HDR definida da cena, que são necessários para ajuste de diferentes displays. E a regra de ligação pode ser dinâmica, por exemplo, pode ser um número de regras armazenadas. Por exemplo, o mapeamento = 5 pode ser ainda preenchido por diferentes mapeamentos dependendo, por exemplo, de qual representação de cor da imagem HDR de saída será o resultado que é mapeado (por exemplo, Y_16b versus Y_10b), ou para qual display será (por exemplo, display HDR de 5000 nit, ou um display HDR de 50000 nit, ou um display HDR de 1500 nit), etc.

[095] E o técnico no assunto entenderá que esta codificação pode ser incorporada de diversas maneiras, por exemplo, por meio de regras diferentes, por exemplo, mudando na inicialização a regra de ligação do “objeto = 3 ^ usar mapeamento = 5”, em “objeto = 3 ^ usar mapeamento = 7”, ou tendo o modulo de segmentação produzindo diferentes códigos de segmento dependendo das particularidades da imagem HDR de saída, ou o mapeamento pode ser mudado dinamicamente, por exemplo, se referindo a outras particularidades (como um apontador variável para o início de diferentes algoritmos ou LUTs ou entradas nas listas de diferentes equações, etc. ). Isto permite também, por exemplo, o manuseamento do comando da interface do usuário fácil, tal como, por exemplo, uma modificação controlada pelo usuário da “aparência de brilho geral” da cena, que pode ser implementada por meio da realocação de diversas novas funções de mapeamento para diferentes objetos da cena, todos os objetos/regiões do valor cinza sendo modificadas na iluminação em um relacionamento de mapeamento particular (por exemplo, o janela de vidro embaçada pode ser amplamente não modificada, considerando que já é clara, talvez clareada um pouco mais comparada ao resto da imagem a fim de não perder muito da aparência HDR devido a proporção de luma com o resto da imagem, mas o interior da sala em volta pode ser clareado, considerando que é a parte da iluminação média que mais influencia a aparência de brilho da imagem; e vice versa ao escurecer o display, pois o usuário percebe-o como brilho desconfortável, por exemplo). Somente esta parte sobrescrita precisa então ser tratada de forma diferente, mas se é tão difícil e crítica, provavelmente precisará, de qualquer maneira, do processamento complexo da renderização. Então o criador de conteúdo tem uma opinião muito melhor sobre o que, por exemplo, está clareado e como está clareado, considerando que o clareamento não precisa ser um estabelecimento ou multiplicação simples, mas pode ser uma estratégia complexa equilibrando o brilho das sub-regiões (por exemplo, limitando uma porcentagem dos pixels para branco), o que é tipicamente inteligente em cenários do display restringido por gama, onde os algoritmos atuais podem levar aos artefatos.

[096] Outro uso muito útil dos limites de demarcação do segmento reservado é ilustrado no sistema doméstico do lado de recebimento da Fig. 6. Aqui, a televisão 602 recebe um sinal SB, por exemplo, de uma estação de televisão através de vias aéreas. O sinal compreende em metadados METB, e código(s) de especificação da configuração HDR SET_HDR, que pode ser co-transmitido de diversas maneiras (mas tipicamente como metadados no início de uma execução de imagens), e especifica como o display deve se comportar aqui. Um código SET_HDR interessante pode ser usado para comutar entre a renderização LDR e HDR, reserva, por exemplo, para economizar energia, pois atualmente transmitimos, por exemplo, um programa de notícias em estúdio, o que não precisa da quantidade máxima de efeitos cinemáticos HDR. Então, entre, por exemplo, o comercial e o filme antes dele e as notícias, um código SET_HDR de “render_LDR” pode ser transmitido (ou co-codificado em um programa de vídeo armazenado, por exemplo, em um gravador do disco rígido doméstico, ou servidor de armazenamento de vídeo em rede-internet), o que significa que a partir daí o display HDR irá renderizar um brilho branco máximo de, por exemplo somente 500 nit (apesar de ter uma capacidade de brilho máximo de 5000 nit). Agora, conforme as realizações da nossa invenção presentemente revelada, pode-se facilmente fazer isto estabelecendo o valor de cinza diferenciador da região gTR igual a 255, o que significa que todas aas lumas abaixo (isto é, todas as lumas possíveis na imagem de 8 bits) precisam ser tratadas com o mesmo mapeamento, que pode, por exemplo, ser um co-armazenado com a imagem, ou pré armazenado no mapeamento da gama do display que então renderiza tudo em no máximo 500 nit. Por exemplo, pode-se usar um valor gTS que demarca quais cinzas serão renderizados, talvez escurecidos, e acima deste todos os cinzas podem ser limitados a um branco escurecido relativamente escuro.

[097] Agora é importante entender que existem dois tipos de mapeamentos/transformações para aplicar às lumas (ou codificações relacionadas a iluminação similares).

[098] O primeiro são mapeamentos “relacionados ao hardware” matemáticos simples, que corrigem somente o ambiente e o display de visualização particular. Por exemplo, se uma imagem é codificada para uma gama 2.2 CRT (display de referência), mas mostrada em um LCD com uma função de transferência eletro-óptica sigmoidal, o próprio display pode usar a matemática colorimétrica elementar para corrigir isto, fazendo o LCD renderizar a imagem como ser fosse um CRT de referência. Similarmente, pode-se otimizar amplamente as características do ambiente de visualização com matemática simples. Primeiramente, é claro, ao escalonar uma renderização mais escura, precisa-se baixar o brilho de referência associado à codificação da imagem. Isto já é amplamente realizado pelo mapeamento do valor de código máximo (por exemplo, 255) para p brilho máximo do display de renderização. No entanto, também pode ser feito mais complexo, por exemplo, uma sub faixa particular de lumas da imagem seria alocada em uma faixa particular das luminâncias renderizadas do display. Mas tipicamente também uma correção da gama deve ser aplicada, considerando tais coisas como uma mudança no contraste dependendo da luminância da imagem renderizada e seu entorno. Isto dá resultados bastante aceitáveis se o conteúdo da informação da faixa de iluminação (isto é, a codificação da informação ao longo de diversas sub faixas de aparência) nos dois sistemas é relativamente similar, ainda é difícil quando as faixas da aparência são muito diferentes. Para ir a um alcance dinâmico muito mais estreito, deve-se decidir quais sub faixas ainda devem ser mostradas com qual qualidade, isto é, tipicamente com qual contraste entre os objetos e qual contraste dentro do objeto, e frequentemente, faixas de sobreposição são geradas pelo algoritmo de mapeamento. A outra maneira é ainda mais difícil. Se tivermos somente um par de faixas de objeto comprimidas, é difícil julgar onde colocá-las em uma faixa de aparência HDR de saída, deixando de lado os novos valores inventivos da aparência/luma. Torna-se ainda mais difícil gerar uma boa imagem HDR natural a partir de uma imagem mapeada LDR na qual as faixas de luma de 8 bits dos objetos dissimilares da luminância da cena foram inapropriadamente codificadas se sobrepondo (como ao simular uma iluminação muito uniforme, destruindo todas as informações ou informações suficientes da iluminação da cena original).

[099] Todas as outras transformações dos valores de cinza (ou em cores gerais) dos pixels do objeto podem ser vistas como transformações genéricas que pode se locais ao invés de globais, que são tipicamente feitas por um artista (ele pode ainda corrigir se a calibração matemática simples acima para um cenário de visualização diferente não é suficientemente preciso). O artista pode fazer gradações artísticas muito complexas, nas quais, por exemplo, mudam as diferentes lumas presentes nas nuvens na fotografia, para tornar uma aparência de tempestade mais ameaçadora. Ou podem ainda usar um efeito de renderização da computação gráfica, para ter feixes de raio de luz saindo do olho de um robô, conforme representado pelas lumas/cores de pixel desejadas. Para a nossa discussão, podemos exemplificar com dois cenários típicos. Ou todo o posicionamento importante na faixa da luminância dos valores de cinza do pixel do objeto (a gradação de cor) foi feito em uma imagem HDR mestra (IM_MSTR_HDR, vide a Fig. 4, que pode ser, por exemplo, uma imagem de 16 bits com uma gama particular de definição), e a imagem LDR (Im_1) é derivada unicamente por meio de transformações matemáticas simples naquele HDR mestre, como, por exemplo, uma função gama da qual o fator gama é ajustado com base em tais características como o histograma da imagem HDR, isto é, a conversão de HDR para LDR é meramente um deslocamento adequado simples dos valores de cinza (tipicamente sobre desvios não muito grandes), de forma que todas as informações sejam contidas relativamente precisamente, esteja em um estratégia de codificação diferentes. Neste caso, uma imagem HDR final a ser renderizada em um display HDR pode ser derivada a partir da imagem LDR aplicando esta estratégia de mapeamento matemático inverso. Ou, um graduador humano 520 pode derivar alternativamente a imagem LDR com base em outra gradação otimamente ajustada começando a gradação mestra conforme codificada na imagem HDR mestra IM_MSTR_HDR (isto é, ele começa, por exemplo, com a imagem [0,1.0] como se fosse LDR e começa livremente a transformá-la colorimetricamente para seja qual for os seus gostos). Isto é, neste cenário, existe ambas uma codificação da aparência ótima para os sistemas de renderização HDR na imagem HDR IM_MSTR_HDR, e outra aparência ótima para sistemas LDR, codificadas na imagem LDR graduado (por exemplo, vantajosamente 8 bits) Im_1. Apesar de os nossos métodos serem aplicáveis a qualquer transformação de luma ou cor para objetos entre uma primeira e segunda definição do espaço de cor para as cores do pixel, tipicamente de diversos brilhos máximos do display pretendido e/ou profundida de bit (a única coisa necessária é que existe um bom relacionamento de ordem entre as regiões mais claras e mais escuras em pelo menos uma das codificações da imagem/representações de cor), focaremos nossa exemplificação em um exemplo do segundo tipo. Isto é, O graduador pode ter especificado muitos mapeamentos de cor ajustados, isto é, de luma_in geral para o formato funcional de luma_out (por exemplo, como um LUT) para diversos sub-objetos ou regiões da(s) imagem(s) que na nossa estratégia serão convertidos e uma série de (um ou mais) valores de cinza diferenciadores da região (gTS), um número de funções ou algoritmos de transformação, e tipicamente também uma ou mais regras de ligação, ligando segmentos obteníveis com as transformações a serem aplicadas (por exemplo, se existirem três valores de cinza diferenciadores da região sucessivos, os objetos abaixo do primeiro gTS1 podem ser segmentados como ‘0”, acima de gTS1 como “1”, e então se o segundo gTS2 é um valor mais alto aplicável ao mesmo conjunto de objetos (isto é, a mesma faixa de luma), acima daquele gTS serão segmentos “2”, mas abaixo das lumas já pertencem a “1”. Se o gTS2 é somente uma redefinição dos objetos mais escuros e mais claros, como nosso exemplo de objeto muito escuro, o acima das lumas limites serão, em ambos os casos, planos de fundo do segmento “1”, mas tipicamente podem existir alguns outros metadados explicando o significado dos valores de cinza diferenciadores da região. Por exemplo, pode ser simplesmente suficiente definir o tipo de valores de cinza diferenciadores da região como “further_demarcation_in_same_luma_range”, ou “modified_demarcation”, etc. Mas para os casos mais complexos, e na verdade devido a não muitos dados adicionais serem necessários, um codificador pode escolher fazer isto sempre assim, pode-se somente co-codificar o que foi feito para cada situação, com, por exemplo, as regras de alocação do valor do segmento. Por exemplo, “se a luma < gTS1 ^ objeto/segmento = 0”, se “luma > gTS2 ^ segmento = 2”, etc. Desta maneira, garante-se qualquer possível interpretação incorreta resultante e má interpretação.

[0100] A Fig. 3 elucida um possível exemplo vantajoso de como codificar as realizações acima, encaixando- os na estrutura de trabalho das atuais tecnologias de codificação da imagem, tal como, por exemplo, uma codificação de vídeo MPEG padrão como AVC ou similar.

[0101] Pode-se começar colocando alguns dos metadados em um cabeçalho global Gen_Im_HDR (por fotografia, ou para a primeira fotografia de uma sessão de fotografias, por exemplo), que é tipicamente útil para as transformações predominantes. Por exemplo, para gravações simples, pode ser suficiente codificar aqui um primeiro mapeamento Glob_TM1 a ser aplicado a maioria das fotografias, e um segundo mapeamento global Glob_TM2 a ser aplicado a algumas regiões muito mais claras, por exemplo. O primeiro mapeamento poderia ser aplicado a nossa sala da Fig. 1 (isto é, tudo sendo o plano de fundo, escadaria, e objeto muito escuro), e então o segundo mapeamento poderia ser aplicado para clarear/impulsionar a janela de vidro embaçada. E a diferença entre estes dois objetos é rapidamente encontrada no lado de recebimento por meio do valor de cinza diferenciador da região codificada gTS_glob (tipicamente esta janela terá lumas (muito) mais altas na imagem LDR Y-8b que o resto do objeto, mas sem estes metadados, isto pode ser muito difícil de determinar automaticamente). Se a câmera é girada na sala, pode, por exemplo, ser que a janela de vidro embaçada comece a se tornar mais clara devido a mais luz do sol atravessá-la. Isto pode ser codificado variando gradualmente Glob_TM2 e possivelmente gTS_glob para imagens sucessivas na filmagem. Isto permite, por exemplo, que mantenha-se a codificação da janela de vidro embaçada na imagem Y_8b a mesma ao longo das sucessivas imagens (por exemplo, usando a melhor alocação de código possível para reter a quantidade máxima de detalhe nas pinturas do vidro embaçado), pois pode-se impulsionar o brilho da janela por meio do mapeamento variante Glob_TM2 (isto é, as mudanças de iluminação estão na transformação funcional ao invés de na codificação da cor da textura pixelada). Então um número de blocos de dados de pixel é codificado, por exemplo, por meio de um DCT. Se a codificação global é suficiente para toda a imagem, então todos os dados do pixel seguem aquele cabeçalho global, até o final da filmagem, ou mesmo o clipe do filme. No entanto, supomos neste exemplo que temos o cenário mais complexo onde em algum lugar na imagem, começando antes de u bloco particular (i- 1,j-2), temos que começar a fazer as transformações locais. Isto é, tipicamente poderíamos usar alguma do conhecimento de transformação global como já codificado em Glob_TM1 etc., por exemplo, para transformar os pixels do plano de fundo do papel de parede, mas temos que fazer para pelo menos um novo objeto local uma nova transformação. Isto é, algumas da estratégia de transformação serão redefinidas localmente, por exemplo, sobrescritas. Neste exemplo, os metadados locais Loc_MET_1 contém uma nova estratégia para demarcar as partes mais claras acima de gTS_L_loc_1, por exemplo, devido a existirem objetos ainda mais claros ali, como uma luz. Também um valor de cinza diferenciador da região para determinar um ou mais objetos escuros gTS_D_loc_1 é co-codificado. No exemplo, o objeto de luz pode ainda ser suficientemente transformado com a transformação aplicável e atualmente disponível para as regiões mais claras, mas um novo mapeamento Loc_TM_DK é codificado para transformar os objetos escuros (por exemplo, aqui para a primeira vez que a escadaria ocorreu, e já sabíamos como transformar a janela e o papel de parede, mas não ainda não os degraus escuros). Um exemplo de uma regra de ligação da transformação LnkRL_1 também é codificada, cujas regras estabelecem que as lumas abaixo do valor de cinza diferenciador da região do objeto escuro gTS_D_loc_1 devem ser mapeadas com a transformação para a escadaria Loc_TM_DK.

[0102] Esta informação é novamente suficiente para um número de blocos sucessivos (ou em geral um formato definido geral), contendo plano de fundo, ou degraus, até terminamos perante o bloco (i+2,j), onde temos que codificar o valor de cinza diferenciador da região gTS_D_loc_2 permitindo a segmentação do objeto muito escuro, e sua estratégia de mapeamento Loc_TM_DK_2. DAT_TM dá uma ordem dos dados, tal como, por exemplo, ordem espacial (ou temporal na transmissão) dos blocos ao longo de uma via de escaneamento, como é bem conhecido a partir da codificação da imagem.

[0103] Apesar de termos somente descrito um exemplo intercalado, também pretendemos cobrir sistemas nos quais os metadados estão fisicamente destacados dos dados do bloco de pixel, também associáveis às posições particulares do bloco. Apesar de algumas estruturas de codificação do vídeo poderem perfeitamente englobar o exemplo acima (devido a eles já terem sido usados dedicados ou genéricos a vontade, os espaços reservados na memórias dos metadados no lugar, outras estruturas de codificação do vídeo não deve ter memória de metadados para armazenar tudo, ou perder a compatibilidade com versões anteriores se alguns dados são escritos intercalados. Portanto, outras realizações equivalentes poderiam codificar todos os metadados (gTS etc.) em uma parte separada do sinal (por exemplo, no início de um filme em um disco, ou nos intervalos regulares durante a transmissão, etc.), e então tornas estes dados associáveis por meio de um código de associação geométrica com blocos particulares ou outras regiões. A maneira mais simples de fazer isto é escrever o número do bloco (e potencialmente também o número da imagem, número do conteúdo/filme, etc.) após os dados, por exemplo, como: “gTS1 - 230 / ImageNr/TimeCode = 2541, Block_loc = (X=20, Y=12)”. Esta parte de metadados separada pode ainda, por exemplo, residir em um sinal diferente, e ser fornecida através de um meio diferente, por exemplo, o filme é colocado em um blu-ray no tocador, mas os metadados “explicando” como o valor(es) de cinza diferenciador da região é recuperado de um armazenamento em rede (por exemplo, um serviço dedicado permitindo a renderização HDR melhorada) através da internet, por exemplo.

[0104] A Fig. 4 mostra como uma segmentação tipicamente parecerá, na qual o exemplo que também explicamos como, por exemplo, a janela de vidro embaçada pode ser subdividida em sub regiões, o que seria útil, por exemplo, se a parte inferior é menos iluminada brilhantemente, por exemplo, devido às partes de fora bloquearem parte da luz. Neste caso, um novo tipo de segmento SEGM_TYP_2 resultará, por exemplo, segmento = “5”. Entendemos agora como as regras de segmentação por meio da comparação simples com os valores de cinza diferenciadores da região determinados otimamente podem facilmente gerar objetos de iluminação diferente (tipicamente a iluminação diferente na cena HDR) que pode precisamente ser segmentado, independente do seu relacionamento com os blocos. Assim, pode-se codificar todos os outros dados úteis, tal como mapeamentos a serem usados atualmente, em uma base de bloco, enquanto os resultados ainda são aplicados à precisão do objeto, isto é, sem nenhuma formação de halo ou artefatos de bloco, etc.

[0105] Queremos falar um pouco mais sobre os valores gTS. Já mencionamos que eles podem ser definidos independentes de qual codificação técnica da luma está sendo usado, por exemplo, pode-se usar valores gtS da luma em um espaço de cor YCrCb da gama 2.2, ou valores diferenciadores Y da luminância em uma codificação XYZ das cores da imagem, etc. Permanece a questão interessante se os valores gTS são definidos no espaço de cor de referência da primeira ou da segunda imagem, por exemplo, a imagem inicial ou final. Se usar uma representação LDR mapeada para codificar um grau mestre HDR, poder-se-ia recuperar esta imagem HDR por meio do mapeamento de aumento da resolução da luminância a partir desta imagem. Então, faria sentido definir os valores gTS ao longo do eixo da luma de codificação da imagem LDR, apesar de em princípio nas situações comuns, poder-se-ia também especificá-los ao longo do eixo da luma HDR, considerando que por meio do inverso das funções de mapeamento de recuperação HDR estes valores gTS com base em HDR poderiam ser convertidos em valores gTS com base em LDR equivalentes. Tipicamente, os metadados no começo do vídeo especificarão a codificação cuja definição é aplicável. Agora, vamos mergulhar um pouco mais fundo no que pode em alguns cenários acontecer para os valores gTS com base em LDR. Em princípio, poder-se-ia ter um mapeamento a partir da imagem HDR mestre para a segunda imagem LDR que sobrepõe (levemente) os histogramas da luma das regiões que na imagem HDR original estavam separados (por exemplo, algumas das partes mais escuras dos degraus pode obter lumas no LDR que também ocorrem no objeto muito escuro). Poderíamos então especificar o diferenciador gTS na metade das caudas do histograma de sobreposição, ou em uma posição da luma melhor. Apesar de em princípio, poder existir questões ao aumentar a resolução, isto não precisa ser um problema para diversas estratégias de mapeamento, em particular, se elas já têm um comportamento relativamente suave em torno da sobreposição (isto é, não aumenta o contraste entre os pixels). No entanto, nos limitaremos aqui aos sistemas que normalmente devem ter sistemas separados em ambas as imagens LDR e HDR. As diversas realizações de aparelho podem ser restritas para considerar este contraste, por exemplo, limitando a escolha do mapeamento HDR para LDR que um graduador pode escolher, etc. Isto será fácil para codificações não comprimidas (por meio das quais significamos a compressão espacial psicovisual como técnicas de frequência como a DCT, e não compressão da sub faixa da luma). Para as codificações comprimidas, devemos ser um pouco mais cuidadosos com as questões como, por exemplo, as estruturas de tabuleiro de xadrez da codificação DCT incompleta. Apesar tal necessidade não ser sempre um problema na prática, algumas vezes o artefato pode se tornar mais grave visualmente, por exemplo, parecendo uma área mais ruidosa. Em particular, isto pode acontecer se no LDR descomprimido original os histogramas dos degraus e do plano de fundo estiverem separados (talvez tocando, ou com alguns códigos não utilizados entre eles), mas após a decomposição com base em DCT, os sinais recuperados teriam alguns pontos do tabuleiro de xadrez mais escuros a partir da entorno mais claro que cairiam na sub faixa alocada para os degraus mais escuros. Se também tiver uma curva do mapeamento de tom que se alonga seriamente ao longo daquele valor gTS entre os degraus e o plano de fundo (por exemplo, uma função descontínua com uma grande compensação entre os dias partes de mapeamento do tom) então poderia ser que estes pontos se tornassem significativamente mais escuros no plano de fundo pelo menos próximo aos degraus. Diversas realizações de aparelho (ou método) podem lidar com tais diversas maneiras, e em particular uma interface do usuário pode oferecer ao graduador diferentes maneiras de interagir e especificar este comportamento da codificação. Primeiramente, ele pode tornar a curva de mapeamento de tom menos íngreme, e o aparelho pode ou inicialmente oferecer a ele uma escolha de somente mapeamentos menos íngremes, ou pode iterativamente (pelo menos uma iteração) corrigir isto, oferecendo o graduador para especificar novamente os mapeamentos somente para as regiões onde julga o artefato como muito grave. Também, o mapeamento pode ser tal que existem alguns códigos extras. Em particular, pode-se facilmente definir tal comportamento com dois valores gTS. A Fig. 7 ilustra esquematicamente tal cenário. Neste gráfico, a Luma_in será as lumas da imagem HDR, e a luma_out da codificação LDR correspondente deste, o que enviaremos através de um codificador MPEG legado, por exemplo. Na imagem HDR, as regiões claras são de lumas/luminâncias bastante separadas das regiões escuras, que mostra sua separação ao longo do eixo luma_in. Na teoria, poderíamos projetar um mapeamento que os faria tocar ao longo do eixo Luma_out (LDR), mas agora projetamos um mapeamento que deixa alguma faixa ProtRng de códigos vazios entre eles. Estes códigos não deveria existir na codificação LDR, mas após a descompressão DCT, algumas das partes mais escuras dos tabuleiros de xadrez podem cair nesta ProtRng. O decodificador, no entanto, pode reconhecer isto, e removê-los do sinal, por exemplo, limitando-os ao valor de Luma_out mais baixo da faixa clara, antes de fazer o aumento da resolução da luminância para recuperar a imagem HDR. Com este princípio, poderíamos ainda reduzir esta faixa protetora ProtRng, ainda em tal extensão que alguns códigos após a descompressão DCT poder cair na faixa escura da imagem LDR e ser mapeada potencialmente longe da faixa clara na imagem HDR) pelo inverso do mapeamento escuro MapDrk ao invés do mapeamento correto para estes pixels, a saber, o mapeamento claro MpBrght. Mas tais artefatos DCT normalmente têm uma estrutura que passa por alguns dos valores intermediários para os pontos mais escuros no tabuleiro de xadrez. Então, o codificador pode, por exemplo, detectar alguns destes valores incorretos no bloco, detectar que pode haver um problema potencial e mudar após a descompressão DCT, mas antes de aumentar a resolução da luminância, tais valores na faixa clara da imagem LDR, mesmo se estes pixels, na verdade, pixels do objeto escuro, somente para estar no lado seguro (um efeito HDR levemente incorreto, mas também nenhum potencial artefato forte). O codificador pode usar um código reservado para esta “limitação à faixa” (0 ou 1), para indicar se isto deveria acontecer a um bloco, ou se deveria ser deixado de lado e somente aumentar a resolução, e o graduador pode indicar os blocos problemáticos, por exemplo, clicando neles com seu mouse ou rabiscando através de conjunto conectado de blocos problemáticos. Apesar de o decodificador não poder saber a diferença, o codificador pode ter o sinal original e todas as informações determinar se tal problema pode acontecer, assim pode haver um modo de pseudocor com o qual o graduador pode alternar entre os pixels incorretos mostrado, por exemplo, como vermelho saturado claro versus sua cor real após a reconstrução (incorreta) da imagem HDR. Diversas outras opções (interativas) também estão disponíveis, por exemplo, o codificador usa mais palavras de código DCT para blocos que foram selecionados como problemáticos pelo graduador, ou da mesma maneira menos blocos DCT, de forma que ainda exista um erro de frequência inferior, mas os padrões xadrezes rápidos são removidos em caso de estes darem uma aparência final melhor. Ou, por exemplo, uma pequena mudança para os dados originais ou coeficientes DCT podem ser feitos, por exemplo, um contra padrão pode ser aplicado aos blocos LDR antes de ser codificado por DCT, de forma que os valores do tabuleiro de xadrez mais baixos não caiam mais na faixa LDR escura.

[0106] A Fig. 5 mostra um exemplo de um possível aparelho de gradação 510 em um lado de criação de conteúdo, controlado por um graduador 520 (o técnico no assunto entenderá como as mesmas realizações da nossa invenção se aplicariam, por exemplo, em um aparelho de transcodificação automática com base na colorimetria matemática ou qualquer outra realização).

[0107] Dentro do aparelho de gradação 510 está um codificador de imagem 549 para codificar uma imagem de uma cena de alto alcance dinâmico, cuja imagem pode ter sido capturada anteriormente, por exemplo, por um filme de celuloide ou sistema de câmera digital eletrônica, ao qual os efeitos especiais podem ter sido adicionados, e que no caso do vídeo pode ser uma imagem em uma sequência da composição temporal final. O codificador de imagem (que, agora para a simplicidade, presumimos ser uma unidade com um IC, mas pode ser um conjunto de software, onde alguns componentes podem ainda executar em um servidor remoto, etc.) pode compreender tipicamente diversos sub componentes (tipicamente sob controle do software, permitindo que o graduador escolha parâmetros), e tipicamente compreenderá alguma variante de uma unidade de codificação da textura do pixel 552, que é disposto para codificar as cores dos pixels da imagem de acordo com uma representação da imagem definida particular (Im_1), por exemplo, com lumas de palavras de código de N bits, como, por exemplo, palavras de código de 8 bits ou 10 bits ou 12 bits e codificações da crominância como Y_Cr e Y_Cb. Considerando que diversas variantes de codificação já existem, variando em codificações do tipo VC1, VP8 e MPEG similares, até codificadores fractais ainda menos populares, não precisaremos elucidar este aspecto.

[0108] No entanto, também é compreendida uma unidade de análise da imagem 550 que pode aplicar análise de imagem mais complexa ou mais simples. Em tais aparelhos de gradação profissionais, conforme mostrados no exemplo, tipicamente muitos dos algoritmos incorporados de software estão disponíveis, dando ao graduador quase o controle total sobre a imagem, ambos ao querer estudar suas propriedades e composição, e ao querer mudá-los arbitrariamente. Ele pode, por exemplo, usar uma pipeta para amostrar uma cor particular (e pode então definir a partir desta cor de pixel amostrada uma “cor de objeto” típica, por exemplo, escolhendo os limites colorimétricos apropriados em torno da cor amostrada), ou olhar as formas de onda do sinal, ou histogramas, ou outras representações das regiões (por exemplo, o sistema pode mapear as sub faixas da luma no topo de uma região, por exemplo, por meio de pseudocores). Ele pode, por exemplo, clarear (temporariamente) uma região particular para inspecionar visualmente mais claramente sua textura em um ou mais displays de referência 530. Ele pode tipicamente aplicar um número de processamentos de imagem, como apontando uma região, ou aplicando um efeito de iluminação ou outro efeito. Ele pode demarcar um objeto desenhando um limite em torno dele com um laço, etc.

[0109] Agora, tipicamente a unidade de análise da imagem pelo menos converterá um objeto em um valor de cinza diferenciador da região (gTS), ou em outras palavras, associar a um objeto pelo menos um gTS relacionado determinado. A unidade pode, por exemplo, determinar o histograma da região do objeto selecionado, e determinar que o valor mínimo da luma que ela contém é superior a aquele da região em volta, por exemplo, toda a imagem. O manuseio interativo pode ser envolvido, por exemplo, o graduador pode primeiro clarear a região, de forma que agora seu novo valor mínimo seja mais lato que o valor mais alto no resto da imagem, ou uma parte relevante deste geometricamente relacionada ao objeto (por exemplo, limitando o objeto).

[0110] Este valor de cinza diferenciador da região gTS será gerado para um formatador 554 que pode (novamente seguindo as regras de algum padrão de codificação de imagem, legado ou novo) co-codificar em um sinal de imagem de saída (S(Im_1, MET(gTS)) a representação da imagem (Im_1) e o valor de cinza diferenciador da região (gTS), o último tipicamente em um formato de metadados textuais pré acordados. Por exemplo, este sinal de imagem pode ser gravado em um disco blu-ray 511, ou salvo em alguma outra memória como um disco do servidor de rede ou memória de estado sólido, ou transmitir o sinal de imagem em tempo real de uma conexão da transmissão do sinal, etc. Deve ficar claro para o técnico no assunto que apesar de termos descrito esta funcionalidade na presente construção física, outras realizações são possíveis.

[0111] Tipicamente ao graduar no aparelho de gradação, o graduador usará simultaneamente sua unidade de determinação do mapeamento da luma 553 para determinar um mapeamento da luma (TOM) para pelo menos alguns dos objetos (os outros objetos então, obviamente, também tendo uma transformação, talvez uma transformação da identidade, mas esta transformação pode ser, por exemplo, padrão como predefinida, ou escolhida pelo display de renderização, etc.). Ele definirá um mapeamento entre as lumas do pixel conforme codificadas em uma primeira representação de imagem (por exemplo, uma imagem Y_16b HDR de entrada), e lumas dos pixels em uma segunda representação de imagem (por exemplo, uma imagem LDR Im_1), ou ao contrário. A unidade de determinação do mapeamento da luma 553 pode determinar matematicamente uma função de mapeamento por si só, por exemplo, propondo-a como uma sugestão inicial ao graduador, olhando nas diversas propriedades visuais da região, por exemplo, da imagem HDR, e como elas pode ainda serem razoavelmente representadas em uma codificação LDR. Isto pode resultar na aplicação, por exemplo, de um mapeamento de multissegmentos ou sigmoidal, com as curvaturas dos joelhos e ombros, por exemplo, determinadas por meio do isolamento particular dos sub ressaltos do histograma global, ou entendimento da imagem, tal como a detecção da face, ou qualquer variante desta. O graduador pode então ajustar esta função, por exemplo, deslocando ou dobrando o ombro do sigmoide. No nosso método, pode-se fazer isto em relação aos valores gTS. Por exemplo, o aparelho de gradação pode já definir um valor de cinza importante (por exemplo, 999) que pode ser um ponto de controle, por exemplo, para uma parte de uma curva de mapeamento de multissegmentos, mas o graduador pode então melhorar este ponto, por exemplo, deslocá-lo de forma que uma parte mais relevante de um objeto, por exemplo, como os degraus é agora transformada por um mapeamento da luma (tom) parcial. Ilustramos alguns conceitos ainda com o exemplo da Fig. 8. Conforme já mencionado, podemos usar nosso método em um mero método de codificação, por exemplo, no qual uma imagem HDR deve ser codificada através de uma imagem LDR utilizável legada codificada (suporte LDR). Nesta situação, haverá tipicamente somente algumas funções fixas para mapeamento entre as duas imagens. Com a Fig. 8 descrevemos, no entanto, como nosso sistema pode com os valores gTS ser usado em outro cenário da capacidade de ajuste do display, em que outros graus são determinados para diferentes displays, se estas informações já foram todas graduadas (isto é, o graduador pelo menos verificou como tais transformações apareceriam em alguns displays de referência muito diferentes como o LDR, sbLDR com um pequeno alcance dinâmico) e codificou no sinal da imagem tipicamente como diversas funções a serem aplicadas em uma ou mais imagens da textura (Im_1), ou se havia somente dados codificados para um grau HDR bonito e talvez um bom grau LDR, e no lado da renderização um sistema de display (por exemplo, display ou computador) está determinando com base nestes dados nossos valores gTS pelo menos um outro grau para, por exemplo, um display MDR de alcance dinâmico médio. Neste gráfico, usamos uma representação da luminância final que é absoluta. Luminance_in pode ser o sinal de entrada conforme definido como pareceria, por exemplo, em algum display de referência, e luminance_out pode ser as luminâncias renderizadas de saída em diversos displays reais com capacidades de brilho diferenciadas. Supomos que os objetos de luminância mais baixa são amplamente codificados corretamente e portanto, renderizados, então ambos os displays (Dis1, Dis2) usarão o mesmo mapeamento de tom TM_FDrk, que pode ser uma transformação da identidade, ou algum alongamento do contraste. Agora, acima de gTSh1 começam as regiões claras na imagem e existem duas regiões claras (por exemplo, iluminadas pelo sol até gTSh2, e iluminada pela forte iluminação do estádio de futebol acima de gTSh2). O display 1 pode ter um brilho máximo muito alto, então temos muitas das salas para alocar as sub faixas de brilho dele para diversas classes de iluminação visual. O primeiro mapeamento do tom de processamento do brilho TM_TBri1_Dis1 pode, para este display claro, alongar consideravelmente os dados originais, de forma que a região pareça agradavelmente clara e contrastante. Um segundo mapeamento do tom de processamento do brilho TM_TBri2_Dis1 pode ainda compensar aquela região para luminâncias renderizadas muito altas, de forma que visualmente esta região seja muito diferente das partes iluminadas pelo sol, por exemplo, a iluminação do estádio, na verdade, parece muito desagradável. Esta discriminação pode facilmente ser feita com os valores gTS (por exemplo, no exemplo deste mapeamento linear eles podem ainda parametrizar a função do mapeamento). Para um display com brilho máximo menor, computador determinando, por exemplo, o mapeamento final pode fazer outra coisa para as diversas regiões determinadas pelos valores gTS. Por exemplo, ele pode processar os brilhos mais baixos com uma função de mapeamento menos contrastante TM_Bri1_Dis2, desta forma ainda existe algum espaço deixado para as regiões iluminadas pela luz do estádio, que necessita, no entanto, ser levemente limitada com a função TM_Bri1_Dis2.

[0112] Este mapeamento da luma (TOM) é finalmente co-codificado no sinal da imagem de saída (S(Im_1, MET(gTS), TOM) pelo formatador 554, de acordo com as especificações definindo o sinal da imagem acordada. Novamente, tal mapeamento em princípio, mapeia a partir do uso qualquer primeira especificação da codificação de cor determinando qualquer primeira imagem para qualquer primeiro display de referência (em particular, com qualquer alcance dinâmico da luminância de saída) para similarmente qualquer segunda codificação da imagem (em particular com brilho máximo superior ou inferior, alcance dinâmico menor ou maior, etc.), contanto que seja claramente especificado e acordado com o lado de recebimento.

[0113] Tipicamente, um codificador de imagem 549 que de acordo com os conceitos da realização é disposto para co-codificar de maneira inteligente o valor(es) de cinza diferenciador da região escolhido (gTS) é útil para demarcar as regiões de brilho médio das regiões de alto brilho, isto é, por exemplo, a parte do histograma da luma abaixo de certa porcentagem, e uma porcentagem de valores mais altos, especialmente quando separados por códigos inutilizados (ou uma definição similar com base nas luminâncias renderizadas). Isto é consequentemente muito útil para a codificação da cena HDR, em qualquer espaço de formato/cor a imagem finalmente será codificada em pelo menos uma versão (por exemplo, Y_8b ou Y_10b ou Y_16b, e outras definições como a luminância branca pretendida, preto, curva gama, etc.), considerando que estas cenas HDR tipicamente não têm luminâncias do objeto de cena similares, e consequentemente após as lumas de imagem de captura da câmera em vista da iluminação uniforme usada pelos designers de iluminação, como na produção LDR, mas preferencialmente têm regiões de iluminação muito diferentes. E os valores gTS podem caracterizar estes adequadamente.

[0114] Então basicamente o graduador aplica somente suas operações clássicas na imagem(s) como a seleção do objeto, definindo as curvas do mapeamento ótimo para diferentes partes (tipicamente sub faixas da luma) daquele objeto, etc., e o codificador 549 traduz isto em parâmetros das realizações desta invenção, tal como valores de cinza diferenciadores da região gTS.

[0115] Elucidamos a invenção na Fig. 5 com um sistema de produção do conteúdo de entretenimento doméstico, por exemplo, tendo acesso a um servidor de vídeo 580 através de uma conexão 581, que contém arquivos de vídeo, tal como a gradação HDR mestra IM_MSTR_HDR do dito algum filme ou programa de televisão, que foi produzido no momento de produzir o filme ou o programa, como sendo a última gradação de referência. Isto então será convertido para uma gradação de cinema doméstico para um lançamento da versão doméstica, sendo codificado, por exemplo, como uma imagem MPEG-AVC de 8 bits Im_1, e os metadados de acordo com qualquer uma das realizações apresentadas. É claro, o codificador pode também ser incorporado em outro sistema, aparelho ou cenário de uso, por exemplo, para determinar um ou mais graus principais diretamente de um sinal de câmera bruto da câmera 501 cobre a conexão (por exemplo, sem fio) da imagem/vídeo 505, ou para remasterização, etc.

[0116] A Fig. 6 mostra uma possível realização de um sistema lateral de recebimento, a saber, um sistema de renderização da imagem ou vídeo do consumidor doméstico. Uma televisão 602 pode receber diretamente um primeiro sinal de vídeo (ou imagem) SB(Im_1, MET) através, por exemplo, das vias aéreas. Esta alimentação do vídeo exemplar já foi explicada acima, e usa os valores de cinza diferenciadores da região entre as execuções das imagens (tipicamente indo de um conteúdo para outro, ou partes de um programa como reportagens em um programa de notícias que ou seriam renderizados cinematicamente, com alto brilho e precisão HDR (isto é, também conforme a alocação precisa no eixo da luminância de saída de diversos objetos determinando a aparência da imagem), ou deve ser executado (quase LDR) com brilho reduzido (e energia). Pode haver também um aparelho de processamento de vídeo 601 (como, por exemplo, um conversor ou PC), que pode obter seu vídeo através de uma ou mais conexões à internet (I_net). Por exemplo, um servidor do youtube ou similar pode fornecer um sinal HDRm que preferencialmente é ambos simplesmente codificado e utilizável de uma maneira versátil para diversos displays de renderização possíveis diferentes (o então chamado critério de “capacidade de ajuste de display”). Por exemplo, além de uma codificação Y_8b da Im_1 do sinal HDR, conterá um ou mais dos metadados da realização acima, e, por exemplo, também um indicador de processamento PROC_IND, que especifica como esta imagem Im_1 pode ser processada, por exemplo, para obter uma versão da imagem HDR. Por exemplo, pode especificar que o lado de recebimento pode usar diversas estratégias de transformação da cor/luma, por exemplo, com um indicador como “receiver_determines_optimal_mapping”. Neste caso o aparelho de recebimento como o conversor ou TV pode se determinar para aplicar um primeiro mapeamento, por exemplo, tem as luzes acesas na sua sala de visualização, e um segundo mapeamento se as luzes forem apagadas. Na verdade, o processamento permitido pode ser especificado em termos das tolerâncias ou mudanças percentuais, por exemplo, um aparelho lateral de renderização pode ser permitido a aplicar uma função gama até 1.2, mas não mais forte para um grau, por exemplo, se o display tem um brilho máximo dentro de uma faixa daquela dos display de referência (por exemplo, o grau pode ser determinado para um display de referência de 700 nit, e permitiu ser levemente modificável se o display real está dentro de uma faixa de 50% deste, isto é, com um brilho máximo entre 350 e 1050 nit). O indicador de processamento pode também especificar que somente um ou um de um par de transformações determinadas especificamente pode ser usada, etc. O indicador pode ter uma definição variável, que pode se tornar complexa, por exemplo, pode compreender diretrizes para o controle da interface do usuário, orientando o espectador através de seleções para ter uma aparência ótima do filme (dando a ele algumas opções de otimização aprovadas pelo criador, como algumas das maneiras para melhorar os escuros, tornando-os maus coloridos, mas de alguma maneira diminuindo o humor da imagem), conforme desejado pelo criador do conteúdo (calibração manual com sub conjuntos selecionado de imagem, por exemplo), etc. Normalmente, existirão cenários reservas, já que o espectador tem o controle final, então estas diretrizes podem ser ignoradas ou anuladas, mas as presentes realizações permitem um alto grau de versatilidade, como, por exemplo, um mais próximo pelo criador do conteúdo de como seu conteúdo deve renderizado no ambiente de renderização final (se display doméstico, cinema, ao ar livre, profissional, por exemplo, em um estádio de futebol, etc.).

[0117] O decodificador de imagem 605 pode tipicamente compreender diversas das unidades a seguir. Uma unidade de decodificação da textura do pixel 608 precisa ser disposta de forma que possa realizar qualquer matemática necessária para decodificar os sinais da imagem recebida, que pode ser codificado de acordo com muitos padrões, então, por exemplo, o software pode ser executado, o que pode ser melhorado se um novo codificador de ondulação leve for lançado. É claro, haverá o desagrupamento do sinal e talvez a demodulação etc. (o que tipicamente será feito por um desformatador 607, com “a extração e potencialmente a decodificação também os metadados como o valor(es) de cinza diferenciador da região) mas a unidade de decodificação da textura do pixel 608 será capaz de fazer tais coisas como, por exemplo, a decodificação aritmética, decodificação DCT inversa, etc., como todos os componentes nos padrões visuais MPEG, e similares. Uma unidade de segmentação da imagem 606 fará a segmentação, e conforme dito, isto pode ser feito facilmente por meio da limitação dos valores gTS, mas estratégias de segmentação mais complicadas também podem ser suportadas. Então, uma unidade de transformação da cor do pixel 609 realizará o mapeamento de pelo menos as lumas do pixel, que pode tão simples quanto a gravação, por exemplo, do valor de saída da função PD_BLCK(i+2,j) pertencente ao valor da luma do pixel daquele pixel da Im_1 particular como valor de entrada (Luma_in). Este valor de saída será escrito na imagem de saída HDR IM_RC_HDR naquele local do pixel. Esta imagem pode ser aquela enviada através de uma conexão 688 para a TV (por exemplo, para condução direta ou outro processamento por meio de uma unidade de processamento da imagem 620 na TV ou no display geral, que também é capaz de fazer as transformações da cor).

[0118] Pode haver uma imagem intermediária IM_INTRM envolvida, e apesar de esta poder ser qualquer representação de referência, atualmente supomos para explicação simples, é uma imagem de luma de 8 bits (com também palavras de 8 bits para duas representações do canal de cor). Se a representação da imagem de entrada Im_1 não estiver comprimida (por exemplo, DCT), então isto pode ser uma cópia simples da Im_1, e de outra maneira é tipicamente a imagem resultante da descompressão.

[0119] O sistema também mostra a distribuição do vídeo em rede doméstica através de um meio de ligação da comunicação em rede, como a antena 699 para um display portátil 630 (por exemplo, um IPAD que o espectador usa para continuar a assistir TV na sua cama no seu quarto). Isto ilustra agradavelmente a versatilidade das realizações, considerando que o aparelho 601 pode então pré condicionar outro sinal de imagem IM_RC_MDR otimamente para este dispositivo, que pode, por exemplo, tem um alcance dinâmico médio, entre LDR (que podemos definir que termina aproximadamente acima do brilho máximo de 7 50 nit) e HDR de alta qualidade, que começa acima de 250 nit. A imagem MDR pode então ser codificada na IM_RC_MDR usando ainda a mesma Im_1 para as texturas do pixel, e o mesmo valor(es) de cinza diferenciador da região, mas funções de mapeamento modificadas para mapear a faixa diferente das luminâncias de saída renderizada do display.

[0120] As presentes realizações também permitem a interatividade da interface do usuário melhorada no lado de renderização, considerando que o espectador pode, por exemplo, ajustar suas funções de mapeamento parametricamente. Por exemplo, clarear o objeto muito escuro pode ser tão simples quanto controlar a inclinação da função PD_BLCK(i+2,j). Algoritmos inteligentes podem aplicar modificações coordenadas da luma a todos os objetos na imagem(s) em sincronia estética no toque de um único botão (por exemplo, habilitando uma função inteligente de brilho), mas também é possível habilitar o controle de diversos objetos oferecendo uma interface de usuário mais complexa. Por exemplo, ao assistir TV, o usuário pode usar seu display portátil 630 como um controle remoto, e ter uma cópia da imagem da TV no display daquele controle remoto, com os diversos objetos significantes já pré selecionados com os métodos do valor de cinza diferenciador da região. O espectador pode então rapidamente com (por exemplo, alguns controles deslizantes saltando do topo dos objetos) um par de mudanças indicar sua renderização preferencial em um ou mais pares de imagem (por exemplo, no começo do filme, algumas cenas características importantes, ou sob um comando de pausa, a imagem atual para aquela cena a ser exibida). Um botão de desfazer pode recuperar a situação, etc. A inteligência artificial pode ser usada para deduzir as preferências dos espectadores a partir das suas ações, mesmo por meio do armazenamento das especificidades para programas não relacionados em momentos de reprodução muito diferentes, como em dias diferentes. O sistema pode consequentemente concluir que o espectador gosta dos seus pretos em breu, ou reciprocamente clareados, e então aplica este conhecimento a outras imagens.

[0121] Os componentes algorítmicos revelados neste texto podem (inteiramente ou parcialmente) serem realizador na prática como hardware (por exemplo, partes de uma aplicação específica IC) ou como software sendo executado em um processador de sinal digital especial ou um processador genérico, etc. Os componentes podem ser semiautomáticos em um sentido que pelo menos alguma entrada do usuário pode estar/ter estado (por exemplo, na fábrica, ou entrada do consumidor ou outra entrada humana) presente.

[0122] Deve ser compreensível para o técnico no assunto a partir da nossa apresentação quais componentes podem ser melhores ótimas e podem ser realizadas em combinação com outros componentes, e como etapas (opcionais) dos métodos correspondem aos respectivos meios dos aparelhos e vice versa. O fato de que alguns componentes são revelados na invenção em um certo relacionamento (por exemplo, em uma única figura em uma certa configuração) não significa que outras configurações não sejam possíveis como realizações sob o mesmo pensamento inventivo conforme revelado para patentear aqui. Também, o fato de que por razões pragmáticas somente um espectro limitado de exemplos foi descrito, não significa que outras variantes não possam estar dentro do escopo das reivindicações. Na verdade, os componentes da invenção podem ser incorporados em diferentes variantes ao longo de qualquer cadeia de uso, por exemplo, todas as variantes de um lado da criação, como um codificador pode ser similar ou corresponder aos aparelhos correspondentes em um lado de consumo de um sistema decomposto, por exemplo, um decodificador e vice versa. Diversos componentes das realizações podem ser codificados como dados de sinal específicos em um sinal para transmissão, ou outro uso, tal como coordenação, em qualquer tecnologia de transmissão entre o codificador e o decodificador, etc. A palavra “aparelho” neste pedido de patente é usada no seu sentido mais amplo, a saber, um grupo de meios permitindo a realização de um objetivo particular, e pode consequentemente, por exemplo, ser (uma parte de) um IC, ou um utensílio dedicado (tal como, um utensílio com um display), ou parte de um sistema em rede, etc. “Arranjo” ou “sistema” também é destinado a ser usado no sentido mais amplo, assim pode compreender, entre outros, um único aparelho adquirível físico, uma parte de um aparelho, uma coleção de (partes do) aparelhos cooperando, etc.

[0123] A denotação produto de programa de computador deve ser entendida para englobar qualquer realização física de uma coleção de comandos permitindo um processador de propósito genérico ou especial, após uma série de etapas de carregamento (que pode incluir etapas de conversão intermediárias, tal como tradução para uma linguagem intermediária, e uma linguagem do processador final) para inserir os comandos no processador, para executar qualquer uma das funções características de uma invenção. Em particular, o produto de programa de computador pode ser realizado como dados em um transportador, tal como, por exemplo, um disco ou fita, dados presentes em uma memória, dados se deslocando através de uma conexão de rede - com fio ou sem fio - ou código de programa no papel. Além do código do programa, os dados característicos necessários para o programa também podem ser incorporados como um produto de programa de computador. Tais dados podem ser fornecidos (parcialmente) de qualquer maneira.

[0124] A invenção ou qualquer dado utilizável de acordo com qualquer filosofia das presentes realizações, como os dados de vídeo, também podem ser incorporados como sinais nos transportadores de dados, que podem ser memórias removíveis como discos ópticos, discos rígidos removíveis, dispositivos portáteis através de meios sem fio, etc.

[0125] Algumas das etapas necessárias para a operação de qualquer método apresentado podem já estar presentes na funcionalidade do processador ou quaisquer realizações do aparelho da invenção ao invés de descrever no produto de programa de computador ou qualquer unidade, aparelho ou método descrito aqui (com especificidades das realizações da invenção), tais como etapas de entrada e saída de dados, etapas de processamento tipicamente incorporadas bem conhecidas, tal coo a condução do display padrão. Também desejamos a proteção para os produtos resultantes e resultantes similares, como, por exemplo, os novos sinais específicos envolvidos em qualquer etapa dos métodos ou em qualquer sub parte dos aparelhos, bem como quaisquer novos usos de tais sinais, ou quaisquer métodos relacionados.

[0126] Deve ser percebido que as realizações mencionadas acima ilustram ao invés de limitar a invenção. Onde o técnico no assunto pode facilmente perceber um mapeamento dos exemplos apresentados para outras regiões das reivindicações, para concisão, não mencionamos todas estas opções profundamente. Além das combinações de elementos da invenção conforme combinados nas reivindicações, outras combinações dos elementos são possíveis. Qualquer combinação de elementos pode ser percebida em um único elemento dedicado.

[0127] Qualquer sinal de referência entre parênteses na reivindicação não é destinado a limitar a reivindicação, nem é nenhum símbolo particular nos desenhos. A palavra “compreendendo” não exclui a presença de elementos ou aspectos não listados em uma reivindicação. A palavra “um” ou “uma” antecedendo um elemento não excluir a presença de uma pluralidade de tais elementos.

Claims

1. CODIFICADOR DE IMAGEM (549) PARA CODIFICAR UMA IMAGEM (IM_MSTR_HDR) DE UMA CENA DE ALTO ALCANCE DINÂMICO, compreendendo: - uma unidade de codificação da textura do pixel (552) disposta para codificar as cores dos pixels da imagem com uma representação da imagem (Im_1) compreendendo N palavras de codificação do bit; - uma unidade de análise da imagem (550) disposta para determinar e gerar um valor de cinza diferenciador da região (gTS), que é um valor de luminância demarcando abaixo dele as luminâncias de todos os pixels de um primeiro objeto em pelo menos um bloco da imagem (IM_INTRM), e acima dele as luminâncias de todos os pixels de um segundo objeto em pelo menos um bloco da imagem; e - caracterizado pelo codificador de imagem compreender um formatador (554) disposto para co-codificar em um sinal de imagem de saída (S) a representação da imagem (Im_1) e o valor de cinza diferenciador da região (gTS), o codificador de imagem compreendendo adicionalmente uma unidade de determinação do mapeamento da luma (553) disposta para determinar um mapeamento da luma (TOM) para pelo menos um do primeiro e segundo objeto definindo um mapeamento entre as lumas dos pixels conforme codificada na representação da imagem (Im_1) e lumas dos pixels em uma segunda representação de imagem (IM_RC_HDR), em que uma das representações da imagem e a segunda representação da imagem é uma imagem de alto alcance dinâmica com um brilho de pico estabelecido fixo, e o outro é uma imagem de baixo alcance dinâmico, que são duas graduações de uma cena de alto alcance dinâmico criada por um graduador de cores automático ou humano, e a unidade de determinação de mapeamento luma sendo disposta para fornecer o mapeamento luma (TOM) para o formatador (554), formatador esse que está disposto para codificar o mapeamento luma (TOM) no sinal de imagem de saída (S).

2. CODIFICADOR DE IMAGEM (549), de acordo com a reivindicação 1, caracterizado por ser disposto para codificar diversos valores de cinza diferenciadores de região (gTS_D_Loc_1, gTS_D_Loc_2) entre seções compreendendo diversas das palavras de código de N bits codificando as cores do pixel a partir da representação da imagem (Im_1).

3. CODIFICADOR DE IMAGEM (549), de acordo com a reivindicação 1, caracterizado por ser disposto de modo a codificar um valor de cinza diferenciador da região antes de uma execução de diversas imagens sucessivas, sendo um valor de cinza diferenciador da região para todas as imagens sucessivas.

4. DECODIFICADOR DE IMAGEM (605) PARA DECODIFICAR UMA REPRESENTAÇÃO DE IMAGEM CODIFICADA (Im_1, MET, TOM) DE UMA CENA DE ALTO ALCANCE DINÂMICO, compreendendo: - uma unidade de decodificação da textura de pixel (608) disposta para obter a partir da representação da imagem codificada (Im_1) as cores de pixel dos pixels de uma imagem decodificada (IM_INTRM); e caracterizado pelo decodificar de imagem compreender - um desformatador (607) disposto para extrair da representação da imagem codificada (S) um valor de cinza diferenciador da região (gTS), que é um valor de luminância demarcando abaixo dele as luminâncias de todos os pixels de um primeiro objeto em pelo menos um bloco da imagem (IM_INTRM), e acima dele as luminâncias de todos os pixels de um segundo objeto em pelo menos um bloco da imagem e extrair um mapeamento da luma (TOM) da representação de imagem codificada; uma unidade de segmentação da imagem (606) disposta para usar o valor de cinza diferenciador da região (gTS) para obter um segmento da luma inferior e um segmento da luma superior na imagem decodificada (IM_INTRM); e uma unidade de transformação da cor do pixel (609) disposta a aplicar uma primeira transformação de cores (PD_BLCK) como definida no mapeamento da luma (TOM), qual transforma pelo menos os valores da luma das cores do pixel, em pixel no pelo menos um do segmento da luma inferior, e o segmento de luma superior, para obter uma segunda representação de imagem (IM_RC_HDR), em que a imagem decodificada (IM_INTRM) e a segunda representação de imagem (IM_RC_HDR) são duas graduações de uma cena de alto alcance dinâmica criada por um graduador de cor automático ou humano, e em que uma da representação de imagem e a segunda representação de imagem corresponde a uma imagem HDR principal classificada (IM_MSTR_HDR), e a outra é uma imagem LDR, e em que o mapeamento luma define um mapeamento entre lumas de pixels codificados na representação de imagem (Im_1) e lumas codificados na segunda representação de imagem.

5. DECODIFICADOR DE IMAGEM (605), de acordo com a reivindicação 4, caracterizado por compreender uma unidade de determinação da transformação (610) disposta para selecionar uma estratégia de transformação da cor do pixel a partir de uma fonte de memória não associada a nenhum dos dados da representação da imagem codificada (S) .

6. DECODIFICADOR DE IMAGEM (605), de acordo com a reivindicação 5, caracterizado pela unidade de determinação da transformação (610) ser disposta para determinar a estratégia de transformação da cor do pixel com base em pelo menos um parâmetro do ambiente de renderização.

7. MÉTODO DE CODIFICAÇÃO DE IMAGEM PARA CODIFICAR UMA IMAGEM (IM_MSTR_HDR) DE UMA CENA DE ALTO ALCANCE DINÂMICO, compreendendo: - codificação das cores dos pixels da imagem com uma representação da imagem (Im_1) compreendendo N palavras de codificação do bit; - determinação e geração de um valor de cinza diferenciador da região (gTS), que é um valor de luma demarcando abaixo dele as lumas de todos os pixels de um primeiro objeto em pelo menos um bloco da imagem, e acima dele as lumas de todos os pixels de um segundo objeto em pelo menos um bloco da imagem; e - caracterizado pelo método compreender co- codificação em um sinal de imagem de saída (S) a representação da imagem (Im_1) e o valor de cinza diferenciador da região (gTS) , e um mapeamento da luma (TOM) para pelo menos um dos primeiro e segundo objeto cujo mapeamento da luma define um mapeamento entre lumas de pixels codificado na representação de imagem (Im_1) e lumas dos pixels em uma segunda representação de imagem (IM_RC_HDR), em que uma das representações de imagem e a segunda representação de imagem é uma imagem HDR com um brilho de pico estabelecido fixo, e a outra é uma imagem LDR, em que a representação de imagem (Im_1) e a segunda representação de imagem (IM_RC_HDR) são duas graduações da cena HDR criada por um graduador de cores humano ou automático.

8. MÉTODO DE DECODIFICAÇÃO DA IMAGEM PARA DECODIFICAR UMA REPRESENTAÇÃO DE IMAGEM CODIFICADA (Im_1) DE UMA CENA DE ALTO ALCANCE DINÂMICO, compreendendo: - obtenção a partir das cores de pixel da representação da imagem codificada (Im_1) as cores dos pixels de uma imagem decodificada (IM_INTRM); caracterizado pelo método compreender - extração da representação da imagem codificada (S) um valor de cinza diferenciador da região (gTS), que é um valor de luminância demarcando abaixo dele as luminâncias de todos os pixels de um primeiro objeto em pelo menos um bloco da imagem (IM_INTRM), e acima dele as luminâncias de todos os pixels de um segundo objeto em pelo menos um bloco da imagem; o método compreendendo ainda extrair um mapeamento luma (TOM) da representação de imagem codificada; segmentar usando o valor do cinza do diferenciador da região (gTS) para obter um segmento de luma inferior e um segmento de luma superior na imagem decodificada (IM_INTRM); e aplicação de uma transformação de cores (PD_BLCK) conforme codificada no mapeamento luma (TOM), que transforma pelo menos valores de luma das cores de pixel em pixels em pelo menos um dos segmentos da luma inferior e o segmento da luma superior, para obter uma segunda representação de imagem (IM_RC_HDR), em que a imagem decodificada (IM_INTRM) e a segunda representação de imagem (IM_RC_HDR) são duas graduações de uma cena de alto alcance dinâmico criada por um graduador humano ou automático de cores, e em que uma da representação de imagem e a segunda representação de imagem corresponde a uma imagem HDR principal classificada (IM_MSTR_HDR) e a outra é uma imagem LDR, em que o mapeamento luma define um mapeamento entre lumas de pixel codificados na representação de imagem (Im_1) e lumas codificados na segunda representação de imagem.