BR112016027461B1 - Método de codificação de uma imagem de alta faixa dinâmica, codificador de imagem disposto para codificar uma imagem de alta faixa dinâmica, decodificador de imagem disposto para receber um sinal de imagem de alta faixa dinâmica, e, método de decodificação de um sinal de imagem de alta faixa dinâmica - Google Patents

Abstract

MÉTODO DE CODIFICAÇÃO DE UMA IMAGEM DE ALTA FAIXA DINÂMICA, CODIFICADOR DE IMAGEM DISPOSTO PARA CODIFICAR UMA IMAGEM DE ALTA FAIXA DINÂMICA, DECODIFICADOR DE IMAGEM DISPOSTO PARA RECEBER UM SINAL DE IMAGEM DE ALTA FAIXA DINÂMICA, E, MÉTODO DE DECODIFICAÇÃO DE UM SINAL DE IMAGEM DE ALTA FAIXA DINÂMICA. A presente invenção se refere a possibilitar uma boa tecnologia de codificação de imagem ou de vídeo de HDR, que tem a capacidade de produzir imagens de alta faixa dinâmica, assim como imagens de faixa dinâmica curta; inventou-se um método de codificação de uma imagem de alta faixa dinâmica (M_HDR), que compreende as etapas de: converter a imagem de alta faixa dinâmica em uma imagem de faixa dinâmica de luminância mais curta (LDR_o) aplicando-se a) dimensionamento da imagem de alta faixa dinâmica a uma escala predeterminada do eixo de luma como [0, 1], b) um mapeamento de tom de sensibilidade que muda o brilho das cores de pixel que são abrangidas por ao menos uma subalcance que compreende as cores mais escuras na imagem de alta faixa dinâmica, c) uma função gama, e d) uma função monotonicamente crescente arbitrária que mapeia as lumas resultantes da realização das etapas b (...).

Description

CAMPO DA INVENÇÃO

[001] A invenção refere-se a codificação de uma imagem (isto é, uma imagem estática), mas, de preferência, mais imagens de alta faixa dinâmica (High Dynamic Range) (isto é, vídeo), e que corresponde a sistemas e métodos da técnica para conduzir as informações de imagem codificadas necessárias para um lado de recebimento, e decodificadores para decodificar as imagens codificadas e, por fim, tornar as mesmas disponíveis para tela.

[002] Uma imagem de HDR é uma imagem que codifica as texturas de uma cena de HDR (que pode conter, geralmente, tanto regiões muito brilhantes quanto escuras), de tal maneira, com informações suficientes para a codificação de alta qualidade das texturas de cor dos vários objetos capturados na cena, que uma renderização visualmente de boa qualidade da cena de HDR pode ser realizada em uma tela de HDR com brilho de pico elevado como, por exemplo, 5.000 cd/m2 (5.000 nit). Na presente estrutura de codificação de HDR desenvolvida ao longo dos anos anteriores, também se deseja, ao mesmo tempo, codificar várias subvistas dinâmicas abrangidas nessa cena, o que pode servir como boas imagens de acionamento para várias telas de faixa dinâmica sucessivamente reduzido, ao menos uma aparência de imagem de LDR adequado para acionar, por exemplo, uma tela de pico de brilho de 100 cd/m2 (100 nit).

[003] Além disso, uma codificação de HDR é, de preferência, geralmente projetada para que a mesma não apenas se correlacione relativamente bem com as tecnologias de codificação de vídeo existentes, mas até mesmo possam se ajustar às estruturas de codificação de imagem ou de vídeo atuais da tecnologia existente, como, por exemplo, armazenamento em disco blu-ray (e suas limitações como quantidade de memória de armazenamento, como também todos os aspectos substancialmente já padronizados), ou conexões por cabo HDMI, ou outros sistemas de transmissão ou armazenamento de imagem etc. Especificamente, os sistemas de codificação de HDR que usam duas imagens codificadas por unidade de tempo (por exemplo, uma imagem de LDR, e uma imagem que tem intensidades de iluminação locais para reforçar cada pixel a um pixel de imagem de HDR) são vistos, especialmente, por fabricantes do aparelho como desnecessariamente complexos.

[004] A codificação de vídeo de HDR (ou até mesmo de imagem estática) foi, apenas recentemente, buscada por tentativa e tem sido uma tarefa intimidadora até o momento, e a crença característica é de que a mesma precisa de significativamente mais bits, para codificar os brilhos acima da faixa de LDR dos objetos em cena (por exemplo, codificações que codificam as luminâncias da cena diretamente), ou a mesma precisa de alguma abordagem de duas camadas, sendo que, por exemplo, além de uma imagem de refletância do objeto há uma imagem de reforço de iluminação, ou estratégias de decomposição semelhantes. As abordagens alternativas, como, por exemplo, o sistema de codificação de HDR da Dolby, geralmente, sempre usam tal tecnologia de codificação de HDR de duas camadas (consulte US8248486B1). O documento WO2010/105036 é um outro exemplo de tal sistema de codificação de 2 imagens por unidade de tempo da Dolby. Alguns mapeamentos de tom fixo simples TM (por exemplo, que emula o comportamento da fotografia de celuloide analógica clássica) podem ser usados para mapear uma imagem de LDR para uma classificação de HDR que corresponde à mesma, ou vice-versa. Essa pode ser qualquer função de mapeamento não muito correta (devido ao fato de que o classificador pode ter usado decisões de otimização complicadas, ou seja, sua classificação de LDR), então, pode haver uma diferença considerável entre a predição da imagem original, diga-se, imagem de HDR, e a própria imagem de HDR original, mas isso não é problema devido ao fato de que o sistema pode enviar as diferenças como uma segunda imagem de correção (fluxo de bits residual 742).

[005] Um outro exemplo de tal sistema de codificação de duas imagens é o sistema de codificação de HDR de technicolor (documento JCTVC-P0159r1, do 16° encontro do Time de Junta Cooperativa em codificação de vídeo de ITU- T SG 16 WP3, San José de 9 a 17 de janeiro de 2014) que codifica como uma primeira imagem um sinal de baixa resolução que é a iluminação local conforme será normalmente gerado em uma luz de fundo de LED 2D modulada, e a segunda imagem é uma imagem com textura de, normalmente, modulações de faixa dinâmica mais curta após aquele sinal de baixa frequência, que será normalmente gerado após a exibição por meio de sinais de acionamento de válvula de LCD adequados.

[006] A Philips inventou, recentemente, uma abordagem muito mais simples de única imagem(ainda não publicada amplamente, mas alguns aspectos podem ser encontrados nos documentos WO2012/147022 e WO2012/153224), que é uma nova direção na codificação de imagem e de vídeo, e não apenas, a priori, não fácil de imaginar, mas também quando, ao fazer isso, leva a muitas questões técnicas novas a serem solucionadas, o que, entretanto, funciona bem na prática.

[007] Com o termo “alta faixa dinâmica” (HDR) entende-se que qualquer imagem (ou imagens) conforme capturada do lado de captura tenha uma alta razão de luminância e contraste em comparação com a codificação de LDR legado (isto é, razões de luminância e contraste de objeto de 10.000:1 ou mais podem ser manipuladas pela codificação, e todos os componentes da cadeia de manipulação de imagem até a renderização; e as luminâncias de objeto capturado podem estar acima de 1.000 cd/m2 (1.000 nit), ou mais especificamente, podem ser tipicamente reproduzidas/renderizadas acima de 1.000 cd/m2 (1.000 nit) para, devido ao ambiente de reprodução, gerar alguma aparência desejada de, diga-se, uma lâmpada acesa ou exterior ensolarado). E, geralmente, a renderização de tal imagem (ou imagens) é HDR (isto é, as imagens devem ser adequadas no sentido em que as mesmas contêm informações suficientes para a renderização de HDR de alta qualidade, e, de preferência, de uma maneira tecnicamente fácil de usar), o que significa que a imagem (ou imagens) é renderizada ou pretende-se que seja renderizada nas telas com pico de brilho de ao menos 1.000 cd/m2 (1.000 nit) (o que não implica que as mesmas não devem ou não precisam ser, alternativamente, renderizadas em telas de LDR de, por exemplo, pico de brilho de 100 cd/m2 (100 nit), tipicamente, após o mapeamento de cor adequado).

ANTECEDENTES DA INVENÇÃO

[008] Recentemente, inúmeras tecnologias de codificação de HDR foram propostas como, por exemplo, o método de camada dupla da Dolby (WO2005/1040035). Entretanto, atualmente, a indústria ainda está buscando uma tecnologia de codificação de vídeo (/imagem) de HDR pragmática que se adeque a todos os requisitos (um saldo dos mesmos), como os fatores importantíssimos como quantidade de dados, mas também, complexidade computacional (preço de ICs), facilidade de introdução, versatilidade para os artistas criarem o que desejarem etc. Especificamente, uma abordagem de camada dupla é vista como desnecessariamente complexa. Alguém, idealmente, gostaria de ter a capacidade de projetar uma tecnologia de codificação que se adeque à codificação legada, como, por exemplo, a codificação de HEVC de MPEG baseada em DCT. Um problema é que isso é um tanto contra intuitivo: como se pode codificar uma imagem de HDR, que deveria ser, por definição, algo diferente de uma imagem de LDR, que tem geralmente uma quantidade maior de alcances de brilho/luminância interessantes, em uma tecnologia otimizada para conter imagens de LDR? Esses sistemas de manipulação/codificação de imagem de LDR legado foram projetados e otimizados para funcionar com os típicos cenários de imageamento de LDR, que são normalmente bem iluminados com, por exemplo, uma razão de iluminação em estúdio de 4:1(ou, por exemplo, 10:1), fornecendo para a maioria dos objetos (que pode variar em refletância entre, diga-se, 85% para branco e 5% para preto) na vista, uma razão de contraste total de cerca de 68:1 (respectivamente, 170:1). Caso se observe a renderização relativa (isto é, mapear a imagem branca para o branco da tela disponível) das luminâncias do objeto que começam a partir de um pico de branco, um típico monitor LCD anterior sem regulação de intensidade de luz local teria tido algo como 100 cd/m2 (100 nit) de branco e 1 cd/m2 (1 nit) de preto, o que estaria correlacionado à razão de contraste de imagem e, geralmente, se pensaria que nos sistemas de CRT médios que podem ter sido observados também durante o dia teriam algo como uma capacidade de 40:1. O fato de existir uma função gama de alocação de código de luminância de legado padrão de 2,2 nesses sistemas pareceu satisfatório para a maioria dos cenários de contraste de cena ainda superior. Embora alguns erros tidos como aceitáveis atualmente tenham sido cometidos, tais erros de renderização de regiões de cena de luminância elevada codificadas de modo ruim (por exemplo, grande limitação de exteriores claros atrás de uma janela) eram também aceitáveis devido ao fato de que as telas de LDR não poderiam, de qualquer modo, renderizar essas luminâncias de objeto fisicamente precisas.

[009] Entretanto, existem cenários para os quais há, no momento, um desejo de aprimorar a renderização como, por exemplo, uma cena em ambiente interno na qual um indivíduo pode ver simultaneamente ambientes externos ensolarados, em cujo caso pode haver uma razão de iluminação de 100:1 ou até mais. Com a renderização relativa linear (isto é, focalização nas primeiras regiões codificadas com mais brilho, ou equivalentemente, o cinza intermediário das regiões de cena com mais brilho, e mapeamento do branco da imagem para o branco da tela), o branco das partes internas faria o mapeamento para o preto psicovisual para o espectador! Então, em LDR, essas regiões ensolaradas normalmente aparecerão como limitadas (moderadamente) (geralmente, já na imagem codificada que tem dificuldade de discriminar códigos em torno de 255, no máximo, para esses pixels). Entretanto, em uma tela de HDR, deseja-se mostrar as mesmas tanto brilhantes quanto coloridas. Isso forneceria uma renderização muito mais naturalística e espetacular de tais cenas (como se você realmente estivesse de férias na Itália), mas mesmo cenas em que o conteúdo de brilho mais elevado é apenas composto de algumas reflexões especulares já mostra um aprimoramento de qualidade visual maior. Se os artefatos como erros de limitação ou quantização não parecerem inconvenientes, por exemplo, em uma tela de 5.000 ou 10.000 cd/m2 (5.000 ou 10.000 nit), deseja-se, ao menos, ter a capacidade de conduzir tais telas de HDR com o tipo certo de imagem, para que as imagens renderizadas sejam tão bonitas quanto a tela de HDR permitir.

[0010] O pensamento clássico era, entretanto, que para codificar faixas adicionais de brilho em excesso, precisaria se ter (muito) mais bits, que são os bits superiores que codificam as luminâncias de objeto acima de uma faixa de LDR. Isso poderia acontecer através da codificação natural em palavras de código único maiores (como OpenEXR com 16 bits dos quais um bit de sinal, exponente de 5 bits e mantissa de 10 bits, ou codificação de LogLuv de Ward, que tenta rigorosamente de modo matemático capturar todas as possibilidades de luminâncias de objeto com alta precisão), ou com o uso de uma primeira camada com códigos de alcance de LDR padrão (por exemplo, uma aproximação de JPEG clássica da imagem de HDR), e uma segunda camada para aprimorar tais luminâncias de pixel para brilho superior (por exemplo, uma imagem de reforço para reforçar cada pixel, caso necessário, para uma luminância superior, isto é, uma multiplicação de duas tais imagens de 8 bits equivalentes a um único código de 16 bits linear).

[0011] Um grande problema prático a ser solucionado quando se projeta uma tecnologia de codificação de HDR prática, além do fato de que, logicamente, precisa ter a capacidade de manipular uma grande gama de imagens de diferentes HDR, é que os fabricantes de hardware desejam quantidades menores de bits por palavra-código (canal, isto é, a luma, e dois canais cromáticos), entretanto, e embora a presente tecnologia proposta abaixo possa também funcionar com palavras com mais bits, propõe-se uma solução que funciona bem sob uma limitação de 10 bits para ao menos um canal de luminância (ou, mais precisamente, uma luma) (nota- se que, embora sejam elucidadas as modalidades com um canal de luminâncias, os presentes conceitos podem, com as devidas alterações, ser concretizados como funcionando em representações de cor de RGB (lineares ou não lineares) etc.). Além disso, foi desenvolvida uma estrutura que pode realizar, em uma filosofia dupla, tanto a codificação de pixels de cor (da aparência de HDR por meio de uma imagem de LDR) quanto a conversão de aparência de cor para diversos cenários de renderização (isto é, as aparências ideais necessárias para renderizar uma cena em diversas telas com diferentes picos de brilho, por exemplo, PB = 800 nit) de uma maneira funcional, o que significa que apenas as funções precisam ser co-codificadas quando se codifica a aparência de ao menos uma classificação adicional e, especificamente uma aparência de HDR além de uma aparência de LDR, em vez de, para cada figura, ao menos uma segunda figura.

[0012] Têm-se, atualmente, duas categorias de sistemas de codificação de HDR, uma vez que o mercado gostaria de tal versatilidade em um sistema de codificação, devido aos vários reprodutores e suas necessidades diferentes. No sistema de modo-i(ou aparência de HDR codificada como uma única imagem de definição, por exemplo, em um disco de BD, ou um fluxo de imagens de AVC ou HEVC através de uma conexão de rede), usa-se uma imagem de aparência de HDR como a imagem de único pixel, que é usada para codificar as texturas de cor e formatos do objeto (consultar no documento WO2015007505 do requerente como tal única imagem de HDR pode ser enviada para um receptor para definir as cores de pixel de ao menos a aparência de HDR, e como com as funções de reclassificação adequadas o receptor pode calcular, por meio de processamento das cores nessa imagem, outras imagens aparências). Com isso, deve-se que toma-se a imagem de classificação superior de HDR original, isto é, uma imagem idealmente classificada colorida parece melhor em uma tela de HDR de referência como, por exemplo, tipicamente uma tela de pico de brilho de 5.000 cd/m2 (5.000 nit), e que se transforme a mesma apenas minimamente: aplique apenas basicamente uma função de alocação de código ou função de transferência Optoeletrônica OETF (nota-se que embora essa OETF defina como as luminâncias da cena conforme capturadas, por exemplo, por uma câmera são transferidas para códigos luma, os engenheiros de televisão, em vez disso, gostam de especificar a função inversa que é a função de transferência eletro-óptica EOTF para ir de códigos luma para luminâncias renderizadas de tela de referência) com o uso da OETF idealmente aloca os 10 bit de códigos disponíveis, por exemplo, para o canal de luma Y’ através de todos os valores de brilho, um indivíduo precisa ser capaz de realizar em uma tela de referência [0 a 5.000] cd/m2 ( [0 a 5.000] nit). Outras classificações desejadas para diferentes picos de brilho podem, então, ser realizadas transformando-se essa imagem de aparência de HDR. Na presente estrutura, permite-se esse ajuste de aparência de tela realizando-se, geralmente, apenas uma segunda classificação que está na outra extremidade do alcance de telas possíveis a serem servidas, ou seja, uma aparência que é ideal ou razoável de acordo com o criador de conteúdo/classificador de cor para uma tela de pico de brilho de 100 cd/m2 (100 nit) (que é, normalmente, a tela de referência para a categoria de telas de LDR). Nota-se que essa é uma co-codificação de uma aparência adicional em vez de uma mera etapa de recoloração do lado da criação. Essa transformação de cor necessária é determinada mediante a aplicação de funções de mapeamento como funções gama que realizam um reajuste de brilho global (por exemplo, clareia as cores mais escuras na imagem), as curvas arbitrárias em formato de S ou inversas em formato de S para ajustar o contraste local, funções de processamento de saturação de cor para ajustar, por exemplo, a saturação para o brilho correspondente de alguns objetos ou regiões na imagem etc. Pode-se, de modo liberal, co-codificar essas funções (quaisquer que sejam as funções necessárias, contanto que pertençam a um conjunto limitado de funções de base que o receptor pode entender de uma maneira padronizada) como metadados associados à imagem de aparência de HDR pixelizada, em cujo caso se DEFINE, de modo paramétrico, a segunda imagem de classificação de aparência de LDR da imagem de aparência de HDR (isto é, não é mais necessário codificar essa imagem de aparência de LDR como uma imagem de pixel). Nota-se, cuidadosamente, a diferença com sistemas de codificação de duas camadas: no presente sistema, as funções de transformação de cor é tudo o que é codificado sobre a segunda aparência com capacidade de reclassificar a segunda aparência no receptor, então, em vez das funções aproximadas de tecnologias de 2 imagens, as presentes funções contêm o conhecimento inteligente total de como as iluminações dos vários objetos devem se comportar em várias aparências de renderização de acordo com o criador de conteúdo. Dado esse conhecimento de como os artistas criadores desejam parecer para transformar, a partir da primeira aparência para telas com um primeiro nível de capacidades de renderização de cor para uma segunda aparência para telas com um segundo nível de capacidades de renderização de cor (especificamente, o pico de brilho de tela), uma tela com capacidades intermediárias (por exemplo, 1.200 cd/m2 (1.200 nit) pico de brilho) podem, então, obter automaticamente uma imagem de acionamento mais ideal para essa situação de renderização com o uso do conhecimento nas duas classificações e interpolação (por exemplo, a tela pode realizar uma mistura assimétrica das duas imagens pixelizadas da aparência de HDR e da imagem de aparência de LDR derivada da imagem de aparência de HDR e as transformações funcionais, nas quais as porcentagens de mistura multiplicativas são determinadas por quão próxima a tela de HDR ou de LDR da tela atual está em uma escala não linear psicovisual), o que será melhor do que acionar a tela com a imagem de aparência de HDR ou a imagem de aparência de LDR original.

[0013] Essa é uma definição potente, embora simples não somente de uma aparência de imagem (HDR) única em uma cena (por exemplo, uma renderização de 5.000 cd/m2 (5.000 nit)), mas uma estrutura total para acionar renderizações razoáveis da cena para várias telas possíveis no campo como em uma residência do consumidor (e, ainda, a adaptação potencial para visualizar o ambiente, por exemplo, aplicando-se uma modelagem pós-gama à sensibilidade de contraste alterada da visão humana sob várias iluminâncias circundantes). É principalmente útil, por exemplo, para aplicações/cenários nos quais um criador tenha realizado uma boa versão de HDR de seu conteúdo e deseja ter antecipadamente essa aparência de HDR na codificação atual enviada para os receptores (por exemplo, em um disco de BD de HDR, ou mediante o pedido de um filme de HDR online através da internet, ou uma difusão de televisão da HDR etc.). Não é necessário que um cliente que adquire essa versão de conteúdo tem, de fato, uma tela de HDR, uma vez que o mesmo pode adquirir a mesma para mais tarde, quando tiver uma tela de HDR e pode, agora, usar a conversão de HDR-2-LDR, mas seria a opção preferenciada quando o cliente desejar o conteúdo para sua tela de HDR.

[0014] Enquanto a maneira de codificação de cenas de HDR de aparência de HDR (conforme explicado, o modo i que é aquele modo de ao menos imagens de aparência de HDR codificadas como uma imagem de pixel, mas, de fato, também promove aparências nessa mesma cena que são codificadas, então, parametricamente com funções de transformação de cor, como, por exemplo, uma modalidade de limitação, na qual a aparência de LDR isola um subalcance da imagem de HDR e limita o restante) já impõe desafios técnicos significativos para obter um novo sistema técnico pragmático para futuras imagens, mas, principalmente, também para codificação de vídeo (levando-se em conta tais fatores como simplicidade de projeto de IC (integrated circuit - circuito integrado) para os fabricantes de hardware, permitindo, ainda, que os desenvolvedores de conteúdo criem quaisquer conteúdos bonitos de HDR que desejem criar como filmes de ficção científica, programas de televisão espetaculares ou documentários sobre a natureza etc., com muitos efeitos de HDR criativos como lâmpadas que realmente parecem estar acesas), o mercado deseja ainda uma outra camada de complexidade, que será ensinada neste relatório de patente.

[0015] Ou seja, para algumas aplicações (que serão chamadas de modo-ii), pode ser desejável ter uma imagem de aparência de LDR como a única imagem pixelizada que codifica os objetos da cena, que é, por exemplo, gravada como a única imagem em um disco blu-ray. Embora o criador de conteúdo também se preocupe muito com a qualidade da aparência de HDR, o mesmo se atenta muito na aparência de LDR que é semelhante a como seria com as tecnologias de legado. Haverá, então, geralmente parâmetros de função co-codificados em metadados associáveis para derivar uma imagem de aparência de HDR ao atualizar a imagem de aparência de LDR que foi comunicada no sinal de imagem S_im. Pode haver várias razões para se escolher essa variante de modo-ii (ou aparência de LDR), que pode, por exemplo, ser para sistemas de legado que não têm capacidade de realizar qualquer processamento (por exemplo, se um indivíduo preferir codificar a única imagem em uma modalidade específica que codifica as cores como cores de Y’uv em vez de uma codificação de YCrCb, um indivíduo poderia, ainda, codificar isso em uma estrutura de HEVC de legado, fazendo de conta que a imagem de Y’uv é uma imagem de YCrCb com colorido incomum e com o uso adicional de esquemas de codificação baseados em DCT de legado, como padronizado em um dos membros da família de codec de MPEG), mas também para aplicações que precisam de uma aparência de LDR (por exemplo, ao assistir um filme em uma tela portátil com pouco brilho) e pode não desejar realizar muito processamento. Ou, talvez, o criador não deseja investir muito tempo na criação de uma aparência de HDR perfeita (mas, por exemplo, apenas um rápido ajuste mínimo de sintonia fina de uma autoconversão de LDR-2- HDR que, por exemplo, isola as regiões brilhantes e as reforça de modo não linear, por exemplo, para uma remasterização de um filme antigo de “O Gordo e o Magro”), e considera sua aparência de LDR ser a classificação mestre mais importante das aparências de LDR e HDR, que deve ser diretamente codificada sem precisar de qualquer transformação de cor, com possíveis erros de cor. Por exemplo, uma emissora de televisão pode escolher essa opção, especialmente para transmissões sobre a vida real (por exemplo, as notícias podem não precisar estar no HDR mais espetacular).

[0016] Essa codificação de aparência de LDR (modo ii) tem, no entanto, complexidade adicional devido à natureza matemática do problema e à matemática de codificação por um lado, versus desejos de classificação artística liberal por outro lado, o que torna isso uma tarefa desencorajadora para se produzir uma boa estrutura técnica. Para ser mais preciso, por um lado, precisa-se de funções que, primeiro, diminuam a classificação de uma imagem de HDR mestre desejada e, no receptor com essas funções recebidas (ou as funções inversas da diminuição, de fato) o receptor possa atualizar para ao menos uma aproximação próxima da imagem de HDR original novamente, isto é, na função de metadados, os dados de parâmetro serão parâmetros para funções (derivadas pelo codificador das funções que o classificador usou na redução do HDR mestre) que podem mapear a única imagem de LDR para uma predição de HDR suficientemente próxima Rec_HDR. Mas, por outro lado, a imagem de LDR deve, quando diretamente renderizada em uma tela de +- 100 cd/m2 (100 nit), isto é, sem mais transformação de cor, parecer suficientemente boa de acordo com o classificador de cor também. Então, haverá um equilíbrio entre a seleção das funções, e como irão influenciar as aparências de LDR Rec_HDR, e que, também levando em conta outras questões, como os fabricantes de CI ou de aparelho gostariam de ver um conjunto limitado de funções padrão que são úteis para a reclassificação de aparências, e os criadores de conteúdo desejam que essas funções especifiquem rapidamente quais aparências eles desejam, uma vez que o tempo de classificação é caro e a temporização das liberações do filme pode ser crítica. Na descrição abaixo, será descrito um sistema prático para manipular essa variante de modo ii de codificação de cena de HDR.

[0017] Os documentos a seguir estão tangencialmente relacionados à presente invenção, mas, não obstante, é de interesse mencioná-los e distingui-los.

[0018] Durante a reunião de Sapporo MPEG2014/M34274, R. van de Vleuten et al. da Philips publicaram (julho de 2014, então, após a data de prioridade deste pedido) “Proposed electro-optical transfer function (EOTF) for HDR video delivery”. Esse documento contém o EOTF que é também usado para as presentes modalidades para realizar um pré-mapeamento para a faixa dinâmica LDR. Entretanto, esse documento ensina apenas que esse EOTF tem boas propriedades de correlação com o aparecimento de iluminação humana, e por isso, poderia ser útil como uma função de alocação de código luma para codificação de imagem de HDR. Ergo, claramente, o que, no máximo, pode ser derivado desse documento, é um ensinamento ou uma inspiração de que se for desejado codificar uma única imagem ou vídeo de HDR mestre, isto é, as imagens com lumas de pixel codificadas para, por exemplo, uma tela de 5.000 nit, então, esse EOTF é útil. A codificação somente de um vídeo de HDR significa que há apenas imagens definidas com referência ao pico de brilho de, por exemplo, 1.000 nit ou 5.000 nit, que precisa ser comunicado aos receptores, e não há nada mais, em particular, nenhuma outra aparência classificada nas mesmas imagens de cena como imagens de LDR com pico de brilho de 100 nit, que também precisam ser comunicadas. Essa codificação única de vídeo de HDR é muito mais simples tecnicamente, e uma vista diferente na codificação de HDR que não é o que a presente invenção ensina. Tais imagens apenas de HDR não são adequadas para a exibição direta em telas de LDR legado, que tem tipicamente um pico de brilho de cerca de 100 nit, como, por exemplo, as regiões escuras se parecerão muito mais escuras em tal tela que é 50 vezes mais escura do que a tela de 5.000 nit para a qual as imagens de HDR foram criadas. Conforme claramente mencionado acima, o presente pedido fornece tecnologias para os cenários em cujos casos não se deseja conduzir as informações de HDR de uma cena de HDR original para um receptor, mas pode-se desejar, de fato, comunicar uma versão de LDR de tal imagem (de uma maneira que, entretanto, permite a imagem reconstruída da imagem de HDR no receptor), que fornece uma aparência adequada quando renderizada diretamente em uma tela de legado, isto é, com as regiões escuras não sendo muito escuras. Ou seja, um requisito técnico muito diferente da codificação apenas de imagem de HDR e, por isso, este pedido ensina fatores adicionais bem contemplados.

[0019] O documento m34165 da mesma reunião de Sapporo de Tourapis et al. “Report on the XYZ/HDR exploratory experiment 1: EOTFs for XYZ HDR delivery”, semelhantemente é apenas um estudo sobre como várias funções de EOTF são realizadas quando apenas imagens de HDR são codificadas com as mesmas (devido ao fato de que o uso de EOTF errado pode levar a bandagem no lado de recebimento), isto é, sem qualquer consideração, ou até mesmo, mencionam uma necessidade de uma imagem de LDR, deixar a qualidade visual ou artística dessa imagem de LDR.

[0020] O documento WO2013/046095 ensina princípios técnicos gerais necessários para se ter a capacidade de realizar qualquer decodificação de HDR, em particular, novamente decodificação de dados de cena de HDR que foram codificados como imagens únicas de HDR, mas, que não precisam necessariamente ser renderizadas em uma tela com o mesmo pico de brilho de tela (PB_D) como a luminância de ponto branco da imagem de HDR recebida (por exemplo, considera-se um decodificador de sinal que recebe conteúdo de HDR especificado, isto é, com os brilhos de pixel de objeto de imagem com cor classificada coreto a ser renderizado em uma tela de referência de 5.000 nit PB_D, no entanto, tem uma tela fixada de, diga-se, 2.000 nit PB_D, ou 7.000 nit, por isso, deve realizar uma transformação de faixa dinâmica ideal para obter imagens de aparência correta para enviar para sua tela conectada atual). Precisa-se saber várias coisas, como o que a luminância de ponto branco do código foi (por exemplo, R=G=B=1.023 significava um branco de 1.000 nit, ou 5.000 nit, conforme mudaria seriamente a transformação necessária para algum branco renderizável na tela conectada), e que é o EOTF usado que define, de fato, os códigos de RGB ou luma, isto é, que liga os códigos luma às luminâncias que supostamente devem representar, isto é, que devem ser renderizadas na tela conectada. Também há alguns ensinamentos gerais de que alguns dados de transformação de faixa dinâmica podem ser co- comunicados com a (única) imagem/vídeo de HDR (ou imagens/vídeos) comunicada, ou talvez imagem de LDR (ou imagens) comunicada. Esse ensinamento poderia, no máximo, inspirar um leitor versado na técnica a co-comunicar alguma modificação de aparência desejada com a imagem (por exemplo, o HDR podem de propósito, ser escurecido um pouco por qualquer razão, e então, clareado novamente no lado do receptor comunicando-se uma transformação de faixa dinâmica/mapeamento de tom de clareamento, ou talvez a transformação poderia ocorrer no lado de recebimento independente do que o lado de codificação teria feito com a imagem antes de transmiti a mesma; essa função de mapeamento de tom deve ser contrastada com o EOTF, que é uma alocação técnica pura de códigos luma para a luminâncias, mas o mapeamento de tom pode realizar algumas alterações adicionais do brilho dos pixels, por exemplo, tecnicamente realizadas como um mapeamento de input_luma para output_luma, por exemplo, por razões artísticas). Para esse pedido de patente o ensinamento sobre a estrutura de manipulação de dados principais para gerenciar a compreensão do significado de algum tipo de codificação de imagem de HDR (definida pelo que o máximo do pico de brilho dos códigos corresponde, por exemplo, R=G=B=1.023 precisa ser renderizado como branco de 5.000 nit; e que o EOTF foi usado para alocar todos os códigos luma de RGB para, de fato, serem valores de RGB e luminâncias lineares renderizadas em tela), que não pode ser derivado disso, é a construção de um sistema técnica novo e diferente específico que comunica os dados de imagem de HDR como imagens de LDR como no presente pedido, deixa-se os componentes necessários específicos que realiza isso de modo pragmático conforme reivindicado.

[0021] O Doc. JVT-S087 do 19° Encontro de MPEG de Genebra: Segall et al. “Tone mapping SEI message”, ensina apenas, de modo genérico, que se alguém tiver um desejo por “algum” mapeamento de tom seja aplicado às luminâncias de pixel, então, pode ser comunicado isso em uma mensagem de SEI de metadados dedicados. Isto é, o lado de recebimento poderia, então, receber, por exemplo, uma codificação de 10 bit de uma imagem de HDR, e, por exemplo, usar a imagem de SEI para converter em uma imagem de LDR de 8 bits padrão que corresponde à mesma, isto é, com os brilhos de pixel do objeto mais adequados para renderizar em uma tela de 100 nit PB_C (em vez de, por exemplo, a tela de 1.000 nit ou 5.000 nit para qual a imagem de HDR foi feita). Por exemplo, um formato sigmoide pode ser usado. Isso é, novamente, um exemplo de comunicar apenas os dados de cor de pixel de um vídeo de HDR de imagens, então, esse documento contém novamente nada suficiente para inspirar no sentido de algum componente de um sistema de codificação dupla compatível com LDR para imagens de HDR como se tem.

[0022] O documento JCTVC-P0159r1/m32076 de Lasserre et al. “High dynamic range video coding” é um exemplo de um sistema de 2 camadas (isto é, um fluxo de imagem básico e um fluxo de imagens de correção) (consulte a Figura 1), consequentemente, bem distante da tecnologia apresentada, e que não contém qualquer inspiração útil, ou ainda provável de ser consultada para inspiração útil. Os sistemas de duas camadas estão sem sua filosofia técnica, consequentemente, construção e os componentes técnicos usados, muito diferente de codificações de imagem única, mais transformações de função de cor para derivar outras imagens de faixa dinâmica.

[0023] Os documentos EP2406959 ou WO2010/105036 também são apenas uma codificação de HDR de duas camadas (consultar a Figura 7, fluxo de bits residual 742), muito diferente e irrelevante para absorver ensinamentos de modo suficiente retidos nos conceitos do presente pedido. O mesmo fornece uma visão interessante sobre alguns aspectos de codificação de imagem de HDR como informações de antecedente.

[0024] O documento M34355 da conferência Sapporo de julho (novamente, após a data de prioridade) de Stessen et al de Philips “Chromaticity-based color signals” ensina que quando um indivíduo deseja codificar (apenas) imagem de HDR (ou imagens), pode-se desejar usar outro espaço de cor além do espaço de cor Y’CbCr de codificação de LDR de legado. O mesmo menciona novamente que o eixo “brilho” desse espaço de cor poderia ser definido com o EOTF da Philips que, sem nenhuma surpresa, também é usado em alguns outros dentre as revelações e ensinamentos, como no presente pedido de patente. O documento, então, ensina adicionalmente que caso se deseje realizar processamento de cor em um espaço que é determinado por, por exemplo, tal EOTF altamente inclinado e duas crominâncias, por exemplo, se um receptor gostaria de realizar sua transformada de faixa dinâmica de qualquer modo ou outra otimização de cor em seu fim, por exemplo, sempre que o mesmo tiver decidido automaticamente que poderia ser uma transformada razoável para converter a(s) imagem(ns) de HDR recebidas em imagem(ns) de LDR, então, esse espaço pode não ser tão útil, e erros de cores de uma magnitude maior que o desejável poderiam ocorrer. Portanto, os autores introduziram as cromaticidades de canais de duas cores que são independentes de faixa dinâmica. Pouco valor para os ensinamentos do presente pedido poderia ser derivado disso, muito menos que esses ensinamentos seriam abrangidos pelo padrão da tecnologia necessária para codificação ou decodificação de vídeo de HDR baseado em LDR.

[0025] A proposta genérica da Philips de TM- AVC0671 apresentada no fórum de padronização de DVB, é meramente um ensinamento de sistema de caixa preta de nível alto no sentido de negócios que foram desenvolvidos de uma (modo-ii) possibilidade para codificar imagens de HDR comunicando-se, de fato, imagens de LDR (+ o tipo certo de metadados funcionais, deve-se pesquisar mais sobre um invento, para que isso funcione subitamente). A mesma, no entanto, não fornece quaisquer especificações sobre os componentes necessários, conforme apresentado neste pedido de patente. A mesma diz apenas que há um “conversor de faixa dinâmica” de caixa, que uma pessoa suficientemente versada na técnica entenderia sobre o que o mesmo faria em tal topologia de sistema, mas nenhum detalhe dos internos foi revelado. Além disso, uma captura de tela da ferramenta de classificação é mostrada, em que um graduador humano no lado de criação poderia usar para especificar todas as funções necessárias, como também na presente invenção, mas o requerente foi cuidadoso para não mostrar quaisquer detalhes técnicos que seriam deriváveis daquela figuração simples.

SUMÁRIO DA INVENÇÃO

[0026] Precisa-se ter uma codificação aprimorada de imagens de HDR e, especificamente, começou-se com a filosofia de que especialmente no momento atual, quando há muitos sistemas de LDR legado no campo, precisa-se de alguns níveis de compatibilidade. Isso significa, por um lado, que se deseja manter o uso de CIs (de)codificadores existentes que implementam a funcionalidade como (I)DCT [= primeiro nível de compatibilidade com tecnologias de comunicação de imagem]. Mas, além disso, deve haver o segundo nível de compatibilidade com telas que, por causa de seu pico de brilho baixo, precisa de imagens de LDR (isto é, uma aparência de LDR, não uma aparência de HDR com, por exemplo, cores muito escuras nas partes mais escuras da imagem, mas, em vez disso, com cores mais escuras que foram clareadas para melhor visibilidade nas telas de LDR) devido ao fato de que as mesmas só podem renderizar imagens de LDR (isto é, a aparência de LDR correta sob tal capacidade de faixa dinâmica de tela). Isso se deve ao fato de que, além das TVs de legado atualmente empregadas, no futuro haverá um espectro de telas que varia de telas portáteis pequenas com pouca capacidade de brilho como computadores do tipo laptop ou computadores do tipo pad ou até mesmo telefones móveis nos quais um consumidor deseja também ver alguma renderização de filme de HDR, até as telas de HDR mais avançadas, que no futuro podem ter um pico de brilho de, por exemplo, 10.000 cd/m2 (10.000 nit), e todas as telas entre ou ao redor das mesmas. Então, embora a tela ainda seja legada e simples, poderia ser servida por um CI de mapeamento de cor e nova decodificação com alta complexidade em, por exemplo, um decodificador de sinal futuro ou computador que fornece o conteúdo de HDR através, por exemplo, de um HDMI ou outra conexão, sendo que o decodificador de sinal oferece qualquer combinação das opções inventadas e descritas. Nota-se que uma imagem de LDR legado precisaria ser alguma otimização entre contraste intraobjetos e interobjetos. Seria desejável ver as texturas interiores de objeto de modo claro, ainda deseja-se também ter, na imagem de LDR, uma impressão da aparência talvez com grande contraste de HDR da cena original. Isto é, a diferença entre uma região com muito e pouco brilho pode não ser renderizável perfeitamente com a imagem de LDR, no entanto, ainda deveria haver um remanescente desse, fazendo com que as alterações de iluminação na cena sejam transportáveis o mais idealmente possível em LDR pelo classificador humano.

[0027] Esses requisitos foram convertidos em uma abordagem na qual um indivíduo precisaria, no cenário ideal, (ao menos) de duas gradações para o mesmo filme ou as mesmas figurações a partir do provedor de conteúdo, que serão chamadas de uma imagem de LDR (a ser usada para cenários de tela de LDR, por exemplo, com telas com pico de brilho em torno de 100 cd/m2 (100 nit)) e uma imagem de HDR (para as telas mais brilhantes, por exemplo, uma tela de referência de pico de brilho de 5.000 cd/m2 (5.000 nit)).

[0028] Então, para diversos cenários exemplificadores práticos, tem-se um ponto de partida para as modalidades de codificação de HDR inovadora como entrada de uma imagem classificada de HDR mestre (diga-se, é classificada por vontade própria, de acordo com qualquer que seja o gosto do criador com qualquer que seja o software de processamento de cor e, por exemplo, codificada em uma codificação de cor de partida como OpenEXR, e pode até mesmo ser uma atualização para uma aparência de HDR de uma imagem que foi originalmente capturada como LDR, por exemplo, adicionando-se efeitos gráficos de computador). Precisa-se, então, codificar esse HDR mestre (M_HDR) de um modo que seja praticamente útil para as tecnologias de codificação de vídeo e de imagem atuais (isto é, apenas minimamente modificadas a partir do modo normal de usar tais tecnologias de codificação que pode envolver uma redefinição dos significados de código, isto é, as respectivas luminâncias codificadas por vários códigos luma, mas não que, por exemplo, todos os barramentos precisem ser alterados para 12 bit, isto é, os presentes métodos devem funcionar com hardware de 12 bits, mas também, se apenas 10 bits por componente estiverem disponíveis, ou se uma qualidade inferior for aceita até mesmo em sistemas de 8 bits), para, por exemplo, um novo reprodutor de disco de BD, ou CI de televisão que recebe vídeo com fluxo contínuo de Internet, ou qualquer receptor conectado a qualquer que seja a fonte de imagem amplamente compatível com uma variante das tecnologias de codificação de imagem/vídeo atuais.

[0029] Chegou-se a uma importante compreensão de que uma imagem de HDR pode ser codificada como uma imagem de aparência de LDR (isto é, uma imagem que, com pouco ou nenhum processamento colorimétrico - pode ser uma conversão em um outro espaço de cor, mas sem qualquer ou muito mapeamento de tom para converter o brilho dos objetos de imagem para serem mais adequados a uma tela com um outra faixa dinâmica de luminância - pode ser diretamente usada para a tela com boa qualidade em uma tela de LDR) caso apenas se adicionar os parâmetros das funções de mapeamento de cor que podem converter essa aparência de LDR em uma imagem de aparência de HDR (o presente modo ii). O leitor deve considerar que isso não é uma coisa trivial a se fazer, mesmo teoricamente, certamente não a priori, mas até mesmo após ter definido a tarefa técnica (devido ao fato de que, sem o desenvolvimento adicional correto, pareceria um tanto contraditório codificar uma aparência por meio de uma outra aparência que é supostamente diferente). Especificamente, uma vez que muitas das presentes modalidades começam de um M_HDR existente, as funções podem mapear a imagem de aparência de LDR pixelizada em uma reconstrução próxima Rec_HDR do M_HDR. Mas, logicamente, isso, em geral, pode não apenas ser realizado de qualquer maneira específica ad hoc, isto é, uma cadeia de codificação técnica específica é necessária.

[0030] A presente invenção pode ser realizada, por exemplo, ao menos dos seguintes modos: um método de codificação de uma imagem de alta faixa dinâmica (M_HDR), que compreende as etapas de: - converter a imagem de grande faixa dinâmica em uma imagem de faixa dinâmica de luminância mais curta (LDR_o) mediante a aplicação de: a) normalização da imagem de grande faixa dinâmica a uma escala do eixo de luma que é [0, 1] produzindo uma imagem de grande faixa dinâmica normalizada com cores normalizadas que têm luminâncias normalizadas (Yn_HDR), b) cálculo de uma função gama nas luminâncias normalizadas que produzem luminâncias convertidas por gama (xg), c) um primeiro mapeamento de tom que reforça essas luminâncias convertidas por gama de pixels da imagem de grande faixa dinâmica normalizada que se situa abaixo de 0,1 com uma quantidade predeterminada que se situa entre 1,5 e 5,0, produzindo lumas (v), e d) uma função de mapeamento de tom monotonicamente crescente arbitrária que mapeia as lumas que resulta da realização das etapas b e c para emitir lumas (Yn_LDR) da imagem de faixa dinâmica mais curto (LDR_o); e - emitir em um sinal de imagem (S_im) uma codificação das cores de pixel da imagem de faixa dinâmica de luminância mais curta (LDR_o), e - emitir os valores de sinal de imagem (S_im) que codificam os formatos de função das conversões de cor acima b a d como metadados, ou valores para suas funções inversas, cujos metadados permitem que um receptor reconstrua uma imagem de alta faixa dinâmica reconstruída (Rec_HDR) a partir da imagem de faixa dinâmica de luminância mais curta (LDR_o).

[0031] Essa combinação específica de funções de conversão de luma provou ser um modo muito bom de manipular a codificação de imagens de HDR na mentalidade do modo ii, isto é, em particular, no modo duplo de codificação de imagens de HDR como imagens de aparência de LDR derivadas por essas funções de conversão de um HDR mestre, cujas imagens de LDR servem o propósito duplo de codificar exatamente a aparência de HDR, assim como de serem imagens de aparência de LDR bem utilizáveis.

[0032] Nota-se que qualquer codificação das cores de pixel, isto é, que representam as cores dos pixels em algum sistema de codificação de espaço de cor pode ser usada, e algumas serão mais pragmáticas do que outras. Por exemplo, o LDR_o poderia ser produzido como uma imagem (R’G’B’) [em que os traços indicam alguns mapeamentos não lineares de componentes de RGB lineares]. Elucida-se um exemplo que tem capacidade de codificar a imagem de LDR para ser comunicada a um receptor de uma maneira Yu’v’ e, então, também o processamento como o mapeamento de tom pode ser realizado em uma representação de Yxy com coordenadas de cromaticidade de xy como, por exemplo, então, u’v’, mas os mesmos princípios da invenção abaixo podem também ser incorporados em outras representações de cor, por exemplo, representações de RGB lineares (isto é, os cálculos são, então, feitos com componentes de RGB diretamente em vez de componentes de Y), etc. Também, os versados na técnica compreenderão quais das diversas maneiras podem ser usadas para co-codificar os parâmetros que caracterizam os mapeamentos funcionais (que podem ser, por exemplo, uma função multilinear definida por seus pontos de mudança de segmento), que serão, geralmente, como metadados no sinal de imagem S_im, ou associáveis ao mesmo, (por exemplo, uma estrutura de mensagem de SEI ou semelhante), o que significa que, no momento em que um receptor precisar dos parâmetros para fazer sentido para os dados de cor de pixel codificado para transformar os mesmos em, por exemplo, uma imagem de saída de RGB linear para renderização em uma tela conectada, o mesmo deve ter obtido esses parâmetros de definição de aparência através de alguma tecnologia de comunicação de dados, por exemplo, um local de memória conectável por meio de algum enlace de comunicação.

[0033] Essa combinação específica de um mapeamento de “sensibilidade” que clareia ao menos as cores do objeto mais escuras em uma imagem (em um subalcance de cores de pixel mais escuras, que pode-se definir, na prática, para ser os 10% de luminâncias mais baixas de uma imagem linear normalizada, que pode ser, por exemplo, um canal de Y, ou os valores de RGB lineares mais baixos correspondentes) e uma função de gama/potência funciona bem para manipular as características colorimétricas de imagens de HDR e, em particular, sua típica discrepância com renderização de LDR. Muitas renderizações de LDR poderiam, logicamente, ser contempladas, por exemplo, uma renderização trivial ignora apenas todas as cores que são consideradas muito brilhantes ou muito escuras através de limitação, mas essa não é, necessariamente, a melhor aparência de LDR, e certamente não é útil para a reconstrução de aparência de HDR de boa qualidade.

[0034] Já que tanto uma imagem de HDR (diretamente no modo i) quanto uma imagem de LDR (em particular, uma imagem de LDR que está, de fato, codificando uma imagem de HDR) podem ser, de fato, codificadas em um recipiente semelhante, por exemplo, recipiente de HEVC de 3x 10 bits, pode-se perguntar qual é a diferença entre uma imagem de HDR e de LDR. Essa diferença é uma diferença calorimétrica, que é muito importante quando uma tela, um ambiente de visualização e um espectador estão envolvidos. Matematicamente, pode-se medir isso a partir de típicos valores de pixel na imagem normalizada (isto é, uma imagem de LDR ou de HDR normalizada) e, em particular, o histograma. Se a mesma for uma imagem de LDR regular, normalmente não haverá um contraste tão alto entre as cores de pixel mais escuras e as mais brilhantes. Logicamente, em imagens de LDR também pode haver valores que são brancos, assim como valores que são pretos (zero), mas esses irão corresponder às luminâncias reais a serem renderizadas diferentes, devido ao fato de que há uma função de alocação de código diferente definindo as mesmas. Outros receptores/decodificadores inovadores reconhecerão a situação e aplicarão, em cada caso, a decodificação adequada. Quando se diz que a imagem de LDR precisa ser diretamente útil em uma tela legada, significa que o receptor que fornece imagens decodificadas para o receptor irá compreender/decodificar os valores de luma com uma função de alocação de código de legado, isto é, geralmente, o gama 2,2 de Rec. 709. Agora, uma imagem master_HDR (modo i) pode ser codificada por uma função de alocação de código totalmente diferente, o que significa que uma luma preta de, diga-se, 0,05 corresponde a um preto muito mais escuro do que para uma imagem de LDR, e 0,96 corresponde a uma cor muito mais brilhante. Além desse modo ii introduzir um conceito mais novo de que os códigos luma podem estar, agora, relacionados ao HDR ou poderem ser lumas renderizadas por uma outra alocação de código, e que pode, até mesmo, ser variável dependendo das escolhas pelo classificador (em particular, a curva de cliente)! Especificamente, uma imagem de modo i não terá, geralmente, um histograma relativamente uniforme (bem aceso) como na codificação de LDR legado, mas, geralmente, um histograma bimodal, em que há inúmeros objetos mais escuros, e inúmeros pixels muito mais brilhantes (por exemplo, os pixels externos que poderiam ser 100x mais brilhantes em uma representação de luminância linear, mas podem ser, por exemplo, 3x mais brilhantes quando se usa uma função de alocação de código específica, isto é, na representação de luma finalmente usada). Em algumas imagens de HDR, os pixels mais brilhantes podem também estar em menor número, por exemplo, um par de lâmpadas em uma cena de noite. Em uma imagem de modo ii, a relação será novamente diferente. Haverá, ainda, alguma diferença suficiente entre as regiões (supondo- se, na elucidação simples do presente documento, de que as imagens de HDR estão então formadas), não apenas porque as funções relativamente simples podem mapear o Rec_HDR, como também devido ao fato de que até mesmo a renderização direta de LDR pode ser desejável para reter um tanto da aparência de contraste. Mas, por outro lado, as duas faixas de luminância podem ter sido encolhidas uma em direção a outra até um certo grau em função das limitações da escala de LDR. Mas, o que é importante em tudo isso é que ainda pode-se ver alguma assinatura de uma imagem ser ou não proveniente de uma cena de LDR ou de HDR. Não apenas os algoritmos de análise de imagem matemática pode analisar a aparência de faixa dinâmica conforme codificados em imagens (por exemplo, para produção de televisão em tempo real, em que a qualidade final das aparências é menos importante do que, por exemplo, os custos de produção), para os quais uma unidade de análise de imagem 177 pode ser usada. Mas, em geral, as presentes tecnologias de codificação em seu formato de maior qualidade serão usadas com um classificador de cor humano no final da criação, que pode ver, geralmente, em uma tela de HDR e de LDR como o sistema se comporta (isto é, como as aparências de LDR e de HDR de fato parecem ser), girar os botões de seu teclado de classificação e, por fim, codificar uma imagem de LDR e as funções de reconstrução de HDR com as quais ele está satisfeito. Nota-se que, normalmente os receptores não precisam realizar uma análise total da situação. Os mesmos não precisam, por si, se preocupar com a possibilidade da imagem normalizada que receberam ser uma imagem de HDR ou uma imagem de LDR, e com qual variante de imagem de LDR. Os mesmos precisam apenas aplicar “cegamente” as funções recebidas. A única coisa que precisam saber, geralmente, é o que as funções definem e/ou o que a única imagem define. Então, geralmente, o sinal conterá um indicador (IND) de qual tipo de sinal ele é. Logicamente, podem ter sido comunicadas muitas coisas sobre o sinal, por exemplo, para televisões que desejam realizar seu próprio aprimoramento de imagem adicional inteligente, mas, geralmente, o que um receptor precisa saber minimamente é que esse sinal de codificação de HDR S_im é do tipo que contém uma imagem diretamente útil para renderização de LDR (independente de sua aparência poder ser justada para uma imagem de LDR melhor pelos receptores que podem mapear o por tom a imagem de LDR recebida LDR_t com mais funções de mapeamento de tom [parametrizadas com Ff1, Ff2, etc.] ou não). Com essas informações, o receptor sabe que se uma tela de LDR conectada tiver que ser servida com imagens adequadas, as imagens de aparência de LDR podem ser diretamente enviadas para o mesmo, e se for uma tela de HDR, primeiro, as transformações de cor serão aplicadas para obter as imagens de HDR corretas para renderização. O leitor versado na técnica compreenderá que isso pode ser indicado de diversos modos, por exemplo, com uma palavra-chave como “DIRECTLDR”, ou com um conjunto de números “100/5.000”, que indica que a única imagem é uma imagem destinada a uma tela de 100 cd/m2 (100 nit) (tela real ou de referência) e foi derivada e é mapeável para uma imagem de HDR de 5.000 cd/m2 (5.000 nit) (que não significa que nenhuma outra imagem para telas de outro pico de brilho pode ser derivada da imagem de LDR com as informações nos parâmetros que definem as funções de transformação de cor) etc.

[0035] Se for observado um pouco mais detalhadamente para o que uma imagem de HDR pode ser tipicamente (quando normalizada e para ser classificada para uma imagem de LDR de modo ii ideal), deve-se compreender como várias cenas serão tipicamente classificadas em um ambiente definido por tela de referência de HDR com um pico de brilho de, por exemplo, 5.000 ou 10.000 cd/m2 (5.000 ou 10.000 nit).

[0036] Novamente, tendo-se o exemplo de elucidação de uma cena interna com um ambiente externo ensolarado brilhante, pode-se desejar classificar as cores externas no M_HDR para aproximadamente cinza médio de HDR, então, cerca de 20% de 5.000 cd/m2 (5.000 nit), isto é, +1.000 cd/m2 (1.000 nit). As cores do ambiente interno não devem ser renderizadas com típicas luminâncias de ambientes internos reais, uma vez que se vê o filme em um outro ambiente, por exemplo, um ambiente normal escurecido de visualização de televisão. Então, definidamente, as cores de ambientes internos não devem ser renderizadas em 1/100° das luminâncias de pixel de ambientes externos ensolarados, uma vez que essas não são também renderizadas exatamente, apenas uma cópia exata em qualquer lado de recebimento do qual a classificação mestre de referência na tela de referência teria sido feita. Deve-se levar em consideração o aparecimento para o espectador mediano adaptado, em particular, que na aparência de HDR os ambientes internos não devem parecer escuros de modo irreal. Pode-se classificar essas cores em, por exemplo, 1/10° da luminância média das cores de região de imagem “espaço externo ensolarado”, então em torno de +- 100 cd/m2 (100 nit). Entretanto, agora, o mapeamento ingênuo dessas lumas em uma tela de referência de LDR de 100 cd/m2 (100 nit) (com um mapeamento de cor que é, diga-se, próximo de uma extensão linear ao menos conceitualmente), as cores de espaços externos ensolarados em LDR pareceriam perfeitas, em cerca de 20 cd/m2 (20 nit) e acima até branco, mas as cores de espaços internos seriam renderizadas em torno de 2 cd/m2 (2 nit), que pareceriam como pretos psicovisuais. Esta é a razão pela qual se deve realizar “alguma” otimização, que pode ser um tanto complexa dependendo da complexidade de uma cena de HDR específica, que é o motivo pelo qual, de preferência, tem-se um classificador de cor humano envolvido no lado da criação de conteúdo, para os aspectos da presente estrutura de codificação. Para tornar essas cores de ambientes internos também razoavelmente visualizáveis, pode-se colocá-las um tanto mais escuras do que cinza médio (18%), mas não muito mais na otimização. Então, pode-se desejar reforçar essas cores mais escuras com um fator geralmente entre 5 e 7 (dependendo do que está nas regiões escuras respectivamente brilhosas, logicamente, a otimização pode ser diferente para uma base escura em que se deve dificilmente ver ferramentas na parede e pode limitar a luz da lâmpada que ilumina as mesmas), mantendo as cores mais brilhantes acima dessas. A Figura 5 mostra dois cenários exemplificativos da presente cadeia de codificação de HDR/LDR. As curvas 501 e 502 mostram apenas a primeira curva de mapeamento de tom (“sensibilidade”) característica, isto é, antes do gama. As mesmas são definidas por, com valores normalizados possíveis para a log(7?/70) ' entrada xg entre zero e 1,0, e um valor de RHO ideal no caso do HDR mestre ser definido com um pico de brilho de tela de referência de f 1.000 cd/m2 (1.000 nit) para a curva 501 (que significa que qualquer que seja o conteúdo na cena capturada, as luminâncias de objeto no M_HDR são definidas entre zero e maximamente 1.000 cd/m2 (1.000 nit), o valor para o qual, por exemplo, uma centelha de soldagem ou o sol podem ser graduados), e 5.000 cd/m2 (5.000 nit) para a curva 502. O valor de RHO ideal pode ser determinado de várias maneiras, conforme o leitor versado na técnica compreenderá. Por exemplo, o classificador pode escolhê-lo, adequado para o que o mesmo considera uma boa aparência de LDR dada a imagem de M_HDR específica. Ou, um aparelho no lado da criação pode calculá-lo, automaticamente, por exemplo, de acordo com a equação a seguir:

[0037] Nessa equação PBHDR é o pico de brilho da tela de referência associada à classificação de M_HDR (isto é, que define o alcance de valores possíveis, e tipicamente, corresponde ao PB de uma tela real na qual o graduador estudou e criou sua aparência de HDR mestre), por exemplo, 1.000 ou 5.000 cd/m2 (1.000 ou 5.000 nit) como na Figura 5, e GAM é um valor gama, que pode ser, tipicamente, por exemplo, 2,4. Logicamente, o aparelho (ou classificador) pode se desviar desses valores por qualquer outro algoritmo ou heurística, por exemplo, no caso de uma aparência um tanto mais brilhante, ou plana, ser necessária etc.

[0038] Agora, pode-se ver na Figura 5 que se forem determinados os fatores de reforço (em comparação com à diagonal, sendo que a luma de HDR normalizada está no eixo x, e a luma de LDR normalizada no eixo y) para a parte do primeiro mapeamento de tom/mapeamento de tom de sensibilidade apenas para um valor entre +- 1,5 e 4,0, tem-se, após aplicar o mapeamento de gama com um gama de 2,4 também, os fatores de reforço de cerca de 6 a 7 para os 10% mais escuros das cores (curvas 503 respectivamente 504 sendo o mapeamento combinado de log e gama), que é aproximadamente o que se precisa (o classificador pode, mais tarde, ajustar conforme desejado com sua curva de mapeamento de tom arbitrário, mas é uma boa estratégia para, por exemplo, aparelhos de autoconversão, que envolvem minimamente o classificador apenas no caso do ajuste ser necessário ou desejável). Em geral, um indivíduo gostaria de ter, de modo geral, um reforço de +- 4 a 8 para as operações combinadas de mapeamento de tom de log/gama (isto é, unidade 602 e 603), que significaria que um valor de reforço entre 1,5 e 5,0 seria adequado para a parte de sensibilidade baseada em RHO apenas (unidade 603). Qualquer função de mapeamento de tom para a unidade 603 que tenha tal comportamento para as cores mais escuras satisfaria o que se deseja para a presente invenção, mas a equação baseada em log acima é uma maneira pragmática simples de se realizar isso. O comportamento para as cores mais claras acima será, geralmente, uma compactação suave, isto é, com um formato de função que mapeia geralmente de modo não linear as luminâncias mais claras acima da faixa tomado pelas cores mais escuras reforçadas. Agora, pode-se ter imagens de HDR muito complexas, que podem desejar outros valores, mas tais situações extremas podem ser manipuladas por uma definição de curva arbitrária adequada pelo classificador (ou um algoritmo de classificação automática). Nota-se que no lado da decodificação, a cadeia de processamento precisa ser substancialmente inversível, para ter capacidade de calcular o Rec_HDR a partir da única imagem (ou imagens) de LDR comunicada. “Substancialmente inversível” significa que não se tem necessariamente que obter exatamente os mesmos valores de componente de cor em Rec_HDR como no M_HDR original, as diferenças de cor devem estar em um limite de tolerância. Portanto, o receptor deve, por fim, ter a capacidade de obter as funções de transformação de cor necessárias para atualizar a aparência de HDR Rec_HDR, independente se o mesmo calcular as mesmas pela inversão das funções de rebaixamento originalmente usadas no lado do receptor quando se faz com que o LDR_o (ou LDR_i) forme o M_HDR e receber as informações de formato dessas funções, ou pela recepção direta das funções inversas necessárias para realizar a atualização para Rec_HDR. Isso, inter alia, significará geralmente que para a função de mapeamento de tom arbitrária que o classificador pode definir para ajustar a aparência de LDR para suas preferências críticas, o mesmo precisará definir uma função monotonicamente crescente relacionada às lumas de LDR e HDR normalizadas conforme o versado na técnica compreenderá.

[0039] A cadeia técnica de modo ii básica pode funcionar de uma maneira simples. Por exemplo, para algumas cenas menos críticas, o classificador pode ocupar a função arbitrária com valores padrão que são uma transformação de identidade. Nota-se também que embora sejam descritos os componentes técnicos básicos necessários na cadeia, nas realizações práticas, um ou mais desses blocos podem ser agrupados em unidades reais que realizam as funções. Por exemplo, em algumas aplicações, pode ser desejável enviar um LUT total de todas as funções de mapeamento de cor juntas, enquanto em outras aplicações, pode ser vantajoso enviar as funções separadas, devido ao fato de que a televisão (automaticamente, por exemplo, após análise da cena, ou sob controle de interface de usuário pelo espectador) pode, por exemplo, desejar ajustar adicionalmente, por exemplo, a primeira função que clareia a imagem um tanto em comparação com a sensibilidade ou o valor de RHO recebido da tecnologia de comunicação de imagem/vídeo. As versões mais avançadas podem usar algumas etapas de processamento adicionais, por exemplo, o método de codificação pode determinar um valor de ganho (gai) para mapear a luma máxima da imagem de faixa dinâmica mais curto (LDR_o) para um valor específico dos valores possíveis na imagem de grande faixa dinâmica reconstruída (Rec_HDR), e para codificar esse valor de ganho no sinal de imagem (S_im), que não deve ser confundido com as cores normalizadas de forma de dimensionamento final em relação ao pico de brilho da tela conectada (por exemplo, Lm=5.000 cd/m2 (5.000 nit)). Esse ganho permite classificação e/ou codificação mais versátil.

[0040] Um método aprimorado muito útil de codificação de uma imagem de alta faixa dinâmica (M_HDR) compreende: após aplicar qualquer um dentre os mapeamentos de cor acima para determinar a imagem de faixa dinâmica mais curta (LDR_o), aplicar um mapeamento de tom técnico adicional (301) para determinar uma segunda imagem de faixa dinâmica mais curta (LDR_i) que pode ser usada para acionar telas de LDR como uma alternativa de imagem de acionamento alternativa para a imagem de faixa dinâmica de luminância mais curta (LDR_o), cujo mapeamento de tom técnico é determinado por: a) se determinar uma primeira região geométrica da imagem de faixa dinâmica de luminância mais curta (LDR_o) para a qual a visibilidade de criação de faixas na imagem na imagem de alta faixa dinâmica reconstruída correspondente (Rec_HDR) está acima de um nível aceitável, b) se determinar uma faixa de lumas (L_u) para essa região, c) se determinar um segunda faixa de lumas de pixel (L_uu) adjacente no eixo de luma às alcance de lumas (L_u), sendo que a segunda faixa é identificada para satisfazer as condições de que a mesma tem várias lumas acima de um número mínimo (MIN), e corresponde a uma segunda região de imagem geométrica que contém uma textura que pode ser representada com o uso de menos que o número mínimo de códigos em uma imagem de LDR (LDR_i) na qual se aplicam as funções que produzem uma imagem de alta faixa dinâmica reconstruída (Rec_HDR) de qualidade visual suficiente para essa segunda região, e d) se determinar uma função de mapeamento de redistribuição que redistribui as lumas da primeiro e da segunda faixas de luma, para que os códigos adicionais estejam disponíveis para a primeira faixa, e emitir nos valores de sinal de imagem (S_im) que codificam o formato de função da função de mapeamento de redistribuição ou, de preferência, seu inverso.

[0041] Um método é um tanto limitado em relação à troca entre reconstrução total ou suficientemente precisa do Rec_HDR, e a aparência da imagem de LDR LDR_o, em particular, se o hardware (e custos de classificação) ditar que umas quantidades relativamente limitadas de funções de classificação precisam ser usadas. Algumas cenas de HDR podem não ser tão difíceis (por exemplo, o espectador comum pode não ser muito crítico sobre a possibilidade das sombras de um lado sombreado de uma rua ensolarada serem um pouco mais escuras, ou um pouco mais cinza claro, contanto que os desvios da aparência ideal não sejam muito excessivos), mas algumas cenas de HDR podem ser mais críticas (por exemplo, em algum lugar na faixa de luminância de HDR pode haver um rapaz parcialmente escondido na névoa luminosa, e se o contraste local existente for muito alto, ele pode ficar muito visível, mas se o contraste for muito baixo, ele pode ficar invisível, mudando a história). Seria vantajoso ter uma outra dimensão de classificação possível, ao menos para receptores não legados (e não sabem como realizar qualquer processamento de HDR), e podem realizar algum mapeamento de tom adicional. Uma tela legada poderia, então, obter a imagem de LDR com “melhor esforço”, que será a única imagem transmitida, mas os receptores futuros inteligentes poderiam realizar alguns truques técnicos inteligentes para otimizar ainda mais a aparência de LDR, para que se aproxime do que o classificador deseja (talvez até limite alguns valores na aparência de LDR final, o que seria incongruente com a reconstrução de HDR se isso acontecesse na única imagem de LDR transmitida). Existindo tal possibilidade, alguns métodos de codificação ou codificadores devem satisfazer essa necessidade. Compactar um imagem de HDR com razão de contraste altíssimo muito complexa em uma única imagem de LDR (por exemplo, uma imagem de HDR que têm diversas regiões importantes com muitos valores de cinza, por exemplo, uma sala sem iluminação escura, uma segunda sala relativamente bem iluminada, e, ao mesmo tempo, um espaço externo iluminado com sol colorido, e com essas 3 regiões contendo também gradientes importantes que cobrem muitos valores de cinza, por exemplo, de uma tabela de branco sob a lâmpada na sala bem iluminada), poderia ocorrer que uma ou mais regiões se tornassem inaceitáveis, devido ao comprimento limitado de palavra (por exemplo, 10 bits) para os componentes de cor, em qualquer lugar (dependendo dos formatos das funções de mapeamento de cor) há a criação de faixas na imagem, a qual é considerada muito grave. Essa região pode ser identificada, por exemplo, pelo classificador que a observa (e o mesmo pode ser auxiliado ao receber indicação de possíveis áreas críticas pelo software de análise de imagem de HDR no aparelho de classificação). Os detectores de criação de faixas na imagem podem calcular, por exemplo, que para uma região prolongada (que potencialmente leva também em consideração quais luminâncias essa região tem, e JNDs estimados) há saltos de cada vez de inúmeras cores sucessivamente iguais, e podem definir um nível aceitável com base nos valores de tal cálculo (e típicos experimentos em fábrica). O aparelho de classificação após ter encontrado tal região (por exemplo, por meio de segmentação mais fina daquilo que o classificador selecionou aproximadamente), pode, então, determinar aproximadamente a faixa L_u de luminâncias que correspondem à mesma. Por exemplo, pode haver criação de faixas na imagem em um céu azul, cujas cores têm luminâncias entre L_sky_low e L_sky_high. O problema seria mitigado, se a codificação de LDR tivesse mais valores para codificar a imagem, sendo que deve-se compreender que no lado de codificação, o M_HDR e quaisquer transformações podem ainda ter altíssima precisão. Mas esses códigos não existem: tem-se apenas os 10 bits disponíveis para todas as luminâncias necessárias, e precisa-se também codificar suficientemente todas as outras regiões de imagem de iluminação diferente. Mas um truque pode ser usado, caso alguns códigos possam ser emprestados das regiões da imagem que tem luminâncias adjacentes a L_u, especialmente se a qualidade visual dessas regiões piorar um pouco, tirando-se alguns códigos de seu alcance de código (que o classificador geralmente julgará, por meio de uma simples operação de aceitar o resultado, ou discordar em relação a qual caso será feita uma outra tentativa, que é mais agressiva no caso da criação de faixas na imagem ainda ser grande para a área originalmente com faixas e a região adjacente ainda pode ser mais deteriorada, ou um pouco menos agressiva se o classificador indicar que a região adjacente começa a se deteriorar muito). Uma maneira simples de redistribuir os códigos é, por exemplo, uma modificação linear ou não linear da parte de função local. Agora, a questão com a única imagem transmitida LDR_o, é que o céu pode, por exemplo, ter se tornado um pouco escuro demais e, talvez, com muito contraste por meio dessa operação (e, também, as regiões adjacentes podem ser um tanto escuras demais, e sua aparência de textura pode ter mudado etc.). Isso pode não ser muito problemático no caso de pequenas alterações e cenas menos críticas, e um pouco mais inconveniente para cenas difíceis. Esse é o preço que os sistemas legados podem ter que pagar, devido ao fato de que os mesmos não podem fazer absolutamente nada com qualquer um dos dados recebidos exceto por renderizar diretamente o LDR_o, mas novos receptores podem aplicar o inverso das transformações usadas para redistribuir as lumas, para criar uma aparência de LDR muito próxima daquela originalmente pretendida (isto é, com as luminâncias de céu adequadas etc.), mas, agora, com menos criação de faixas na imagem. Um receptor não precisa fazer muita análise inteligente, precisa apenas ver que tal função de mapeamento de tom técnico está disponível, e precisa aplicar a mesma à reconstrução da única imagem de LDR transmitida LDR_t para obter a melhor imagem de aparência de LDR LDR_ul. Inúmeros métodos podem também ser aplicados nos aparelhos de classificação para fornecer boas sugestões para a região adjacente, por exemplo, uma região com uma quantidade suficiente de lumas (por exemplo, igual à quantidade no céu) e com alguma textura complexa pode ser determinada. As modalidades simples podem por exemplo, usar todos os códigos abaixo da faixa das regiões com faixas, até o preto mais escuro.

[0042] A quantidade de códigos adicionais para a primeira faixa é determinada com base em um critério de visibilidade de criação de faixas na imagem para a primeira região geométrica. Um algoritmo automático pode estar em uma proporção, por exemplo, 20% de códigos adicionais e, geralmente, o classificador humano reconhecerá isso. O algoritmo também pode realçar as regiões que o mesmo tinha que piorar, por exemplo, deixando-se intermitente uma coloração dessas regiões, para que o classificador possa verificar rapidamente a possibilidade dessas terem qualidade visual suficiente também no HDR reconstruído Rec_HDR.

[0043] Na maioria das modalidades práticas, a identificação da primeira região geométrica que mostra a criação excessiva de faixas na imagem é normalmente realizada por fim por um classificador humano por meio de uma unidade de interface de usuário (105), por exemplo, rabiscando-se uma linha ondulada ao longo da região com faixas, e a quantidade de criação de faixas na imagem da primeira região geométrica na imagem de alta faixa dinâmica reconstruída (Rec_HDR) e a qualidade visual de reconstrução da segunda região geométrica na imagem de alta faixa dinâmica reconstruída (Rec_HDR) ser julgada pelo classificador humano como aceitável ou não aceitável, sendo que no caso do julgamento aceitável, os valores que codificam o formato de função da função de mapeamento de redistribuição ou seu inverso são codificados no sinal de imagem, ou no caso do julgamento inaceitável, as etapas são realizadas com diferentes parâmetros para resultar em uma função de mapeamento de redistribuição alternativa. Por exemplo, 10% de mais códigos pode ser alocado para a região com faixas, talvez, às custas de uma faixa de lumas adjacentes alargadas L_uu.

[0044] Uma modalidade interessante do método de codificação de uma imagem de grande faixa dinâmica (M_HDR) tem as cores de pixel da imagem de faixa dinâmica de luminância mais curta (LDR_o) que são codificadas como um canal de luma e coordenadas de cor u’ e v’ que são calculadas coordenadas de cor 1931 CIE independentes de dispositivo que são deriváveis para qualquer representação de RGB (isto é, a representação de cromaticidade CIE 1976 (u’,v’)). Normalmente, de acordo com a filosofia legada, as imagens (especialmente imagens de LDR) seriam codificadas como imagens de YCrCb. Mas, se for alterado qualquer codec (por exemplo para a transmissão por internet), pode-se, também, codificar os componentes de cor como planos de componente de Yuv que tem algumas vantagens tanto na qualidade de imagem das imagens transmitidas, quanto na facilidade de aplicar as várias transformações de cor do presente sistema (logicamente, as televisões de legado não terão, então, capacidade de produzir figurações com boa aparência).

[0045] Concluiu-se que a definição de luma escolhida em geral, (definida pela estratégia de mapeamento de tom total escolhido das etapas acima, que, por fim, obtém as lumas em LDR_o ou LDR_i) que, juntamente com duas coordenadas de cromaticidade independentes de luma, em particular, as coordenadas de u’,v’ padronizadas pelo CIE, será uma boa codificação a ser usada nas tecnologias de compactação de vídeo ou imagem padrão. As tecnologias de compactação semelhantes, por exemplo, a HEVC irão, tipicamente, aplicar ao menos compactação espacial fazendo-se DCTs de blocos de amostras, mas para vídeo, as mesmas podem também fazer a compactação baseada em estimação de movimento, etc.

[0046] Em modalidades simples, a codificação do comportamento de transformação de cor funcional das conversões de cor pode ser comunicada com apenas alguns parâmetros simples armazenando-se nos metadados associados ou associáveis à única imagem (ou imagens): a) um valor de sensibilidade (por exemplo, RHO, ou um parâmetro equivalente que define RHO chamado de SENS e definido no presente documento abaixo, ou qualquer função ou correlato de RHO que permite determinar um valor de RHO), b) um valor gama (GAM), e c) inúmeros valores que caracterizam o formato funcional da função arbitrária que mapeia as lumas.

[0047] Um método de codificação de uma imagem de alta faixa dinâmica (M_HDR) que compreende determinar um valor de ganho para mapear a luma máxima da imagem de faixa dinâmica mais curta (LDR_o) para um valor específico dos valores possíveis na imagem de alta faixa dinâmica reconstruída (Rec_HDR), e codificar esse valor de ganho no sinal de imagem (S_im). Isso é útil para um dimensionamento adicional da imagem de Rec_HDR que pode ser obtida a partir da imagem de LDR, por exemplo, se a imagem de LDR de uma filmagem relativamente escura é representada de modo relativamente brilhante, isto é, que representa, em lumas, um valor relativamente alto na faixa de lumas de LDR possíveis, ainda, a imagem de HDR deve ser renderizada de modo não muito brilhante, que é melhor manipulada ao já se decodificar a mesma com uma luma máxima não muito alta.

[0048] Um método de codificação de uma imagem de alta faixa dinâmica (M_HDR) que compreende determinar uma estratégia de modificação de saturação das cores da imagem de alta faixa dinâmica (M_HDR) para as cores na imagem de faixa dinâmica mais curta (LDR_o), ou do modo inverso, e codificar essa estratégia de modificação de saturação como valores paramétricos em metadados no sinal (S_im). Geralmente, os classificadores também desejarão afetar a saturação de uma imagem, por exemplo, os mesmos podem alterar a saturação do LDR_o obtido a partir de M_HDR com alguma estratégia de mapeamento de saturação, e/ou a saturação de Rec_HDR a partir de LDR_o (por exemplo, primeiro, um mapeamento de tom que deixa as cromaticidades de u,v das cores de Rec_HDR obtidas nos valores que se tinha em LDR_o, e, então, alterando-se as saturações dessas cores de Rec_HDR).

[0049] Algumas modalidades do método de codificação de uma imagem de alta faixa dinâmica (M_HDR) compreendem: após aplicar qualquer um dos mapeamentos de cor acima para determinar a imagem de faixa dinâmica mais curta (LDR_o), aplicar um mapeamento de tom técnico (301) adicional para determinar uma segunda imagem de faixa dinâmica mais curta com lumas redistribuídas, isto é, lumas geralmente de valores ligeiramente alterados para ao menos uma região geométrica e subalcance de luma da imagem (isto é, uma imagem de faixa dinâmica curto imagem de luma redistribuída LDR_i), que garante que ao menos, para o classificador, nas regiões mais importantes, da segunda imagem de faixa dinâmica mais curta (LDR_i), por exemplo, que são cuidadosamente observadas pelo típico espectador destinado, devido ao fato de que são, por exemplo, grandes e brilhantes, e propensas à criação de faixas na imagem, códigos luma suficientes podem ser alocados para codificar as texturas nessas regiões com precisão suficiente para possibilitar a reconstrução da imagem de alta faixa dinâmica reconstruída (Rec_HDR) com erros abaixo de um critério de erro predeterminado (uma quantidade de criação de faixas na imagem mínima).

[0050] É importante que em algumas modalidades não seja escolhida nenhuma estratégia de mapeamento de tom incomum. Especificamente, se for desejado que se tenha capacidade de obter um Rec_HDR com boa qualidade, isto é, perto em valores de cor de pixel matemáticos ao M_HDR, então, é preciso garantir que não haja texturas não amostradas adequadamente em LDR_i, que acontece caso seja garantido que o mapeamento final antes da quantização uniforme seja, agora, muito plano.

[0051] Geralmente, isso pode ser feito através de estratégias de contagem de luma na figuração de LDR e/ou estratégias de contagem de luma como, por exemplo, um detector de criação de faixas na imagem na imagem de HDR, ou qualquer tal critério de erro de reconstrução de HDR predeterminado. Em algumas modalidades, o critério pode ser realizado por um classificador humano. Sua presença pode ter sido vista, tendo-se uma estratégia de remapeamento técnico co-codificada em S_im, a ser aplicada pelos receptores de geração futuros mais inteligentes.

[0052] O método pode ser incorporado em um codificador de imagem (100) disposto para codificar uma imagem de alta faixa dinâmica (M_HDR), que compreende: - uma unidade de conversão de faixa dinâmica (104) disposta para converter a imagem de alta faixa dinâmica em uma imagem de faixa dinâmica de luminância mais curta (LDR_o), sendo que a unidade de conversão de faixa dinâmica (104) compreende, conectados em ordem de processamento: a) um normalizador (601) disposto para normalizar a imagem de alta faixa dinâmica em relação a um eixo de luma que está na faixa de [0,1] e para emitir luminâncias normalizadas (Yn_HDR), b) uma unidade de conversão de gama (602) disposta para aplicar uma função gama às luminâncias normalizadas e para emitir luminâncias convertidas por gama (xg), c) uma primeira unidade de mapeamento de tom (603) disposta para aplicar um primeiro mapeamento de tom que reforça essas luminâncias convertidas por gama que se situam abaixo de 0,1 com uma quantidade predeterminada que se situa entre 1,5 e 5,0, produzindo lumas (v), d) uma unidade de mapeamento de tom arbitrário (604) disposta para d) aplicar uma função arbitrária que mapeia as lumas (v) para emitir lumas (Yn_LDR) da imagem de faixa dinâmica mais curta (LDR_o); sendo que o codificador de imagem (100) compreende adicionalmente: - um compactador de imagem (108) disposto para aplicar uma transformação de redução de dados às cores da imagem de faixa dinâmica mais curta (LDR_o), cujas cores são organizadas em imagens de componente, e em que a transformação de redução envolve ao menos aplicar uma transformação de DCT em blocos de valores de componente de cor adjacentes, produzindo uma codificação compactada (LDR_c) das cores de pixel da imagem de faixa dinâmica de luminância mais curta; e - um formatador (110) disposto para emitir, em um sinal de imagem (S_im), a codificação compactada (LDR_c), e disposto para, adicionalmente, emitir nos valores de sinal de imagem (S_im), codificar o formato de função das conversões de cor como metadados, ou valores para suas funções inversas, cujos metadados permitem que um receptor reconstrua uma imagem de alta faixa dinâmica (Rec_HDR) com base na imagem de faixa dinâmica de luminância mais curta (LDR_o).

[0053] Uma modalidade pragmática de tal codificador é uma na qual a unidade de conversão de gama (602) usa um valor gama igual a 1/(2,4), e/ou a primeira unidade de mapeamento de tom (603) usa um mapeamento de tom sendo que RHO tem um valor predeterminado, cujo valor é, geralmente, uma função do pico de brilho da tela servida destinada e/ou da tela de referência associada à codificação de HDR mestre M_HDR.

[0054] Um codificador de imagem (100) disposto para especificar um ganho que permite mapear o máximo dos códigos luma na imagem de faixa dinâmica mais curta (LDR_o) para um valor de luma escolhido da imagem de alta faixa dinâmica reconstruída (Rec_HDR), e que tem o formatador (110) disposto para produzir esse ganho como um valor em metadados no sinal de imagem (S_im).

[0055] Um codificador de imagem (100), conforme reivindicado em qualquer uma das reivindicações de codificador acima que compreende uma unidade de mapeamento de tom técnico (106), disposto para determinar automaticamente ou guiado por ser humano as informações de textura e estatística da imagem de faixa dinâmica mais curta (LDR_o) e em particular, ao menos uma região geométrica crítica que é propensa aos erros de reconstrução, em particular criação de faixas na imagem no Rec_HDR, e com base no mesmo calcular um segundo mapeamento de tom (Ff1, Ff2, ...) para ser aplicado como uma transformação para a imagem de faixa dinâmica mais curta (LDR_o) para produzir uma segunda imagem de faixa dinâmica mais curta (LDR_i) que tem um número mínimo de códigos luma (por exemplo, 1,3*L_u) que caracteriza as texturas de ao menos algumas regiões propensas a erro importantes da segunda imagem de faixa dinâmica mais curta (LDR_i), permitindo, desse modo, a reconstrução da imagem de alta faixa dinâmica reconstruída (Rec_HDR) com erros abaixo de um critério de erro predeterminado. Para possibilitar a comunicação das informações necessárias que permite, após a codificação, que um receptor implemente, de modo espelhado, o presente sistema de modo ii, é útil transmitir (ou armazenar, para transmissão posterior) um sinal de imagem de alta faixa dinâmica (S_im) que compreende: - uma imagem de faixa dinâmica mais curta pixelizada (LDR_o) com cores de pixel codificadas; e adicionalmente: - um valor de sensibilidade (RHO); e - um valor gama (GAM); e - um valor de ganho (GAI); e - um conjunto de valores que especificam um formato de função de mapeamento de tom arbitrária (P_CC).

[0056] A partir desses valores, o receptor pode, então, determinar os formatos de função de todas as funções a serem aplicadas à única imagem de LDR comunicada (LDR_o, ou LDR_i), caso qualquer imagem de maior faixa dinâmica do que a imagem de LDR 100 cd/m2 (100 nit) seja necessária e calculada.

[0057] Especificamente, a S_im também pode compreender valores 207 que codificam uma estratégia de remapeamento técnico (Ff1, Ff2, ...) para mapeamento entre uma classificação de LDR artística conforme desejado pelo criador/classificador humano do conteúdo, e um LDR técnico que, quando amostrado, tem lumas suficientes para todas as regiões da imagem para a boa reconstrução de Rec_HDR, ou ao menos aquelas regiões determinadas como mais críticas por uma unidade de análise de imagem automática e/ou um humano.

[0058] Especificamente, é útil, embora muito pragmático, que os receptores determinem rapidamente qual dentre os diversos (muitos) mecanismos de codificação de imagem de HDR atuais possíveis diferentes é usado, em particular, ao compreender, no sinal de imagem S_im, um indicador (IND) que especifica que uma imagem de alta faixa dinâmica foi codificada no mesmo, e com um método que a codifica como uma imagem de faixa dinâmica curto, que é diretamente útil, sem uma necessidade de adicionalmente mapear por tom, para renderização em uma tela de LDR. Vários modos de codificação podem ser planejados e concordados, contanto que qualquer receptor compreenda isso.

[0059] Um produto de memória como um disco blu- ray armazena qualquer modalidade do presente sinal de imagem de alta faixa dinâmica (S_im).

[0060] Para se ter uma cadeia de comunicação de imagem, na extremidade de recebimento pode-se ter várias realizações de aparelhos que são ou compreendem um decodificador de imagem (150) disposto para receber um sinal de imagem de alta faixa dinâmica (S_im) e que compreende: - um desformatador (151) disposto para obter uma imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) e dados de parâmetro (P) fora do sinal de imagem (S_im); e - um descompactador (152) disposto para aplicar ao menos uma transformação de DCT inversa à imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) para obter uma imagem de faixa dinâmica mais curta pixelizada (LDR_t); e uma unidade de conversão de faixa dinâmica (153) disposta para transformar a imagem de faixa dinâmica mais curta (LDR_t) em uma imagem de alta faixa dinâmica reconstruída (Rec_HDR), sendo que a unidade de conversão de faixa dinâmica (153) compreende, na ordem de processamento: a) uma unidade de mapeamento de tom arbitrário (402) disposta para aplicar um mapeamento de tom arbitrário, sendo que os parâmetros que definem o mesmo (P_CC) são recebidos nos dados de parâmetro (P), b) uma primeira unidade de mapeamento de tom (403) disposta para aplicar um mapeamento conforme definido por ao menos um parâmetro recebido (RHO) que define o primeiro mapeamento de tom que foi determinado anteriormente por qualquer uma dentre as modalidades de codificador ou de método de codificação, e c) uma unidade de conversão de gama (404) disposta para aplicar um mapeamento de gama com um valor gama recebido (GAM).

[0061] Esse decodificador primeiramente desfará todas as típicas codificações legadas de compactação, por exemplo, HEVC ou semelhantes e, então, aplicará os vários mapeamentos na ordem inversa (nota-se que nem tudo precisa estar, em todas as modalidades, exatamente na ordem inversa; por exemplo, em Yu’v’ pode-se escolher fazer o processamento de luma e saturação ortogonal em uma ordem inversa, talvez com funções matemáticas ligeiramente diferentes, contanto que o resultado final seja exata ou aproximadamente a cor pretendida). Deve-se observar também que pode haver etapas adicionais de processamento, que podem existir apenas na extremidade de recebimento (por exemplo, uma imagem pode ser codificada em alguma representação de RGB como Rec. 2020, mas pode precisar ser convertida para um outro formato conforme compreendido por uma televisão, por exemplo, DCI-P3, e adicionalmente convertido nas cores primárias reais da TV).

[0062] Então, o decodificador de imagem (150) compreenderá uma unidade de conversão de faixa dinâmica (153) disposta para transformar a imagem de faixa dinâmica mais curta (LDR_t) em uma imagem de alta faixa dinâmica reconstruída (Rec_HDR), e pode haver normalmente unidades lógicas e mais funções de processamento de cor que definem ao menos quando fazer o desejado (por exemplo, dependendo de qual tela ou de quais telas estão atualmente conectadas e são servidas).

[0063] Uma modalidade pragmática do decodificador de imagem tem a primeira unidade de mapeamento de tom (403) disposta para aplicar uma função da fórmula: , na qual v é uma luma de pixel, e RHO é um (RHO-1) parâmetro com valor real ou número inteiro recebido nos dados de parâmetro (P).

[0064] Uma modalidade útil do decodificador de imagem (150) compreende uma unidade de remapeamento de tom (159) disposta para aplicar um mapeamento de tom adicional (Ff1, Ff2, ...) recebido no sinal de imagem (S_im) à imagem de faixa dinâmica mais curta (LDR_t) para obter uma segunda imagem de faixa dinâmica mais curta (LDR_ul) que inverte uma ação de redistribuição de código, aplicada por qualquer um dos métodos do codificador 5 a 7 produzindo uma segunda imagem de faixa dinâmica curto (LDR_i) com lumas redistribuídas para obter uma criação de faixas na imagem reduzida em ao menos uma região da imagem de alta faixa dinâmica reconstruída (Rec_HDR). De fato, o codificador não precisa necessariamente saber com exatidão como qualquer codificador chega a uma função de transformação específica que redistribui as lumas, o mesmo precisa apenas aplicar as funções inversas para obter substancialmente a aparência de LDR (LDR_ul) pretendida.

[0065] Uma outra modalidade útil do decodificador pode compreender codificações de Yu’v’ da imagem de LDR, e em relação à mesma, compreende uma unidade de transformação de cor (155) disposta para converter uma representação de cor de Yu’v’ em uma representação de cor de RGB. O mapeamento de tom pode ser realizado antes da conversão ser feita deixando, portanto, a conversão para RGB para a última parte da cadeia de processamento, ou alternativamente, a conversão pode ser realizada primeiramente, e um processamento de cor equivalente pode ser feito nos sinais de RGB.

[0066] Em correspondência a qualquer um dos decodificadores, os métodos correspondentes de decodificação de um sinal de imagem de alta faixa dinâmica (S_im) compreendem obter uma imagem de alta faixa dinâmica reconstruída (Rec_HDR), aplicando-se as conversões de cor codificadas nos dados de parâmetro (P) para a imagem de faixa dinâmica mais curta (LDR_t), em particular, um método de decodificação de um sinal de imagem de alta faixa dinâmica (S_im) compreende: - obter uma imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) e dados de parâmetro (P) fora do sinal de imagem (S_im); descompactar a imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c), aplicando-se ao menos uma transformação de DCT inversa à imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) para obter uma imagem de faixa dinâmica mais curta pixelizada (LDR_t); e transformar a imagem de faixa dinâmica mais curta (LDR_t) em uma imagem de alta faixa dinâmica reconstruída (Rec_HDR), mediante: a) a aplicação de um mapeamento de tom arbitrário, sendo que os parâmetros que definem o mesmo (P_CC) são recebidos nos dados de parâmetro (P), b) a aplicação de um mapeamento conforme definido por ao menos um parâmetro recebido (RHO) que define o primeiro mapeamento de tom que foi anteriormente determinado por qualquer uma dentre as modalidades de codificador ou de método de codificação, e c) a aplicação de um mapeamento de gama com um valor gama recebido (GAM), que é, de preferência, igual a 2,4. Descreve-se um sistema que permite que o classificador otimize, de modo simplesmente potente, a aparência de uma aparência de LDR em uma imagem de HDR de uma cena de HDR. De preferência, um sacrifício em relação à qualidade visual tão pequeno quanto possível é realizado, mas, uma vez que o LDR pode precisar de alguma otimização devido a suas limitações de faixa dinâmica, o sistema permite que o classificador ajuste os microcontrastes de objetos de cena interessantes para o mesmo específicos, isto é, objetos de característica geralmente importante nessa cena e, desse modo, se algum sacrifício de qualidade de brilho precisar ser feito, o sacrifica-se a aparência precisa de alguns objetos menos importantes como uma parede no fundo, em vez do objeto principal na cena. A invenção pode ser realizada de muitos outros modos (práticos) como com intermediários contendo os requisitos técnicos principais das várias modalidades como os parâmetros de definição incorporados nos sinais, e muitas aplicações dos mesmos podem resultar, como vários modos de comunicar, usar, transformar cor etc. os vários sinais possíveis, e vários modos de incorporar os vários componentes de hardware, ou de usar os vários métodos, em sistemas de consumidor ou profissionais. Qualquer componente pode, logicamente, ser realizado em ou como um componente pequeno, ou vice-versa como um núcleo-chave de um aparelho grande ou sistema que funciona predominantemente devido a esse componente.

BREVE DESCRIÇÃO DOS DESENHOS

[0067] Esses e outros aspectos do método e aparelho de acordo com a invenção ficarão evidentes e serão elucidados com referência às implementações e modalidades doravante descritas neste documento, e com referência aos desenhos anexos, que servem meramente como ilustrações específicas não limitadoras que exemplificam o conceito mais amplo.

[0068] A Figura 1 mostra esquematicamente um exemplo de uma modalidade de um codificador e um decodificador de acordo com a presente invenção, em uma tecnologia de comunicação de imagem;

[0069] a Figura 2 mostra esquematicamente uma modalidade de como pode parecer um sinal de imagem de HDR S_im de acordo com a presente invenção;

[0070] a Figura 3 elucida esquematicamente, através de uma espécie, como se pode obter, de modo genérico, uma classificação de LDR técnica, que poderia até mesmo ocorrer abaixo da cobertura automaticamente sem perturbar o classificador ou criador de conteúdo em algumas modalidades, o que permite a melhor amostragem das lumas do objeto e, portanto, reconstrução de Rec_HDR de melhor qualidade;

[0071] a Figura 4 é uma elucidação esquemática simples de um decodificador possível de acordo com a presente invenção;

[0072] a Figura 5 mostra curvas de modalidade possíveis de dois x dois para realizar o mapeamento de sensibilidade que clareia significativamente as cores, ou a classificação de LDR inicial combinada, em adição ao comportamento de gama; e

[0073] a Figura 6 é uma elucidação esquemática simples de uma unidade de conversão de faixa dinâmica possível de um codificador.

DESCRIÇÃO DETALHADA DOS DESENHOS

[0074] A Figura 1descreve um típico sistema exemplificativo que incorpora a presente invenção, com um codificador de imagem (ou vídeo) 100 em um lado da criação, e um decodificador de imagem 150. Presume-se que haja uma memória 101 em um sistema de classificação que contenha uma imagem de aparência de HDR classificada mestre (M_HDR) que foi classificada conforme desejado pelo criador de conteúdo de acordo com técnicas de classificação de cor atualmente conhecidas para, diga-se, um filme em um software de classificação de cor como, por exemplo, do Da Vinci (semelhantes a outros sistemas podem se beneficiar das técnicas no presente pedido, por exemplo, M_HDR podem ser proveniente, diretamente, de uma câmera, após, por exemplo, um ajuste de uma curva de aparência de câmera nos mostradores da câmera etc.). Nesse M_HDR, por exemplo, a claridade da luz que brilha através das janelas pode ser sido escolhida para fornecer uma aparência mais agradável na tela de referência de [0,5.000] cd/m2 ( [0,5.000] nit) ao ser fornecida a esses pixels uma luminância pretendida a ser renderizada L_out em um código de luma correspondente v_HDR, e muitos efeitos de luz adicionais podem ter sido projetados, assim como outras otimizações de cor. O M_HDR é inserido por meio de entrada de imagem 115 no presente codificador 100, e pode também ser visto em uma tela de referência de HDR 102 (cujas características exatas da tela de referência teórica, por exemplo, [0 a 5.000] cd/m2 ( [0 a 5.000] nit) são propostas para a codificação de HDR). Isso significa que, quando o classificador deseja realizar uma aparência de LDR (que não deve codificar apenas as texturas do objeto de modo suficientemente preciso, para que, no lado de recebimento uma reconstrução Rec_HDR razoavelmente precisa do M_HDR possa ser obtida, mas também, essa aparência de LDR deve ser adequada para renderizar, de modo ideal, a cena de HDR codificada em uma tela de LDR), o classificador possa comparar, ao mesmo tempo, o quanto a aparência de LDR, dadas as limitações técnicas, parece na tela de LDR 103 semelhante ao M_HDR, e possa otimizar pela alteração das funções de mapeamento de cor para obter o mesmo a partir do M_HDR conforme desejado de acordo com seu gosto. As duas telas podem estar em ambientes de visualização ideais diferentes e o classificador pode estar olhando para ambas separadas, por exemplo, por uma parede (por exemplo, em dois ambientes de referência confinados com sua respectiva abertura de janela para olhar simultaneamente as mesmas, e com cortinas que podem ser fechadas se o classificador desejar ver apenas uma delas durante algum intervalo de tempo). O graduador pode também verificar a classificação reconstruída da aparência de HDR na tela de HDR 102 (por exemplo, comutar Rec_HDR e M_HDR, alternativamente).

[0075] Por meio de uma unidade de interface de usuário 105 que oferece ao classificador controles clássicos como, por exemplo, rodas giratórias ou, semelhantemente, corrediças para definir os valores como um valor gama ou de sensibilidade, o classificador pode realizar transformações colorimétricas que definem como o M_HDR deve ser mapeado para a imagem de aparência de LDR, com os parâmetros das transformações a serem emitidas em um sinal de imagem S_im por meio de uma saída 116 do codificador que pode ser conectável a qualquer meio de transmissão de imagem 140, por exemplo, uma rede de comunicação, ou uma memória de portadora física como um BD ou memória de estado sólido etc.

[0076] A aparência de LDR é gerada por meio de uma unidade de conversão de faixa dinâmica 104, que é disposta para aplicar transformações colorimétricas ao menos nas lumas das cores de pixel, mas também geralmente nas coordenadas de cromaticidade. Por “lumas”, entende-se qualquer codificação que seja, por fim, conversível em uma luminância física, ou até mesmo por meio de modelos psicovisuais, um brilho (que é a aparência final que um espectador verá quando a imagem for renderizada em uma tela). Nota-se que, por matemática equivalente, as transformações de luma podem ser aplicadas como transformações correspondentes em componentes de RGB diretamente. Embora o objetivo final seja o brilho correto do objeto (aparências) na aparência, pode-se limitar a presente discussão técnica à determinação de luminâncias na faixa de referência, por exemplo, [0 a 5.000], ou um espaço de cores impendente de dispositivo como XYZ definido por essa faixa. Além disso, supõe-se que quaisquer transformações cromáticas das cores sejam feitas no plano UCS de espaço 1976 CIE Luv, entretanto, o versado na técnica pode compreender o quão semelhantemente outros segundos e terceiros componentes de cor podem ser usados, sendo que os componentes básicos da presente invenção são, em geral, aplicáveis.

[0077] CIELuv define u e v a partir de XYZ (semelhantemente, pode-se transformar a partir de algum RGB) como:

[0078] Supõe-se, por questão de simplicidade, que as escalas de HDR e LDR (isto é, as escalas de telas teóricas associadas à matemática de codificação das duas imagens) têm as mesmas três (ou mais) R, G, B, cores primárias, e pode, por isso, dimensionando-se a respectiva máxima de, diga-se, 5.000 e 100 cd/m2 (5.000 e 100 nit) para 1,0, ser colocalizado como exatamente sobreposto. Então, um mapeamento de tom de HDR para LDR, então, se torna uma transformação relativa ao longo da direção de luma normalizada nessa única escala de RGB dependente de dispositivo. Por exemplo, se for desejado fazer com que as cores mais escuras na aparência de HDR, sejam as mesmas na tela de LDR e de HDR, isso se torna, como uma transformação relativa na mesma escala, o seguinte: devido ao fato de que em uma definição de cores definida em 5.000 cd/m2 (5.000 nit) tais cores na imagem de HDR terão pequenos códigos (por exemplo, abaixo de 0,1), precisa-se clarear as mesmas para se tornarem suficientemente visíveis em uma tela de LDR de 100 cd/m2 (100 nit), por exemplo, com valores em torno de 0,3. O mapeamento exato irá depender da definição das lumas tanto para a imagem de LDR quanto de HDR, devido ao fato de que, como uma generalização das definições de “gama 2,2” da imagem de LDR de legado e da codificação de vídeo, pode-se, agora, definir a função de alocação de códigos arbitrária que mapeia a partir de luminâncias físicas para códigos luma (ou, do modo inverso, devido ao fato de que os engenheiros de tv começam definindo-se uma tela de referência que, além disso de um alcance de referência de [0 a 5.000] cd/m2 ( [0 a 5.000] nit) tem algum comportamento EOTF de tela de referência que indica como, por exemplo, as lumas 1024 mapeiam para as luminâncias renderizáveis ao longo desse alcance de referência). Pode-se usar não apenas uma potência de 1/(7,0) gama como OETF, como também se pode usar as funções de alocação de código descontínuas caso em uma filmagem de imagens em que não há luminâncias presentes entre um alcance inferior de luminâncias e um alcance superior de luminâncias. Nota-se também que o trabalho em uma representação de Y’uv com cromaticidades independentes de luma (u,v) permite-se trabalhar de modo totalmente independente e livre nas direções acromáticas e cromáticas de espaço de cores.

[0079] Limitando-se a presente elucidação para o leitor versado em relação aos mapeamentos acromáticos de HDR-2-LDR apenas, esses podem ser formulados de modo geral como, em princípio, uma função de mapeamento de tom arbitrária das lumas [0, 1] da imagem de aparência de HDR para as lumas [0, 1] da imagem de aparência de LDR, conforme pode ser visto com um exemplo na Figura 2a.

[0080] Especificando-se tal função, pode-se supor que o mapeamento em todas as cores (Y_M_HDR, u,v) é realizado para que para uma cor não acromática (u<>u_wp, v<>v_wp) em que (u_wp, v_wp) são as coordenadas de cromaticidade de um ponto branco escolhido como D65, a função de mapeamento de tom determinada 210 é dimensionada de modo não linear para uma luminância máxima L_max(u,v) capaz de ser obtida para essa cor, conforme ensinado em mais detalhes no documento WO2014056679. O leitor versado pode compreender como tal processamento em vez de ser aplicado em uma codificação de cor de Y’uv pode ser também, semelhantemente, realizada em uma codificação de cor de RGB.

[0081] Uma vez que o classificador especifica um comportamento de mapeamento de tom, os codificadores têm informações suficientes para uma transformação de faixa dinâmica de brilho a ser aplicada em qualquer cor possível em M_HDR, produzindo uma aparência de LDR LDR_o original (descompactada, possivelmente ainda não quantizada em uma representação de flutuação). A partir disso, qualquer transformação matemática exata ou aproximada pode ser determinada pelo codificador, o que permite que um receptor realize a predição de outro modo, de LDR_o para Rec_HDR. O graduador pode verificar por meio de uma saída de imagem 111 como tal imagem (após suficientemente formata em um sinal de imagem que pode ser comunicado através de um enlace de comunicação de imagem como, por exemplo, HDMI) pareceria em uma tela de LDR 103 de referência (diga-se, 100 cd/m2 (100 nit), ou no futuro, talvez, 500 cd/m2 (500 nit)).

[0082] Entretanto, será ensinado na presente invenção que é útil quando o mapeamento de tom não é apenas construído de qualquer maneira genérica, mas de uma maneira específica, e os (poucos) parâmetros correspondentes são codificados, de modo útil, como metadados separados no sinal de imagem S_im, devido ao fato de que os mesmos podem, então, ser vantajosamente usados em um lado de recebimento, por exemplo, durante o ajuste para derivar uma imagem de acionamento ideal para uma tela específica de X cd/m2 (X nit).

[0083] Como um primeiro parâmetro, o classificador escolherá, por exemplo, um parâmetro de sensibilidade SENS, ou RHO diretamente. Esse será um valor que é intuitivamente semelhante a valores de ASA ou ISO conhecidos na fotografia, e determinam, geralmente, quão clara a imagem de LDR parecerá (inter alia, o quanto as cores do objeto escuro de M_HDR são produzidas).

[0084] Conforme uma modalidade preferencial, o codificador pode usar uma função EOTF/OETF que já fornece uma boa aparência de LDR inicial,

[0085] cuja função EOTF é definida conforme segue:

[0086] Essa equação define as luminâncias L de HDR a serem renderizadas correspondendo os códigos luma v em [0, 1] dispersa de modo equidistante com base na quantidade de bits disponível para a palavra-código de luma das cores de pixel, como, diga-se, 1.024 valores possíveis. Lm é uma variável que pode ser escolhida que indica o pico de brilho da tela de referência da representação de cor linear/luminância de M_HDR ou Rec HDR, que pode, por exemplo, ser fixada como 5.000. Por exemplo, o classificador terá mostradores para escolher a sensibilidade que pode ser geralmente relatada para rho como:

[0087] Juntamente com o valor de SENS (RHO) que determina o comportamento de cores escuras e alguma aparência de brilho geral, o classificador pode coajustar a gama (GAM) como algum parâmetro de flexão que realoca o brilho do objeto/da região ao longo da faixa de lumas de LDR possíveis. Certamente, quando o mapeamento das luminâncias L em uma representação de espaço de XYZ de referência da classificação de M_HDR (que pode ser uma representação intermediária útil), para valores de luma v da aparência de LDR, o classificador definirá a função inversa.

[0088] Ao se realizar cálculos matemáticos elementares na divisão de RHO, pode ser visto que a função inversa (OETF) é: primeiro aplicada a uma produção de e, então, calcular:

[0089] Geralmente, no codificador pode haver uma dentre diversas modalidades possíveis de uma unidade de análise de imagem 177. Essa unidade pode estar disposta com inteligência artificial para analisar regiões na imagem, e cada uma dessas regiões poderia produzir problemas particulares em codificação de HDR, em particular, do tipo de modo ii Especificamente, a mesma pode identificar regiões que poderia estar propensa à criação de faixas na imagem, e regiões que são suficientemente texturizadas, para que as mesmas possam ser codificadas com uma quantidade menor de códigos de componente de cor e/ou luma. Em algumas aplicações, essa unidade pode automaticamente chegar a uma proposição de codificação final (por exemplo, um transcodificador) sem qualquer envolvimento de classificador humano, mas em outras aplicações pode, por exemplo, colocar as regiões sob a atenção do classificador, para que o mesmo possa examiná-las. Certamente, pode haver uma interação com a interface de usuário, por exemplo, o classificador poderia indicar que deseja atenuar uma criação de faixas na imagem com uma região particular, ou com uma textura particular e, então, a unidade 177 pode extrair tal região e seu alcance de luma etc.

[0090] Conforme pode ser visto na Figura 2, embora se possa decidir codificar uma função de mapeamento de tom final em geralmente um espaço de LUT reservado nos metadados 205, geralmente será codificado um parâmetro de sensibilidade (por exemplo, 200 ISO) ou um valor de RHO, e um valor gama (por exemplo, 2,8) em respectivamente campo de metadados de sensibilidade 202 e campo de metadados de gama 203. A Figura 2 mostra esquematicamente como uma imagem ou sinal de vídeo S_im (200) parece, e o versado na técnica saberá, certamente, que pode ser definido na prática, mas muitas variantes digitais, devido aos recipientes de dados de imagem existentes etc. As modalidades de codificador usam uma codificação de 3 componentes clássica da imagem de cor de pixel (201), que será a imagem de aparência de LDR otimizada por classificador. Essa imagem de LDR LDR_o será geralmente codificada por DCT de modo clássico, codificada por tiragem, formatada etc. de acordo com um formato de codificação de imagem padronizado semelhante a JPEG, ou um formato de codificação de vídeo padronizado semelhante a MPEG-HEVC, VP1, etc. O leitor versado na técnica irá entender que reformatar de modo colorimétrico para ser capaz de reutilizar tecnologias de codificação legada (ou futuro similar) como um conceito genérico faz parte desta invenção, mas não é tão importante que tais codificações sejam, de fato, usadas. E uma outra parte desta invenção são os metadados necessários para serem coerentes com os dados, por exemplo, ao menos quando recupera a Rec_aparência de HDR da cena (devido ao fato da aparência de LDR pode, em teoria, ser usada diretamente para acionar uma tela de LDR, com nenhum processamento dinâmico de alcance adicional, mas apenas mapeamento de redefinição colorimétrica de Y’uv para algum dispositivo dependente de codificação de espaço de RGB).

[0091] Além disso, o classificador pode usar um valor de ganho (co-codificado em um campo de metadados de ganho 204) para que as funções não precisem mapear por si só 1,0 a 1,0. Por exemplo, o ganho pode indicar como uma imagem de LDR que é definida através da faixa completa [0,1] deve ser mapeada de, diga-se, apenas um [0,1500] subalcance d [0,5000] alcance da tela de HDR. A outra maneira de limitar a faixa de LDR usada também é, a princípio, possível, embora tenha menos probabilidade de ser usada. Esse ganho pode ser usado para produzir algumas imagens não muito claras, conforme se pode imaginar se a cena for, por exemplo, uma cena nebulosa, ou uma imagem escura que é razoavelmente clareada em LDR, mas precisa permanecer escura em HDR.

[0092] Esses três parâmetros (RHO, GAM, GAI) já fornecem um primeiro mapeamento muito útil de uma imagem de M_HDR para uma imagem de aparência de LDR correspondente, com um ajuste de iluminação ou brilho praticamente global. Isso pode, por exemplo, ser suficiente para difundir shows da vida real, em que os parâmetros ideais são determinados logo antes do início da difusão. Usuários mais críticos como produtores de filme, podem desejar um controle melhor ajustado sobre a aparência. Os mesmos podem desejar especificar uma função de mapeamento de tom mais amplo que aquele “loggama” acima, com dobras bem posicionadas na curva que pode aumentar, por exemplo, o brilho ou contraste local médio de um objeto particular (por exemplo, uma face) para um subalcance desejado de todas as luminâncias de LDR renderizáveis (ou mais precisamente, suas lumas correspondentes). Ou uma especificação de uma inclinação local pode especificar o contraste desejado em algum subalcance BL interessante de uma região importante na imagem, no custo de posições e contastes de brilho de outras regiões/objetos na imagem de aparência de LDR.

[0093] Agora, uma questão importante que se deve entender é que, com o sistema de modo-i (aparência de HDR), o classificador pode definir tais mapeamentos de modo arbitrário, devido ao fato de que se precisa apenas derivar uma imagem de aparência de LDR (que não é reconstrução, mas pode ser feita por destruição de dados, se assim desejado pelo classificador), devido ao fato de que nessa abordagem de codificação tem-se a imagem de aparência de HDR já codificada como imagem única no sinal de imagem S-im. Em sistemas de modo-ii, no entanto, é necessário cumprir um critério duplo: por um lado, deve-se ter a capacidade para reconstruir a imagem de Rec_HDR com qualidade boa, mas, por outro lado, deseja-se uma liberdade suficiente para criar a maior parte, se não todas as aparências de LDR que um classificador pode desejar (e, então, pode ser bem criativo em alguns momentos, conforme um indivíduo pode ver, por exemplo, no filme Sin City 2).

[0094] Mas deve-se entender que qualquer que seja a classificação LDR_o, o classificador foi feito com seu mapeamento de tom preferencial 210, em uma codificação legada essas lumas de LDR de saída serão submetidos à quantização uniforme clássica (e mesmo fazendo-se DCT). Então, é preciso ter cuidado para não criar mapeamentos que são muito planos em algumas partes de seu alcance (isto é, o derivativo local delta_LDR_out/delta_HDR-in não deve ser muito pequeno, para que uma quantidade mínima exigida de códigos luma de LDR seja alocada para aquele alcance delta_HDR-in ou o delta_LDR_out correspondente), devido ao fato de que, de outro modo, quando se reforça essa faixa no mapeamento de tom LDR-2-HDR, serão visualizados artefatos, como criação de faixas na imagem ou artefatos de DCT visíveis e com contraste excessivo.

[0095] Poderia se ter um mecanismo de controle com uma rigidez dos pontos de controle locais que o usuário usa para alterar o formato do mapeamento de tom arbitrário, mas que é desagradável para o usuário, especialmente se implantado de modo muito adverso (certamente, o sistema pode avisar se o classificador está esperando para realizar curvas de mapeamento muito insólitas, por exemplo, inversões como uma curva em N não devem ser feitas).

[0096] Uma modalidade útil é mostrada na Figura 3, que elucida o comportamento de uma unidade de mapeamento de tom técnico 106, que pode ser usada para determinar uma segunda aparência de LDR, alternativamente útil para LDR_o por receptores mais inteligentes que precisam auxiliar uma tela de LDR.

[0097] Assume-se que o classificador escolheu sua curva desejada que fornece a aparência de LDR apropriada, que é a curva sólida na Figura 3. Se a curva de mapeamento de tom não for boa, isso significará que há ao menos uma faixa que é muito plana, que se assume no presente documento que seja a parte R-u do HDR com mais brilho de pixels de LDR, diga-se o céu da cena. É necessário ser possível estender essa faixa L_u em LDR, para que um pouco mais de códigos luma possam ser alocados, e de uma maneira tanto não destrutiva (pouca alteração em sua aparência) a quando possível para o classificador.

[0098] Isso pode ser feito quando há uma faixa adjacente L_uu que contém objeto mais texturizado.

[0099] Esta é uma saída do enigma de que a curva de aparência para adquirir uma aparência de LDR desejada ao mesmo tempo determina a quantização ou número de códigos luma disponíveis para codificar de modo fidedigno as diversas texturas de região de HDR (a caracterização fiel suficiente de todas as texturas que estão na cena que são o objetivo primário de qualidade de codificação em codificação de HDR). Ter 1024 níveis de luma/cinza diferentes (e milhões de códigos) deve ser suficiente para codificar bem todas as texturas para a visão humana, se bem feito. Objetos complexos podem ser codificados com relativamente menos códigos, visto que o olho visualiza primeiro o padrão de textura áspero e, em seguida, não tanto os valores precisos das cores de pixel. Apenas em situações desfavoráveis particulares pode-se ter uma questão, se houver gradientes de brilho para os quais foram usados muitos poucos códigos.

[00100] Então, existem duas coisas quando se adapta uma curva: a unidade de mapeamento de tom técnico 106 geralmente mantém a adaptação quando necessário de modo suficientemente local no eixo de luma, para que não haja desorientação das lumas de muitas cores de objeto (por exemplo, evitar novamente escurecer muito as regiões escuras críticas). Um critério de qualidade para essa cena exemplificativa pode ser que seja necessário clarear as cores escuras para conseguir uma boa aparência de LDR, então, uma alteração local nas cores claras não irá desorientar a mesma de nenhuma maneira. Então, o mapeamento de tom unidade 106 geralmente redistribuirá os códigos na mesma subalcance de luma local em torno da área de problema e determina uma curva de adaptação correspondente para isso, que é a linha pontilhada (essa curva pode seguir de algum modo o formato da curva original, em suas duas partes de codificação de região de imagem, isto é, se houvesse um formato de local de inclinação de modo parabólico para as lumas de céu, pode geralmente usar um segmento parabólico de inclinação semelhantemente maior, em escala para o ar, mas que não é absolutamente necessário, visto que apenas precisão de codificação é o critério).

[00101] Então, precisa-se estender o alcance de brilho da região do céu de algum modo, para ter códigos suficientes para codificar fielmente um gradiente de céu azul Rec_HDR. Mas quanto é necessário fazer e o quanto a faixa de ajuste R_Adj pode ser estendida?

[00102] Isso depende de diversas coisas. Certamente, R_adj deve-se cobrir a região na qual há um problema, que será geralmente uma região de aparência relativamente simples, como regiões relativamente uniformes como um gradiente no céu (esse gradiente azul existirá de alguma forma ao longo da faixa de luma de LDR). Por outro lado, deve-se precisar de uma região adjacente que é suficientemente texturizada. Na situação improvável de que a região adjacente é ainda outro gradiente suave (que poderia ocorrer em imagens sintéticas, como imagens de teste de gradiente artificial, as quais terão que ser satisfeitas com qualquer alocação de luma ideal que houver, mas isso não ocorre geralmente em imagens naturais), R_adj pode se tornar relativamente grande. Na situação normal na qual será encontrada uma faixa texturizada que possa estender L_u com uma faixa L_uu de um tamanho que depende de quantos códigos foram adicionados e a complexidade do padrão de textura. Se for preciso adicionar apenas 3 códigos para o céu, precisa-se salvar 3 códigos luma em L_uu e se for texturizado o suficiente, poderia ser feito além de uma faixa de ay 10 a 15 lumas, dependendo do que o classificador ou o espectador acha/pode achar aceitável.

[00103] O aparelho pode conter tabelas para isso.

[00104] Então, o problema desagradável com codificação de luma dependente de curva de aparência é agora amplamente solucionado. Por um lado, não se escurece os objetos mais escuros adjacentes muito severamente, visto que apenas altera-se as cores de L_uu um pouco na faixa superior expandindo-se a faixa de céu L_u, mas em grande parte, mantém- se a parte inferior de L_uu a mesma, apenas amostrado um pouco menos, que não é uma questão visualmente notável de qualquer forma, devido ao fato de que as texturas não precisam de tantos códigos de qualquer maneira. A faixa de céu ampliada pode ser um pouco subideal, mas não deve realmente ser um problema, e adquire-se uma qualidade aprimorada Rec_HDR, em contrapartida. Porém, isso só ocorre se não for tomada qualquer ação contrária na extremidade de recebimento, por exemplo, por um receptor que não pode realizar qualquer processamento. Devido ao fato de que no decodificador pode-se realizar uma estratégia de pré-compensação na unidade de remapeamento de tom 159. Isso, então, tornará a alocação de luma uma matéria puramente técnica que não é de interesse das intenções artísticas do classificador. Devido ao fato de que a unidade de recapeamento de tom 159 irá aplicar a correção para a extensão local em uma compressão novamente, antes de usar a aparência de LDR pretendida resultante (LDR_ul) para, por exemplo, acionar uma tela de LDR. Então, no exemplo do céu, em que, estendendo-se o limite inferior de céu de L_u para baixo no brilho de objetos na faixa adjacente L_uu (escurecendo-se, desse modo, esses objetos), a unidade de recapeamento de tom 159 de um decodificador 150 aplicará o mapeamento inverso de 301 como uma correção. Isso significa que, visualmente a faixa de céu terá sua faixa de luma original L_u novamente e, quando renderizada em uma tela de LDR, a faixa de luminância correta, ainda que a mesma tenha mais precisão devido ao fato de que foram alocados mais códigos luma de codificação de textura. De modo similar, na aparência LDR_ul, o objeto com brilho adjacente em L_uu também terá o brilho sem regulação correto, e apenas se difere em precisão devido à quantidade reduzida de códigos. E o versado na técnica pode entender como essa técnica pode sempre, nas diversas outras situações possíveis, aprimorar a precisão de codificação nessas regiões de uma imagem onde necessário, na medida em que mantém a aparência de LDR prevista LDR_ul do classificador. A única coisa que a unidade de recapeamento de tom 159 precisa ser capaz de fazer é aplicar uma estratégia de mapeamento de tom para o LDR_t técnico codificado, por exemplo, por meio de um LUT, que pode ser co-codificado no sinal S_im (ou parcialmente codificado se o mapeamento de tom puder ser derivado de, por exemplo, um conjunto limitado de pontos de controle, por exemplo, delimitar segmentos lineares) e, consequentemente, deve ser claro o porquê o mesmo é vantajoso para codificar essa função de ajuste técnico separadamente (Ff1, Ff2,...) em S_im, devido ao fato de que o mesmo pode ser usado pelo decodificador mesmo para adquirir uma aparência de LDR mais desejável LDR_ul, uma vez que o mesmo foi determinado no lado da criação e aceito pelo classificador e comunicado para um lado de recebimento.

[00105] Haverá amplamente duas categorias de modalidades de codificador que possibilitarão o descrito acima. A primeira faz amplamente todo o processamento automaticamente, e não precisa envolver o usuário. Os detectores de suavidade e textura categorizarão automaticamente as diversas regiões e, então, identificarão o padrão de gradiente no céu e os objetos localizados de modo adjacente (isto é, na faixa de luma localizado abaixo e/ou acima L_u) outros objetos texturizados. Diversos caracterizadores de textura podem ser embutidos para determinar a complexidade da textura (por exemplo, sem grânulos finos, quantidade de valores de cinza interligados etc.) e determinar, a partir disso, como as interferências visualmente notáveis que levam a menos lumas de codificação serão, e a faixa L_uu necessária resultante. Conforme mencionado, essas preferências podem ser pré-embutidas nas fórmulas que determinam a funcionalidade de L_uu ou com LUTs. Além disso, em algumas modalidades, DCT ou outros emuladores de compressão podem estar presentes, por exemplo, que calculam as imagens descomprimidas resultantes de LDR LDR_d mediante diversas escolhas para R_adj e o formato de distúrbio de mapeamento de tom funcional 301, e calculam uma medição severa para a visibilidade típica (em alcance de visualização normal, tamanho de tela, brilho circundante, etc.) da criação de faixas na imagem e /ou outros artefatos de compressão. A unidade de análise de textura 117 pode estar presente para isso, que está geralmente disposta para analisar texturas e, em particular, seu impacto de aparência, tanto no original (LDR_o) quanto no codificado LDR_c, ou no fato de que a decodificação do mesmo LDR_d que, em última instância, estará presente na extremidade de recebimento. Especificamente, os remapeamentos para HDR por unidade de mapeamento de cor LDR-2- HDR 118 podem ser usados para possibilitar que o classificador verifique o impacto de aparência, se necessário. Se o classificador desejar verificar a capacidade de reconstrução desse M_HDR como Rec_HDR, o mesmo pode, por exemplo, comutá- los ao mesmo tempo em sua tela de HDR 102, por meio de saída de imagem de HDR 119. De fato, o decodificador pode ter diversas saídas (que foram mostradas separadas, mas certamente as mesmas podem ser roteadas internamente para apenas uma saída) 111, 112, 113, 114 para ser capaz de verificar as diversas versões de LDR.

[00106] Uma segunda categoria de codificadores com reclassificação técnica pode envolver diretamente o classificador humano. Se o mesmo já estiver verificando a qualidade dos algoritmos automáticos, ele pode ter uma opção para influenciar os resultados (isto é, geralmente semiautomaticamente). Isso deve ser simples para o classificador, pois ele pode desejar estar mais envolvido com a determinação artística da aparência, isto é, a colocação das lumas de objeto, em vez de questões técnicas, como artefatos de compressão (se já estiver aguardando para olhar para os mesmos, e embora o mesmo vá verificar um ou mais cenários típicos e aprovados, a linha de comunicação de imagem pode ser, certamente, compressões adicionais que poderiam ter mais artefatos severos).

[00107] Nessas modalidades de codificador, a unidade de interface de usuário 105 geralmente permitirá que o classificador especifique áreas de imagem geométrica que, de acordo com o mesmo, são áreas particularmente problemáticas. Por exemplo, ele pode rabiscar através do céu, e as unidades de análise de histograma e de análise de textura, então, focalizarão essa parte da imagem quando realizarem suas análises e a determinação de curva de mapeamento de tom parcial de atualização técnica. Por exemplo, os mesmos podem propor de modo sucessivo uma estratégia que adiciona alguns códigos luma a mais em um momento para o céu, até que o classificador esteja satisfeito. Por exemplo, um algoritmo de modalidade da unidade de mapeamento de tom 106 pode multiplicar essa faixa do objeto de gradiente (sensível a criação de faixas na imagem) por k= por exemplo, 1,5 e selecionar uma faixa próxima de uma região de imagem texturizada e compactar a mesma para L_uu-1,5*L_u. Isto é, qualquer redistribuição curvilínea ou linear dos códigos nas duas regiões pode ser usada. O L_uu pode ser selecionado para ser ao menos por exemplo, 3*L_u, no qual os valores são geralmente otimizados por um projetor de aparelho na base de um conjunto de imagens representativas. Se a proposição pelo aparelho for boa, o classificador aceita a mesma, fazendo o codificador armazenar os parâmetros correspondentes em S_im ou, de outro modo, uma nova iteração é iniciada, por exemplo, com k=1,1*1,5.

[00108] A perturbação 301 irá levar a um mapeamento de tom final, que corresponde a uma classificação técnica final LDR_i, a qual será a aparência de LDR que é enviada no sistema de comunicação após formatação adicional de acordo com o sistema de codificação de HDR de modo-ii e que corresponde amplamente ao que o classificador deseja como aparência de LDR.

[00109] A vantagem do envolvimento do classificador reside em que ele pode indicar - ao menos com um mínimo de envolvimento - quais regiões são semanticamente mais relevantes. O analisador de textura estatística pode determinar que poucas lumas (isto é, poucos pixels) de fato existem em uma região entre por exemplo, as lumas escuras de ambientes internos, e as lumas de brilho dos ambientes externos ensolarados, e consequentemente, decide aplicar uma estratégia de remapeamento que aplica poucos códigos no mesmo (no caso, o remapeador de decodificador 159 pode reconstruir de modo arbitrário a aparência de LDR desejada, pode-se até mesmo usar uma curva de deformação técnica forte que quase corta todo o subalcance usado de modo limitado da codificação de LDR_i tornando, desse modo, imediatamente adjacente em LDR_i luma valor os ambientes internos e subalcances externos). Entretanto, se nessa região pequena houver um objeto importante, como a face de alguém ou um objeto que foi enfatizado de algum como como um objeto aparecendo, o classificador pode se contrapor ao mesmo. Diversas modalidades práticas são possíveis, por exemplo, o mesmo pode rabiscar no desenho um retângulo ao redor dessa região e, então, gira um mostrador que aumenta a quantidade de códigos luma a serem usados para aquela região. O leitor versado na técnica entenderá que há diversas outras maneiras da interface de usuário selecionar uma região ou objeto importante na imagem ou foto, e para indicar como os mesmos devem ser codificados com lumas, mesmo até o classificador que desenha ou influencia o formato da própria curva de modificação 301.

[00110] O resto do sistema de modo-ii é como segue:

[00111] Opcionalmente, a unidade de conversão de faixa dinâmica pode realizar algum processamento de saturação de cor (por exemplo, visto que a coloração diminui com o escurecimento e vice-versa, o classificador pode desejar compensar a saturação que se tornou, de algum modo, inapropriado devido ao mapeamento de tom de luma). Uma boa modalidade exemplificativa prática funciona com uma função de saturação geral do tipo destrutivo de não informações. Isso significa também que essa função de saturação é, em alguma parte, muito plana, então, a mesma também pode ser revertida. Mas, em algumas modalidades, a função de saturação pode precisar ser apenas aplicada na atualização de LDR-2-HDR, e então, pode ser mais liberal. Na Figura 3, mostrou-se uma saturação suave de s_in para s_out, que pode ser codificada com inúmeros valores S1, S2, S3 em um LUT no sinal S_im. Esses podem ser os valores de s_out para valores de s_in equidistantes (uma quantidade suficiente para que a curva desejada possa ser razoavelmente recuperada de modo suave no decodificador), mas isso também seria, por exemplo, pontos de controle em formato de função. Uma função de dessaturação pode, por exemplo, ser codificada como uma linha com decline menor que 45 graus (em um gráfico de s_in em função de s_out). Em tal caso de dessaturação, o sinal de imagem poderia ter apenas um valor inteiro ou oscilante para o multiplicador nos metadados. Supõe-se no exemplo de elucidação, que s_out será a saturação da imagem de HDR, e precisa-se reforçar a saturação das cores mais escuras, agora escurecidas, da cena para aumentar o colorido, mas o versado na técnica pode compreender que pode haver diferentes variantes de processamento na mesma filosofia de codificação estrutural. Supõe-se, por questão de simplicidade de elucidação, que a saturação seja realizada no espaço de uv, por exemplo, independente da luma, pode-se realizar a operação s_out = s_in+MS(s_in)*s_in. O MS(s_in) é, então, o valor multiplicador recuperável da função, conforme visto na 2b e codificado em LUT 206, que estira o vetor de saturação em uma direção de matiz em comparação com algum ponto branco. Supõe-se, por questão de simplicidade, que foi definido o presente espaço de uv em um espaço cilíndrico com a saturação máxima na periferia (e codificado como 1,0). Logicamente, o versado na técnica entenderá que pode-se codificar a presente estratégia de saturação em uma outra definição colorimétrica, ou dado que a definição é, por exemplo, no espaço de Y’uv cilíndrico, o designer do hardware ou software de decodificador pode escolher realizar, de fato, a mesma de modo equivalente em um outro espaço de cores, como o espaço de YCrCb baseado em RGB, etc. O classificador pode também determinar e codificar, em S_im, estratégias de saturação dependentes de luma, isto é, funções que alteram a saturação, cujo multiplicador varia com a luminância da cor processada. Basicamente, uma modalidade mais avançada de S_im terá uma estrutura de codificação de saturação. Isso pode ser, por exemplo, uma definição baseada em web que tem inúmeras matizes chave (por exemplo, os 6: RGBCYM) uma função de multiplicador definida sobre luma: MS(Y’). A partir disso, o que pode ser codificado como 6 LUTs de valores semelhantes a 206, na extremidade de recebimento, o decodificador pode determinar uma estratégia de saturação para todas as cores na escala por meio de interpolação. Uma estratégia mais complexa pode, até mesmo, introduzir variabilidade da saturação na direção radial. Esse pode ser facilmente codificado ao se determinar essas funções (semelhante àquelas vistas em Figura 2b, mas, agora, variáveis sobre a altura da luma na escala) de modo simplesmente paramétrico, por exemplo, como funções de deslocamento, gama, ganho. Nesse caso, tem-se: s_out = s_in+F(s_in, Y’) para as matizes chave, e, por exemplo, no caso de um controle de formato de função de três parâmetro, pode-se codificar em S_im tanto como 3x6 LUTs que especifica o comportamento de luma de, por exemplo, o parâmetro de saturation_gamma como variante sobre Y’, ou 6 LUTs para as matizes, mas onde nem um único valor multiplicador é codificado em cada posição, mas um trio [sat_offset(Y’_i), sat_gain(Y’_i), sat_gama(Y’_i)]_LUT_of_yellow, consecutivamente através de inúmeras posições i que amostram as possíveis lumas na escala.

[00112] Agora, em algumas modalidades de um codificador (e decodificador correspondente), há uma transformação opcional para u’v’ para as características de cor dos pixels, que serão, agora, elucidadas (mas, outras modalidades podem, alternativa ou adicionalmente codificar, por exemplo, em R’G’B’ ou YCrCb etc. diretamente, e não têm, ao menos, a unidade opcional 107 no lado de dentro; Nota-se também que para alguns Yu’v’ o processamento pode ser matematicamente reescrito como processamento de RGB linear equivalente).

[00113] Tendo-se aplicado à transformação de faixa dinâmica para criar a aparência de LDR correta (por exemplo, no espaço de RGB, ou XYZ etc.), supõe-se que o mapeamento ainda não tenha sido feito no espaço de Y’uv, a unidade de transformação de cor 107 da modalidade de elucidação exemplificativa não fará a conversão para a presente representação de u’v’, sendo que as lumas Y’ nessa representação de cor são determinadas pela presente função de mapeamento de tom total (isto é, as lumas de imagem de LDR intermediárias LDR_i), e u, v conforme para as equações acima. Podem ser realizadas, também, transformações colorimétricas na unidade 107, que condicionam as cores já quando um RGB dependente de dispositivo diferente ou espaço multiprimário é previsto. Por exemplo, se o presente M_HDR foi codificado com um triângulo de RGB menor, mas o LDR é para uma tela com ampla escala, o classificador já pode predefinir uma estratégia de reforço de saturação, embora as coisas, frequentemente, fiquem invertidas, em cujo caso, a unidade 107 pode implementar um mapeamento de escala cromática.

[00114] Por fim, o LDR_uv resultante é codificado com uma imagem de LDR clássica ou compactador de vídeo 108, isto é, geralmente DCT ou transformado por ondeletas etc.

[00115] Essa imagem LDR_c compactada é enviada para um formatador 116, que adiciona os metadados na função de mapeamento aplicada de acordo com um formato padronizado, para que esteja adequadamente disponível em um lado de recebimento. Isto é, esse formatador auxilia o valor de sensibilidade (RHO ou alternativamente, SENS), a mapear por tom adicionalmente para o ajuste da aparência de LDR conforme determinado normalmente pelo classificador humano (embora, no futuro próximo, alguns codificadores possam ser inteligentes o bastante para realizar, por si próprios, o ajuste) com parâmetros de definição de função 205 geralmente como um LUT de valores (F1, F2, ...), a codificação de saturação 206, por exemplo, também, um conjunto de parâmetros que definem uma função multilinear etc.

[00116] O mapeamento de tom adicional, por razões técnicas, é geralmente armazenado separadamente na imagem ou sinal de vídeo S_im, de preferência, como um conjunto de valores inteiros ou reais 207, que podem ser usados para armazenar, por exemplo, um LUT de 256 pontos ou de 1.024 pontos.

[00117] O LDR_c codificado pode ser decodificado novamente para LDR_d, e então, atualizado pela unidade de mapeamento de cor 118 para que o classificador possa ver por meio da saída de imagem 119 como o Rec_HDR de HDR reconstruído se pareceria em uma extremidade de recebimento. Se o mesmo desejar, poderia, até mesmo, testar a influência de algumas típicas definições de compactação, por exemplo, até a forte compactação. O decodificador descrito aqui poderia também ser usado em uma estratégia de recodificação, em que a aparência de classificação pode já ter sido preparada anteriormente, mas, agora, por exemplo, uma versão de LDR altamente compactada de baixa qualidade é determinada novamente para algum aplicativo específico de comunicação de imagem/vídeo. Esse classificador secundário pode, até mesmo, reajustar os parâmetros. Dependendo da possibilidade do mesmo ter o M_HDR original disponível, o mesmo pode, por exemplo, determinar novamente as funções de desvalorização para obter uma nova aparência de LDR mais adequadamente ajustada (por exemplo, que serve os espectadores de telefone móvel), e, de fato, o mesmo pode até fazer isso quando tem apenas o bom Rec_HDR disponível em vez de M_HDR. A separação de uma parte de classificação técnica para alocar mais adequadamente os códigos luma é muito útil para tais cenários. Devido ao fato de que as funções que mapeiam o LDR_o (e a LDR_ul de reconstrução próxima correspondente do mesmo) determinam a aparência artística real de LDR, as mesmas podem ter sido determinadas de uma vez por todas pelo classificador primário no momento ou perto do momento da produção inicial do conteúdo. Mas, o codificador ainda pode automatica ou semiautomaticamente, com o envolvimento do classificador secundário, determinar o mapeamento técnico com as pequenas modificações como 301, e o LDR_i (ou LDR_t) correspondente, e os metadados codificados Ff1, Ff2, no conjunto de valores reais ou inteiros 207 em S_im, que pode, logicamente, ser diferente para diferentes limitações tecnológicas, como a quantidade de bits (por exemplo, apenas 8 bits para o canal de luma).

[00118] O decodificador 150 pode ser um CI em, por exemplo, como nessa elucidação, um decodificador de sinal ou computador conectável a uma tela 160 ou televisão (então, quando se diz decodificador inventado para cobrir qualquer pequena realização do mesmo como um “decodificador de sinal em um bastão de USB” ou qualquer realização de aparelho grande e se beneficia da presente invenção como um decodificador de sinal com instalações de leitura de disco rígido e disco óptico, e o codificador pode ser qualquer coisa dentre um pequeno dispositivo até um grande sistema de classificação etc.), mas, logicamente, a televisão pode não ser um monitor limitado, mas compreende toda essa tecnologia de decodificação em seu próprio CI. A tela 160 pode ser tanto uma tela de LDR quanto uma tela de HDR, ou basicamente, qualquer tela conectada por meio de qualquer tecnologia de comunicação de imagem por meio de saída de imagem 157, como, por exemplo, fluxo contínuo sem fio para um dispositivo multimídia portátil ou um projetor de cinema profissional.

[00119] O decodificador obtém a presente S_im formatada por meio da entrada de imagem 158, e um desformatador 151 irá, então, separar a mesma em uma imagem LDR_c (IMG na Figura 2) para descompactação por um descompactador do tipo JPEG ou do tipo MPEG clássico 152, e os parâmetros P dos metadados (por exemplo, uma definição de sensibilidade 1.000, e alguns valores que podem ser usados para reconstruir um formato funcional de mapeamento de tom ou mapeamento de saturação). Opcionalmente, no decodificador está a unidade de recapeamento de tom 159, devido ao fato de que uma vez que esse remapeamento técnica é normalmente não uma deformação grava da aparência de LDR LDR_ul pretendida pelo classificador, alguns decodificadores podem suportar ou ignorar a mesma. Os decodificadores totalmente compatíveis com HDR devem, entretanto, usar essa unidade 159 para aplicar uma estratégia de nova correção técnica conforme codificados nos valores de Ff 207, para chegar à aparência de LDR LDR_ul corrigida (que é uma aproximação próxima de LDR_o). Essa imagem de LDR (LDR_ul) corrigida é direcionada a uma unidade de ajuste de cor de tela 154 adicional. Essa unidade 154 pode aplicar a otimização necessária para uma tela de escala ampla específica, diga-se, 1.300 cd/m2 (1.300 nit) (ajuste). Embora as variantes sejam possíveis, projetou-se um típico decodificador para a presente filosofia de codificação de HDR, que tem uma trajetória de processamento de imagens para recuperar o LDR_ul (ou se 159 não estiver presente, sua aproximação LDR_t), mas também tem uma segunda trajetória de processamento de imagens para determinar o Rec_HDR. Isso é realizado na unidade de conversão de faixa dinâmica 153, que geralmente se aplica aos mapeamentos inversos aplicados no codificador (de fato, no sinal um codificador irá geralmente codificar os parâmetros desse mapeamento inverso, isto é, uma atualização). A unidade de ajuste de cor de tela 154 será geralmente disposta para combinar as informações nas duas classificações, que poderiam ser realizadas com base no uso de apenas uma imagem e dos parâmetros de mapeamento de cor P, mas supõe-se, nessa modalidade de elucidação, que se obtém uma imagem de Rec_HDR e LDR_ul como entrada e, então, interpola-se aqueles, de acordo com qual tela com qual pico de brilho está conectada para ser fornecida com as imagens adequadamente classificadas.

[00120] Com exceção do mapeamento de tom para obter a aparência de brilho correta, uma unidade de transformação de cor 155 pode, geralmente, ser compreendida disposta para realizar adaptações cromáticas para otimizar para uma escala de cor diferente da escala de codificação (por exemplo, Rec. 2020 para DCI-P3 ou Rec. 709 etc.).

[00121] O que será produzido por meio da saída de imagem 157 e, por isso, calculado pela unidade 154, logicamente, dependerá da tela conectada. Se a mesma for uma tela de LDR, a unidade 154 pode enviar, por exemplo, LDR_ul, após, logicamente, o remapeamento de cor correto (pela unidade 155) a partir da codificação de Y’uv para uma codificação de R’G’B’ dependente de dispositivo específico, por exemplo. Se a tela 160 conectada estiver próxima de uma tela de pico de brilho de 5.000 cd/m2 (5.000 nit) (consultar, também, o fato de como o aparelho de decodificação pode perguntar a uma tv suas capacidades no documento WO 2013/046096; um controlador 161 pode realizar tal comunicação com a tela e até mesmo com o espectador para obter suas preferencias, e pode estar disposto para configurar como a unidade de ajuste de tela 154 deve se comportar e qual tipo de aparência de imagem o mesmo deve calcular e produzir) a imagem de aparência de Rec_HDR pode ser produzida, novamente após a formatação adequada de acordo com o que a televisão deseja receber (isto é, isso ainda pode ser uma codificação de Y’uv, por exemplo, o presente formato de S_im com, agora, uma imagem de aparência de HDR armazenada em 201/IMG, e alguns metadados funcionais podem também ser transmitidos para que a televisão possa realizar algum último ajuste colorimétrico de aparência com base nas informações sobre como a alteração de classificação através do espectro de possibilidades de renderização conforme codificado nesses metadados, ou pode já ser uma imagem de acionamento de tela de HDR de R’G’B’). Para telas com pico de brilho intermediário, a unidade 154 pode produzir uma imagem de acionamento adequada, novamente no presente formato de Y’uv ou em um outro formato.

[00122] Por fim, o criador de conteúdo pode descrever no sinal se o mesmo deseja que a mapeamento por compensação de unidade 159 não seja pulado, por exemplo, devido ao fato de que o criador de conteúdo acha que LDR_t se desvia seriamente de LDR_ul. Isso pode ser feito mediante a codificação de um Boolean 209 em um campo dos metadados de IGNORE_TECHNICAL_MAPPING.

[00123] Deve ficar claro para o leitor que onde foi elucidado apenas o mínimo de um conjunto de parâmetros, certamente, ao longo dos mesmos diversos conjuntos racionais de metadados funcionais de mapeamento de cor podem ser codificados em S_im, por exemplo, um conjunto para ir da imagem única IMG (que é uma imagem de LDR) para uma referência, por exemplo, uma imagem de aparência de [05.000] nit HDR, e um segundo conjunto pode ser adicionado para ir para, por exemplo, uma aparência de MDR de 1500 nit. E, embora o fato de realizar uma decomposição específica de um formato de função uma sensibilidade, gama, ganho e ajuste adicional seja vantajoso, e ao menos bom para elucidação técnica, qualquer um dos mapeamentos, por exemplo, o mapeamento LDR-2-MDR pode ser codificado em S_im em uma forma condensada, por exemplo, preenchendo, apenas, o mapeamento de tom LUT ou conjunto de valores 205, que codifica a função de mapeamento final (isto é, todos juntos, sensibilidade, ajuste e mapeamento técnico).

[00124] A Figura 4 mostra esquematicamente uma típica modalidade da presente unidade principal de decodificador 400 (nesse exemplo, a parti mínima de modo ii, sem relação técnica ou conversão de Yu’v’ etc.). Após um descompactador 401 fazer o comprimento de execução e a decodificação aritmética, e DCT inversa etc., obtém-se uma imagem LDR_t, que se supõe estar em representação de gama 2,2. (isto é, com lumas ou componentes R’G’B’ definidos de acordo com Rec. 709) e normalizada. Pode haver uma primeira unidade de controle 420, que pode enviar diretamente essa imagem para uma LDR TV conectada 410 (que significa diretamente que pode haver, logicamente, alguma formatação de legado envolvida; a princípio, LDR_t poderia também ser, por exemplo, uma imagem linear, em cujo caso haverá uma necessidade de mapear por re- gama-2,2 a mesma antes de enviá-la para a tela de LDR, mas pode ser vantajoso se não for necessário; as funções de mapeamento de tom adicionais serão geralmente diferentes dependendo de qual tipo LDR_t é, o que pode também ser indicado com um indicador IND_2 em S_im). Então, uma primeira unidade de mapeamento de tom 402 realiza o mapeamento inverso do mapeamento de tom arbitrário, sendo que os parâmetros definidores desse formato de função P_CC são recebidos nos metadados MET(F). Então, uma segunda unidade de mapeamento de tom 403 realiza um mapeamento de tom escurecendo novamente as cores mais escuras em relação àquelas mais brilhantes, por exemplo, aplicando-se a equação de rho acima, com um valor de RHO recebido. A unidade poderia também calcular o valor de RHO a partir de um pico de brilho de tela recebido PB_HDR, recebido da tela de HDR 411 conectada. Em seguida, uma terceira unidade de mapeamento de tom 404 realiza uma função de potência gama com um valor GAM recebido que é, por exemplo, 2,4, de preferência. Em seguida, um multiplicador 405 pode realizar uma multiplicação com GAI, que, por padrão, pode ser 1,0. Opcionalmente, um processador de saturação de cor 406 pode realizar algum processamento de saturação. Por fim, a unidade de controle 421 pode enviar a imagem para a tela de HDR 411, e a mesma pode realizar algum processamento adicional, por exemplo, para formatar corretamente a imagem de acordo com um padrão que a tela compreende, por exemplo, através de uma conexão HDMI.

[00125] A Figura 6 mostra uma modalidade de unidade de conversão de faixa dinâmica de codificador simples. A mesma compreende uma unidade de normalização 601 para normalizar todos os componentes de cor para 1 (isto é, se, por exemplo, R, G e B forem normalizados para 1,0, então, a luminância máxima será normalizada para 1,0, e vice-versa). As luminâncias normalizadas Yn_HDR de pixel de imagens de HDR (ou em modalidades equivalentes, por exemplo, os componentes de RGB lineares normalizados) vão para um primeiro mapeador de tom 602 que realiza uma operação gama, com um gama conforme desejado pelo classificador (ou unidade de classificação automática), mas, por fim, fixa a 1/(2,4). Então, um segundo mapeador de tom 603 realiza a transformação que clareia adequadamente as cores escuras de HDR, por com um fator de RHO adequado proposto pelo sistema de classificação dependendo da diferença de faixa dinâmica entre (o pico de brilho de) M_HDR e o LDR normalmente de 100 cd/m2 (100 nit) LDR, e geralmente aceito por fim, pelo classificador, que pode ou não alterar esse valor de RHO inicialmente proposto. Então, com o uso do terceiro mapeador de tom 604, o classificador começa o ajuste fino buscando por vários objetos na imagem, e por fim, define uma curva de mapeamento de tom padronizada CC, ao alterar várias lumas dessas várias de acordo com os objetos de imagem importantes do classificador. Isso produz as lumas Yn_LDR de da imagem de LDR_o, com todos os dados prontos para serem codificados.

[00126] Os componentes algorítmicos aqui revelados podem (inteira ou parcialmente) ser obtidos na prática como hardware (por exemplo, partes de um CI específico de aplicação), ou como software executado em um processador de sinal digital especial, ou um processador genérico etc.

[00127] O versado na técnica compreenderá, a partir da nossa apresentação, quais componentes podem ser aprimoramentos opcionais e podem ser concebidos em combinação com outros componentes, e como as etapas (opcionais) dos métodos correspondem aos respectivos meios de aparelhos, e vice versa. A palavra “aparelho” neste pedido é usada em seu sentido mais amplo, a saber, um grupo de meios que permitem alcançar um objetivo específico, e podem, assim, ser (uma pequena parte de) um CI, ou um aparelho dedicado (como um aparelho com uma tela), ou parte de um sistema ligado em rede, entre outras coisas. O termo “disposição” destina-se também a ser usado em seu sentido mais amplo, de modo a compreender, entre outras coisas, um único aparelho, uma parte de um aparelho, um conjunto de (partes de) aparelhos que operam em conjunto etc.

[00128] Uma versão de produto de programa de computador da presente modalidade como denotação deve ser entendida como abrangendo qualquer concretização física de um conjunto de comandos que permite que um processador para fins gerais ou específicos, após uma série de etapas de carga (que pode incluir etapas de conversão intermediárias, como tradução para uma linguagem intermediária, e uma linguagem de processador final) insira os comandos no processador e executar qualquer uma das características da invenção. Em particular, o produto de programa de computador pode ser concebido como dados em um portador, 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 em papel. A não ser pelo código de programa, dados característicos necessários para o programa também podem ser incorporados como produto de programa de computador. Deve ficar claro que, por computador, deve-se entender qualquer dispositivo com capacidade de realizar as computações de dados, isto é, o mesmo pode também ser, por exemplo, um telefone móvel. Também, as reivindicações do aparelho podem cobrir versões implantadas por computador das modalidades.

[00129] Algumas das etapas necessárias para a operação do método podem já estar presentes na funcionalidade do processador em vez de descritas no produto de programa de computador, como as etapas de entrada de dados e de saída de dados.

[00130] Deve-se notar que as modalidades mencionadas acima ilustram, e não limitam, a invenção. Nos pontos onde o versado na técnica puder realizar facilmente um mapeamento dos exemplos apresentados para outras regiões das reivindicações, por uma questão de concisão, nem todas as opções foram mencionadas em profundidade. 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 executada em um único elemento dedicado.

[00131] Qualquer sinal de referência entre parênteses na reivindicação não se destina a limitar a reivindicação. O uso do verbo “compreender” e suas conjugações não exclui a presença de elementos ou etapas não mencionados em qualquer uma das reivindicações ou na presente descrição. A palavra “um” ou “uma” antes de um elemento não exclui a presença de uma pluralidade de tais elementos.

Claims (6)

1. MÉTODO DE CODIFICAÇÃO DE UMA IMAGEM DE ALTA FAIXA DINÂMICA (M_HDR), compreendendo as etapas de: - converter a imagem de grande faixa dinâmica em uma imagem de faixa dinâmica de luminância mais curta (LDR_o), o método sendo caracterizado por calcular a imagem de faixa dinâmica de luminância mais curta (LDR_o) mediante a aplicação de: a) normalização da imagem de grande faixa dinâmica a um escala do eixo de luma que é [0,1] produzindo uma imagem de grande faixa dinâmica normalizada com cores normalizadas que têm luminâncias normalizadas (Yn_HDR); b) cálculo de uma função gama nas luminâncias normalizadas que produzem luminâncias convertidas por gama (xg); c) um primeiro mapeamento de tom que produz lumas (v) que é definido como v = log(1+(RHO-1)*xg)/log(RHO) em que RHO é uma constante que tem um valor predeterminado; e d) uma função de mapeamento de tom estritamente crescente arbitrária para as lumas para obter a emissão de lumas (Yn_LDR) da imagem de faixa dinâmica mais curta (LDR_o); e e) emitir em um sinal de imagem (S_im) uma codificação das cores de pixel da imagem de faixa dinâmica de luminância mais curta (LDR_o), e f) emitir em um sinal de imagem (S_im) como valores de metadados que codifica o formato de função das conversões de cor acima b a d, cujos metadados permitem que um receptor reconstrua uma imagem de grande faixa dinâmica reconstruída (Rec_HDR) a partir da imagem de faixa dinâmica de luminância mais curta (LDR_o), sendo que um valor que é uma função de RHO é emitido nos metadados.

2. MÉTODO DE CODIFICAÇÃO DE UMA IMAGEM DE GRANDE FAIXA DINÂMICA (M_HDR), de acordo com a reivindicação 1, caracterizado pelo cálculo de função gama usar um valor gama igual a 1/(2,4).

3. MÉTODO DE CODIFICAÇÃO DE UMA IMAGEM DE GRANDE FAIXA DINÂMICA (M_HDR), de acordo com a reivindicação 1, caracterizado por compreender determinar um valor de ganho (gai) para mapear a luma máxima da imagem de faixa dinâmica mais curto (LDR_o) para um valor específico dos valores possíveis na imagem de grande faixa dinâmica reconstruída (Rec_HDR), e codificar esse valor de ganho no sinal de imagem (S_im).

4. CODIFICADOR DE IMAGEM (100) DISPOSTO PARA CODIFICAR UMA IMAGEM DE ALTA FAIXA DINÂMICA (M_HDR), compreendendo: - uma unidade de conversão de faixa dinâmica (104) disposta para converter a imagem de grande faixa dinâmica em uma imagem de faixa dinâmica de luminância mais curta (LDR_o), o codificador de imagem sendo caracterizado pela unidade de conversão de faixa dinâmica (104) que compreender: a) um normalizador (601) disposto para normalizar a imagem de grande faixa dinâmica em relação a um eixo de luma que está no alcance de [0,1] e para emitir luminâncias normalizadas (Yn_HDR); b) uma unidade de conversão de gama (602) disposta para aplicar uma função gama às luminâncias normalizadas e para emitir luminâncias convertidas por gama (xg); c) uma primeira unidade de mapeamento de tom (603) disposta para aplicar um primeiro mapeamento de tom que rende lumas (v) que é definido como v = log(1+(RHO- 1)*xg)/log(RHO), em que RHO é uma constante que tem um valor predeterminado; d) uma unidade de mapeamento de tom arbitrário (604) disposta para aplicar uma função estritamente crescente arbitrária que mapeia as lumas (v) para emitir lumas (Yn_LDR) da imagem de faixa dinâmica mais curto (LDR_o); sendo que o codificador de imagem (100) compreende adicionalmente: - um compactador de imagem (108) disposto para aplicar uma transformação de redução de dados às cores da imagem de faixa dinâmica mais curta (LDR_o), cujas cores são organizadas em imagens de componente, e em que a transformação de redução envolve ao menos aplicar uma transformação de DCT em blocos de valores de componente de cor adjacentes, produzindo uma codificação compactada (LDR_c) das cores de pixel da imagem de faixa dinâmica de luminância mais curta; e - um formatador (110) disposto para emitir, em um sinal de imagem (S_im), a codificação compactada (LDR_c), e disposto para, adicionalmente, emitir nos valores de sinal de imagem (S_im), codificar o formato de função das conversões de cor como metadados, cujos metadados permitem que um receptor reconstrua uma imagem de grande faixa dinâmica (Rec_HDR) com base na imagem de faixa dinâmica de luminância mais curto (LDR_o), sendo que os valores compreendem um valor caracterizando RHO.

5. DECODIFICADOR DE IMAGEM (150) DISPOSTO PARA RECEBER UM SINAL DE IMAGEM DE ALTA FAIXA DINÂMICA (S_IM), caracterizado por compreender: - um desformatador (151) disposto para obter uma imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) e dados de parâmetro (P) do sinal de imagem (S_im); e - um descompactador (152) disposto para aplicar ao menos uma transformação de DCT inversa à imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) para obter uma imagem de faixa dinâmica mais curta pixelizada (LDR_t); e - uma unidade de conversão de faixa dinâmica (153) disposta para transformar a imagem de faixa dinâmica mais curta (LDR_t) em uma imagem de grande faixa dinâmica reconstruída (Rec_HDR), sendo que a unidade de conversão de faixa dinâmica (153) compreende: a) uma unidade de mapeamento de tom arbitrário (402) disposta para aplicar um mapeamento de tom estritamente crescente arbitrário, sendo que os parâmetros que definem o mapeamento de tom estritamente crescente arbitrário (P_CC) são recebidos nos dados de parâmetro (P); b) uma primeira unidade de mapeamento de tom (403) disposta para aplicar um mapeamento conforme definido por uma emque a informação do RHO constante é recebida nos dados de parâmetro (P); e c) ua unidade de conversão de gama (404) disposta para aplicar um mapeamento de gama com um valor de gama (GAM).

6. MÉTODO DE DECODIFICAÇÃO DE UM SINAL DE IMAGEM DE ALTA FAIXA DINÂMICA (S_IM), caracterizado por compreender: - obter uma imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) e dados de parâmetro (P) fora do sinal de imagem (S_im); descompactar a imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c), aplicando-se ao menos uma transformação de DCT inversa à imagem de faixa dinâmica mais curta pixelizada compactada (LDR_c) para obter uma imagem de faixa dinâmica mais curta pixelizada (LDR_t); e transformar a imagem de faixa dinâmica mais curta (LDR_t) em uma imagem de grande faixa dinâmica reconstruída (Rec_HDR), mediante: a) a aplicação de um mapeamento de tom estritamente crescente arbitrário, sendo que os parâmetros que definem o mesmo (P_CC) são recebidos nos dados de parâmetro (P); b) a aplicação de um mapeamento conforme definido pela constante (RHO), sendo que o mapeamento é definido por c) aplicando um mapeamento de gama com um valor de gama (GAM) que é igual a 2,4.