BR112018012456B1 - Aparelho de transformação de cor, decodificador de imagem hdr e método para calcular cores resultantes - Google Patents

Abstract

Para possibilitar a geração prática e rápida de uma família de classificações HDR de boa aparência para várias telas nas quais pode ser necessário exibir a imagem HDR, a presente invenção refere-se um aparelho de transformação de cor (201) para calcular as cores resultantes (R2, G2, B2) de pixels de uma imagem de saída (IM_MDR) para uma tela com um brilho de pico de tela (PB_D) a partir de cores de entrada (R, G, B) de pixels de uma imagem de entrada (Im_in) com um código de luma máximo correspondente a um brilho de pico de primeira imagem (PB_IM1) que é diferente do brilho de pico de tela, o aparelho de transformação de cor caracterizado por compreender: - uma unidade de determinação de transformação de cor (102; 2501) disposta de modo a determinar uma transformação de cor (TMF; g) compreendendo ao menos uma função de mapeamento de matiz (CC) recebidos através de uma entrada de metadados (116), e sendo que a divisão do brilho de pico de primeira imagem pelo brilho de pico de segunda imagem é maior que 2 ou menor que 1/2; - uma unidade de determinação de fator de escala (200; 2603) disposta de modo a determinar um fator multiplicativo comum resultante (...).

Description

CAMPO DA INVENÇÃO

[001] A invenção se refere a métodos e a aparelhos para otimizar as cores de pixels, em particular suas luminâncias, em uma codificação de entrada de uma imagem de alta faixa dinâmica (HDR, de “high dynamic range”), em particular, um vídeo compreendendo várias imagens HDR consecutivas, para se obter uma aparência artística correta para uma tela com um brilho de pico de tela específico, conforme desejado por um classificador de cor ao criar um conteúdo de imagem, sendo que a aparência corresponde a uma aparência HDR de referência da imagem HDR conforme classificada para uma tela de referência, por exemplo uma tela de masterização de alto brilho de pico (PB), quando a imagem otimizada é renderizada em qualquer tela real com um brilho de pico (PB_D) diferente do brilho da tela de referência correspondente para a qual foi feita a classificação (gradação) da imagem HDR. O leitor entenderá que uma aparência correspondente não significa necessariamente uma aparência que é exatamente a mesma para um observador, uma vez que telas de brilho de pico (ou faixa dinâmica) mais baixo nunca podem realmente renderizar exatamente todas as aparências de imagem renderizáveis em uma tela de brilho de pico mais alto, mas que, em vez disso, haverá alguma troca ou concessão nas cores de ao menos alguns pixels de objeto, cujos ajustes de cor a tecnologia descrita a seguir possibilita que o classificador o faça. Mas a imagem pretendida codificada e a imagem realmente renderizada terão aparências suficientemente similares. Tanto os métodos de codificação lateral como os aparelhos para especificar tal aparência, bem como para receber aparelhos laterais, como, por exemplo, uma tela ou aparelho de TV, organizados para calcular e renderizar a aparência otimizada são descritos, bem como métodos e tecnologias para comunicar informações usadas para controlar a otimização fazendo transformações de cores.

ANTECEDENTES DA INVENÇÃO

[002] Recentemente, várias empresas começaram a pesquisar e publicar [vide documento WO2007082562 [Max Planck], um método de duas imagens com uma camada residual, e o documento WO2005104035 [Dolby Laboratories], que ensina um método de certa forma similar no qual pode-se formar uma imagem de razão para intensificar a reclassificação de uma baixa faixa dinâmica (LDR, de “low dynamic range”) de uma cena HDR] como elas podem codificar ao menos uma imagem estática, ou um vídeo de várias imagens temporalmente sucessivas, assim chamadas “imagens de alta faixa dinâmica”, sendo que as imagens HDR são caracterizadas pelo fato de as mesmas geralmente codificarem ou serem capazes de codificar ao menos algumas luminâncias de objeto de pelo menos 1000 nits, mas também luminâncias escuras de, por exemplo, menos de 0,1 nit, e serem de qualidade suficiente para serem renderizadas nas chamadas telas HDR, que têm brilhos de pico (sendo branca a luminância da tela, isto é, a cor renderizável mais brilhante) geralmente acima de 800 nits, ou mesmo 1000 nits, e potencialmente, por exemplo, 2000 ou 5000 ou mesmo 10.000 nits. Obviamente, essas imagens, por exemplo, de um filme, podem e precisam também ser exibidas em uma tela LDR com um brilho de pico geralmente de cerca de 100 nits, por exemplo quando o observador deseja continuar a assistir ao filme em sua tela portátil, e geralmente algumas luminâncias e/ou cores diferentes de objetos são necessárias na codificação da imagem LDR em comparação com a imagem HDR (por exemplo, pode ser necessário que a luminância relativa em uma faixa [0,1] de um objeto em uma classificação HDR seja muito menor do que na imagem de classificação LDR, porque ela será exibida com uma retroiluminação muito mais brilhante). Desnecessário dizer também que a codificação de vídeo pode ter requisitos adicionais em comparação com a codificação de imagem estática, por exemplo para possibilitar um processamento em tempo real barato etc.

[003] Dessa forma, geralmente, o criador de conteúdo faz uma versão ou aparência de imagem HDR, que é geralmente a classificação mestra (o ponto de partida do qual podem ser criadas classificações adicionais, que são aparências na mesma cena quando é necessário renderizar em telas com recursos de brilho de pico diferentes, e que são geralmente feitas fornecendo-se aos vários objetos em uma imagem, diretamente a partir da câmera, cores artísticas agradáveis, para transmitir, por exemplo, algum tipo de atmosfera). Isto é, com a expressão “uma classificação” indicamos que uma imagem foi tão ajustada por um classificador de cor humano que as cores dos objetos parecem artisticamente corretas para o classificador (por exemplo, ele pode criar um porão escuro no qual os objetos nas áreas de sombra sejam dificilmente visíveis, mesmo com a presença de uma única lâmpada no teto que brilha intensamente, e pode ser necessário que essas várias luminâncias renderizadas sejam coordenadas de forma inteligente para fornecer ao observador a experiência ideal) para um dado cenário de renderização pretendido, e é ensinado abaixo os componentes técnicos para possibilitar tal processo de classificação que produz uma imagem classificada, também chamado de “classificação”, dado nossas limitações de codificação HDR. E, então, o classificador geralmente produz também uma imagem LDR já existente (também chamada de imagem SDR padrão), que pode ser usada para exibição em telas LDR já existentes, as quais ainda poderão ser utilizadas por um longo tempo. Essas imagens podem ser transmitidas alternativamente como comunicações de imagem separadas através, por exemplo, de uma rede de comunicação de vídeo como a internet, ou um canal DVB-T. Ou os documentos WO2007082562 e WO2005104035 que ensinam métodos de codificação escaláveis nos quais a imagem HDR pode ser reconstruída em um lado de recepção a partir da imagem LDR, com algum mapeamento de matiz na mesma, e uma imagem HDR residual para se aproximar suficientemente da imagem HDR original (mas apenas a imagem HDR com aquelas cores de pixel e luminância de objeto particulares sendo reconstruída a partir da imagem LDR da camada de base). Tal codificação escalável poderia, então, ser armazenada conjuntamente em um produto de memória como, por exemplo, um bastão de memória de estado sólido, e o aparelho no lado de recepção, por exemplo um aparelho de TV, ou um “settopbox” (STB - conversor/decodificador de sinal de televisão externo) poderia então determinar qual seria a versão mais adequada para seu aparelho de TV conectado.

[004] Isto é, em um setor da memória as imagens LDR básicas poderiam ser armazenadas, e em outro setor as imagens HDR, ou as imagens de correção, como uma imagem de intensificação de luminância, a partir das quais pode-se calcular as imagens HDR partindo das imagens LDR correspondentes para os mesmos pontos no tempo. Por exemplo, para aparelhos de TV de até 700 nits, qualquer unidade que realiza os cálculos da imagem final a ser renderizada no aparelho de TV pode usar a imagem LDR classificada, e acima de 700 nits, ela pode usar a imagem HDR (por exemplo, verificando qual tela de qual PB está conectada, ou “sabendo” que a tela produz ela mesma a melhor seleção de imagem).

[005] Embora isto permita fazer duas classificações de referência artisticamente perfeitas de uma cena HDR para dois cenários de renderização específicos, por exemplo um aparelho de TV de 5000 nits, e um aparelho LDR (cujo padrão tem um 100 nits PB), pouca pesquisa tem sido feita e publicada sobre como se pode manusear aparelhos de TV intermediários com brilho de pico intermediário, sendo que os brilhos de pico correspondem às duas imagens de classificação artística que podem ser obtidas ou determinadas em um lado de recepção de dados de imagem (sendo que o brilho de pico correspondente de uma codificação é definido como a luminância a ser renderizada em uma tela de referência quando o código máximo, por exemplo 1023 para 10 bits, é inserido, por exemplo 5000 nits para uma aparência classificada de 5000 nits) que, sem dúvida, estará brevemente disponível no mercado, por exemplo um aparelho de TV de 1800 nits. Por exemplo, o criador de conteúdo pode gastar um tempo considerável para fazer uma classificação HDR mestra de 1000 nits de seu filme, porque, por exemplo, os 1000 nits podem ser um brilho de pico PB_C de conteúdo acordado (isto é, a cor de pixel mais brilhante que pode ser definida, que será uma cor acromática branca) para o padrão específico de codificação de vídeo HDR usado pelo criador, e ele pode gastar mais ou menos tempo derivando uma LDR correspondente (ou também recentemente chamada de faixa dinâmica padrão (SDR, de “standard dynamic range”), uma vez que essa era a maneira usual de se fazer vídeo LDR antigo, por exemplo, de acordo com o conjunto de imagens da Recomendação ITU-R BT. 709 ou simplesmente Rec. 709), com uma aparência de contraste relacionada ao brilho. Mas isso significa que existe apenas um único vídeo de boa aparência disponível no caso de o observador ter exatamente uma tela HDR específica com PB_D de 1000 nits, ou uma tela SDR antiga. Contudo, não se espera que todas as pessoas tenham telas com exatamente o mesmo tipo de exibição com o mesmo brilho de pico de tela PB_D, tampouco, que no futuro, todo vídeo será codificado com exatamente o mesmo conteúdo ou brilho de pico de codificação PB_C (isto é, alguém que compra a tela ideal para conteúdo BD (“Blu-ray Disc”), poderá ainda ter uma tela subideal quando o mercado migrar para serviços baseados na internet com PB_C=5000 nits), e então, ainda assim, haverá a influência do ambiente de visualização, em particular seu brilho e iluminância médios. Portanto, embora todas as tentativas de codificação HDR tenham se concentrado essencialmente em obter conteúdo através de um meio de comunicação, e ser capaz de decodificar em todas as imagens HDR em um lado de recepção, a Requerente acredita que qualquer sistema pragmático de manuseio de HDR precisa dispor de mais capacidades. A Requerente conduziu experimentos que mostram que, para se ter uma aparência artística, convincente e realmente boa para qualquer tela intermediária ou mesmo uma tela fora de faixa (por exemplo, obter uma aparência de 50 nits que está abaixo da menor classificação que pode, geralmente, ser de 100 nits), nem a HDR nem a imagem LDR serão realmente adequadas para essa tela de brilho de pico intermediário (a qual chamaremos deste ponto em diante no presente documento de faixa dinâmica média (MDR, “medium dynamic range”)). E, como mencionado anteriormente, o tipo de tela MDR que alguém tem disponível depende até do PB_C das imagens HDR sendo recebidas ou solicitadas. Igualmente, poderia ser o caso do consumidor ter em sua sala de estar um aparelho de TV real ou outra tela com um brilho maior que o brilho de pico da tela de referência como uma tela ideal pretendida para a classificação da imagem HDR recebida, isto é, por exemplo, 10000 nits em comparação com 5000 nits, e então pode ser desejável também ter uma classificação aprimorada para essas telas de brilho mais elevado, apesar do criador de conteúdo ter pensado que seria preciso apenas especificar a aparência na cena HDR para telas com PB de até 5000 nits. Por exemplo, a Requerente descobriu que cenas de importância crítica, por exemplo, o rosto de uma pessoa no escuro pode se tornar escuro demais ao se usar a imagem HDR, devido ao contraste inadequadamente elevado dessa imagem HDR para uma renderização de tela com brilho de pico mais baixo, e mesmo assim a imagem LDR é excessivamente brilhante em muitos locais, alterando drasticamente a atmosfera de, por exemplo, uma cena noturna. A Figura 14 mostra um exemplo de um típico manuseio de imagem de cena HDR que queremos poder obter. O número de referência 1401 mostra a cena original, ou ao menos, como ela foi aproximada em uma classificação HDR mestra (porque geralmente não se codifica o sol para ser renderizado em uma tela em seu brilho original de 1 bilhão de nits, mas, ao invés disso, por exemplo, em pixels de 5000 nits). Vemos uma cena contendo alguns objetos no ambiente interno, que serão relativamente mais escuros, mas que não são, geralmente, realmente escuros, por exemplo entre 1 e 200 nits, e alguns objetos no ambiente externo ensolarado visto através da janela, como a casa, que podem na vida real ter luminâncias de vários milhares de nits, mas que para o uso do aparelho de TV à noite no ambiente interno são melhor renderizados com cerca de, por exemplo, 1000 nits. Em uma primeira classificação, a qual chamaremos de classificação HDR com um brilho de pico da primeira imagem neste PB_IM1 meramente exemplificador correspondendo a um brilho de pico PB_H HDR de por exemplo 5000 nits, veremos que é útil posicionar os objetos no ambiente interno a uma altura relativamente baixa num eixo de luminância relativa (de modo que num eixo de luminância absoluta os objetos seriam renderizados em luminâncias de cerca de 30 nits), e os objetos no ambiente externo ficariam próximos ou na parte mediana da faixa de luminância, dependendo das preferências do classificador para essa tomada, por exemplo, no filme, ou transmissão etc. (no caso de transmissão ao vivo a classificação poderia ser tão simples como ajustar apenas alguns parâmetros antes da transmissão, por exemplo com o uso de um mapeamento predominantemente fixo entre a aparência HDR e LDR, mas adicionando, por exemplo, um único parâmetro gpm para possibilitar o ajuste de tela). A questão de quais códigos reais correspondem às luminâncias desejadas depende não apenas do PB da codificação, mas também do formato da função de alocação de código usada, que é às vezes chamada de uma função de conversão ou transferência optoeletrônica (OECF, de “opto-electronic conversion or transfer function”); também chamada de OETF), e que, para a codificação HDR, geralmente tem um formato íngreme, mais íngreme do que as funções gama 1/2.2 de LDR (o versado na técnica compreenderá que é possível formular as tecnologias em qualquer representação; portanto, onde para fins de simplicidade descrevemos abaixo os conceitos da presente invenção em representações de luminância, pelo menos algumas das etapas poderão, mudando o que deve ser mudado, ser aplicadas em lumas, isto é, as classificações de 10 bits das luminâncias, por exemplo).

[006] É necessária uma aparência LDR correspondente (neste mero exemplo chamado IM_GRAD_LXDR), para a qual certamente todos os vários objetos da faixa dinâmica de luminância maior precisam ser comprimidos em uma faixa dinâmica menor, correspondendo a um PB de 100 nits. O classificador irá definir estratégias de transformação de cor, geralmente funções simples para manter simples os circuitos integrados de comunicação de vídeo, pelo menos para os próximos anos, que definem como reposicionar as luminâncias de todos os objetos (por exemplo, conforme pode ser visto, seria necessário posicionar a casa próximo do máximo da faixa de luminância e da faixa de código correspondente para mantê-la com uma aparência suficientemente brilhante em comparação com os objetos no ambiente interno, o que pode, para certas modalidades, ser feito, por exemplo, com mapeamento de matiz de corte suave). Isso é o que é especificado no lado de criação de conteúdo, em um aparelho de classificação 1402, e um aparelho que usa conteúdo pode precisar determinar, com base nas informações das aparências classificadas (S_im) que o mesmo recebe por algum meio de comunicação de imagens (1403), quais luminâncias ideais os vários objetos devem ter para uma tela real com um brilho de pico que é diferente do brilho de pico correspondente a qualquer uma das classificações artísticas, geralmente duas, recebidas (ou pelo menos os dados dessas imagens). Nesse exemplo, isso pode envolver várias estratégias. Por exemplo, os objetos no ambiente interno escuro são bem renderizáveis em telas de qualquer PB, mesmo de 100 nits, portanto, a otimização de cor pode mantê-los em ou próximo de 30 nits para qualquer PB pretendido. A casa pode precisar receber alguma luminância a ser renderizada entre aquela das classificações LDR e HDR, e o sol pode receber a cor (isto é, PB) mais brilhante possível em qualquer tela conectada ou a ser conectada.

[007] Queremos agora enfatizar, como ficará claro adiante, que desenvolvemos uma estratégia que pode surpreendentemente codificar uma cena HDR (daí a razão de introduzirmos o termo “cena”) realmente como uma imagem LDR (+ metadados de transformação de cor); portanto, onde, para fins de simplicidade de compreensão, vários dos conceitos da presente invenção e metaestruturas técnicas podem ser descritos com um cenário no qual Im_1, a imagem a ser transmitida para um lado de recepção é uma imagem HDR que deve ser reclassificável em uma imagem LDR, os mesmos princípios podem também ser utilizáveis, e devem ser usados em outros cenários importantes de mercado, no caso de Im_1 ser realmente uma classificação LDR (que pode em um lado de recepção ser reclassificada em uma imagem HDR, ou qualquer faixa dinâmica média (MDR), ou qualquer imagem fora da faixa das classificações LDR e HDR transmitidas).

[008] A Figura 29 resume esquematicamente qual deve ser a aparência típica de um sistema de codificação de acordo com a invenção anterior da Requerente, que servirá de base para sua construção.

[009] Há uma fonte de imagem 2901 das imagens HDR originais, que pode ser, por exemplo, uma câmera para confecção de programas de vídeo em tempo real, mas assumimos, para manter nosso foco, que ela seja, por exemplo, uma unidade de armazenamento de dados que cria o filme com cores pré-classificadas, isto é, todas as cores, e em particular os brilhos, dos pixels foram tornados ideais para a apresentação em, por exemplo, uma tela de referência com PB_D de 5000 nits, por exemplo por um classificador de cor humano. Então, a codificação desses dados pode, nesse exemplo, significar o que segue abaixo (mas deseja-se enfatizar que é possível, também, fazer a codificação como algumas imagens HDR, e em particular que o ajuste para obter as imagens ideais para uma tela MDR pode funcionar também com base na redução de classificação das imagens HDR recebidas, com base na filosofia de se ter informações específicas de conteúdo muito importantes nas funções de transformação de cor que relacionam duas aparências de faixas dinâmicas diferentes na mesma cena, geralmente algumas bastante capazes, isto é, imagem(ns) HDR de alto PB_C, e uma ou mais imagens SDR). O codificador 2921 compreende primeiramente uma unidade de transformação de cor 2902, disposta de modo a converter as imagens HDR mestras em uma imagem SDR adequada. O termo “adequada” significa, geralmente, que a aparência será uma boa aproximação da aparência HDR, enquanto retém uma quantidade suficiente de informações de cor para poder realizar em um lado de recepção a reconstrução das imagens de aparência HDR de 5000 nits a partir das imagens SDR recebidas. Na prática, isso significa que um classificador humano, ou algum algoritmo inteligente depois de analisar os detalhes da imagem HDR, como, por exemplo, quantidades e posições potenciais de classes de pixels com valores específicos de sua luminância HDR, irá selecionar as curvas adequadas de redução de classificação, para as quais no sistema mais simples haverá apenas uma, por exemplo, a curva CC, ou uma outra, mudando o que deve ser mudado, em uma curva de redução de classificação aproximada Fcrs. Isso possibilita ao codificador fazer imagens SDR Im_LDR, que são apenas imagens SDR normais (embora quando acopladas com as funções que relacionam essa aparência SDR à aparência HDR mestra original, elas contenham precisamente as informações corretas também da imagem HDR, isto é, para poder reconstruir a imagem ou imagens HDR). Como essas são apenas imagens SDR, elas são não só bem renderizáveis em telas já existentes (isto é, com PB_D de 100 nits), mas também podem ser codificadas com o uso de técnicas normais de codificação de vídeo SDR, e isso é muito útil, porque já existe um investimento de bilhões de dólares em hardware no campo (por exemplo, em satélites) que não precisa ser alterado. Dessa forma, desassociamos de modo inteligente as informações da HDR em funções para codificação funcional, mas, no que diz respeito à presente invenção, isso possibilita uma segunda aplicação importante, ou seja, a capacidade inteligente e otimizada por conteúdo de reclassificar as imagens ao que for necessário para obter uma aparência correspondente em uma tela MDR com qualquer PB_D. Isso elimina a necessidade do classificador realmente criar todas essas terceiras aparências, contudo elas ainda serão geradas de acordo com sua visão artística, isto é, as necessidades específicas desse conteúdo, porque pode-se usar os formatos de suas funções de transformação de cor F_ct (especificamente as funções de transformação de luminância, porque a conversão HDR para MDR está associada basicamente à obtenção do brilho correto para todos os objetos da imagem e, portanto, este pedido se concentrará principalmente nesse aspecto), quaisquer que possam ser, que também serão transmitidos conjuntamente com as imagens pixelizadas SDR como metadados, ao se derivar as imagens MDR ideais. Assim, as imagens SDR reclassificadas (Im_LDR) passam para uma unidade de codificação de vídeo 2903, a qual assumimos para fins de simplicidade de elucidação como sendo um codificador HEVC padronizado, mas o versado na técnica entenderá que a unidade pode ser qualquer outro codificador projetado para transmitir as imagens da faixa dinâmica selecionada, isto é, SDR, neste exemplo. Isso produz imagens SDR codificadas, Im_COD, e mensagens SEI correspondentes, por exemplo SEI(F_ct), compreendendo todos os dados necessários das funções de transformação, embora elas tenham sido projetadas para ser transmitidas (por exemplo, em várias modalidades, formulações paramétricas, ou LUTs (tabelas de consulta), que possibilitam manusear de modo diferente a derivação das imagens MDR ideais na tela, mas podem ser projetadas modalidades adequadas para qualquer variante). Um formatador 2904 formata tudo em um formato de sinal necessário, por exemplo ATSC para ser transmitido via canal de satélite, ou algum formato adequado para a internet etc. Assim, o meio de transmissão 2905 pode ser qualquer um dentre uma rede por cabo, uma rede de comunicação dedicada, ou uma memória em pacote como um disco blu-ray (BD) etc. Em qualquer lado de recepção, seja o aparelho de recepção um “settopbox”, tela, computador ou receptor de sala de cinema profissional etc., o aparelho de recepção conterá um desformatador 2906, que recria vídeo codificado decodificado por sinal. O decodificador de vídeo 2920 compreenderá, mudando o que deve ser mudado, uma unidade de decodificação de vídeo 2907, por exemplo um decodificador HEVC, que compreende também um leitor de dados de função (2911) disposto para coletar dos metadados as funções F_ct, e construir e apresentá-las no formato adequado para uso adicional, nessa aplicação a determinação otimizada da imagem MDR, de acordo com os vários algoritmos possíveis descritos abaixo ou seus equivalentes. Então, a unidade de transformação de cor 2908 simplesmente criaria, na decodificação normal de HDR, uma reconstrução Im_RHDR da uma ou mais imagens HDR mestras originais, o que quer que sejam, por exemplo, definidas com PB_C de 1000 nits ou 5000 nits. Entretanto, nas modalidades descritas abaixo, a unidade de transformação de cor 2908 tem, também, a possibilidade de reclassificar imagens idealmente para qualquer tela disponível (por exemplo, o usuário insere no STB (“settopbox”) a informação de que ele adquiriu uma TV de 3000 nits 2910, ou, se esse decodificador já estiver incluído na TV, esta irá, obviamente, “conhecer” suas próprias capacidades). Isso é indicado esquematicamente como uma unidade de ajuste de cor 2902 que obterá informações sobre todos os detalhes da situação de visualização (em particular do PB_D da tela a ser servida com imagens), e então usará qualquer um dos métodos apresentados abaixo para ajustar idealmente as cores para obter uma imagem MDR, Im3000nit. Embora isso possa parecer algo desejável de se fazer, ser capaz de fazê-lo de uma maneira razoável é na verdade uma tarefa complexa.

[010] A Requerente ensinou genericamente através dos documentos WO2011/107905 e WO2012/127401 o conceito de gerar várias classificações adicionais (que são necessárias para fazer as imagens de cena HDR recebidas parecerem ideais qualquer que seja o brilho de pico de uma tela conectada, e não, por exemplo, escuras demais ou brilhantes demais para pelo menos uma parte da imagem) com base nas imagens classificadas recebidas disponíveis, e tais documentos ensinam os conceitos principais que são necessários para o ajuste de tela, o qual, por sua vez, é necessário para todas ou pelo menos uma classe maior de modalidades reais. Entretanto, ainda era um problema chegar a variantes de codificação simples que se conformassem às limitações práticas de, por exemplo, complexidade de circuitos integrados (CI), capacidade de trabalho do classificador, etc., o que os inventores poderiam fazer depois de estabelecer alguns princípios básicos comuns para o manuseio prático de imagens HDR. De modo correspondente, havia ainda o problema de como chegar a uma tecnologia simples correlacionada que permitisse ao criador de conteúdo ajustar a classificação otimizada artisticamente à ao menos uma tela real presente em um lado de recepção, e as várias necessidades de ajuste de tela com base em tal tecnologia.

[011] Exceto onde e até o ponto especificamente mencionado nesta descrição, quaisquer discussões acima referentes à técnica anterior ou mesmo às crenças ou interpretações particulares da Requerente para explicar algo não se destinam a especificar inadvertidamente quaisquer detalhes de quaisquer limitações que, por exemplo, precisam estar, ou não poderiam estar em qualquer uma das modalidades da presente invenção. Além disso, qualquer coisa que não seja explicitamente mencionada não se destina a ser nenhuma opinião específica sobre quais características ou variantes podem ou não ser fundamentadas em qualquer modalidade específica a partir de mero conhecimento prima facie da técnica anterior, ou qualquer declaração implícita sobre evidência etc. Deve ficar claro que alguns ensinamentos podem ser interessantes à luz da multiplicidade de modalidades abaixo, e que dada a totalidade dos ensinamentos e o que pode ser bem entendido a partir disso, alguns exemplos do exposto acima podem se referir apenas a algumas modalidades vantajosas específicas.

SUMÁRIO DA INVENÇÃO

[012] Em particular, foi desenvolvida uma tecnologia muito útil de mapeamento de luminância (pelo menos de mapeamento de luminância, porque, em virtude dos muitos fatores e variantes de modalidades para fins de simplicidade de explicação, ignorou-se por enquanto a dimensão cromática de tons vermelhos e azuis), que tem por base a multiplicação dos três componentes de cor por um único multiplicador comum que é tão otimizado que contém todo o conhecimento necessário para criar a aparência ideal da imagem MDR de qualquer cena HDR que é necessária para renderizar a aparência dessa cena em qualquer tela realmente disponível com um brilho de pico de tela PB_D específico (o versado na técnica compreende que os mesmos cálculos podem ser feitos em um servidor, para servir posteriormente uma tela com PB_D específico, isto é, a tela não está fisicamente conectada ao aparelho de cálculo de cor ou de luminância). Se um criador processa sinais de cores RGB lineares, e também potências não lineares dos mesmos como, de preferência, os componentes comuns Y’CbCr para vídeo, o criador pode intensificá-los (multiplicando os componentes por um único multiplicador resultante gt) de uma maneira similar àquela em que intensificaria as luminâncias dessas cores. Isto é, o criador de conteúdo pode então especificar, de acordo com suas preferências, uma estratégia de mapeamento de luminância, que pode, em modalidades, ser formada de várias subestratégias de mapeamento, por exemplo uma intensificação geral de brilho, uma função formatada arbitrariamente por ajuste fino (CC) etc. E essa preferência pode então ser realmente calculada como várias estratégias de multiplicação. Desnecessário dizer, por exemplo, que, e certamente para as técnicas da presente invenção, nas variantes mais básicas é preciso apenas uma tal especificação de função, em algumas modalidades nem mesmo para todas as luminâncias possíveis da imagem de entrada, e onde nos referimos como CC nas explicações, pode ser também alguma outra função. Em qualquer caso, qualquer que seja a complexidade com que o criador deseja especificar seu mapeamento de luminância, o processo pode ser visto como várias multiplicações que levam a uma multiplicação final que será realizável como uma otimização final de luminância, daquilo que se considera como componentes de cor normalizados. Apresentamos várias possíveis modalidades reais com base nesse princípio, que então separa o manuseio das luminâncias do manuseio das cores.

[013] Por não ser comumente conhecida ou usada de forma padronizada pelos engenheiros de codificação de vídeo, antes de discutir os detalhes da otimização de imagens MDR, para assegurar que o leitor conheça os pensamentos e princípios básicos, esclarecemos o princípio na Figura 16. Supondo-se que tenhamos uma função sigmoide para transformar qualquer possível luminância de entrada Y_in (que corresponde a um código de luma da imagem de entrada recebida e a ser processada, Im_in, por exemplo 950) em um valor de luminância de saída, o qual, para fins de simplicidade, assume-se também que seja valor normalizado entre 0,0 e 1,0. Pode-se então escrever essa função também como uma multiplicação, que pode ser derivada em comparação com a transformação unitária (isto é, a diagonal). Se desejássemos transformar, por exemplo uma Im_in HDR nela mesma, aplicaríamos essa transformação unitária. Caso se queira transformar as luminâncias relativas HDR em luminâncias relativas LDR (ou apenas luminâncias), pode-se aplicar a função sigmoide. Mas pode-se, de modo equivalente, multiplicar esse valor Y_in pelo fator g da curva direita. Tal estratégia de multiplicação torna a tecnologia HDR relativamente mais simples, por exemplo, ao concatenar em cascata várias transformações desejáveis, mas também, como é o assunto deste pedido, mostrar cenários de ajuste, para se chegar a uma imagem de aparência ideal, correspondendo em grande parte à aparência HDR mestra, para qualquer tela realmente conectada.

[014] Como um método prático de codificação de imagens HDR e, em particular, de vídeo (e, de fato, simultaneamente, uma aparência classificada LDR útil para exibição direta em telas LDR já existentes), a Requerente inventou um sistema que armazena (ou transmite) apenas uma dentre o par de imagens HDR e LDR como uma imagem principal que constitui os únicos dados de cor de pixel realmente transmitidos (sendo a outra imagem comunicada parametricamente como especificações de funções de processamento de cores para derivá-la da imagem (ou imagens) realmente recebida, e que, além disso, pode, quando tecnicamente derivada corretamente, ser então realmente codificada de acordo com técnicas tradicionais de compressão (lida para rápida identificação e disposta, por exemplo, em um repositório de luma AVC de 8 bits ou HEVC de 10 bits, e executar a compressão DCT etc., como se não fosse uma imagem HDR de uma cena HDR, mas alguma representação SDR inadequada da mesma), isto é, contendo as texturas de cor de pixel dos objetos capturados da cena HDR, isto é, ele contém a composição geométrica de todos os formatos de objetos e alguma codificação das texturas nos mesmos, e possibilita qualquer renderização desejada ou ajuste de cor correspondente para reconstruir esse aspecto geométrico das imagens. Portanto, realmente, no que diz respeito ao que pode ser estabelecido em qualquer lado de recepção, nossa codificação de imagens de cena HDR contém, além das imagens realmente transmitidas, ao menos uma classificação adicional (e geralmente, em vista do custo de classificação, exatamente uma) (por exemplo, imagens SDR com PB_C de 100 nits são transmitidas, mas as funções de comunicação de cor transmitidas conjuntamente possibilitam a reconstrução de exatamente uma classificação adicional, por exemplo uma reconstrução de uma imagem HDR mestra com PB_C de 5000 nits), que é geralmente codificada não como uma segunda imagem, mas como um conjunto de transformações funcionais para as cores de pixels da imagem principal (geralmente limitado devido aos CIs de decodificação necessários para entender e implementar todas as transformações de cor). Dessa forma, se a imagem principal (Im_in) fosse uma imagem HDR (por exemplo, referenciada a um brilho de pico de 5000 nits), as funções (ou algoritmos) de transformação de cor seriam para possibilitar o cálculo a partir da mesma de uma imagem LDR (geralmente como SDR padronizada de 100 nits). E o versado na técnica saberá como se pode facilmente codificar tal transformação com o menor número de bits necessário, por exemplo, uma função com uma primeira parte linear e, então, uma parte em curva em direção a (1,0, 1,0) poderá ser codificada por um valor real ou outro parâmetro que forneça um declive (coeficiente angular) (declive de cor preta) e um ponto de parada da parte linear, e quaisquer que sejam os parâmetros necessários para definir o formato da parte superior. Diversas variantes práticas irão transmitir reclassificações SDR da imagem HDR mestra como a(s) única(s) imagem(ns) comunicada(s), uma vez que isso é útil para todas as situações nas quais as telas SDR já instaladas precisam de uma imagem que possa renderizar diretamente, sem a necessidade de nenhuma transformação de cor adicional (como uma tela HDR ou o aparelho que prepara as imagens precisaria fazê-lo em tal modalidade).

[015] A Figura 1 fornece uma possível modalidade não limitadora típica, mas meramente ilustrativa, de tal transformação de cor e a correspondente codificação baseada em transformação da (ao menos uma) classificação adicional, a qual, o versado na técnica reconhecerá, não é o único sistema que pode se usar nas modalidades de nossa invenção. Em particular, nos pontos onde esclarecemos alguns dos princípios que podem ser vantajosamente aplicados em uma representação de cor linear (em particular f(Max), ou f(Y) onde Y é a luminância no numerador e Max e Y no numerador de g; e o multiplicador que multiplica os componentes RGB lineares), os princípios podem também ser aplicados em espaços de cor não lineares (a parte que leva aos cálculos de g e/ou a multiplicação, que pode multiplicar, por exemplo, componentes de cor R’, G’ e B’, onde o traço indica que são leis de potência com uma potência 1/N onde N é um número real ou um número inteiro dos componentes lineares, por exemplo R’=sqrt(R)).

[016] Presume-se, nesse exemplo, que uma imagem HDR é codificada como imagem de textura (e recebida como Im_in), e uma classificação LDR pode ser construída a partir da mesma em qualquer lado de recepção de vídeo, aplicando-se transformações de cor às suas cores de pixel. Entretanto, o mesmo raciocínio técnico se aplica quando, por exemplo, é reconstruída uma imagem HDR com base em uma imagem principal que é uma imagem LDR, isto é, adequada para a renderização direta em uma tela LDR, isto é, quando renderizada em uma tela LDR mostrando os brilhos e contrastes adequados para os vários objetos na imagem dada a limitação de brilho de pico da tela LDR. Nesse caso, a transformação de cor irá definir uma imagem HDR a partir da imagem LDR. Deve-se notar que, em algumas modalidades (embora não necessariamente), a ordem das unidades de processamento pode ser invertida no codificador e no decodificador, por exemplo quando o codificador diminui a faixa dinâmica e codifica a imagem principal como uma imagem LDR, e então o processamento da ordem de luminância (ou luma) pode ser invertido durante a reconstrução, no lado do decodificador, da classificação HDR a partir da imagem principal LDR correspondente, isto é, aplicando-se primeiramente a curva padronizada, e então o ajuste de exposição da unidade 110 aplicado na direção inversa etc.

[017] Assumindo-se, por enquanto, para fins de explicação, que o aparelho de transformação de cor 201 seja parte de qualquer aparelho de recepção (que pode ser um aparelho de TV, um computador, um telefone móvel, um servidor de cinema digital interno, uma cabine de visualização em uma sala de controle de sistema de segurança etc.), mas em um lado de codificação em um aparelho de codificação ou transcodificação os mesmos componentes tecnológicos possam estar presentes para verificar o que é exequível e pode ser codificado para transmissão. Um sinal de imagem ou mais geralmente um sinal de vídeo S_im é recebido através de uma entrada 103, conectável a várias fontes de imagem, como, por exemplo, um leitor de BD, uma antena, uma conexão de internet etc. O sinal de vídeo S_im compreende, de um lado, uma imagem (ou um vídeo de várias imagens para diferentes instantes no tempo) de pixels Im_in com cores de entrada, e, por outro lado, metadados MET que podem compreender vários dados, entre outros, os dados para se construir de forma exclusiva em um lado de recepção as funções de mapeamento de cor, possivelmente alguns dados de descrição relacionados, por exemplo, ao propósito da classificação do brilho de pico da imagem de entrada, e o que quer que seja necessário para possibilitar as várias modalidades descritas abaixo. A codificação das imagens de vídeo pode, geralmente, ser feita com o uso uma estratégia de codificação do tipo MPEG, por exemplo HEVC de MPEG existente, isto é, uma codificação baseada em DCT de cores de pixel YCbCr, uma vez que nossa codificação de aparência de faixa dinâmica pela tecnologia de reclassificação baseada em transformação de cor é essencialmente indiferente quanto à estratégia de compressão realmente utilizada na parte da compressão que trata da formatação adequada das imagens para fins de armazenamento ou transmissão. Assim, embora as várias modalidades de nossa invenção possam ser utilizadas em várias outras definições de cor de entrada, como, por exemplo, vantajosamente Yuv, nesse exemplo um primeiro conversor de cor 104 é disposto para converter a representação YCbCr em uma representação RGB linear (nessa modalidade, conforme mostrado abaixo, pode-se, com os mesmos princípios da invenção, formular também modalidades que funcionam diretamente nos componentes YCbCr ou YUV). Um segundo conversor de cor 105 pode realizar um mapeamento de uma primeira representação RGB para uma segunda representação. Isso se deve ao fato de que o classificador de cor pode realizar uma classificação e observar o que acontece em um primeiro espaço de cor, por exemplo, Recomendação ITU-R BT. 709 ou simplesmente Rec. 709, e ainda assim os dados de imagem são codificados de acordo com um segundo espaço de cor. Por exemplo, podem ser usadas as cores primárias da Digital Cinema Initiatives P3: Vermelho=(0,68,0,32), Verde=(0,265,0,69), Azul=(0,15,0,06), Branco=(0,314,0,351). Ou, pode-se codificar usando o recente formato de cor Rec. 2020 etc. Por exemplo, a imagem pode ser transmitida em uma representação de cor definida em um espaço de cor Rec. 2020, mas o classificador realizou sua classificação de cor no espaço de cor DCI-P3, o que significa que os receptores converterão primeiro para o espaço de cor P3 antes de fazer todas as transformações de cor, por exemplo para obter uma classificação LDR a partir de uma imagem HDR, ou vice-versa. Como o classificador reclassificou sua imagem HDR em uma imagem LDR (presumindo-se que todos os valores foram normalizados para [0,1]) nesse espaço de cor de classificação que, conforme dito acima, foi, por exemplo, Rec. 709, antes das funções matemáticas recalcularem a classificação no lado de recepção, o segundo conversor de cor 105 farão a transformação para esse espaço de cor Rec. 709 (o versado na técnica reconhece que podem ser aplicadas várias estratégias de transformação, por exemplo, um mapeamento colorimétrico relativo pode ser usado em alguns casos, ou alguma estratégia de compressão de saturação pode ter sido utilizada e que pode ser invertida etc.). Então, os metadados geralmente aplicam uma estratégia de otimização de cor, a qual assumimos que nesta simples modalidade prática seja executada por um processador de saturação de cor 106. Pode haver várias razões para o classificador aplicar uma estratégia de saturação específica (por exemplo, “dessaturar” as cores brilhantes de um modo específico para adequá-las a uma posição de luminância mais alta na paleta RGB, ou aumentar a riqueza cromática (colorido) de cores que se tornaram mais escuras devido ao mapeamento HDR para LDR etc.). Por exemplo, o classificador pode achar que os tons de azul escuro de, por exemplo, uma cena noturna no céu estão um pouco “dessaturados” demais, e, portanto, ele pode aumentar previamente a saturação desses tons na imagem HDR linear antes de executar a função de otimização de luminância para obter a aparência LDR (isto é particularmente interessante porque nossas típicas modalidades de transformações de luminância deixam a cromaticidade da cor inalterada, isto é, afetam unicamente o aspecto de luminância da cor). Na modalidade do exemplo simplificado, assumimos que a saturação é uma simples alteração de escala para as cores (isto é, a mesma qualquer que seja seu matiz, luminância ou saturação inicial), com um valor s, o qual é lido nos metadados MET transmitidos e recebidos. Nas modalidades mais simples, nos concentramos apenas nos aspectos de luminância das transformações de cor, deixando o processamento de cores como essa etapa única de pré-processamento, mas o versado na técnica compreende que outras estratégias de saturação são possíveis, e podem ser coordenadas de modo inteligente com o processamento de luminância. As cores têm, agora, seus valores corretos (R,G,B) para realizar um processamento puro voltado para a luminância.

[018] Uma propriedade-chave de tais modalidades de transformação de cor, conforme mostrado na Figura 1, é que se pode realizar uma alteração de escala pura da cores (isto é, alterar apenas a propriedade de cor correlacionada à luminância, isto é, qualquer medida que meça o comprimento do vetor de cor da cor enquanto retém as razões dos componentes de cor que determinam a cromaticidade da cor, sendo que as funções matemáticas da transformação de cor podem, obviamente, ser incorporadas de várias maneiras, por exemplo, nos componentes RGB lineares conforme mostrado), cuja transformação de cor pode-se, conforme explicado, reformular como uma transformação comum de múltiplas alterações de escala (com um número real g, por exemplo 0,753, ou qualquer codificação do mesmo que possa ser convertida em um número real, por exemplo INT(1000*g)) nos três componentes de cor de modo similar. Isso define nosso mapeamento HDR para LDR (ou, de modo similar, nosso mapeamento LDR para HDR, ou um mapeamento de qualquer primeira imagem classificada de uma primeira faixa dinâmica para uma segunda faixa dinâmica significativamente diferente, sendo que as duas diferem em seu brilho de pico associado de sua tela de referência associada, isto é, a luminância corresponde ao código máximo na codificação de N bits, de geralmente ao menos um fator de 4 isto é, 2 paradas, ou ao menos um fator de 1,5 ou 2, e possivelmente várias outras paradas), ao menos no que diz respeito aos aspectos de luminância dos objetos da imagem, que é a questão dominante nas conversões de faixas dinâmicas.

[019] No (mero) exemplo esclarecedor da Figura 1, o processamento é da seguinte forma. O calculador de máximos 107 calcula para cada cor de pixel qual dos componentes RGB é o mais alto, por exemplo, o componente vermelho é 0,7 (o qual chamaremos de Rmax). Isso será uma medida do comprimento do vetor de cor, isto é, uma modalidade de um correlato de luminância. O mapeador de luminância 102 aplica uma sequência de transformações nesse componente máximo, sendo a codificação dessas transformações recebida nos metadados MET, as quais, por fim, resultam em uma transformação funcional de luminância total. Essa transformação codifica como as luminâncias normalizadas para 1 da imagem HDR devem todas ser alteradas para se obter a imagem LDR com a aparência LDR classificada artisticamente correta. Por exemplo, geralmente são aplicadas as seguintes transformações, as quais o classificador no lado de codificação/criação de conteúdo especificou como fornecendo uma boa aparência LDR, classificando em seu software de classificação e então clicando no botão Salvar depois de estar satisfeito com a aparência LDR. Primeiramente, um multiplicador de ganho 108 multiplica o componente máximo (por exemplo, Rmax) por um fator de ganho recebido (gai), produzindo Rmax_1, um valor diferente entre 0 e 1 para cada pixel (por exemplo, em algumas modalidades o classificador poderia ajustar o nível de 70% das luminâncias HDR para o nível 100% das luminâncias LDR, ou alguma outra classificação desejada). Deve-se notar que o processamento é realmente feito no máximo dos três componentes de cor, e não, por exemplo, na luminância da cor, apesar do fato de que um comportamento de transformação de luminância possa ter sido transmitido. Em seguida, uma unidade de aplicação de função de potência 109 eleva o resultado atual Rmax_1 para uma potência gam, sendo que o número gam é novamente lido dos metadados recebidos, produzindo o resultado Rmax_2. Então, a unidade de ajuste de exposição 110 aplica uma transformação de modificação de exposição global, como, por exemplo, mediante a aplicação da seguinte equação:

[020] Rmax_3= ln ((lg-1)* Rmax_2+1)/ln (lg), onde lg é novamente um número otimizado pelo classificador recebido e ln o logarítmico neperiano (natural) de base 2,71, produzindo Rmax_4. Então, uma curva padronizada é aplicada pelo mapeador de luminância 111, produzindo Rmax_4=CC(Rmax_3). Isto é, essa curva pode ser transmitida, por exemplo, como um número de pontos característicos (por exemplo, 6) (ares coordenados de luma de entrada/luma de saída), entre os quais podem ser calculados pontos intermediários no lado de recepção com o uso de alguma estratégia de interpolação transmitida ou previamente acordada (por exemplo, interpolação linear), e então a seguinte função é aplicada: por exemplo, se Rmax_3=0,7, a função transmitida específica produz para esse valor Rmax_4=0,78. Finalmente, um conformador de transformação de tela 112 faz a transformação de acordo com a função gama usada de uma típica tela LDR (esse último conformador de transformação de tela pode também ser opcional, para telas que recebem entrada em coordenadas lineares), isto é, o inverso da função gama da Rec. 709 geralmente. O versado na técnica compreenderá como essas equações podem ser formuladas por estratégias equivalentes, por exemplo, mediante a formação de uma única LUT para aplicar todos os possíveis valores de entrada de max (R,G,B) em [0,1]. Deve- se compreender que algumas das unidades podem ser ignoradas, por exemplo, o ganho gai pode ser ajustado em 1,0, que o remove efetivamente, uma vez que o mesmo tem um processamento de identidade como resultado. Certamente, outras funções de transformação podem também ser usadas, por exemplo, aplicando-se apenas uma curva padronizada, mas nossa pesquisa revelou que o exemplo parece uma forma pragmática para classificadores obterem uma boa aparência LDR. O que é importante para nossas modalidades abaixo é que se pode construir qualquer estratégia de processamento de luminância desejada, em que aquela aqui descrita é meramente uma estratégia muito boa em termos práticos.

[021] Finalmente, então, um fator multiplicativo comum g é calculado, dividindo-se o resultado de todas essas transformações, isto é, por exemplo f(Rmax) pelo próprio máximo dos componentes de entrada RGB, isto é, por exemplo, Rmax. Esse fator g é calculado para ser capaz de apresentar a transformação de luminância como uma estratégia de multiplicação. Finalmente, para se obter a cor de saída desejada e seu brilho LDR desejado, um multiplicador de alteração de escala 114 multiplica os valores de RGB de entrada, ou neste exemplo os valores resultantes do processamento de saturação opcional (processador de saturação de cor 106), com o fator multiplicativo comum g para fornecer as cores corretas com a luminância ajustada para todos os objetos da imagem, ou, de fato, todos os pixels de imagem nesses objetos. Isto é, nesse exemplo, isso resulta na aparência LDR classificada como uma imagem RGB linear, começando de uma imagem HDR inserida em S_im, da qual as cores de pixel (R2,G2,B2) são fornecidas sobre uma saída de imagem 115. Certamente, o versado na técnica compreende que, mesmo tendo a aparência colorimétrica correta para uma imagem LDR, suas cores ainda poderão ser codificadas de acordo com qualquer princípio para uso adicional, assim como a própria imagem (por exemplo, uma aplicação será enviar o sinal para o controlador de LCD via um barramento a partir do CI de cálculo, mas uma outra aplicação pode ser enviar a imagem através de uma conexão HDMI para um aparelho de TV para renderização, diretamente ou com processamento adicional de ajuste fino específico do fornecedor da tela, sendo que potencialmente alguns metadados adicionais são incluídos com o sinal de vídeo transmitido para orientar o ajuste fino).

[022] O leitor deve entender, também, um importante princípio adicional de nossa tecnologia de codificação e uso de HDR. Até agora com referência à Figura 1 explicamos apenas como se pode codificar duas aparências de faixas dinâmicas diferentes (isto é, com os brilhos de todos os objetos coordenados de maneira correspondente) de uma cena HDR, isto é, como codificar duas imagens originais classificadas por um criador de conteúdo. E por que fazemos isso? Tudo seria simples se houvesse apenas uma tela LDR (100 nits), e em particular apenas um tipo de tela HDR (por exemplo, de 5000 nits) nas instalações dos vários observadores de conteúdo. A tela LDR exibiria, então, a classificação LDR, e a tela HDR, o que quer que fosse, exibiria a “classificação HDR”. Isso funcionaria bem para brilhos de pico de tela com desvio moderado em relação ao brilho de pico da imagem recebida para renderização, mas provavelmente não forneceria bons resultados para grandes desvios. Em particular, qual imagem uma tela de 1000 nits precisaria exibir: a de 100 nits, ou a de 5000 nits? Agora, poderia-se muito bem classificar ao menos uma ou mais imagens com exatamente a mesma tecnologia que aquela mostrada na Figura 1, por exemplo, determinar as funções de transformação de cor para realmente calcular a classificação de melhor aparência para telas com PB_D de cerca de 1000 nits. A aparência em cerca de 500 nits ou 2500 nits talvez ainda seria inadequada, pelo menos para algumas cenas HDR de importância crítica (por exemplo, um monstro no escuro pode se tornar escuro demais para que ainda seja visto, ou, ao contrário, pode se tornar irrealisticamente brilhante, ou o contraste de outro monstro na neblina cinza poderia se tornar tão baixo a ponto de torná-lo invisível etc.). Em muitos cenários (e especificamente em aplicações de difusão em tempo real), o classificador pode não se importar em fazer uma terceira classificação com funções de transformação de segunda cor nos metadados MET_TR2, ou talvez nem queira gastar muito tempo nos detalhes de criação da segunda aparência classificada (por exemplo, a LDR derivada da HDR mestra). Portanto, introduzimos o princípio de que, de um lado, é possível conhecer muito sobre a semântica real da cena HDR a partir da observação de duas classificações que se encontram geralmente em lados extremos, no que diz respeito ao uso contemplado típico, da escala de brilho de pico. Por exemplo, pode-se ver que uma explosão tem seu brilho intensificado na cena HDR em comparação com a cena LDR, onde não há muitos códigos disponíveis acima daqueles necessários para renderizar suficientemente o restante da cena (ou ao contrário, pode-se ver que a explosão é reduzida em LDR em comparação com sua impressionante versão brilhante em uma imagem HDR). Isso não nos diz necessariamente como se deve intensificar a explosão para um PB_D específico, por exemplo se a intensificação deve começar agressivamente de imediato ou apenas para telas HDR de alta qualidade, por exemplo com PB acima de 2000 nits, mas pelo menos sabe-se que para classificações intermediárias (MDR) seria preciso intensificar a bola de fogo da explosão. Em termos de tecnologia, o que é necessário depende da situação, como a complexidade do tipo de cena HDR, e da urgência do usuário, em equilíbrio com o que é comum no campo de aplicação específico, tempo e custo exequíveis etc. O princípio reside em que o lado de recepção, por exemplo, CI do “settopbox” ou TV, possa derivar por si só as outras classificações necessárias (entre as duas classificações recebidas, ou mesmo fora da faixa), geralmente com alguma assistência do lado de criação, com metadados que são diferentes em natureza das transformações de cor usadas para criar uma segunda classificação real original, isto é, conforme o material artístico especificado e aprovado pelo classificador. Também porque a física e os requisitos técnicos envolvidos nessa chamada fase de ajuste de tela serão diferentes. Deve-se notar que, embora sejam descritas versões onde o criador realmente transmite parâmetros que são ideais para a presente cena HDR de acordo com suas preferências particulares, ensina-se também que os mesmos princípios podem ser aplicados exclusivamente no lado de recepção, por exemplo, onde o aparelho de recepção executa uma análise de imagens para obter um valor de parâmetro de ajuste de tela adequado, por exemplo gpr ou gpm. Para algumas cenas, não é tão crítico qual será a luminância renderizada final dos vários objetos da imagem, por exemplo a luz em um ambiente fechado na vida real pode ser um pouco mais intensa, e, dessa forma, a luz do ambiente externo vista através de uma janela poderia ser relativamente mais ou menos intensa. Nesse caso, o aparelho ou o classificador pode decidir, com uma ferramenta técnica muito simples, ajustar a aparência para ser um pouco mais brilhante (por exemplo, 3 passos unitários em alguma faixa) em comparação com o resultado da execução de um algoritmo de referência, ao menos para uma parte da faixa de luminância. Para algumas cenas mais críticas, o classificador, ou o fabricante da tela, por exemplo, para aprimorar automaticamente a imagem, ou fornecer ao usuário um controle de interface de usuário de aparência mais inteligente, pode desejar um controle mais preciso sobre várias partes da cena HDR (em particular várias faixas de brilho, mas em alguns cenários, pode haver, por exemplo, informações que possibilitam identificar objetos específicos, caso em que pode ser executado um ajuste de tela dependente de objeto), para várias subfaixas da faixa de possíveis brilhos de pico de tela, desde que, obviamente, tudo esteja em sintonia com as típicas limitações de hardware para esses tipos de tecnologia.

[023] Assim, simplesmente codificar e decodificar ainda que apenas duas possíveis imagens de faixa dinâmica classificadas de uma cena capturada não é uma tecnologia suficiente para tratar completamente e de modo correto o uso de imagens HDR, uma dura lição que as pessoas ávidas para chegar a esse mercado com soluções demasiadamente simples tiveram de aprender, e, dessa forma, precisa-se também, juntamente com os princípios de codificação coordenados conjuntamente, de uma metodologia de ajuste de tela, e, em particular, uma que seja pragmática dadas as necessidades típicas, limitações e preferências de manuseio de vídeo, em particular de vídeo HDR.

[024] Com isso, após essa longa, mas necessária introdução, já que tudo nesse campo muito recente de codificação de imagens HDR, em particular de vídeo, é muito novo, e especialmente pelo fato de que algumas das abordagens técnicas da Requerente não são sequer conhecidas, quanto mais comumente conhecidas, chegou-se aos detalhes dos fatores, componentes, modalidades e linhas de raciocínio recém desenvolvidas para o ajuste de tela. A invenção descrita abaixo resolve o problema apresentando um método pragmático, mas poderoso no que diz respeito às várias necessidades de ajuste de otimização para o processamento de alteração de escala comum (multiplicativo) que definem a aparência colorimétrica de ao menos duas imagens classificadas, de obtenção de classificações intermediárias (aparências reclassificadas (semi)automaticamente da faixa dinâmica média (MDR)) para telas reais, a ser conectado e fornecido com uma imagem otimizada para renderização, que pode ser calculada em qualquer lado de recepção com o uso de um aparelho de transformação de cor (201) para calcular cores resultantes (R2, G2, B2) de pixels de uma imagem de saída (IM_MDR) que é ajustada para uma tela com um brilho de pico de tela (PB_D) a partir de cores de entrada (R,G,B) de pixels de uma imagem de entrada (Im_in) que tem um código de luma máximo correspondendo a um brilho de pico de primeira imagem (PB_IM1) que é diferente do brilho de pico de tela (PB_D), caracterizado pelo aparelho de transformação de cor compreender:

[025] - uma unidade de determinação de transformação de cor (4201, 102; 2501) disposta de modo a determinar uma transformação de cor (TMF) a partir de dados de especificação de processamento de cores (MET_1) compreendendo ao menos uma função de mapeamento de luminância (CC) recebidos através de uma entrada de metadados (116), sendo que os dados de especificação de processamento de cores especificam como as luminâncias dos pixels da imagem de entrada (Im_in) devem ser convertidos em luminâncias para os pixels de uma segunda imagem (Im_RHDR) que tem, correspondendo ao seu código de luma máximo, um brilho de pico de segunda imagem (PB_IM2), que é diferente do brilho de pico de tela (PB_D) e do brilho de pico de primeira imagem (PB_IM1), e sendo que a divisão do brilho de pico de primeira imagem pelo brilho de pico de segunda imagem é maior que 2 ou menor que 1/2;

[026] - uma unidade de determinação do fator de alteração de escala (4205, 200; 1310) disposta de modo a determinar um fator multiplicativo comum resultante (gt; Ls), sendo que a unidade é disposta de modo a determinar esse fator multiplicativo comum resultante mediante as etapas de: primeiro estabelecer ao longo de uma direção predeterminada (DIR), que tem um ângulo em sentido anti-horário diferente de zero em relação à direção vertical sendo ortogonal a uma direção que abrange as luminâncias da imagem de entrada, uma métrica preestabelecida (1850, METR) para localizar os brilhos de pico de tela, e uma posição (M_PB_D) nessa métrica que corresponde ao valor do brilho de pico de tela (PB_D), sendo que a métrica começa na posição de uma diagonal representando uma função de transformação de identidade, e, segundo, estabelecer uma transformação de segunda cor (1803; F_M) para determinar ao menos luminâncias das cores resultantes (R2, G2, B2) dos pixels da imagem de saída (IM_MDR), sendo que a transformação de segunda cor está baseada na transformação de cor (TMF) e na posição (M_PB_D);

[027] e, terceiro, determinar o fator multiplicativo comum resultante (gt; Ls) com base na transformação de segunda cor (1803; F_M); e sendo que o aparelho de transformação de cor (201) compreende adicionalmente

[028] - um multiplicador de alteração de escala (114) disposto para multiplicar cada um dos três componentes de cor de uma representação de cor das cores de entrada pelo fator multiplicativo comum resultante (gt) para obter as cores resultantes (R2, G2, B2).

[029] Conforme ficará evidente para o versado na técnica ao estudar as várias possibilidades descritas abaixo, queremos desde já enfatizar alguns fatores que não devem ser lidos com limitação de escopo, para que sejam entendidos os conceitos fundamentais. Primeiramente, embora todas as telas adicionais funcionem, no final das contas, com componentes de cor RGB, os cálculos de cor podem, de forma realmente equivalente, ser feitos em outras representações de cor. A transformação de cor inicial que precisa ser determinada ou estabelecida é o mapeamento entre as duas imagens classificadas representativas de faixas dinâmicas diferentes e transmitidas conjuntamente, por exemplo, a conversão SDR para HDR_5000nits. Isso já contempla variantes nas diversas modalidades, porque algumas variantes mais simples podem comunicar essa transformação necessária como uma única função de mapeamento de luminância ou de matiz (CC), mas outras modalidades podem comunicar a transformação de cor necessária total, ou mesmo a parte de transformação de luminância da mesma, como uma sequência de transformações de cor; por exemplo, no lado de criação, o classificador de cor humano, ao derivar idealmente a SDR a partir da HDR mestra, fez primeiro um novo clareamento aproximado de brilho de várias regiões da imagem, e então projetou um ajuste fino para alguns objetos na imagem (cujas alterações de luminância diferenciais podem também ser comunicadas em tal modalidade alternativa através do formato da curva CC). O que precisa realmente ser calculado é uma ou mais funções ideais finais para calcular não a imagem HDR, mas a imagem MDR (por exemplo, para um PB_D de 1650 nits) a partir da imagem SDR recebida.

[030] Isso pode ser feito também de várias maneiras em outras modalidades; por exemplo, algumas modalidades podem calcular uma vez uma função de mapeamento de luminância final para quaisquer luminâncias (ou lumas) SDR possíveis na imagem de entrada, carregá-la na parte de cálculo de cor, por exemplo, como uma tabela de valores de gt a serem usados, e então processar a transformação de cor pixel por pixel. Porém, alternativamente, as determinações de qualquer cálculo de função parcial pode ocorrer em tempo real à medida que os pixels são recebidos, mas o versado na técnica compreenderá como o formato da função (ou funções) de reclassificação desejada precisa ser estabelecido para essa imagem específica ou cenas de imagens, primeiro, a partir do que foi projetado pelo criador de conteúdo, e então, para o que é preciso de modo coordenado para as limitações da tela conectada ou a ser servida.

[031] Dessa forma, pode-se definir imagens de aparências diferentes para controlar telas de um certo brilho PB_D que podem ter muitos valores e que não correspondem ao PB da imagem recebida (nem ao brilho de pico de outra imagem classificada derivável da mesma, mediante aplicação das transformações de cor recebidas diretamente em uma imagem de entrada, cujas funções são uma especificação de como derivar exclusivamente para esse outro par das duas imagens, por instante no tempo, no caso de um vídeo), com base naquela imagem recebida e uma transformação de cor adequadamente definida (a qual, para fins de entendimento, o leitor pode, sem limitação, assumir que seja criada por um classificador de cor humano) compreendendo ao menos uma transformação de luminância (a qual também pode ser realmente definida e recebida como metadados, e/ou aplicada durante os cálculos como uma transformação de luma, uma vez que uma transformação de luminância pode ser convertida exclusivamente em uma transformação de luma equivalente). Qualquer lado de recepção pode, ao menos parcialmente, decidir quanto ao formato de tal função, uma vez que esse formato será pelo menos ajustado por uma propriedade de renderização no lado de recepção como, por exemplo, PB_D, mas, de preferência, o mesmo é também definido pelo criador de conteúdo, o que pode, geralmente, ser feito com o uso das funções de transformação de cor que definem uma relação entre uma imagem LDR e uma imagem HDR. Devido ao fato de que, idealmente, o ajuste de tela deve levar em conta também os requisitos específicos de qualquer cena ou imagem HDR específica (os quais podem variar muito em termos de tipo de objeto e necessidades semânticas dependentes do tipo de objeto para a renderização de luminância dos vários objetos da imagem), é isso que as presentes modalidades relacionadas às funções que já foram definidas para a codificação do par de imagens podem tratar. Essa transformação de cor pode, então, ser finalmente aplicada como uma estratégia de multiplicação aos componentes de cor vermelho, verde e azul (originais ou com a escala de luminância alterada, por exemplo em uma representação normalizada para um máximo de 1,0), linear ou não linear (ou mesmo em outras modalidades à representação Y’CbCr ou outras representações de cor).

[032] A relação entre uma função necessária (ou, de fato, seus fatores gt multiplicativos correspondentes), isto é, um formato desviado dessa função começando a partir de uma transformação de identidade ou sem processamento (a função diagonal que mapearia os lumas SDR em si mesmas no eixo y no caso da borda, quando teoricamente seria calculada a classificação SDR a partir da classificação SDR recebida, ou a HDR a partir da HDR, o que, certamente, não seria realmente feito, mas deveria também ser corrigida para qualquer projeto de tecnologia de acordo com nossos vários princípios, ou seja, uma boa maneira de entender e formular a tecnologia) será determinado estabelecendo-se uma métrica de modo geral. Essa métrica pode ser vista como uma “expansão” da função de caso externo, ou seja, caso se deseje calcular a imagem HDR_5000 nits a partir da imagem SDR recebida (isso é ilustrado para um cenário simples na Figura 18, entre outras). Certamente, os casos mais complicados podem tratar de questões como usar uma métrica variável para as várias possíveis lumas de imagem de entrada (o que pode ser feito, por exemplo, com uma modalidade como a mostrada na Figura 6), e/ou o formato da função pode ser alterado a partir do formato recebido, por exemplo, para ajuste de tela, o comportamento dos pixels mais escuros pode ser alterado, o que pode ser feito, por exemplo, mediante a introdução de um desvio extra ou função de orientação etc. Mas, um aspecto essencial é que pode-se estabelecer uma métrica, e que o valor de PB_D da tela pode, então, ser calculado para uma posição nessa métrica para qualquer luma ou luminância de entrada. A pesquisa dos pesquisadores mostra também que é vantajoso poder selecionar várias direções para a métrica, por exemplo, a direção ortogonal para a diagonal tem uma boa influência de controle do brilho necessário quando é feito o mapeamento da HDR para a SDR, ou vice-versa, com as funções inversas. Para concluir, o versado na técnica pode entender, a partir dos ensinamentos da presente invenção, que a capacidade de localizar um conjunto de M_PB_D (ou M_PB_U em outras modalidades) aponta para cada possível luma de entrada em um gráfico de luminâncias ou lumas (por exemplo, uma luminância normalizada ou não normalizada, isto é, SDR de entrada real (ou HDR na Figura 18) no eixo x, e alguma luminância no eixo y, que pode ser qualquer luminância MDR necessária, por exemplo, em um eixo que expande até o máximo da imagem HDR, isto é, PB_C=5000 nits, por exemplo), estabelece uma função ideal final (na medida em que cria uma imagem de aparência correspondente à uma imagem HDR dadas as limitações da renderização de tela, e as limitações de cálculo pragmático, escolhidas, por exemplo, em função da complexidade de um CI que um fabricante de TV ou STB pode arcar) para calcular os lumas de imagens MDR a partir dos lumas de entrada (deve-se observar que as imagens MDR fora da faixa entre as duas classificações transmitidas conjuntamente também podem ser calculadas).

[033] Em uma modalidade útil, a direção (DIR) situa-se entre 90 graus correspondendo a uma métrica vertical em um gráfico de luminância ou luma de entrada e de saída, e 135 graus correspondendo a uma métrica diagonal.

[034] Em uma modalidade útil, dois pontos externos (PBE, PBEH) da métrica correspondem a um brilho de pico da imagem de entrada recebida (PB_L) pela imagem codificada conjuntamente pelas funções de transformação de cor de outro brilho de pico (PB_H) que pode ser reconstruída a partir daquela imagem mediante aplicação das funções de transformação de cor recebidas nos metadados compreendendo a ao menos uma função de mapeamento de matiz (CC) para ela, e sendo que o aparelho calcula uma imagem de saída (IM_MDR) para uma tela com um brilho de pico de tela (PB_D) que se situa dentro dessa faixa de brilhos de pico (PB_L para PB_H).

[035] Em uma modalidade útil, a métrica é baseada em uma representação logarítmica dos brilhos de pico de tela. Já em modalidades simples, pode-se assim otimizar a aparência de faixa dinâmica e luminância dos vários objetos da imagem de maneira simplificada, por exemplo, pelo valor gp da equação superior dentre as Equações 1 abaixo, que corresponde a uma modalidade de determinação de uma posição dependente do PB_D na métrica, e o consequente formato determinado corretamente das funções para a derivação de imagem MDR a partir de SDR (ou, em geral, MDR a partir de HDR). Mas, certamente, em modalidades mais complexas como indicado acima, as posições na métrica que correspondem à função de transformação de luminância necessária podem variar de modo mais complexo, por exemplo, com base nos parâmetros comunicados especificando um comportamento desejado de reclassificação determinado pelo criador de conteúdo, ou nos parâmetros ambientais como, por exemplo, uma medida, estimativa ou valor equivalente da iluminação circundante (por exemplo, inserido pelo observador, em relação ao que o mesmo consegue ver confortavelmente em tal iluminação) etc., mas, ainda assim, as derivações podem, geralmente, começar a partir de uma quantificação logarítmica do valor de PB_D realmente disponível entre os valores de PB_C das duas LDR e HDR classificadas transmitidas.

[036] Uma modalidade útil tem a unidade de determinação do fator de alteração de escala (200) disposta adicionalmente para obter um parâmetro de ajuste (gpr; gpm) a partir dos segundos dados de especificação de processamento de cores (MET_2) que foram determinados anteriormente no momento da criação da imagem de entrada (Im_in), e disposta de modo a calcular um fator multiplicativo comum resultante (gtu) correspondendo a uma posição na métrica diferente da posição para o brilho de pico de tela (PB_D), sendo que a posição diferente se baseia no valor do parâmetro de ajuste. É importante que o leitor dedique algum tempo para refletir sobre esse aspecto e entendê-lo. Existe um primeiro mecanismo que possibilita que o lado de criação de conteúdo determine o formato exato das funções que fazem o mapeamento entre a classificação da imagem HDR e da LDR, isto é, as imagens criadas no lado de transmissão e estabelecidas no lado de recepção (por exemplo, com PB_C de 100 e 5000 nits). Isso possibilita, de acordo com o nível de qualidade exigido por cada aplicação HDR particular, determinar como as luminâncias dos objetos da imagem HDR devem ser mapeadas para as luminâncias SDR, o que pode não ser uma tarefa simples. Por exemplo, no caso de uma cena de uma vitrine intensamente iluminada no período noturno, e se ao lado dela houver algumas bicicletas no escuro, o classificador poderá usar (conforme apresentado com a Figura 1) uma ou mais funções de mapeamento de luminância para determinar de modo mais ou menos preciso quais luminâncias as bicicletas no escuro devem ter (para que sejam, por exemplo, visíveis apenas em uma típica renderização de imagem SDR, e não brilhantes demais para prejudicar a ilusão, nem invisivelmente imersas na escuridão). Por outro lado, para o objeto brilhante sob as luminárias na vitrine, pode não ser também uma tarefa trivial selecionar as luminâncias ideais, que, ao mesmo tempo, criam uma boa diferença de brilho com as partes escuras da imagem, e um bom contraste e riqueza cromática intra-região para os objetos atrás da vitrine (e ao mesmo tempo, como o leitor deve recordar, também assegurar, mediante a seleção dessas funções, a capacidade de reconstrução da Im_RHDR quando tal imagem classificada SDR for enviada). Dessa forma, isso já é uma tarefa que a tecnologia deveria ser capaz de tratar suficientemente bem, mesmo quando são criadas apenas duas imagens classificadas (por exemplo, de 100 e 1000 nits). A ideia por trás da solução pragmática para derivar as imagens MDR, apresentada no presente documento, é que haja tantas informações importantes nessas funções de transformação de cor, que elas possam ser usadas por algoritmos no lado de recepção para criar boas imagens MDR correspondentes. Contudo, dependendo da imagem e, em particular, da complexidade da cena HDR, ao se utilizar tal algoritmo de criação automática de imagens MDR, é possível que ocorra alguma perda de precisão em comparação com esse par classificado de forma perfeccionista de imagens LDR e HDR representativas. Assim, no caso do criador de conteúdo (isto é, geralmente das preferências do classificador de cor), ele pode enviar um segundo conjunto de metadados de acordo com suas preferências, para controlar mais precisamente a maneira real na qual a(s) função(ões) de transformação de MDR são derivadas, por exemplo como a métrica é construída e os pontos dependentes do PB_D na métrica são calculados, conforme exemplificado, por exemplo, na Figura 6. Dessa forma, enfatiza-se que os metadados da transformação de primeira cor (para cálculo, por exemplo, da reconstrução HDR mestra, Im_RHDR, a partir das imagens SDR recebidas Im_in), especificam como a reclassificação deve ocorrer aproximada e globalmente começando com duas classificações exemplificadoras diferentes (sendo o PB_C da HDR, por exemplo, geralmente 10x mais alto que os 100 nits da classificação SDR, mas de preferência mais alto, ao menos para cenas HDR de alta qualidade), mas que o segundo conjunto de metadados (MET_2) possibilita adicionalmente especificar o comportamento real do ajuste de tela para várias limitações de renderização que poderiam ocorrer devido ao classificador. Ele pode fazer isso de várias maneiras, por exemplo, sabendo que alguma região de sombra crítica deve ser tratada com cuidado porque há uma ação importante ocorrendo nela, e ser rapidamente clareada para a maioria dos cenários de renderização, ou, alternativamente, que algumas regiões brilhantes podem ser cortadas fortemente (corte suave) etc., ou o classificador pode, por exemplo, observar o comportamento em alguma típica tela de referência MDR (por exemplo, de 500 nits para codificações HDR de 1000 nits).

[037] Em uma modalidade útil, a unidade de determinação do fator de alteração de escala (200) está disposta de modo a determinar a posição diferente aplicando uma função monotônica que fornece como resultado uma posição normalizada na métrica como função de ao menos um parâmetro de entrada (gpr), sendo que a função monotônica pode ser determinada pela transformação de cor de modo autônomo, ou com base nos metadados de prescrição que prescrevem qual formato de função será usado, o qual foi determinado anteriormente em um momento da criação da imagem de entrada (Im_in). Pode ser útil determinar o comportamento de posicionamento como uma função. Isso possibilita um comportamento similar ao longo das métricas, no caso de alguém desejar isso, apesar do comprimento dessas métricas variar ao longo da função, isto é, as possíveis lumas de entrada. Por exemplo, isso possibilita simular que todas as telas acima de um dado limiar, por exemplo, 90% do PB_C_HDR (isto é, por exemplo 4500 nits) são supostamente idênticas à tela de referência HDR com PB_D=5000 nits, e renderizar uma imagem MDR que seja tão próxima quanto possível da classificação HDR mestra. Tal função poderia ser estabelecida pelo próprio aparelho de recepção (como um comportamento inato, por exemplo de algum modo de renderização de filme que pode ser selecionado), ou algumas informações na função podem ser transmitidas a partir do lado de criação, por exemplo, toda a própria função monotônica. Enfatiza-se que essa função é aquela que posiciona o ponto M_PB_D ao longo da métrica, isto é, dependendo do PB_D, mas ainda, por exemplo, mais próximo da função de mapeamento da SDR para a HDR mestra do que, por exemplo, o cálculo logarítmico prescreveria (conforme ilustrado, por exemplo, na Figura 15), e essa função não deve ser confundida com as funções para calcular a imagem HDR a partir da imagem SDR, isto é, a(s) função(ões) de transformação de luminância.

[038] Uma modalidade útil compreende uma unidade de análise de imagens (1110) disposta de modo a analisar as cores de objetos na imagem de entrada (Im_in), e, a partir daí, determinar um valor para ao menos um dos parâmetros que controlam o cálculo da imagem de saída (IM_MDR), por exemplo, o parâmetro de ajuste (gpm), ou a direção (DIR), ou o formato da função monotônica que fornece como saída uma posição normalizada na métrica a ser usada no cálculo do fator multiplicativo comum resultante (gt). Algumas modalidades podem fazer bom uso do conhecimento nas funções de transformação de luminância criadas no lado de criação de conteúdo e, ainda assim, determinar o ajuste de tela, em grande parte por elas mesmas. Elas podem, então, por exemplo, avaliar qual tipo de regiões escuras, claras e de brilho intermediário existe na imagem, e, por exemplo, determinar uma direção DIR, que influencia como as regiões de luminância média intermediárias são alteradas (por exemplo, sua luminância de saída e contraste) em comparação com o tratamento, por exemplo compressão, dos realces (isso pode ser feito de modo diferente para a vitrine mencionada anteriormente, que contém objetos significativos que o observador deve reconhecer, em particular se houver objetos comerciais importantes, como, por exemplo, um nome comercial gravado ou jateado em uma janela, isto é, com baixo contraste, mas que ainda precisa ser reconhecível em todas as telas MDR, em comparação, por exemplo, com algumas lâmpadas que poderiam também ser cortadas em uma única cor branca para a maioria dos usuários).

[039] Uma outra modalidade útil do aparelho compreende uma unidade de determinação da quantidade de corte (3710) disposta de modo a determinar uma quantidade mínima de corte abrupto (“hard clipping”) aplicada ao brilho de pico de tela (PB_D) para uma subfaixa das luminâncias mais brilhantes da imagem de entrada (Im_in), sendo que o cálculo do fator multiplicativo comum resultante (gt) é determinado para luminâncias da imagem de entrada dentro da subfaixa para mapear a luminância de entrada para o brilho de pico de tela (PB_D). No caso do criador de conteúdo ou dos fabricantes de TV desejarem ou possibilitarem uma quantidade mínima de corte (para uma pequena subfaixa, por exemplo, os 10% mais brilhantes das luminâncias dos 3% mais brilhantes dos lumas), essa unidade 3710 pode especificar essa preferência. Uma modalidade para se conseguir isso pode ser por meio de alguma auxiliar F_ALT, orientando o cálculo da função de mapeamento de luminância final a ser empregada (F*) conforme determinado pela unidade de determinação da função de luminância (3712). Um exemplo de tal método pode ser através do uso de uma função F_ALT que é uma função de corte, isto é, uma função que fornece um resultado de saída de PB_D (por exemplo, 1500 nits para uma tela que pode renderizar maximamente 1500 nits de branco) independentemente do luma de entrada, e esta é apenas das funções alternativas que o gerador de função 3711 pode gerar.

[040] As modalidades abaixo também são de interesse. A unidade de determinação da função de luminância 3712 pode, então determinar a função final a ser carregada, por exemplo, em uma LUT realizando um cálculo dos lumas MDR diretamente a partir dos lumas de imagem de entrada SDR (isto é, carregar, por exemplo, na unidade 2501 dessa topologia exemplificadora) uma função resultante que é uma mudança brusca ou esmaecimento gradual em direção à estratégia de ajuste alternativo de corte abrupto (vide Figura 38 para uma descrição exemplificadora das possibilidades).

[041] Uma outra modalidade interessante, especialmente para se fazer ajustes dependentes da iluminação circundante, tem uma unidade de estimativa de nível de tons de preto (3702) para estabelecer uma estimativa de um nível de tons de preto, em que o cálculo do fator multiplicativo comum resultante (gt) depende de nível de tons de preto. Essa pode ser uma outra unidade em uma unidade de determinação de função ideal (3701), que pode, por exemplo, ser um software trabalhando em correspondência com uma parte de transformação de cor de núcleo em um CI (isso possibilita a atualização via firmware, por exemplo, para possibilitar estratégias de ajuste novas ou melhores, ou vários níveis de qualidade dependendo do canal de liberação de conteúdo, ou uma assinatura etc.). A estimativa de nível de tons de preto, geralmente indicando um nível de luminância ou nível de luma na tela MDR realmente disponível, isto é, na imagem MDR, abaixo do qual os detalhes da imagem serão pouco ou nada visíveis, pode ser realmente determinada de várias formas, por exemplo solicitando ao observador um valor pragmaticamente bem funcional através de uma interface de usuário como um controle remoto, isto é, alguma entrada 3755 para obter a estimativa do nível, que poderia também estar conectado a um medidor de iluminância, ou uma câmera etc.

[042] É interessante também variar as modalidades em uma direção que controle o comportamento de ajuste para ajustes em múltiplas etapas, por exemplo uma modalidade na qual o cálculo do fator multiplicativo comum resultante (gt) se baseia em uma função de mapeamento de luminância aproximado (Fcrs) e uma função de mapeamento de luminância fino (CC), caracterizadas por primeiramente ser determinada uma função de mapeamento aproximado otimizada (FCrs_opt) com base em pelo menos o brilho de pico de tela (PB_D) para se determinar subfaixas ideais das luminâncias que correspondem à situação real da tela de renderização, e esse mapeamento aproximado ser aplicado à imagem de entrada produzindo lumas aproximados (Y’CG), e então uma função de mapeamento fino é otimizada com base na função de mapeamento de luminância fino (CC) e ao menos no brilho de pico de tela (PB_D), e essa função de mapeamento fino é aplicada aos lumas aproximados. Isso possibilita, por exemplo, que os mapeamentos aproximado e fino de luminância correspondentes ao brilho de pico de tela sejam determinados ao longo de uma métrica (1850) com uma direção (DIR) diferente, sendo que, de preferência, o mapeamento aproximado é executado diagonalmente e o mapeamento fino verticalmente. Certamente, as modalidades adicionais podem, então, fazer um ajuste fino adicional e controlar a maneira como essas pelo menos duas subetapas se ajustam para várias telas MDR, mediante a recepção de segundos metadados MET_2 especificando isso (por exemplo, valor(es) de gpm ou metadados similares).

[043] Para as modalidades que se adaptam a propriedades adicionais do ambiente de visualização, isto é, além das meras características de exibição, é vantajoso que uma função de mapeamento de luminância seja primeiramente estabelecida de acordo com uma situação de visualização de referência com um nível de iluminação fixo, e subsequentemente essa função seja ajustada para o valor do nível de tons de preto, sendo que a partir da função ajustada o fator multiplicativo comum resultante (gt) é calculado, por exemplo na unidade 3701.

[044] Todas essas unidades ou aparelhos de ajuste podem ser fisicamente construídos após um decodificador (isto é, que, por exemplo, deriva a Im_RHDR em estreita correspondência com a classificação HDR mestra), ou integrado com ela, isto é, imediatamente derivando uma imagem MDR a partir da imagem SDR (a imagem HDR pode, então, ser usada no cálculo do software da função ideal para uso no mecanismo de transformação de cor de núcleo).

[045] Outras modalidades e variantes interessantes são, por exemplo, as descritas abaixo.

[046] Uma modalidade exemplificadora de um cálculo do fator multiplicativo comum resultante (gt) necessário para calcular as cores resultantes da imagem de saída compreende calcular primeiro uma razão (gp) do logaritmo de primeiramente uma razão entre um brilho de pico de uma tela (PB_D), em particular da tela conectada na qual a(s) imagem(ns) serão renderizadas e um brilho de pico de referência (PB_IM1, por exemplo, PB_H) correspondente à imagem de entrada, dividido pelo logaritmo de uma razão entre o brilho de pico de referência (PB_H) e um brilho de pico (PB_IM2, por exemplo, sendo um PB_L de uma classificação LDR) correspondendo a uma imagem (Im_LDR) de uma faixa dinâmica de luminância ao menos um fator 1,5 diferente da faixa dinâmica de luminância da imagem de entrada, que é geralmente a segunda classificação recebida da cena HDR. Depois disso, o aparelho de transformação de cor calcula o fator multiplicativo comum resultante (gt) como o fator multiplicativo comum inicial g (que foi determinado a partir da totalidade de todas as transformações de cor parciais usadas para converter entre a primeira e a segunda classificação, que pode, geralmente, ser uma imagem de aparência HDR e LDR) elevada a uma potência que é a razão (gp).

[047] Pode haver outras de tais métricas, mas a métrica não pode ser simplesmente qualquer coisa: quando usada para localizar onde exata ou aproximadamente o brilho de pico intermediário da tela (PB_D) ela deve se situar entre o PB_H e o PB_L, de modo que a aparência MDR seja satisfatória quando renderizada em uma tela com PB_D (e, em particular, é também útil se a métrica fornece bons resultados ao extrapolar aparências fora da faixa [PB_IM1, PB_IM2]).

[048] Assim, o aparelho ou método primeiro determina qual é a transformação de cor entre as duas imagens de aparência codificadas/recebidas (Im_in e IM_GRAD_LXDR, na qual IM_GRAD_LXDR pode ser uma imagem HDR ou LDR, e a outra imagem tem, então, uma faixa dinâmica consideravelmente diferente), sendo que a transformação de cor pode, em várias modalidades, ser realmente representada e transmitida à unidade que executa os cálculos como, por exemplo, uma função (entre uma entrada normalizada e uma luminância de saída), ou um ou um conjunto de fatores multiplicativos g.

[049] Em muitas modalidades, simplesmente todas as cores da imagem de saída MDR podem ser calculadas com o uso deste método, mas em outras modalidades apenas alguns dos pixels são recalculados. Por exemplo, o método pode copiar parte do cenário, ou algum texto ou elementos gráficos, por exemplo, da imagem LDR, e intensificar apenas os pixels que correspondem a uma bola de fogo uma janela com vista para o ambiente externo etc. Nesse caso, uma função também poderia ser definida em pelo menos uma parte da faixa de possíveis luminâncias etc.

[050] Em última análise, qualquer que seja o cálculo do processamento de cores necessário para derivar a imagem MDR, por exemplo, da imagem HDR, o aparelho irá converter o cálculo em um conjunto de valores de multiplicação para multiplicar pelas cores de entrada, as quais podem, geralmente, estar em uma representação de cor RGB linear (ou, de modo similar, a multiplicação poderia, por exemplo, ser feita pelo componente L de uma representação Lu’v’, em que u’ e v’ são as coordenadas CIE 1976 de cromaticidade, mas esses detalhes são irrelevantes para se entender as várias modalidades de ajuste de tela).

[051] Assim, o aparelho precisa primeiramente de uma unidade de determinação de métrica de capacidade (1303), para determinar qual métrica é necessária para localizar o valor de PB_D entre os valores PB_IM1 e PB_IM2. Essa métrica é, geralmente, não linear, e com alguns dos parâmetros de ajuste o aparelho, em alguns cenários vantajosos sob a orientação do classificador de conteúdo, pode influenciar adicionalmente a forma da não-linearidade. Isso se deve, entre outras coisas, ao fato de que o ajuste de tela não é simplesmente uma mera adaptação baseada na física da tela, mesmo sob a aparência da visão humana não linear, mas porque, em particular, mover da HDR para a LDR (especialmente faixas dinâmicas muito altas), pode ser necessário realizar otimizações complexas para acomodar todas as luminâncias de objetos juntas e ainda assim obter uma boa aparência coordenada (as coisas podem ser mais fáceis no caso de a segunda imagem também ser uma imagem HDR, ou pelo menos uma imagem MDR com PB suficientemente alto). Não obstante, apreciamos o fato das modalidades de nosso sistema serem razoavelmente simples, para, com alguns poucos parâmetros, obter pelo menos a maior parte do controle de ajuste de uma aparência, o que é necessário para classes de conteúdo HDR.

[052] A unidade de determinação de métrica de capacidade (1303) pode fazer algo tão simples quanto usar uma métrica pré-fixada (que é, por exemplo, codificada no hardware do CI), ou, em outras modalidades, ela pode determinar a aparência necessária a partir de um indicador do tipo de métrica (COD_METR) que ela recebe do criador de conteúdo através do sinal S_im recebido em um campo de metadados previamente acordado. Como várias cenas HDR podem ser manuseadas diferentemente, o classificador pode, por exemplo, informar que para uma primeira cena no filme de uma tomada em um ambiente externo ensolarado, a métrica a ser usada será a razão logarítmica (e talvez a direção será a direção vertical, ortogonal ao eixo de luminâncias de entrada, conforme mostrado abaixo), mas quando a próxima cena se tornar uma cena ao anoitecer, para obter uma aparência um pouco mais escura, o criador de conteúdo poderá impor que o ajuste de tela deve ser feito com uma métrica baseada em OETF (e, por exemplo, na direção ortogonal à diagonal de identidade, ou, em outras palavras, 135 graus em relação ao eixo da luminância de entrada). Ou, dependendo da necessidade de o conteúdo precisar ser reclassificado para MDR em tempo real (ou, por exemplo, processado para visualização posterior e armazenado em uma unidade de disco rígido (HDD) nas instalações do observador), o aparelho de transformação de cor, por exemplo, e um STB pode fazer alguns cálculos, verificar as estatísticas da imagem, e considerar que a métrica deve ser alterada um pouco, ou que o PB_D deve ser alterado, como se a exibição pretendida fosse apenas um pouco mais escura, resultando em uma imagem um pouco mais brilhante, ou qualquer alteração do ajuste de tela influenciando os parâmetros até que a aparência MDR seja considerada satisfatória, seja por um ser humano ou um algoritmo de análise automática da qualidade da imagem. A unidade de determinação de métrica de capacidade do aparelho no lado de recepção pode construir sua própria métrica, por exemplo a partir de análise estatística de conjuntos de imagens do filme, mas ela geralmente irá apenas fazer a escolha com base em um conjunto de opções pré-programadas.

[053] A unidade de determinação de multiplicador resultante (1310) irá então, conforme explicado abaixo de modo geral por meio de exemplos, posicionar a métrica no mapa de transformação de luminância (ou de fato fazer algo equivalente em seus cálculos), determinar onde o brilho de pico de tela se situa entre as imagens codificadas (isto é, se é necessária uma imagem MDR “mais HDR” ou “mais LDR”, ao menos para alguma subfaixa de cores de pixel, ou um subconjunto de pixels da imagem de entrada Im_in), e então, verificando o formato da função de transformação de luminância total, determinar para cada possível luminância de entrada qual fator multiplicativo comum resultante gt será necessário para calcular a luminância de saída correspondente ou, de fato, a cor de saída para o pixel correspondente na imagem MDR.

[054] Portanto, em vez de usar o fator multiplicativo comum inicial (g), que codifica um mapeamento de luminância para os objetos da imagem de acordo com a preferência artística de um classificador sobre como duas aparências de faixa dinâmica devem parecer, mediante o uso de nossos parâmetros técnicos de função de transformação de cor que transforma de uma primeira faixa dinâmica de uma cena capturada (por exemplo, HDR de 5000 nits como uma imagem principal) para uma segunda faixa dinâmica, por exemplo LDR (para controlar telas de 100 nits já existentes), explicada anteriormente com referência à Figura 1, e que, portanto, produz a segunda classificação de referência artística a partir das imagens da primeira classificação de referência, um novo fator multiplicativo comum resultante (gt) é calculado, o qual caracteriza uma versão adequadamente escalada em função do brilho ou ajustada em função da exibição da reclassificação que fornece uma imagem MDR. Por exemplo, o aparelho ou método pode reduzir a classificação a partir de uma imagem HDR principal (a qual, como descrito, pode ser formulada como uma única ação multiplicativa em cores de pixel RGB por um fator comum). Isso resulta em uma imagem classificada intermediária (MDR) que tem uma aparência adequada para uma tela conectável de brilho de pico intermediário, por exemplo 1250 nits, isto é, todos os objetos da cena HDR na imagem capturada são renderizados nessa tela com um brilho razoável (conforme seria desejável para o criador do conteúdo, e agradável para o observador, independentemente de serem regiões de sombra frias, lagos idílicos, o rosto iluminado de um criminoso sendo interrogado, etc.), e isso em qualquer tela particular, e potencialmente levando em conta outros fatores como ambiente de visualização etc. E, em algumas modalidades, além do brilho das cores de pixel dos objetos da imagem, também a riqueza cromática das cores de pixel pode ser otimizada conforme for desejado, mediante aplicação de uma versão escalada adequadamente de, por exemplo, uma “dessaturação” necessária para criar objetos coloridos brilhantes na classificação LDR. Um requisito importante para obter imagens classificadas corretamente para telas com brilhos de pico consideravelmente diferentes é que ao menos as luminâncias dos vários objetos sejam otimizadas corretamente para cada tela. Caso contrário, o observador poderá ver, por exemplo, algumas partes de uma imagem escuras demais, que podem até mesmo ser insuficientemente discrimináveis. Ou, alguns objetos podem ter o contraste errado, por exemplo, um contraste excessivamente baixo. Mas, devido ao fato de se ter descoberto um modo de formular transformações de luminância como uma multiplicação por um fator g, os mesmos conceitos podem ser aplicados também ao processamento de saturação de cor. E a transformação de saturação de cor também é um processo útil quando é necessário fazer a conversão entre imagens para telas com faixas dinâmicas de luminância consideravelmente diferentes, uma vez que, por exemplo, o classificador pode desejar aumentar a riqueza cromática para as partes escuras de uma cena quando renderizada em telas de baixo brilho de pico, por exemplo entre 100 e 600 nits.

[055] O cálculo de gt é feito no lado de recepção, mas pode, geralmente, ser feito também em um lado de criação para se verificar a ação dos receptores. Mesmo em algumas modalidades, o lado de criação poderia anular quaisquer cálculos dos valores gt no lado de recepção, e especificá-los diretamente para, por exemplo, uma ou mais cenas de um filme, mas nosso foco será apenas nas modalidades de cálculos mais simples na presente descrição.

[056] Pode-se fazer uma distinção entre uma aparência “nativa”, ou mais precisamente uma família de aparências para telas associadas de vários brilhos de pico (e/ou faixas dinâmicas), e uma aparência reajustada, que foi ajustada adicionalmente de acordo com alguns princípios. Pode haver várias razões para o reajuste em um lado de recepção, para o qual os parâmetros de visualização de tela, ambiente, adaptação do observador etc. determinam por fim como uma aparência deve ser, mas, geralmente, nas cadeias de manuseio de imagens ou vídeo HDR pelo menos o brilho de pico da tela na qual a imagem (ou imagens) deve ser renderizada é da maior importância. Por outro lado, várias partes na cadeia criação- consumo de imagens poderiam ter uma participação no aspecto de uma aparência ideal (por exemplo, o consumidor final pode ter uma visão especial sobre o assunto, ou uma necessidade). Pode- se presumir que alguns sistemas - os quais podem ser usados para explicar as modalidades da presente invenção - possibilitarão ao criador de conteúdo, se ele assim desejar, ter alguma participação ativa na aparência final que deve ter a aparência ideal “nativa”, qualquer que seja o conteúdo exibido na tela no lado de recepção. As modalidades mais simples fornecem essa possibilidade, uma vez que uma grande parte da aparência já está codificada nas especificações de transformação de cor que é transmitida em primeiros metadados MET_1 associados à imagem (por exemplo, no mesmo disco óptico ou meio contendo a imagem, ou através de uma mesma conexão de comunicação de imagens), e se ela for simplesmente ajustada ao brilho de pico específico da tela de recepção, então a maior parte da visão do classificador da cena imageada ainda estará presente e perceptível na aparência renderizada final. De fato, se o aparelho de transformação de cor apenas aplicar a métrica como ela é, isto é, sem ajuste fino adicional com parâmetros de definição de variabilidade de aparência como gpr, e então determinar as funções de transformação de cor HDR para MDR com base na transformação de cor recebida (sendo que a TMF determina o mapeamento, por exemplo, de HDR para LDR), então a MDR será determinada exclusivamente pela diferença de classificação (gradação) conforme codificada nas funções de transformação HDR para LDR.

[057] Entretanto, outras partes poderiam também ter uma participação na aparência, e isso poderia ser determinado com o uso exatamente dos mesmos componentes técnicos de nossas várias modalidades, geralmente como uma nova determinação da aparência nativa. Por exemplo, um fabricante de aparelho, por exemplo, um fabricante de aparelhos de TV, pode também ter muito conhecimento e/ou uma visão preferencial de como deve ser a aparência de certos tipos de renderizações de cenas HDR (ou renderizações MDR correspondentes). Por exemplo, ele pode desejar tornar porões escuros um pouco mais claros, ou talvez ainda mais escuros, porque deseja enfatizar os recursos de renderização escura acima da média de sua tela. Ou ele pode desejar uma aparência mais ou menos saturada que a média. Ou ele pode ainda realizar um processamento de cores para outras peculiaridades do hardware da tela, ou preferências de fornecedores como uma aparência de cores típicas para um dado fornecedor etc. No passado, isso seria feito completamente às cegas na imagem recebida após análise da mesma pelo aparelho de TV, ou apenas com funções fixas que sempre fornecem um resultado razoável, por exemplo, de saturação aumentada, independentemente do pensamento do criador sobre como as aparências na mesma cena imageada deveriam variar entre vários cenários de renderização (e assim as cores se tornariam excessivamente saturadas em vez de agradáveis tons pastel), mas com nossa abordagem o processamento adicional do fabricante do aparelho poderia ser coordenado com o que o criador artístico pensa sobre a cena (conforme codificada e suas transformações de cor indo de uma aparência codificada em uma primeira imagem de aparência transmitida, por exemplo, HDR de 5000 nits, para uma segunda aparência de referência, por exemplo, uma LDR já existente de 100 nits). E, em particular, a partir dessa nova especificação funcional de ao menos uma classificação de faixa mais dinâmica da cena HDR, o fabricante do aparelho (por exemplo, de um aparelho de TV) tem muito mais informações semânticas relevantes, porque o classificador humano fez suas escolhas com base em particularidades inteligentes da cena e sua(s) imagem(ns), com base nas quais o aparelho de recepção pode executar cálculos reclassificação ideal mais precisos. Existe ainda uma terceira parte que, com o uso de nossa tecnologia de reclassificação de aparências, poderia ter uma participação sobre a aparência final da imagem. O observador pode fazer um ajuste fino da aparência, por exemplo, geralmente um ajuste pequeno (talvez com uma grande etapa de, por exemplo, uma alteração de até 3 paradas, mas então apenas em uma parte da faixa de luminância, por exemplo, 10% das cores mais escuras), usando seu controle remoto 1122, se ele achar, por exemplo, que no momento a imagem é apenas parcialmente escura demais, porque sua esposa está lendo um livro ao seu lado.

[058] Assim, nosso aparelho de transformação de cor depende predominantemente no que o classificador especificou como suas funções de transformação de cor (em metadados MET, mais precisamente nos metadados MET_1 associados às imagens comunicadas Im_in), que são simples de serem implementadas em um CI, e que podem não precisar de atenção adicional do classificador para a reclassificação. Em algumas modalidades sua única ação não precisa ir além de verificar (rapidamente) se tal vídeo MDR ajustado por tela, por exemplo, um filme de ficção científica com planetas brilhantes queimados pelo sol, ou um programa de TV com vários efeitos de luz, tem uma aparência agradável em uma tela de brilho de pico intermediário escolhido pelo classificador, por exemplo 1000 nits sendo um bom valor para uma tela (MDR) intermediária para uma codificação 5000HDR/100LDR, porque é cerca de 2 paradas abaixo de 5000 e cerca de 3 paradas acima de LDR, e mesmo essa verificação poderia ser dispensada se o classificador confiar exclusivamente no lado de recepção para ajuste adicional de sua aparência nativa (isto é, ele simplesmente especifica suas transformações de cor para classificar apenas uma aparência de referência adicional além de sua aparência principal mestra, por exemplo, LDR de 100 nits, e então todas as novas classificações adicionais são feitas por um fabricante de eletrodomésticos, por exemplo, com software de aprimoramento de cores executado em um computador etc.).

[059] Caso ele realmente faça uma verificação ou especifique como a reclassificação deve acontecer em um lado de recepção, o classificador aceita então o método de otimização de classificação adicional atualmente selecionado por ele (ou uma sugestão automática) que fornecerá imagens MDR agradáveis, mediante, por exemplo, o armazenamento das funções de transformação de cor e da imagem principal em um disco blu- ray, ou um servidor intermediário para posteriormente fornecer aos clientes, juntamente com qualquer informação necessária para aplicar em um lado de recepção o método de otimização de classificação ajustado para uma tela conectável específica (que, nas modalidades mais simples, seriam exclusivamente as funções para classificar a segunda imagem a partir da imagem principal isto é, os dados para calcular o fator multiplicativo comum (g) ou a função de mapeamento de luminância TMF correspondente, mas em modalidades mais avançadas seriam os parâmetros adicionais especificando estratégias de otimização mais precisas). O lado de recepção pode então determinar de modo autônomo uma terceira classificação para, por exemplo, o brilho de pico de 1250 nits, e, por exemplo, quando o aparelho de transformação de cor está incorporado em um servidor de fornecimento de vídeo profissional via internet, armazenar essa terceira imagem (ou imagens) para quando ela for solicitada por um cliente, ou grupo ou uma classe de clientes.

[060] O aparelho de transformação de cor obtém um valor de um brilho de pico PB_D para uma tela para ser fornecida com imagens MDR otimizadas, por exemplo, apenas se uma única tela estiver conectada (por exemplo, o aparelho está incorporado em um aparelho de TV), o PB_D poderá ser um número fixo armazenado em uma parte do CI de memória. Se o aparelho for, por exemplo, um STB, então ele poderá verificar o PB_D a partir da TV conectada. O aparelho de transformação de cor avalia, então, como seu PB_D está relacionado aos brilhos de pico correspondentes às duas imagens classificadas HDR e LDR, isto é, o PB das telas de referência correspondentes para as quais essas classificações foram criadas para terem a aparência ideal. Essa relação pode, por exemplo, ser calculada como uma razão logarítmica gp, ou de modo equivalente como uma diferença relativa. Essa razão é usada para se obter a estratégia de reclassificação (semi)automática intermediária de boa aparência. Assim, os princípios de nossa invenção podem ser aplicados exclusivamente em uma trajetória transformação de luminância, ou exclusivamente em uma trajetória de processamento de saturação de cor, ou ambas, aplicando-se duas vezes o mesmo princípio adequado de ajuste dependente de tela, mas com diferentes especificações de transformação de cor, dependendo da situação ou do que o classificador precisar para qualquer imagem ou vídeo HDR.

[061] Vantajosamente o aparelho de transformação de cor (201) compreende uma entrada de dados de tela (117), disposta de modo a receber o brilho de pico de uma tela (PB_D) a partir de uma tela conectada, para que ela possa determinar a classificação correta para qualquer tela disponível e/ou conectada no lado de recepção, potencialmente realizando os cálculos em tempo real durante a visualização de um vídeo. Nessa modalidade, a entrada de dados pode também residir em uma tela, por exemplo um aparelho de TV, de modo que a tela possa determinar sua própria classificação otimizada a partir dos dados de nossa codificação HDR (por exemplo, o PB_D sendo armazenado em uma memória). Dessa forma, nossa tecnologia de codificação de HDR de fato codifica um conjunto de aparências em uma cena HDR, que pode se assemelhar, por exemplo, a como um sistema de múltiplas vistas pode codificar várias vistas em ângulos diferentes em uma cena, mas agora as diferenças ocorrem em um espaço de cor. Modalidades contrastantes podem residir, por exemplo, em servidores de vídeo profissionais, que calculam previamente várias classificações para vários tipos de tela com brilho de pico em torno de valores de classe de PB_D específicos, a serem fornecidas posteriormente a um consumidor, ou receber ajuste fino em suas aparências por outros classificadores de cor, etc.

[062] As modalidades podem determinar variáveis adicionais do ajuste de tela, por exemplo, o aparelho de transformação de cor (201) pode compreender adicionalmente uma unidade de determinação de direção (1304) disposta de modo a determinar uma direção (DIR) em relação ao eixo de luminância das cores de entrada, e a unidade de determinação do fator de alteração de escala (200) pode compreender uma unidade de interpolação direcional (1312) disposta de modo a determinar uma luminância para um pixel da imagem de saída (IM_MDR) a partir de uma luminância de um pixel da imagem de entrada (Im_in) posicionando a métrica ao longo da direção (DIR). Como um exemplo útil, a tecnologia da presente invenção pode interpolar na direção horizontal, isto é, determinar no mapa de transformação de luminância qual luminância de saída corresponde a uma luminância de entrada no eixo x. A pesquisa adicional da Requerente mostrou que pode ser útil rotacionar a direção de interpolação para determinar onde uma MDR intermediária correspondendo ao PB_D deve ser posicionada, e como ela deve ser processada em termos de cores, uma vez que várias transformações de luminância têm várias definições e comportamento, e tal ajuste diferente pode criar, por exemplo, uma aparência mais brilhante em ao menos alguma subfaixa das luminâncias (por exemplo, algumas funções podem ser definidas com nós entre segmentos com vários comportamentos de transformação de luminância, assim como a extensão dos tons de cinza escuro, com a posição de luminância de entrada fixa, e então uma interpolação direcional pode mudar isso). Em particular, considerou-se a posição de 135 graus em relação ao eixo de luminância de entrada uma posição interessante, uma vez que é possível fazer o ajuste ortogonalmente em comparação com a transformação de identidade, e, por exemplo, as extrapolações podem, então, ser definidas inicialmente como predominantemente espelhadas simetricamente em comparação com essa diagonal). Será mostrado abaixo como posicionar a métrica ao lingo dessa direção DIR, e o versado na técnica deverá entender, assim, como derivar equações matemáticas a partir disso, com o uso da geometria.

[063] Novamente, essa direção pode, por exemplo, ser determinada pelo aparelho no lado de recepção de modo autônomo, por exemplo, com base em sua classificação do tipo de imagem HDR, ou pode ser comunicada como um indicador de direção COD_DIR a partir do lado de criação de conteúdo. Será mostrada uma modalidade vantajosa que pode realizar os cálculos mediante aplicação de uma rotação do mapa que contém a função de transformação de luminância, executada pela unidade de interpolação direcional 1312.

[064] Uma unidade de determinação do multiplicador comum (1311) converterá, então, a transformação de cor necessária para obter a aparência MDR nos vários fatores gt necessários para a multiplicação das cores de entrada.

[065] Vantajosamente, o aparelho de transformação de cor (201) tem sua unidade de determinação do fator de alteração de escala (200) disposta adicionalmente para obter um parâmetro de ajuste (gpr; gpm) a partir dos segundos dados de especificação de processamento de cores (MET_2), e disposta de modo a calcular o fator multiplicativo comum resultante (gt) correspondente a uma posição na métrica diferente da posição para o brilho de pico de tela (PB_D), sendo que a posição diferente se baseia no valor do parâmetro de ajuste. Conforme dito anteriormente, a métrica determina o que deve ser uma aparência MDR em grande parte razoável, se ela não receber nada mais, por exemplo, do criador de conteúdo ou da análise de imagens adicional e do conhecimento especializado de HDR específico do fornecedor, isto é, a aparência MDR já será então em grande boa para muitos tipos de cena HDR, precisamente porque ela está idealmente determinada com base nas funções de transformação de cor recebidas (por exemplo, curva padronizada CC), que determinam como várias classificações da cena HDR devem ser alteradas, ao menos do ponto final da primeira faixa de PB (por exemplo, PB_H) para o segundo (PB_IM2 é, por exemplo, então PB_L). Entretanto, pode- se necessitar de uma alteração mais rápida e mais agressiva para a aparência LDR em algumas imagens, ou mesmo algumas partes de algumas imagens correspondendo a alguns tipos de regiões ou objetos como porões escuros, e uma alteração menos agressiva que a “média” (conforme determinado pelo simples uso da métrica, e direção) dependendo do desvio do PB_D a partir do PB_IM1 para outras situações. Isso deve ser especificado pelo classificador de uma forma tão fácil quanto possível. Nas modalidades mais simples da tecnologia da presente invenção, o classificador pode usar um único parâmetro (gpr) para indicar quanto o ponto M_PB_U a ser usado correspondente ao ponto de cálculo da MDR deve estar mais próximo, por exemplo, do PB_H na métrica, do que quando calculado “cegamente” pelo aparelho no lado de recepção ao incluir PB_D na métrica.

[066] Por exemplo, em algumas modalidades, a unidade de determinação do fator de alteração de escala (200) é disposta de modo a determinar a posição diferente aplicando uma função monotônica que fornece como saída uma posição normalizada na métrica como função do de ao menos um parâmetro de entrada (gpr) situado entre um mínimo, por exemplo um mn_gpr negativo para extrapolação, ou 0 e um máximo (mx_gpr), e certamente, dependente também de algum valor de entrada correlacionado à situação da tela, isto é, PB_D (gpr poderia ser, por exemplo, uma medida da curvatura de uma curva dobrando ao redor da curva linear da Figura 15, etc.). No caso da determinação direta da posição na métrica, o valor de entrada pode ser o próprio PB_D, ou pode ser alguma função desse PB_D, por exemplo a métrica utilizada. Esse valor gpr pode ser definido pelo classificador, por exemplo, com o uso de um botão 1510, ou calculado mediante a análise de imagens baseada em inteligência artificial no lado de recepção. Como pode-se formular a alteração (ao menos para interpolação, e esta pode, de modo correspondente, ser adaptada quando é necessário fazer uma extrapolação) necessária para obter a aparência MDR, como uma transformação de cor que é uma identidade quando se calcula teoricamente a classificação HDR, ou, de modo geral, a classificação principal recebida, a partir dela mesma, e o outro extremo da faixa, isto é, por exemplo, a aparência LDR de 100 nits pode ser obtida ao se aplicar a transformação de luminância transmitida (isto é, “inteira”), pode-se ver isso como a aplicação da alteração multiplicativa, entre nenhuma, isto é, multiplicação por 1,0, ou a extensão mais completa, isto é, multiplicação por g correspondendo aos metadados recebidos para o cálculo da aparência LDR a partir da imagem HDR recebida. A partir disso, para qualquer que seja o valor de multiplicação real para as várias luminâncias de entrada, pode-se definir uma função contínua, conforme exemplificado na Figura 15, que aplica a transformação de cor na extensão máxima (m_MT_norm = 1) ou nenhuma, ou qualquer nesse intervalo, dependendo de uma entrada que caracteriza o cenário de exibição, e o ao menos um valor gpr que caracteriza o tipo de reclassificação desejada.

[067] No caso de se ter uma modalidade do aparelho de transformação de cor (201) na qual a unidade de determinação do fator de alteração de escala (200) usa a métrica de base logarítmica, e calcula o fator gt elevando o valor g a essa razão de correção calculada, o versado na técnica pode entender que pode ser vantajoso corrigir essa razão. Isso pode ser feito de modo pragmático, obtendo-se um parâmetro de ajuste (gpm), por exemplo, a partir dos dados de especificação de processamento de cores (MET), e então calculando-se um valor de potência ajustado (gpp) que é a razão (gp) resultante do cálculo da métrica logarítmica à qual o PB_D corresponde, elevada a uma potência que é o parâmetro de ajuste (gpm), e então uma versão adicional ajustada do fator multiplicativo comum (gtu) que é o fator multiplicativo comum inicial (g) elevado a uma potência igual ao valor da potência ajustada (gpp) é calculado, sendo que o valor gtu será usado de modo geral pelo multiplicador de alteração de escala (114) com o qual multiplicar (por exemplo) as cores de entrada RGB lineares. Desnecessário dizer, mas ainda assim para ficar bem claro ao versado na técnica, que, embora o gpm desse valor de potência seja similar a um valor gama, ele não está relacionado de forma alguma com os gamas conhecidos para telas, ou clareamento genérico de imagens, pois ele é agora um parâmetro de controle da urgência da necessidade de ajustar a outra aparência classificada para alguma cor de imagem MDR necessária que corresponde a algum PB_D, dependendo das particularidades da cena HDR, e, por exemplo, do tipo de otimizações artísticas que eram necessárias para se obter uma classificação LDR razoável. O que ocorre é que uma função de potência foi uma forma pragmática de criar um comportamento de um tipo como aquele exemplificado na Figura 15, e o fato de algumas funções matemáticas serem universalmente redistribuíveis é uma mera coincidência matemática.

[068] De preferência, ofereceu-se também uma solução técnica que possibilita ao criador de conteúdo uma ação ainda mais ativa sobre como será a aparência das classificações intermediárias. De um lado, introduziu-se para a solução uma limitação de que o classificador não deve ser incomodado com uma quantidade demasiada de classificação adicional, uma vez que o tempo dedicado às classificações é dispendioso, e, por exemplo, algumas produções já podem ter excedido o orçamento antes de passar à pós-produção, e o classificador já gastou um tempo razoável criando a classificação HDR mestra (ainda assim, se praticamente ninguém conseguir ver isso em sua tela real, faz sentido não ignorar completamente as questões de renderização final), e então uma aparência LDR associada a ela (ou uma aparência LDR derivada, por exemplo, de uma versão de cinema, e então uma aparência HDR correspondente para visualização em aparelho de TV HDR, ou outra alternativas de fluxo de trabalho). Por outro lado, depois que já se colocou parte da complexidade nas classificações em cada lado de uma faixa de classificações intermediárias necessárias para vários valores de PB_D, isto é, quando já se tem uma classificação HDR e LDR, a determinação de classificações intermediárias pode ser mais simples (deve-se notar, novamente, que a invenção e suas modalidades não se limitam a este típico cenário exemplificador, uma vez que as tecnologias também podem ser usadas para, por exemplo, aumentar a classificação a partir da classificação mestra de 5000 nits para, por exemplo, 20.000 nits, partindo das mesmas funções de redução de classificação e alterando-as adequadamente, ou com funções adicionais para aumento das classificações transmitidas nos metadados etc.). À primeira vista e de modo geral, entretanto, a determinação de uma classificação intermediária ainda pode ser relativamente complexa, em particular se houver um grande número de paradas entre o brilho de pico da classificação MDR e a classificação original em qualquer lado, LDR e HDR. Portanto, de modo ideal, o classificador deve criar completamente uma terceira classificação MDR, ou ao menos completamente de modo suficiente, o que pode ser feito com nossas modalidades mais avançadas. Todavia, foram oferecidas várias soluções simples que podem ser usadas, unicamente, ou se necessário, com um pequeno ajuste fino adicional de, por exemplo, uma parte do mapeamento de luminância global para a geração da imagem classificada intermediária (ou como uma pós-correção na imagem resultante de nosso método de otimização com uma função adicional), ou fazer o ajuste fino local de algum objeto que seja crítico e simplesmente não foi tão corretamente classificado por nossas modalidades simples etc.

[069] Nessa modalidade, o classificador pode rapidamente criar MDRs intermediárias especificando apenas um parâmetro de ajuste gpm ou gpr adicional, que também é transmitido nos metadados MET e especifica até que ponto as classificações intermediárias parecerão com a classificação LDR ou a classificação HDR, ou, em outras palavras, quão rapidamente, quando se passa pelos vários brilhos de pico intermediários de uma tela conectada pretendida, a classificação MDR intermediária muda de uma aparência HDR para uma aparência LDR, ou vice-versa na outra direção (por exemplo, quão brilhante um determinado objeto escuro permanece quando o brilho de pico de tela continua aumentando).

[070] Certamente, além de uma função de ajuste fino de 1 parâmetro (para ir mais rapidamente ou mais lentamente para outra classificação quando se remove o PB_D do ponto de partida, por exemplo, PB_H), podem ser definidos parâmetros adicionais que especificam como exatamente deve ocorrer um ajuste de tela mais ou menos agressivo e dependente da cena, por exemplo como ocorre com o parâmetro gptt na Figura 15. Em princípio, na estrutura técnica da presente invenção, pode-se definir especificações arbitrariamente complexas de como a aparência deve se mover entre a aparência HDR e a aparência LDR para várias posições de PB_D intermediário, como se desviando da abordagem puramente baseada em métrica.

[071] Vantajosamente, uma modalidade adicional do aparelho de transformação de cor (201) tem a unidade de determinação do fator de alteração de escala (200) adicionalmente disposta de modo a obter ao menos um valor de luminância (Lt) demarcando uma primeira faixa de luminâncias de cores de pixel (ou lumas correspondentes) da imagem de entrada de uma segunda faixa de luminâncias, e sendo que a unidade de determinação do fator de alteração de escala (200) está disposta de modo a calcular o fator multiplicativo comum ajustado (gtu) — isto é, a modalidade mais especificamente determinada do fator multiplicativo comum resultante gt - para ao menos uma dentre a primeira e a segunda faixas de luminâncias. O termo “luma” significa qualquer codificação de uma luminância ou qualquer outra medida de brilho de pixel (correlacionada ao comprimento do vetor de cor), cujos valores podem ser calculados de modo equivalente. Por exemplo, em algumas modalidades práticas, pode ser vantajoso tornar esse valor Lt um demarcador Valor, onde Valor é definido como max(R,G,B), isto é, aquele dentre os componentes de cor de uma cor de entrada que é o maior. Isto é, quando o componente de cor maior, por exemplo, o vermelho, for maior que, por exemplo, 0,3, a cor é classificada em um primeiro regime, e, caso contrário, em um segundo regime.

[072] Com essa modalidade, o classificador pode selecionar subfaixas específicas interessantes da faixa de luminância da imagem principal (e consequentemente através da transformação de cor também a imagem derivável, por exemplo, a imagem LDR), e tratá-las de maneira diferente. Na discussão acima, concentrou-se principalmente em quão rapidamente deve se mover da classificação HDR para a classificação LDR (ou vice-versa se a imagem principal Im_in for uma imagem LDR), e como isso pode ser feito tecnicamente em algumas modalidades práticas até mesmo por meio de 1 único parâmetro de controle gpr ou gpm. Essa adaptação será, então, geralmente feita dessa forma para todas as cores de pixel na imagem de entrada, isto é, qualquer que seja seu brilho original, presumiu-se que elas podem ser ajustadas por tela de modo similar, porque a diferença de abordagem já está em grande parte codificada no formato da transformação de luminância para se classificar entre a aparência HDR original e a aparência LDR do classificador. Contudo, pode haver várias partes semânticas em cenas HDR, por exemplo, os tecidos coloridos em áreas relativamente mais escuras de um bazar e o lado externo brilhante visto através da entrance do bazar, e, geralmente, pode haver várias otimizações envolvidas para mapear as várias partes em, por exemplo, uma faixa de luminância LDR relativamente pequena, e ao mesmo tempo criar uma imagem artisticamente convincente. Ou as regiões escuras podem ser muito críticas em uma cena noturna e o classificador pode desejar mantê-las razoavelmente brilhantes mantendo essa subfaixa das luminâncias próxima da aparência LDR até brilhos de pico relativamente altos como, por exemplo, 800 nits, enquanto mantém um bom contraste HDR nas regiões superiores, por exemplo, uma parte das casas próximas de um posto de luz, ou uma parte de uma caverna que é iluminada pelo sol adentrando por uma fenda no telhado, ou caixas comerciais coloridas retroiluminadas etc. Assim, na modalidade mais avançada da presente invenção, o classificador pode desejar especificar o ajuste, em particular, quão agressivamente a classificação MDR se move em direção à segunda classificação de imagem para etapas sucessivas de PB_D, de diferentes maneiras para diferentes partes da cena, em particular partes das imagens de diferentes luminâncias de pixel, e, portanto, ainda é vantajoso dispor de um mecanismo que permita ao classificador especificar adicionalmente seu controle pretendido sobre esse aspecto.

[073] O classificador geralmente especifica um valor de gpm diferente para um dos lados da ao menos uma região que demarca o valor de luma (Lt), e mais valores em regiões adicionais são especificados ao longo da faixa (por exemplo, escuros, médios e brilhantes e hiperbrilhantes). Uma das duas regiões pode usar um valor padrão, por exemplo gpm=1, o que significa usar a estratégia de nossa primeira modalidade, significando que, em algumas modalidades, o classificador precisa apenas especificar um valor de gpm específico para uma das duas regiões com luminâncias em cada lado de Lt. Mas ele pode também especificar e transmitir um valor de gpm exclusivo para ambos os lados: gpm_1 e gpm_2.

[074] Uma modalidade adicional do aparelho de transformação de cor (201) tem a unidade de determinação do fator de alteração de escala (200) disposta adicionalmente para determinar uma faixa de transição suave de lumas em torno do ao menos um valor de luma (Lt), e disposta de modo a interpolar o fator multiplicativo comum ajustado (gtu) entre seu valor determinado em qualquer lado do ao menos um valor de luma (Lt). Para garantir o comportamento de transição suave, que pode não ser necessário para cada cena HDR e cenário de cálculo de MDR, e sem luminâncias de pixel inadequadas para qualquer objeto das classificações intermediárias (as quais, em particular, poderiam ser críticas para certos gradientes, por exemplo no céu, ou um objeto esférico iluminado), essa modalidade possibilita ao classificador especificar uma região de transição. Ele pode especificar a interpolação dependendo de quanto a estratégia de interpolação difere em cada lado de Lt, isto é, quanto gpm_1 para, por exemplo, as luminâncias baixas difere de gpm_2 para as luminâncias altas (típicos bons valores para cada um podem se situar entre 1,5 e 1/1,5), determinar, entre outras coisas, a largura da região de interpolação como um parâmetro adicional I_W, e se o mesmo deve se situar, por exemplo, simetricamente em torno de Lt ou assimetricamente aplicar apenas às luminâncias acima de Lt (alternativamente, o aparelho de recepção poderia determinar de modo autônomo uma estratégia de interpolação usando os detalhes na(s) curva(s) resultante(s), como, por exemplo, que a mesma deve aumentar monotonicamente, ou limitações desejadas nas derivadas em um instante particular ou em um intervalo particular, isto é, a interpolação irá propor ao menos uma estratégia até que as limitações sejam satisfeitas, etc.). Além disso, ele pode, em algumas modalidades, especificar alguma estratégia de interpolação desejada mediante a transmissão da função (ou funções) para calcular o valor de gpm necessário para cada possível luminância na imagem principal nos metadados, mas, por padrão, essa será uma interpolação linear entre os valores gpp transmitidos para cada lado da região de interpolação.

[075] Uma vez fornecidas algumas modalidades exemplificadoras do aparelho de transformação de cor que se pode projetar com os princípios de nossa invenção, serão descritas, a partir deste ponto do presente documento, algumas variantes adicionais de aparelho nas quais o aparelho de cálculo de cor básica pode estar compreendido, nos vários cenários de aplicação, por exemplo, aparelhos no lado do consumidor, no lado de um criador de conteúdo, em um local da companhia de transmissão de conteúdo, por exemplo em uma estação de transmissão/recepção por cabo ou um satélite, ou um serviço baseado na internet para reclassificação de vídeos, por exemplo, de consumidores, por exemplo, um vídeo de casamento ou de férias etc.

[076] No lado de um codificador as modalidades da presente invenção podem ser usadas em um sistema para criar uma codificação de uma imagem de alta faixa dinâmica (Im_src), compreendendo:

[077] - uma entrada para receber a imagem de alta faixa dinâmica (Im_src);

[078] - um conversor de imagem (303) disposto para converter a imagem de alta faixa dinâmica (Im_src) em uma classificação mestra (M_XDR) da imagem de alta faixa dinâmica (Im_src);

[079] - um aparelho de transformação de cor (201), de acordo com qualquer uma das reivindicações acima de aparelho de transformação de cor, disposto para calcular começando a partir das cores de pixel de entrada de uma imagem de entrada (Im_in) sendo a classificação mestra (M_XDR), as cores resultantes de pixels uma segunda imagem classificada (M_X2DR), mediante aplicação da transformação de cor (TMF; g);

[080] - sendo que o aparelho de transformação de cor é disposto de modo a obter ao menos um parâmetro (gpm) e para calcular, com o uso do parâmetro e da transformação de cor, uma segunda imagem (IM_MDR) correspondente a um brilho de pico que é diferente do brilho de pico que corresponde à classificação mestra (M_XDR) e do brilho de pico que corresponde à segunda imagem classificada (M_X2DR);

[081] - uma unidade de formatação de sinal (310) disposta de modo a converter a segunda imagem classificada (M_X2DR) juntamente com a classificação mestra (M_XDR) em uma imagem de alta faixa dinâmica formatada (SF_X2DR) adequada para armazenamento e/ou transmissão de imagem e que compreende dados de cor de pixel da classificação mestra (M_XDR), metadados que codificam a transformação de cor, e o ao menos um parâmetro (gpm); e

[082] - uma saída de imagem (320) para fornecer a imagem de alta faixa dinâmica formatada (SF_X2DR).

[083] Geralmente, os componentes espelharão aqueles em um lado de recepção, mas agora um classificador humano (ou um sistema de reclassificação automática baseado em inteligência artificial) tem outros componentes técnicos para determinar o que um receptor deve fazer, para criar as classificações intermediárias mais perfeitas segundo o desejo do classificador.

[084] Aqui, o classificador geralmente começa a partir do material HDR original (Im_src), por exemplo, diretamente de uma câmera HDR como uma câmera VERMELHA, ou mesmo um sistema de duas câmeras expostas de maneiras diferentes fornecidas pela mesma imagem de cena por meio de um divisor de feixes. O classificador deseja, geralmente, fazer uma classificação HDR mestra disso; conforme explicado com o exemplo da Figura 14, ele deseja posicionar as luminâncias dos vários objetos da imagem, e seus códigos de luma correspondentes, no eixo de luminâncias de 5000 nits, à esquerda da Figura 14. Ele quer também fazer uma classificação LDR correspondente àquela mesma aparência de imagem HDR mestra. Seguindo com o exemplo específico da imagem principal (Im_in), que é na verdade transmitida como um DCT, geralmente comprimido ou não comprimido, sendo uma imagem HDR, nesse cenário a imagem classificada M_XDR, sendo produzida a partir da primeira classificação, seria uma imagem HDR, e então essa imagem HDR seria adicionada ao sinal de imagem juntamente com os metadados da função de processamento de cores, e gravada, por exemplo, em um BD ou outra memória física (321), ou qualquer outro meio de transmissão de imagem. Nesse cenário, o classificador criaria, a partir da classificação HDR mestra, ao menos uma função de mapeamento de luminância (por exemplo, CC) para obter M_X2DR, que nesse caso é uma imagem LDR, isto é, uma imagem para a qual os códigos seriam mapeados para um PB_L de 100 nits.

[085] Entretanto, temos também uma versão, e as correspondentes modalidades de ajuste de tela, a qual chamamos de modo 2, na qual a “imagem HDR” da cena HDR é na verdade codificada como uma imagem LDR de 100 nits. Nesse caso, a M_XDR resultante da classificação inicial que determina a imagem principal pode ser uma imagem LDR. E, nesse modo, as funções que o classificador especifica (CC etc.) mapeariam essa imagem LDR para uma imagem HDR, que, geralmente, é uma aproximação muito fiel, quase idêntica, da imagem de aparência HDR mestra desejada. Nesse modo 2, a Im_in sendo armazenada na imagem ou sinal de vídeo S_im seria uma imagem LDR, e as funções de transformação de luminância (e de transformação de saturação) seriam funções de aumento da classificação, para derivar no lado de recepção uma imagem HDR, e também M_X2DR seria uma imagem HDR. Em qualquer caso, o classificador iria, geralmente, verificar a aparência das três imagens, suas imagens LDR original e de aparência HDR, e uma imagem MDR, nas três telas típicas, com brilhos de pico de tela adequadamente escolhidos correspondendo àqueles das imagens.

[086] Portanto, a imagem de alta faixa dinâmica formatada SF_X2DR de acordo com a tecnologia HDR da presente invenção de fato codifica uma aparência HDR em uma cena, independentemente da mesma realmente conter uma imagem principal HDR ou LDR.

[087] Esse sistema geralmente produzirá também ao menos um parâmetro de ajuste (gpm).

[088] Uma das várias iterações pode estar envolvida, dependendo de se o classificador deseja gastar mais ou menos tempo. Para transmissões em tempo real, o classificador pode, por exemplo, apenas observar se as aparências (para as quais as classificações HDR e LDR envolverão então, geralmente, também algumas poucas operações, por exemplo uma única transformação do tipo logarítmica ou curva S configurada com base nas características da cena logo antes do início da exibição para gerar a classificação mestra, e uma segunda para obter a segunda classificação dependente, por exemplo, LDR a partir de uma classificação HDR mestra) são de qualidade suficientemente razoável nas três telas de referência e, ocasionalmente, ele pode apenas ajustar um simples botão que, por exemplo, altera um parâmetro gpm. Mas quando uma remasterização offline está envolvida, o classificador pode dedicar uma quantidade significativa de tempo para criar uma codificação de várias classificações, por exemplo 2 classificações MDR adicionais entre HDR e LDR, e uma em um dos lados (uma UHDR ultra-HDR, e uma SLDR sub-LDR) etc., algumas delas pelas modalidades de ajuste de tela, ou algumas delas pelas modalidades de codificação conjunta de imagens de aparência de faixa dinâmica original, por transformações de cor completas nos metadados, e finalmente o ajuste de tela para posições PB_D intermediárias entre mais de duas classificações transmitidas originais. Especificamente para alguns programas mais populares, em uma cadeia de comunicação de imagens de uma companhia intermediária, por exemplo, que tem um negócio de venda posterior, transmissão, optimização etc. de conteúdo existente, em um trabalho de remasterização para várias categorias de receptores, pode haver uma classificação adicional na qual um classificador humano investirá mais tempo na criação de diversos cenários de reclassificação mais avançada, e os parâmetros matemáticos dessas várias transformações de cor.

[089] O leitor compreende que todas as variantes ou combinações de aparelhos também podem ser realizadas como métodos de processamento de imagens, por exemplo, um método para calcular cores resultantes (R2, G2, B2) de pixels de uma imagem de saída (IM_MDR) que é ajustada para uma tela com um brilho de pico de tela (PB_D) a partir de cores de entrada (R,G,B) de pixels de uma imagem de entrada (Im_in) que tem um código de luma máximo correspondente a um brilho de pico de primeira imagem (PB_IM1) que é diferente do brilho de pico de tela (PB_D), sendo que o método é caracterizado por compreender:

[090] - determinar uma transformação de cor (TMF; g) a partir de dados de especificação de processamento de cores (MET_1) compreendendo ao menos uma função de mapeamento de matiz (CC) recebidos através de uma entrada de metadados (116), cuja transformação de cor especifica como as luminâncias dos pixels da imagem de entrada (Im_in) devem ser convertidas em luminâncias para os pixels de uma segunda imagem (Im_RHDR) que tem, correspondendo ao seu código de luma máximo, um brilho de pico de segunda imagem (PB_IM2), que é diferente do brilho de pico de tela (PB_D) e do brilho de pico de primeira imagem (PB_IM1), e sendo que a divisão do brilho de pico de primeira imagem pelo brilho de pico de segunda imagem é maior que 2 ou menor que 1/2;

[091] - determinar um fator multiplicativo comum resultante (gt; Ls) primeiramente mediante o estabelecimento ao longo de uma direção (DIR) uma posição (M_PB_D) que corresponde ao valor do brilho de pico de tela (PB_D) em uma métrica estabelecida (1850) que mapeia brilhos de pico de tela em ao menos funções de transformação de luminância, sendo que a métrica começa na posição de uma função de transformação de identidade,

[092] e, subsequentemente, calculando o fator multiplicativo comum resultante (gt; Ls) com base na posição estabelecida e a correspondente ao menos uma função de transformação de luminância que é formulada como o fator multiplicativo comum resultante (gt; Ls); e

[093] - multiplicar cada um dos três componentes de cor de uma representação de cor das cores de entrada pelo fator multiplicativo comum resultante (gt).

[094] Geralmente, pode ser útil se o método determinar a posição (M_PB_D) também em função do formato da transformação de luminância para transformar a imagem de entrada na segunda imagem (IM_HDR) compreendendo ao menos uma função de mapeamento de matiz (CC) conforme recebida através dos metadados.

[095] Também é útil um método para calcular cores resultantes de pixels a partir de cores de entrada de pixels de uma imagem de entrada (Im_in), sendo que o método é caracterizado por compreender:

[096] - determinar um fator multiplicativo comum inicial (g) com base nos dados de especificação de processamento de cores (MET) recebidos através de uma entrada de metadados (116),

[097] - determinar um fator multiplicativo comum resultante (gt), em primeiro lugar calculando uma razão (gp) dos logaritmos de primeiramente uma razão de um brilho de pico de uma tela (PB_D) e de um brilho de pico de referência (PB_H) correspondendo à imagem de entrada, e em segundo lugar uma razão do brilho de pico de referência (PB_H) e de um brilho de pico (PB_L) obtido a partir dos dados de especificação de processamento de cores (MET) e correspondendo a uma imagem (Im_LDR) que resulta quando os dados de especificação de processamento de cores são aplicados às cores de pixel da imagem de entrada, e subsequentemente calculando o fator multiplicativo comum resultante (gt) como o fator multiplicativo comum inicial (g) elevado a uma potência que é a razão (gp), e

[098] - multiplicar uma representação de cor RGB linear das cores de entrada por um fator multiplicativo que é o fator multiplicativo comum resultante (gt).

[099] Útil também é um método para calcular cores resultantes de pixels, de acordo com a reivindicação 7, que compreende a etapa de receber o brilho de pico de uma tela (PB_D) a partir de uma tela conectada.

[0100] Útil também é um método para calcular cores resultantes de pixels que compreende obter um parâmetro de ajuste (gpm) a partir dos dados de especificação de processamento de cores (MET), calcular um valor de potência ajustado (gpp) que é a razão (gp) elevada a uma potência que é o parâmetro de ajuste (gpm), determinar um fator multiplicativo comum ajustado (gtu) que é o fator multiplicativo comum inicial (g) elevada a uma potência igual ao valor de potência ajustado (gpp), e multiplicar uma representação de cor RGB linear das cores de entrada por um fator multiplicativo que é o fator multiplicativo comum ajustado (gtu).

[0101] Útil também é um método para calcular cores resultantes de pixels que compreende obter ao menos um valor de luma (Lt) demarcando uma primeira faixa de lumas de cores de pixel da imagem de entrada a partir de uma segunda faixa de lumas, e calcular o fator multiplicativo comum ajustado (gtu) para ao menos uma dentre a primeira e a segunda faixas de luma. A outra subfaixa pode, então, por exemplo, usar o parâmetro gt padrão determinado a partir da razão de logaritmos que especificam a relação de luminância dos brilhos PB_D, PB_H e PB_L mencionados acima para as modalidades de difusão. Algumas modalidades do método ou aparelho podem usar uma das modalidades anteriores, ou qualquer uma delas que for selecionável, dependendo da situação disponível, que será geralmente codificada com códigos adicionais caracterizadores nos metadados.

[0102] Útil também é um método para calcular cores resultantes de pixels que compreende determinar uma faixa de lumas transitória situada em torno do ao menos um valor de luma (Lt), e interpolar o fator multiplicativo comum ajustado (gtu) entre seu valor determinado em qualquer lado do ao menos um valor de luma (Lt).

[0103] Como o versado na técnica perceberá, todas as modalidades podem ser realizadas como muitas outras variantes, métodos, sinais, sejam transmitidos via conexões de rede ou armazenados em algum produto de memória, programas de computador e em várias combinações e modificações etc.

[0104] Por exemplo, em algumas modalidades, o lado de criação de conteúdo pode controlar como qualquer tela no lado de recepção deve renderizar aparências (intermediárias) com base no que o classificador determinar sobre como várias classificações de faixa dinâmica devem parecer, passando a informação como um sinal de imagem de alta faixa dinâmica codificada (S_im) que compreende:

[0105] - dados de cor de pixel que codificam uma imagem principal que é uma classificação mestra (M_XDR);

[0106] - metadados (MET) compreendendo parâmetros que especificam transformações de cor para calcular uma segunda imagem classificada (M_X2DR) a partir da classificação mestra (M_XDR), caracterizados pelo sinal de imagem de alta faixa dinâmica codificada (S_im) compreender adicionalmente um parâmetro de ajuste (gpm) a ser usado para calcular cores resultantes de pixels a partir de cores de entrada de pixels da classificação mestra (M_XDR) mediante as etapas de:

[0107] - determinar um fator multiplicativo comum inicial (g) com base nas transformações de cor;

[0108] - calcular uma razão (gp) dos logaritmos, primeiramente de uma razão de um brilho de pico de uma tela (PB_D) e um brilho de pico de referência (PB_H) correspondendo à imagem de entrada, e em segundo lugar uma razão do brilho de pico de referência (PB_H) e de um brilho de pico (PB_L) obtido a partir dos metadados (MET) e correspondendo a uma imagem (Im_LDR) que resulta quando os dados de especificação de processamento de cores são aplicados às cores de pixel da imagem de entrada;

[0109] - calcular um valor de potência ajustado (gpp) que é a razão (gp) elevada a uma potência que é o parâmetro de ajuste (gpm);

[0110] - determinar um fator multiplicativo comum ajustado (gtu) que é o fator multiplicativo comum inicial (g) elevado a uma potência igual ao valor de potência ajustado (gpp); e

[0111] - multiplicar uma representação de cor RGB linear das cores de entrada da classificação mestra (M_XDR) por um fator multiplicativo que é o fator multiplicativo comum ajustado (gtu). Esse sinal pode compreender metadados de especificação adicionais para possibilitar que qualquer aparelho no lado de recepção aplique qualquer uma das modalidades da presente invenção, como, por exemplo, um ou mais demarcadores de luminância Lt etc.

[0112] Útil também é um sistema para criar uma codificação de uma imagem de alta faixa dinâmica compreendendo uma interface de usuário (330) que possibilita a um classificador humano especificar o ao menos um parâmetro (gpm), e uma saída de imagem (311) para conexão com uma tela (313) que tem o brilho de pico de tela (PB_D).

[0113] Útil também é um sistema (1130) para determinar cores a serem renderizadas, que compreende um aparelho de transformação de cor (201) e uma interface de usuário (1120) para inserir ao menos um parâmetro especificado pelo usuário que altera ao menos um dentre a métrica, o parâmetro de ajuste (gpr; gpm) ou o brilho de pico de tela (PB_D) a ser usado pelo aparelho de transformação de cor.

[0114] Útil também é um método para calcular cores resultantes (R2, G2, B2) de pixels de uma imagem de saída (IM_MDR) para uma tela com um brilho de pico de tela (PB_D) a partir dos três componentes de cores de entrada lineares (R,G,B) de pixels de uma imagem de entrada (Im_in) que tem um código de luma máximo correspondente a um brilho de pico de primeira imagem (PB_IM1) que é diferente do brilho de pico de tela, sendo que o método compreende:

[0115] - determinar uma transformação de cor (TMF; g) a partir de dados de especificação de processamento de cores (MET_1) compreendendo ao menos uma função de mapeamento de matiz (CC) para ao menos uma faixa de luminâncias de pixel, sendo que a transformação de cor especifica o cálculo de ao menos algumas cores de pixel de uma imagem (IM_GRAD_LXDR) que tem, correspondendo ao seu código de luma máximo, um brilho de pico de segunda imagem (PB_IM2), que é diferente do brilho de pico de tela (PB_D) e do brilho de pico de primeira imagem (PB_IM1), e sendo que a divisão do brilho de pico de primeira imagem pelo brilho de pico de segunda imagem é maior que 2 ou menor que 1/2;

[0116] - determinar um fator multiplicativo comum resultante (gt), mediante as etapas de:

[0117] - determinar uma métrica para localizar posições de brilhos de pico de tela entre o brilho de pico de primeira imagem (PB_IM1), e o brilho de pico de segunda imagem (PB_IM2) e fora dessa faixa; e

[0118] - determinar a partir do brilho de pico de tela (PB_D) a métrica e a transformação de cor do fator multiplicativo comum resultante (gt); e

[0119] - sendo que o método compreende adicionalmente multiplicar os três componentes de cores de entrada lineares (R,G,B) pelo fator multiplicativo comum resultante (gt) para obter as cores resultantes (R2, G2, B2).

[0120] Útil também é um método que compreende adicionalmente determinar a direção (DIR) em relação ao eixo de luminância das cores de entrada (R,G,B), e no qual a determinação de um fator multiplicativo comum resultante (gt) compreende determinar uma luminância para um pixel da imagem de saída (IM_MDR) a partir de uma luminância de um pixel da imagem de entrada (Im_in) posicionando-se a métrica ao longo da direção (DIR).

[0121] Útil também é um método que compreende adicionalmente obter um parâmetro de ajuste (gpr; gpm) a partir dos segundos dados de especificação de processamento de cores (MET_2), e calcular o fator multiplicativo comum resultante (gt) correspondente a uma posição na métrica diferente da posição para o brilho de pico de tela (PB_D), sendo que a posição diferente se baseia no valor do parâmetro de ajuste.

[0122] Útil também é um método que compreende obter ao menos um valor de luminância (Lt, Ltr1) demarcando uma primeira faixa de luminâncias de cores de pixel da imagem de entrada a partir de uma segunda faixa de luminâncias, e calcular o fator multiplicativo comum resultante (gt) para ao menos uma dentre a primeira e a segunda faixas de luminância.

[0123] Para ser capaz de transmitir as informações necessárias de um lado de criação, no qual são geradas as aparências artisticamente adequadas, para qualquer local de uso dessas imagens, é útil dispor de uma especificação técnica de um sinal de imagem de alta faixa dinâmica (S_im) que compreende:

[0124] - dados de cor de pixel que codificam uma imagem principal que é uma classificação mestra (M_XDR) de uma cena de alta faixa dinâmica;

[0125] - metadados (MET) compreendendo parâmetros que especificam uma transformação de cor para calcular uma segunda imagem classificada (M_X2DR) a partir da classificação mestra (M_XDR); caracterizados pelo sinal de imagem de alta faixa dinâmica codificada (S_im) compreender adicionalmente um parâmetro de ajuste (gpm) a ser usado para calcular cores resultantes de pixels a partir de cores de entrada de pixels da classificação mestra (M_XDR) mediante a determinação de um fator multiplicativo comum resultante (gt) que é determinado com base na transformação de cor e do parâmetro de ajuste e um brilho de pico de tela (PB_D) para uma tela para ser fornecida com uma imagem compreendendo pixels que têm as cores resultantes.

[0126] Esse sinal pode ser transmitido por meio de qualquer tecnologia de comunicação de sinal, ou residir em qualquer produto de memória compreendendo os dados de cor de pixel, os metadados (MET) e os parâmetro de ajuste (gpm).

[0127] Embora algumas modalidades possibilitem ao classificador um grau maior ou menor de controle sobre quaisquer reclassificações em qualquer situação de renderização, envolvendo geralmente ao menos um brilho de pico de tela específico diferente do brilho da tela de referência associada à(s) imagem(ns) comunicada(s), outras modalidades (independentemente de o classificador desejar transmitir quaisquer especificações de reclassificação, isto é, qualquer coisa além de suas transformações de cor para reclassificar as imagens comunicadas para uma aparência adicional de faixa dinâmica transmitida apenas parametricamente, por exemplo LDR a partir de HDR) possibilitam a um aparelho de recepção reclassificar adicionalmente por si mesmo uma aparência para uma característica de renderização pretendida, como uma tela MDR de 1500 nits, em particular por meio da modalidade do aparelho de transformação de cor (201) que compreende uma unidade de análise de imagens (1110) disposta de modo a analisar as cores de objetos na imagem de entrada (Im_in), e, dessa forma, determinar um valor para ao menos um dos parâmetros de ajuste (gpm ou gpr etc.), ou o brilho de pico de uma tela (PB_D) a ser usado no cálculo do fator multiplicativo comum resultante (gt), ou métrica, ou direção, ou qualquer parâmetro ou combinação de parâmetros de acordo com qualquer uma das modalidades da presente invenção que possibilitam a especificação de um parâmetro multiplicativo final, g_fin, para obter as cores de uma imagem reclassificada final (R,G,B)_radj.

[0128] Em particular, pode ser útil também se o aparelho tiver meios para possibilitar que um observador (por exemplo, o observador de um aparelho de TV em casa) tenha influência sobre a aparência, por exemplo, ao especificar novamente ele mesmo o parâmetro gpr, por exemplo fornecendo ao mesmo um pequeno deslocamento em qualquer direção, por exemplo gpr_v = gpr + k*0,1, sendo k selecionado de {-3, -2, ...., 3}, ou, em geral, gpr +k*N, tendo N um pequeno tamanho de passo. Isso possibilita alterar um pouco a aparência, mas de forma coordenada com o que o classificador de conteúdo especificou como sendo relevante para a cena, ao reclassificá-la, isto é, de acordo com suas funções de transformação de cor HDR-LDR que ele transmitiu nos metadados correspondentes ao vídeo ou imagem(ns).

[0129] Qualquer tecnologia de método ou aparelho pode ser construída em software, implementando a invenção mediante a codificação de todas as etapas necessárias correspondentes no software para instruir um processador a executá-las, sendo que o software é armazenado em alguma memória e pode ser carregado a partir da mesma. BREVE DESCRIÇÃO DOS DESENHOS

[0130] Estes e outros aspectos do método e aparelho de acordo com a invenção ficarão evidentes a partir de e elucidados com referência às implementações e modalidades descritas deste ponto em diante do presente documento, e com referência aos desenhos em anexo, que, conforme é do entendimento do leitor, servem meramente como ilustrações específicas não limitadoras que exemplificam os conceitos mais gerais que podem ser praticados de outras maneiras, e nos quais traços são usados para indicar que um componente é opcional, sendo que os componentes não indicados por traços não são necessariamente essenciais. Traços podem ser usados também para indicar que elementos considerados essenciais estão ocultos no interior de um objeto, ou para itens intangíveis, como, por exemplo, seleções de objetos/regiões (e a maneira como podem ser mostrados em uma tela). Deve ficar evidente para o versado na técnica que - dada a complexidade do assunto e das várias implementações que são possíveis - mostramos, para fins de concisão dos ensinamentos, apenas alguns componentes em algumas figuras, mas esses componentes podem, mudando o que deve ser mudado, ser adicionados também às outras várias modalidades. Deve-se entender que algumas figuras descrevem aspectos das modalidades em qualquer nível mais alto de abstração, por exemplo, no nível de estrutura técnica.

[0131] Nos desenhos:

[0132] A Figura 1 ilustra esquematicamente um aparelho exemplificador para criar uma classificação secundária (aparência original criada pelo criador, que especifica como uma cena deve parecer se renderizada em uma tela de referência em conformidade com certas características específicas como um brilho de pico específico) de faixa dinâmica diferente de uma classificação mestra de entrada (a qual, para fins de simplicidade de entendimento, pode ser, por exemplo, uma classificação HDR mestra), a qual a Requerente deseja aperfeiçoar com componentes técnicos adicionais neste pedido, para possibilitar facilmente a criação de classificações adicionais, isto é, aparências corretas para outras faixas dinâmicas;

[0133] a Figura 2 ilustra esquematicamente uma parte de cálculo de núcleo exemplificadora que possibilita a criação de ao menos uma classificação adicional (a qual chamaremos de classificação MDR), a partir das informações que especificam duas classificações iniciais que podem ser recebidas através de um meio de comunicação de imagens vindas de um lado de criação de conteúdo, ou ser criadas no mesmo lado, ao menos uma sendo uma classificação HDR;

[0134] a Figura 3 ilustra esquematicamente tal sistema de cálculos para calcular uma classificação adicional, quando incorporado em um sistema exemplificador para explicar alguns aspectos de nossa invenção, sendo que o sistema possibilita a um classificador especificar ao menos três tais classificações, e codificar para as mesmas informações que possibilitam a reconstrução das três classificações em um lado de recepção, por exemplo por um aparelho de TV ou sistema de computador destinado ao consumidor;

[0135] a Figura 4 ilustra esquematicamente os resultados do uso de uma modalidade simples de criação de três classificações intermediárias exemplificadoras (entre uma classificação LDR original e uma classificação HDR, conforme criada pelo classificador de cor do criador de conteúdo), representadas como curvas de mapeamento de luminância (relativa, isto é, normalizada para 1,0) para mapear uma luminância HDR de classificação de entrada, Y_HDR, para uma luminância de saída, Y_L, de uma terceira classificação MDR desejada, com base em uma curva de mapeamento de luminância para gerar a segunda classificação a partir da classificação mestra, sendo que a segunda classificação neste exemplo é uma classificação LDR para uma tela de 100 nits;

[0136] a Figura 5 ilustra esquematicamente uma modalidade mais avançada, que possibilita o ajuste adicional dos formatos das curvas de classificação intermediária, em particular, se elas correspondem ou não em termos de característica de distribuição de luminância ao longo do eixo de luminâncias possíveis de serem renderizadas mais similar à classificação HDR, ou mais similar à classificação LDR;

[0137] a Figura 6 ilustra esquematicamente uma modalidade ainda mais complexa que possibilita a especificação mais precisa das curvas em ao menos duas sub- regiões de luminância, isto é, que possibilita especificar o comportamento de reclassificação de modo diferente dependendo da luminância de objetos para os quais deve ser calculada uma imagem da aparência MDR ideal;

[0138] a Figura 7 ilustra esquematicamente como as modalidades da presente invenção podem criar a terceira classificação, por exemplo, para qualquer tela conectável pretendida com aparência de brilho de pico específico mais similar à classificação HDR, ou mais similar à classificação LDR, ao menos em algumas subfaixas de luminância;

[0139] a Figura 8 ilustra esquematicamente como as modalidades podem também encontrar uma saturação de cor intermediária adequada para as cores de pixel de uma classificação MDR para uma tela de brilho de pico intermediário, a partir de uma imagem classificada de entrada (além da luminância de cores de pixel, pode-se manter as cromaticidades exatamente as mesmas para todas as aparências, mas, em algumas modalidades, pode-se desejar ajustar ao menos a saturação de cor, geralmente deixando os matizes inalterados);

[0140] a Figura 9 ilustra esquematicamente outro exemplo de aplicação das modalidades da presente invenção a uma relação de aparência específica, como um mapeamento de matiz entre HDR e LDR, conforme especificado por um classificador;

[0141] a Figura 10 ilustra esquematicamente outro possível exemplo com as modalidades da presente invenção de uma reclassificação específica para várias telas com brilho de pico intermediário, que combina um movimento rápido em direção à aparência LDR para uma primeira região de pixels com luminâncias dentro de uma primeira subfaixa de luminâncias, e uma alteração mais suave para uma segunda região de pixels com luminâncias dentro de uma segunda subfaixa de luminâncias;

[0142] a Figura 11 ilustra esquematicamente, meramente como um exemplo elucidativo, algumas das possíveis aplicações das tecnologias da presente invenção, algumas possíveis modalidades de receptores capazes de determinar suas próprias especificações de reclassificação pretendidas de acordo com os princípios da invenção (e, em particular, a Figura 11 exemplifica também como, em alguns de tais aparelhos, um usuário no lado de recepção poderia influenciar a aparência de ao menos uma imagem MDR para ao menos um cenário de renderização contemplado);

[0143] a Figura 12 ilustra esquematicamente um processamento exemplificador para ajustar rapidamente contrastes imprecisos de uma aparência reclassificada;

[0144] a Figura 13 ilustra esquematicamente no nível de componente de alto nível o que compreende um típico aparelho de ajuste de tela para derivar uma imagem MDR;

[0145] a Figura 14 mostra um exemplo de uma possível cena HDR, de, por exemplo, um filme, para mostrar ao leitor alguns conceitos básicos necessários de nossa cadeia técnica de HDR e tratamento de problemas;

[0146] a Figura 15 mostra uma possível modalidade de como se pode influenciar adicionalmente a aparência de imagens MDR calculadas, por exemplo, por um classificador de cor humano no lado de criação de conteúdo, isto é, geralmente algum tempo antes de as imagens serem visualizadas;

[0147] a Figura 16 explica, por meio de um exemplo, como se pode, em nossa estrutura, ver o processamento de cores necessário como uma formulação matemático multiplicativa;

[0148] a Figura 17 mostra uma descrição das possibilidades (por exemplo, preferências de um classificador de cor na criação de conteúdo classificado artisticamente para a(s) imagem(ns) de cena HDR) disponíveis para criar imagens MDR reclassificadas ou ajustadas por tela de várias maneiras, por exemplo de acordo com as peculiaridades da cena HDR;

[0149] a Figura 18 mostra o mesmo exemplo, mas agora visto em um sistema de coordenadas matemáticas correspondendo à classificação LDR das aparências HDR e de imagem LDR recebidas na cena HDR, e, neste exemplo, mostrando uma possível determinação de uma função de transformação de luminância MDR direcional;

[0150] a Figura 19 mostra de modo correspondente como tais modalidades específicas de derivação MDR podem ser formuladas em uma escala rotacionada, e explica as consequências técnicas resultantes e soluções encontradas pelo inventor;

[0151] a Figura 20 explica o significado de uma possível métrica que pode ser usada com a presente invenção;

[0152] a Figura 21 explica como, no processo de geração de MDR, se pode levar em conta parâmetros de funções de processamento de cores HDR para LDR ou LDR para HDR que são definidas parametricamente, e como se pode - às cegas ou de maneira guiada - variar esses parâmetros quando necessário, por exemplo, as posições de pontos demarcadores de luminância específicos, e como o cálculo das cores MDR flui em tal formulação técnica;

[0153] a Figura 22 mostra uma outra possibilidade de especificar o comportamento calorimétrico de geração de aparência MDR, por exemplo, por um classificador de cor que pode comunicar essa informação a qualquer um ou vários locais de recepção;

[0154] a Figura 23 é um gráfico mostrando como se pode alterar a escala entre representações normalizada que relacionam uma luminância relativa de 1,0 a valores diferentes de luminância absoluta (geralmente PB_D da tela para a qual calcular uma reclassificação);

[0155] a Figura 24 mostra uma explicação de como converter algumas das modalidades da presente invenção em outras modificações equivalente para produzir as mesmas cores de saída;

[0156] a Figura 25 mostra esquematicamente uma modalidade exemplificadora que a tela adapta quando recebe uma imagem SDR como entrada, com base nos lumas Y’i das cores de pixel da imagem de entrada, com os cálculos na representação de cor não linear, em que outras modalidades mostram como se pode também incorporar os cálculos em RGB representações de cor lineares;

[0157] a Figura 26 mostra esquematicamente uma modalidade adicional quando a tecnologia da presente invenção é incorporada em tal sistema projetado;

[0158] a Figura 27 mostra esquematicamente outra modalidade adicional quando a tecnologia da presente invenção é incorporada em tal sistema projetado;

[0159] a Figura 28 mostra esquematicamente outra modalidade adicional quando a tecnologia da presente invenção é incorporada em tal sistema projetado;

[0160] a Figura 29 mostra esquematicamente uma típica cadeia de um sistema de comunicação de imagem ou vídeo HDR com um codificador, meio de transmissão como, por exemplo, TV a cabo ou a internet, e um decodificador, no qual as modalidades da presente invenção podem ser usadas e integradas;

[0161] a Figura 30 mostra esquematicamente que o ajuste de tela pode ser integrado com a decodificação de várias maneiras, por exemplo, sendo que algumas são úteis quando uma complicada estratégia de reclassificação é calculada por outra unidade externa conectada;

[0162] a Figura 31 mostra um modelo de cálculo que, por exemplo, uma unidade externa a um decodificador de núcleo poderia usar para calcular funções para carregar nas unidades decodificadoras HDR de núcleo;

[0163] a Figura 32 mostra esquematicamente como se pode fazer o ajuste quando se move de uma primeira representação de luma para uma segunda, em uma modalidade de reclassificação fina aproximada dupla;

[0164] a Figura 33 mostra esquematicamente alguns princípios básicos de um possível ajuste para sistemas capazes de renderizar tons de preto muito profundos;

[0165] a Figura 34 mostra esquematicamente um exemplo típico de clareamento de uma aparência/classificação, por exemplo, sob a influência de meios de entrada da interface de usuário para um observador informar suas preferências de brilho ou claridade da imagem ou imagens renderizadas;

[0166] a Figura 35 mostra esquematicamente algumas preferências de ajuste de tela, isto é, o mapeamento de luminâncias de vários objetos/regiões de uma cena para posições e faixas no eixo de luminância MDR, no caso de haver disponível uma série de telas de todos os possíveis valores de brilho de tela, PB_D;

[0167] a Figura 36 mostra esquematicamente outro exemplo de outra cena, com um comportamento desejado topologicamente diferente de como todas essas regiões são mapeadas para vários conjuntos de possíveis telas com valores PB_D;

[0168] a Figura 37 mostra esquematicamente algumas possibilidades do que uma unidade externa pode fazer para determinar o formato da função de reclassificação de luminância/cor desejada, por exemplo, no que diz respeito ao comportamento dos possíveis pixels mais escuros ou mais brilhantes em uma imagem ou imagens;

[0169] a Figura 38 mostra esquematicamente um método de ajuste que mantém a aparência MDR mais próxima da aparência classificada HDR (isto é, para mais luminâncias), ao custo de uma quantidade mínima permitida de corte previamente configurada no aparelho, ou calculada com base ao menos nas propriedades das imagens;

[0170] a Figura 39 mostra esquematicamente como um aparelho poderia usar uma formulação de métrica que, entre outras coisas, possibilitaria ao criador de conteúdo informar um comportamento global de ajuste desejado;

[0171] a Figura 40 mostra esquematicamente uma outra modalidade prática de ajuste;

[0172] a Figura 41 mostra esquematicamente como métodos de ajuste típicos funcionariam para lidar com iluminação circundante não padronizada, isto é, consideravelmente diferente da iluminação esperada para a qual a imagem (ou imagens) codificada foi classificada;

[0173] a Figura 42 mostra esquematicamente aspectos essenciais do funcionamento técnico de várias (porém não todas) modalidades apresentadas a seguir;

[0174] a Figura 43 mostra esquematicamente uma visão técnica de faixa dinâmica MDR baseada em conteúdo em comparação com uma tela faixa dinâmica MDR real, a partir da qual algumas de nossas modalidades técnicas serão descritas; e

[0175] a Figura 44 mostra esquematicamente alguns exemplos numéricos de uma possível modalidade de ajuste de nível de tons de preto, no caso de imagens HDR serem comunicadas como imagens SDR, e precisarem ser estendidas para imagens MDR adequadas de faixa dinâmica mais alta do que as imagens SDR.

DESCRIÇÃO DETALHADA DOS DESENHOS

[0176] Na era da codificação de vídeo LDR ou SDR (SDR é a faixa dinâmica padrão, ou seja, um vídeo codificado já existente, com brilho de pico de codificação PB_C=100 nits, por definição, e uma função de transferência eletro-óptica (EOTF) da Recomendação ITU-R BT.709 (Rec. 709) para associar códigos de luma com luminâncias, ou componentes RGB’ não lineares com componentes lineares), o manuseio de vídeo era relativamente simples em termos técnicos. De fato, não houve menção real de uma codificação de brilho de pico (ou branco mais brilhante que o codec representou como uma quantidade de nits que um aparelho de TV ou tela renderizando a imagem precisa fazer). Esse conceito não existia e não era necessário, como se pode verificar pelo mesmo não ser prescrito, por exemplo, na codificação de vídeo analógico NTSC ou PAL, ou na codificação de vídeo digital da Recomendação Rec. 709, conforme usada na codificação MPEG. A cromaticidade (isto é, amarelidão) da cor branca é definida (x=0,3127; y=0,3290), mas não um valor de luminância. Isso se deve ao fato de que na época havia uma filosofia predominantemente diferente, ou seja, o paradigma de renderização relativa, segundo a qual o código máximo (por exemplo, R=G=B=255) é renderizado em qualquer brilho de pico de tela PB_D que uma tela pode gerar. Por exemplo, no caso de uma TV de 80 nits, a cor branca nas imagens seria um pouco menos brilhante, com um branco 80 nits, e em uma tela de alto padrão com PB_D de 200 nits, os tons de branco seriam mais brilhantes. Não se trata realmente de uma preocupação com qual tom de branco era codificado e que funcionasse bem nessa era de SDR, porque, de um lado, a visão humana é, em grande medida, relativa (portanto, desde que houvesse cores que fossem mais amarelas do que o branco escolhido, o observador as veria como amarelos, e se houvesse regiões de 18% da luminância da cor branca, o que quer isso fosse na em sua TV, elas seriam vistas como tons médios de cinza), e por outro lado, porque não havia uma diferença tão grande entre a tela com PB_D de 80 nits e a de 200 nits. Se a cor branca já era tratada em um certo desinteresse técnico relativo, os tons de preto eram totalmente ignorados (se nada mais for mencionado, presume-se que o preto era zero, ou tão bom quanto zero, mas qualquer pessoa querendo ampliar os detalhes percebe que não só várias tela produzem tons de preto diferentes porque, por exemplo, uma tela de LCD, ao contrário de uma tela de OLED, vaza um pouco da retroiluminação através dos pixels fechados, mas mais importante, a cor preta percebida é influenciada pela iluminação do ambiente de visualização).

[0177] Tudo isso mudou na era da HDR, especialmente se alguém tivesse a ambição de ser capaz de mostrar quase qualquer coisa, isto é, imagens de alta faixa dinâmica, e também, em várias situações, como por exemplo, uma sala de cinema escura situada no sótão da casa, ou uma visualização diurna.

[0178] Pode-se dizer, em resumo, que a era da HDR começou quando a função de transferência eletro-óptica, EOTF, de HDR SMPTE ST.2084 foi padronizada em 2014 (a Requerente desenvolveu uma função similar de alocação de código luma, mostrada como a Eq. 6 abaixo). Esse formato de função altamente íngreme possibilitava codificar as luminâncias de pixel de faixa dinâmica muito mais alta de imagens HDR, isto é, com tons escuros muito mais profundos em comparação com a cor branca, em comparação com a faixa dinâmica máxima de 1000:1 que a OETF da Rec. 709 pode codificar. Assim, uma codificação direta de (únicas) luminâncias de imagens HDR mediante o cálculo de lumas correspondentes com a EOTF 2084 foi desenvolvida, chamada HDR10.

[0179] A questão, que ninguém além da Requerente reconheceu, é que essa codificação é uma codificação absoluta. Isso significa que agora pode-se associar ao código máximo (por exemplo, em 10 bits R=G=B=2A10-1=1023) uma luminância de, por exemplo, 1000 nits. Isso quer dizer que não só qualquer coisa na cena acima de 1000 nits não pode ser codificada, a menos que se aceite fazer a codificação com luminâncias representativas mais baixas que 1000 nits, mas também que o código máximo deve sempre renderizar como 1000 nits em qualquer tela, e um código abaixo de, por exemplo, R=G=B=1000, deve renderizar como uma luminância fixa determinada pelo formato da EOTF 2084.

[0180] Isso tem vantagens e desvantagens. Uma grande vantagem é que, para a criação de uma imagem em si, existe agora uma definição exclusiva da imagem, isto é, o que uma tela deve renderizar como luminâncias de pixel. Até 2014, qualquer artista de criação de conteúdo não tinha (talvez até de modo surpreendente quando se olha para esse cenário antes dessa data) absolutamente nenhuma forma de saber qual seria a aparência da imagem criada, isto é, como qualquer consumidor a veria. Se alguém projetasse uma sala de visualização perfeitamente iluminada, e o criador criasse uma imagem de aparência agradável (por exemplo, com nuvens que precisassem ter um certo tom escuro remetendo a trovões, o que ele poderia verificar em seu monitor de referência de classificação de cores no lado de criação), então, talvez com sorte, se uma tela SDR de 100 nits fosse colocada nessa sala, e renderizasse a imagem (isto é, relativamente com branco codificado de brilho de pico PB_C de codificação renderizado em um brilho de pico de tela PB_D) o queria visto seria nuvens escuras de tempestade, conforme pretendido. Mas se uma nova tela HDR com PB_D de 1000 nits fosse colocada na sala, essas nuvens escuras poderiam parecer muito vivas, talvez quase brilhantes, certamente uma aparência artística muito diferente. Com a EOTF 2084, entretanto, o artista de criação de conteúdo poderia criar suas imagens com códigos HDR adequados, de modo que em nenhuma tela as nuvens seriam mais brilhantes do que, por exemplo, 80 nits, em termos absolutos.

[0181] Todavia, embora simplista e inferior, e agora passo a passo comprovada como insuficiente no mercado, os criadores da tecnologia de renderização relativa não estavam completamente errados. Por várias das razões acima mencionadas com relação, entre outras coisas, à visão humana, e à variação de ambientes de visualização e de propriedades de tela, manter-se rigidamente ligado a um paradigma absoluto também é um erro, e insuficiente. Portanto, seria necessário algo equivalente que fosse capaz de “relativizar”, e da maneira adequada, conforme necessário (e pragmaticamente exequível, dadas as limitações práticas sempre presentes, como complexidade do CI, ou tempo disponível do artista), e isto é o que a Requerente desenvolveu como ajuste de tela. A seguir serão descritas várias modalidades e componentes, para os quais o versado na técnica deve, a partir das exemplificações do presente documento, entender prontamente quais componentes meramente ilustrativos são prontamente complementados ou recombinados com as outras variantes ou equivalentes aqui descritos.

[0182] Antes de se aprofundar nos detalhes técnicos das várias modalidades, o leitor pode desejar se familiarizar com os aspectos técnicos (e artístico) por trás dos presentes conceitos, para se certificar de que entende bem as diferenças entre uma mera codificação de imagem e uma estratégia de otimização de tela desenvolvida conjuntamente em torno de uma tecnologia de codificação HDR.

[0183] Para este efeito, ele pode começar estudando a Figura 14 e o texto abaixo, e ponderar sobre o fato de que se um criador de conteúdo trabalhou para produzir apenas duas imagens classificadas idealmente para duas telas diferentes (por exemplo, com PB_D de 5000 nits e de 100 nits, respectivamente), como uma imagem ideal para uma tela com PB_D de, por exemplo, 700 nits ou 1800 nits pode ser derivada automaticamente, porque em várias aplicações não são usados classificadores humanos gastando muito tempo na classificação de várias versões de imagens da mesma cena HDR, em particular se uma tecnologia de codificação é desenvolvida para transmitir apenas duas imagens de aparência de faixa dinâmica diferente para qualquer cena HDR. Em vista da possível complexidade das imagens, e preferências artísticas, essa não é uma tarefa trivial, mas exige uma dose suficiente de tecnologia para ser capaz de atender aos requisitos. Apenas duas possibilidades do que pode ser necessário para as imagens de aparência ideal ao longo de um conjunto de telas de vários possíveis valores de PB_D em qualquer lado de recepção são ilustradas nas Figuras 35 e 36, e esse é o único requisito quando se tem telas de vários PB_D em um ambiente de visualização razoavelmente fixo, mas acima de tudo, pode haver, geralmente, um segundo passe de otimização de um ambiente de visualização disponível caracterizado, por exemplo, um típico reflexo em um lugar frontal que cria uma cor preta mínima perceptível variável como função da quantidade de iluminação ambiental. Esses vários fatores serão detalhados abaixo com vários componentes alternativos, complementares ou adicionais, para tratar o que for necessário em sistemas, dos mais simples (por exemplo, CI não modificado de uma câmera e telefone móvel) aos mais profissionais, mas mais complexos e caros (por exemplo, em uma cadeia de salas de exibição de cinema).

[0184] A Figura 2 mostra uma descrição exemplificadora de uma possível modalidade de nosso aparelho de transformação de cor inovador, o qual assume-se, por enquanto, que esteja incluído em um aparelho no lado de recepção (por exemplo, um aparelho de TV, ou computador etc.). Presume-se que a parte de mapeamento de luminância é a mesma da Figura 1 (embora, conforme mencionado, os princípios também podem ser formulados em várias representações de cor não lineares), exceto que é revelado neste documento também uma opção de modalidade potencial de fazer vários mapeamentos espacialmente localizados. Pode haver metadados adicionais transmitidos e recebidos, o que possibilita a uma unidade de segmentação 222 discriminar pixels de primeiro tipo de pixels de segundo tipo. Por exemplo, uma parte do céu vista através de uma pequena janela lateral pode receber um mapeamento de luminância um pouco diferente que o do mesmo céu visto através de uma grande janela principal. Isto é, em ou próximo de uma posição espacial (x,y)_1, os pixels com cores (Y_sky, u’_sky, v’_sky), isto é, em particular com luminâncias tendo valores Y_sky dentro de uma faixa, por exemplo mais brilhante que uma luminância limiar, em que x e y são coordenadas espaciais de pixels, Y é uma luminância e u’ e v’ coordenadas uv CIE 1976 de pixels de céu azul, recebem outra transformação para outro valor Y_sky_out_2 que os pixels que têm as mesmas cores de entrada (Y_sky, u_sky, v_sky), mas que residem em posições espaciais (x,y)_2 diferentes. Se a unidade de segmentação apenas classificar os pixels, e carregar parâmetros de mapeamento diferentes para chegar a um fator de ganho comum inicial dependendo de os pixels serem classificados primeiro em comparação com a segunda região identificada, o restante do processamento poderá ser idêntico àquele explicado com referência à Figura 1 (por exemplo, duas trajetórias de cálculo paralelas podem ser usadas com LUTs previamente calculadas, etc.). O leitor deve entender que o processamento para se obter a segunda imagem classificada original (por exemplo, LDR) a partir da imagem comunicada (por exemplo, HDR) não precisa ser igual ao processamento local para determinar uma imagem MDR ajustada por tela, e com isso não queremos dizer simplesmente que, certamente, os valores exatos de funções e parâmetros podem diferir, mas também que as decisões que levam a formatos de transformação de alto nível em impactos podem diferir, mas ao menos se tivermos recebido informações nos metadados que possibilitam a segmentação de conjuntos específicos de pixels, geralmente em objetos de imagem semanticamente especiais, poderemos também fazer o ajuste de tela adaptado separadamente para essas regiões ou objetos, por exemplo, intensificar uma bola de fogo mais rapidamente em direção a uma aparência HDR, no caso de o PB_D da tela já possibilitar alguma renderização de efeito HDR, isto é, mais rapidamente do que o restante da cena, que pode ser ajustado mais gradualmente nos vários valores de PB_D intermediário possíveis. Novamente, os vários parâmetros gai, cc, etc., são lidos a partir dos metadados e enviados às várias unidades para os cálculos de cor (especificamente os cálculos de alteração de luminância), mas agora, por exemplo, a segunda região tem sua própria curva de mapeamento de luminância, cc_2, conformada genericamente, ao passo que a região principal (a parte maior do céu visto através da janela, e, por exemplo, todos os pixels do interior de uma sala) é transformada com a curva cc. PB_H e PB_L são, vantajosamente, armazenados como metadados que especificam as duas classificações (especificamente, o que os códigos de uma classificação significam exatamente, ou, em outras palavras, para quais condições de renderização de referência essas classificações foram feitas), e também são lidos a partir dos metadados e enviados à unidade de determinação do fator de alteração de escala 200 que está disposta de modo a calcular um fator multiplicativo comum resultante (gt) com base nos valores de PB_L, PB_H e PB_D qualquer que seja a origem do valor de PB_D (por exemplo, geralmente a tela conectada transmite seu brilho de pico através de uma entrada de dados 117). A Figura 2 mostra algumas propriedades básicas do ajuste adaptável por PB_D de uma tela, de uma forma que calcula um parâmetro gt diferente daquele que seria empregado para a simples decodificação da outra do par de imagens HDR/SDR e então aquela que é realmente transmitida (se for transmitida uma imagem HDR da cena HDR, então ela pode ser conceitualmente calculada a partir de si mesma com o uso de alguma transformação de identidade, e a imagem SDR pode ser calculada aplicando-se ao menos alguma função que mapeia qualquer luminância ou luma HDR ocorrendo a uma luminância ou luma SDR correspondente, conforme a preferência do criador de conteúdo, e no caso de uma imagem SDR ser transmitida como os únicos dados de pixel de imagem para qualquer imagem de aparência HDR da cena HDR original, então uma transformação de identidade irá mapear SDR para SDR, e alguma função determinada idealmente no lado de criação e comunicada irá mapear para a imagem HDR correspondente do par). Embora iniciou-se a explicação por essa operação trabalhando com uma cadeia de subtransformações (GAM, LG, CC...), trabalhando de modo multiplicativo em componentes RGB lineares através do multiplicador 114, e a função a ser realmente calculada por uma multiplicação com gt ou gtu sendo definida por uma divisão de uma função que é aplicada a max(R,G,B), que é então dividida pela luminância do pixel de entrada, o leitor deve entender que, usando os princípios das modalidades, pode-se variar esses componentes. Por exemplo, mudando o que deve ser mudado, pode-se diretamente alterar a escala dos valores Y’CbCr, ou pode-se usar uma única LUT na parte 102, e essa LUT poderia ser aplicada diretamente aos valores de luma dos pixels de entrada à medida que fossem processados, em vez de no max(R,G,B) do cálculo. E, mais relevante do que essas variações de detalhes, poderia-se variar a intensidade com a qual uma aparência deve ser ajustada, de que maneira, de acordo com qual métrica, isto é, como ela variaria com os possíveis valores de PB_D das telas disponíveis, de acordo com certas preferências particulares incorporadas no aparelho ou transmitidas dos criadores de conteúdo ou fabricantes de aparelhos, ou mesmo observadores durante o uso de sua interface de usuário do STB ou da TV etc., que serão as propriedades de ajuste de uma modalidade.

[0185] Modalidades avançadas possibilitam ao criador de conteúdo especificar e transmitir um parâmetro adicional que determina a otimização de grau, ou seja, um parâmetro de ajuste (gpm) que será, geralmente, um número real, por exemplo 1,253 (ou uma codificação do mesmo, por exemplo uma multiplicação por 1000 e arredondamento para o número inteiro mais próximo etc.). Geralmente, valores de no máximo 1,5 e no mínimo 0,6 serão suficientes para modalidades que operam na modificação da métrica logarítmica mediante alteração da potência que determina o valor gt conforme mostrado abaixo, mas em geral o software do classificador de cor terá limites razoáveis além dos quais o comportamento da reclassificação torna-se extremo demais (não se espera que para uma tela de 300 nits a aparência deve ser implementada imediatamente, isto é, controlá-la com as luminâncias normalizadas dessa aparência, de uma imagem HDR de alta qualidade, uma vez que essa tela não pode fazer tal renderização fielmente, que o classificador verá como, por exemplo, áreas que são escuras demais, e, portanto, quaisquer que sejam os limites na prática, ele não irá querer escolher valores tão elevados).

[0186] A Figura 4 fornece um exemplo de uma modalidade muito simples da otimização inovadora de tela de uma imagem HDR. Presume-se que seja necessário mapear as luminâncias de entrada Y_HDR de uma imagem HDR (isto é, a imagem principal é uma classificação de 1600 nits) como entrada para luminâncias de saída (chamadas Y_L neste gráfico) para qualquer classificação desejada. Por exemplo, a curva 405 mostra a estratégia total (que corresponde a todas as unidades da Figura 1 executando sua transformação de luminância, isto é, as luminâncias resultantes foram derivadas das luminâncias de entrada no início da cadeia; nota: a razão de uma cadeia é que ela foi investigada e considerada útil na prática para o manuseio de imagens HDR para a transformação de vários componentes que podem ser manipulados, e também no ajuste de tela pode-se fazer uso de quaisquer informações de tal reclassificação parcial específica, em qualquer das várias modalidades para vários cenários) de mapeamento de luminância para criar uma imagem agradável para uma tela de 100 nits.

[0187] Vemos nesse exemplo uma típica estratégia dentre várias possíveis, na qual as luminâncias mais escuras são intensificadas (relativamente, em uma escala normalizada!), de modo que haverá visibilidade suficiente dessas regiões na tela escura de 100 nits, porque essas regiões foram classificadas como ultra escuras na classificação HDR principal, e porque ela foi classificada para, por exemplo, telas brilhantes de 1600 nits. As demais luminâncias brilhantes são, então, distribuídas pela faixa superior que ainda está disponível (nesse exemplo, acima de 50% do brilho de pico de saída renderizado, a qual pode-se notar que, devido à natureza não linear da visão humana, não é tanto assim, mas esta é apenas uma elucidação), nesse exemplo de modo linear, mas certamente, o classificador poderia usar, por exemplo, uma curva S ou curva de corte suave para as luminâncias de entrada mais altas, para criar, por exemplo, mais contraste em algumas regiões das imagens, etc. A imagem HDR quando convertida para ela mesma (o que não precisa ser realmente feito, mas é um ponto final teórico das reais transformações de cor em imagens que não têm um brilho de pico PB_H) é equivalente a uma transformação de identidade com declive de 45 graus, e isso foi desenhado no mapa para mostrar classificações que se aproximam da aparência HDR. Os fatores multiplicativos comuns para cada luminância de entrada Y_HDR podem ser lidos a partir das curvas, por exemplo, um aumento b(0,2) mapeia como o multiplicador g o valor Y_HDR=0,2 para o Y_LDR= 0,6 desejado, que corresponde a um fator multiplicativo comum g de 3 para essa luminância de entrada. Entretanto, caso se queira obter a classificação ideal para um monitor de brilho de pico 800 nits (curva 402), como ele é relativamente próximo em propriedades psicovisuais de um monitor de 1600 nits (para o qual a classificação HDR recebida nesse exemplo pareceria ideal), e ainda pode mostrar conteúdo de faixa dinâmica relativamente alta, deveria-se calcular uma reclassificação de 800 nits (MDR_800) que é relativamente próxima da transformação de identidade, isto é, o fator multiplicativo comum resultante gt sendo aqui, b800(0,2), deveria ser próximo de 1, e de modo similar para todas as outras luminâncias de entrada. As reclassificações ideais para telas pretendidas ou conectadas com brilho de pico PB_D de 400 nits (curva 403) e 200 nits (curva 404) devem ter curvas e fatores multiplicativos comuns que progressivamente se aproxima do mapeamento de LDR (curva 405).

[0188] As equações que nossa modalidade usa para derivar qualquer classificação intermediária são: gp=LOG(PB_H/PB_D;2,71)/LOG(PB_H/PB_L;2,71) gt=POTÊNCIA(g, gp) [Eqs. 1]

[0189] É útil alterar, por exemplo, estratégias de ajuste de tela multiplicativo como essa, pois isso pode modelar preferências visuais melhores. Como o versado na técnica pode verificar, isso possibilita calcular a saída necessária Y_L para qualquer entrada Y_HDR, porque o fator multiplicativo comum resultante pode ser determinado, de um lado, com base no lado de recepção ou a imagem que usa a razão fixa gp (que é dependente da tela na qual precisamos renderizar, a qual assumimos por enquanto que, geralmente, será uma tela única nas instalações do consumidor), e, de outro lado, com base do parâmetro inicial g, que é calculado a partir da entrada Y_HDR, e os metadados para as funções de transformação de cor, isto é, na aparência LDR em comparação com a HDR, quando foram recebidas. Como pode ser verificado ao se inserir os valores, gp varia entre log(1)=0 se PB_D=PB_H, e 1 se PB_D=PB_L, isto é, isso irá usar o valor completo de g se PB_D=PB_L, e executar uma transformação de identidade multiplicando-se os valores RGB por 1 se PB_D=PB_H.

[0190] Faz-se aqui uma pausa por um momento para que o leitor contemple e entenda a partir dessa primeira modalidade simples o que geralmente acontece, e não ficará confuso com coisas que definitivamente não são as mesmas. Há, de um lado, um comportamento que mapeia (de modo multiplicativo) as luminâncias de entrada de pixels para as luminâncias de saída. E esse comportamento foi fornecido pelo criador de conteúdo, em particular, seu classificador de cor, uma vez que, geralmente, qualquer receptor receberá todas as informações necessárias para determinar duas imagens classificadas (geralmente uma aparência HDR e uma aparência LDR na mesma cena HDR). E, portanto, o receptor pode conhecer as transformações entre essas imagens, de qualquer forma, mas em particular na forma de uma multiplicação da luminância de entrada enquanto mantém constante a cromaticidade da cor (na verdade, ele geralmente já recebe essas funções e, portanto, usá-las em qualquer receptor para qualquer aplicação adicional será fácil). Por outro lado, como as classificações podem não ser ao menos totalmente ideais para a renderização em telas que não têm o mesmo brilho de pico que os PBs associados às duas classificações, o receptor poderá, além disso, precisar calcular uma nova reclassificação intermediária MDR ideal a partir dessas informações. Isso pode também envolver métricas, sobre as quais fatores multiplicativos podem ser determinados, e funções de transformação de luminância que podem, de modo similar, ser transformadas em valores gt multiplicativos etc., mas esses dois fatores de codificação de classificação original em comparação com o cálculo de uma imagem MDR ajustada por tela não são, embora geralmente relacionados, por vezes em uma medida menor, definitivamente os mesmos, e, portanto, conceitos de design técnico muito diferentes podem levar a soluções muito diferentes (mesmo que alguns componentes tenham o mesmo nome como, por exemplo, a valor gama em algumas modalidades). Pode-se ver o ajuste de tela como algum ajuste fino no par classificado, embora quão precisa e fácil a reclassificação precisaria ser depende da situação, mas uma das visões de design envolvidas é que não se deve perturbar o classificador com a criação real de uma quantidade infinita de classificações originais para a mesma cena HDR (isto é, gostaríamos que o criador de conteúdo estivesse presente em cada TV diferente de um consumidor para criar dinamicamente as imagens personalizadas mais artisticamente belas, mas de modo maximamente automatizado com o mínimo de trabalho adicional necessário para o classificador, o que, novamente, depende do cenário e das preferências dele, isto é, com as várias modalidades que oferecem ao menos parte do controle necessário para se obter a aparência correta, em algo que é um campo muito complexo do processamento de imagens, e o sistema de visão altamente não linear dos consumidores de tais imagens).

[0191] Certamente na prática, esses valores gp e gt não precisam ser calculados o tempo todo, mas geralmente à medida que as classificações possam mudar, por exemplo, por cena de N imagens, LUTs podem ser construídas imediatamente antes de serem necessárias para a reclassificação das imagens de entrada, as quais aplicam a função de mapeamento necessária como na Figura 4, por exemplo para uma tela conectada de 400 nits (e os metadados são recebidos pelo menos em tempo hábil, por exemplo, 5 imagens de antecedência).

[0192] Nesse caso, a unidade 200 procurará o fator multiplicativo comum resultante gt necessário, por exemplo, b800(0,75).

[0193] No caso de a imagem principal ser uma imagem LDR, que precisa ter sua classificação aumentada para, por exemplo, HDR de 6000 nits, ou qualquer imagem reclassificada para um brilho de pico intermediário ligeiramente diferente, são utilizadas equações similares na modalidade: gp=LOG(PB_D/PB_L;2,71)/LOG(PB_H/PB_L;2,71) gt=POTÊNCIA(g, gp) [Eqs. 2]

[0194] O multiplicador de alteração de escala 114 opera agora de modo similar ao mostrado na Figura 1, mas multiplica os três componentes de cor RGB por gt em vez de g, produzindo a aparência de cor desejada.

[0195] Entretanto, pode ocorrer que o classificador deseje uma estratégia de reclassificação diferente para uma complicada cena ou tomada de imagens de vídeo, por exemplo, uma que permaneça mais tempo (isto é, para mais brilhos de pico de tela acima dos 100 nits da LDR) próximo do formato funcional de LDR. Ele precisa especificar isso de uma forma muito simples, e, portanto, para usar de modo ideal um tempo excessivo e caro de classificação, ele determina, por exemplo, um único parâmetro, ou seja, o parâmetro de ajuste gpm.

[0196] Portanto, a modalidade mais avançada de nossa unidade de determinação do fator de alteração de escala 200 aplica as seguintes equações: gpp=POTÊNCIA(gp, gpm) gtu = POTÊNCIA(g, gpp) [Eqs. 3]

[0197] Se o gpm for menor que 1, então as reclassificações de brilho de pico mais baixo terão um comportamento mais similar à LDR em sua aparência (e curva de mapeamento), e, vice-versa, elas terão um comportamento mais similar à HDR para gpm maior que 1, principalmente se o criador ou classificador de conteúdo escolher valores mais altos para gpm.

[0198] Esse efeito é ilustrado na Figura 5. Deve-se notar, novamente, que o gpm não funciona em uma direção de potência (no sentido clássico) ao longo do eixo x (uma vez que o formato das curvas que representam a classificação, isto é, a relação entre todas as luminâncias dos objetos de uma cena, não deve alterar significativamente, mesmo com pequenas alterações como um leve aumento de alguma parte que é psicovisualmente permitida, uma vez que essas correspondem a grandes modificações de aparência luminância/contraste desejadas com o restante das pequenas transformações sendo aceitas por adaptação da interpretação visual no cérebro), mas funciona por valor Y_HDR, portanto, na direção do eixo Y_L por assim dizer. De fato, o que o gpm faz é estender ou comprimir a família de curvas na direção da função de classificação LDR, ou de vice-versa, a função de mapeamento unitária HDR, determina a “agressividade das alterações necessárias da aparência da reclassificação”.

[0199] Como mostrado na Figura 5, escolheu-se um valor de gpm igual a 1,3, e viu-se que a curva resultante (503) do mapeamento de luminância ou fatores multiplicativos comuns (agora chamados de fatores multiplicativos comuns ajustados gtu) se tornou mais similar à curva de transformação de identidade HDR. De modo similar, com um fato de, por exemplo, 0,8, a curva resultante estará situada acima da curva 403, isto é, mais próxima da curva de aparência LDR 405. Isso pode ser útil, por exemplo, se houver objetos escuros importantes na cena, por exemplo, rostos, para os quais é prudente mantê-los suficientemente brilhantes por um longo tempo, isto é, até ser indicado que a tela renderização é suficientemente brilhante, por exemplo, acima de 800 nits.

[0200] Contudo, esse ainda é um ajuste global (no sentido de que todas as luminâncias Y_HDR são manuseadas de uma forma simplesmente relacionada, determinada apenas pelo formato da função de conversão de luminância HDR para LDR e o parâmetro gpm). Um impacto maior de nossas estratégias pode vir de modalidades que possibilitam ajuste diferente para sub-regiões diferentes da luminância de entrada (e, consequentemente, mediante também o mapeamento das luminâncias de saída). Por exemplo, ao se ajustar a curva 403 de modo que a mesma se torne mais brilhante (mais similar a LDR) para as luminâncias mais escuras, por uma questão de necessidade, ela será também mais brilhante para as luminâncias mais brilhantes (porque, para manter a aparência, elas devem, para qualquer reclassificação, ter luminâncias de saída acima daquelas das regiões escuras das imagens), e isso pode ser inadequadamente brilhante. Por exemplo, as regiões brilhantes externas podem perder muito contraste, e o classificador pode percebê-las como desagradavelmente desbotadas para algumas cenas críticas. Isto é, ele gostaria de tornar mais claras as partes mais escuras da cena e, consequentemente, contrastantes e visíveis, ao mesmo tempo, entretanto, que mantém as regiões superiores, por exemplo, próximas da aparência HDR.

[0201] O comportamento desejado é mostrado de outra maneira na Figura 7. Aqui, mostra-se o quanto da imagem LDR classificada contribui para a aparência de qualquer classificação MDR intermediária correspondente a qualquer brilho de pico pretendido de tela entre PB_L e PB_H. O comportamento padrão das Equações 1 é mostrado no gráfico 701. Pode-se ver que é possível atribuir mais peso a qualquer classificação ao longo da trajetória de alteração para vários brilhos de pico intermediários na classificação MDR. Por exemplo, a curva 702 mostra uma situação em que a classificação MDR permanece próxima da classificação LDR até os brilhos de pico intermediários PB_D relativamente brilhantes, e apenas para as telas mais brilhantes começa a mostrar a aparência HDR (na explicação abaixo baseada na métrica utilizada, isso irá corresponder ao local onde se situam as marcas de identificação para diversos valores de PB_D, isto é, se, por exemplo, aqueles de (PB_H+PB_L)/2 ficarão próximos uns dos outros, isto é, próximos do PB_L da posição de classificação LDR). Se e até que ponto essa curva é escolhida dependerá da relação entre as classificações HDR e LDR, isto é, das funções de transformação de cor entre as duas. O classificador pode ter feito várias coisas, como, por exemplo, clarear as partes mais escuras na classificação LDR, um corte suave nas partes mais brilhantes, aumentar o contraste de alguma parte intermediária, processamento de saturação específico em um vitral colorido, etc., mas, por exemplo, se houver regiões escuras críticas, o classificador poderá escolher uma curva como a curva 702, e seu valor de gpm transmitido para vários receptores, em ou associados a S_im. A curva 703, por outro lado, é uma que introduz rapidamente uma grande proporção da aparência HDR, mesmo para telas conectadas relativamente escuras.

[0202] No exemplo da Figura 6, o classificador indica um valor de luminância (ou luma) (Lt) demarcando o regime de otimização, no exemplo, igual a 0,43. Abaixo desse valor Lt, ele especificou um primeiro valor de gpm, por exemplo gpm_1= 0,3, isto é, para cores de entrada com uma luminância Y_HDR <= Lt, a curva resultante é calculada conforme explicado com referência à Figura 5, com esse valor de gpm_1. Acima do valor Lt, o classificador deseja ir para um novo regime de reclassificação, e nesse exemplo para as cores mais brilhantes ele que a aparência HDR. Ele determina um valor maior que 1, no exemplo gpm_2=2,0, fazendo com que os pixels mais brilhantes tenham uma aparência “mais HDR” relativamente forte, mais intensamente do que geralmente necessário, exceto para esse exemplo. No presente exemplo, em vez de usar imediatamente gpm_2=2,0 para valores de Y_HDR maiores que Lt, ele especifica uma interpolação para criar uma região transitória suave. Isso pode ser especificado de várias maneiras, no exemplo explicativo de uma forma simples, especificando-se uma luminância maior do regime transitório, Lt2= 0,72. Acima de 0,72, o fator multiplicativo comum ajustado gtu a ser usado, por exemplo, para criar a LUT da curva será determinado com o uso gpm_2=2,0 ou gpp_R =0,25 nesse exemplo. Na região transitória, uma estratégia de interpolação será usada, incorporada, por exemplo, calculando-se primeiramente os valores de potência em cada lado da transição que posteriormente servirá para determinar o fator multiplicativo comum gtu para luminâncias de entrada escuras e brilhantes, e então, mediante a interpolação das mesmas nas regiões transitórias calculando-se, por exemplo: gpp_L=POTÊNCIA(gp, gpm_1) gpp_R=POTÊNCIA(gp, gpm_2) gpp_i=gpp_L+(Y_HDR-Lt)*(gpp_R-gpp_L)/(Lt2-Lt) [Eqs. 4]

[0203] Certamente, outras estratégias de interpolação podem ser usadas se o classificador assim desejar.

[0204] Esse valor de gpp_i irá, então, ser usado para determinar, de modo similar ao explicado na Figura 3, o valor de gtu para cada luminância de entrada na faixa transitória (isto é, gtu=POTÊNCIA(g, gpp_i)), embora em cada lado da faixa transitória o respectivo valor de gpp_L ou gpp_R é usado na função de potência em g, e com essa formulação uma curva resultante como, por exemplo, a curva 603 pode ser calculada a partir da curva 403, que resultaria do método explicado com referência à Figura 4, ou, na prática, a curva resultante será calculada diretamente. De modo correspondente à tela de 800 nits, o equivalente de uma curva 402 mais simples seria agora a curva 602, que é de fato vista como tendo um comportamento muito mais similar à LDR para os pixels mais escuros, mas ainda fortemente como a HDR para os pixels mais brilhantes. Deve ficar evidente que, para tal modalidade, a unidade 200 produzirá o equivalente gtu para gt, e, caso contrário, tudo será similar para as várias possibilidades de modalidades. Nesse exemplo, fez-se a interpolação dos valores de gtu para serem usados na multiplicação comum mediante, de fato, a interpolação dos valores de gpp que a definem, mas modalidades alternativas poderiam também interpolar os valores de gtu resultantes em cada lado das próprias faixas transitórias. Geralmente, o codificador irá especificar qual método será utilizado. Por exemplo, ele pode indicar que o decodificador deve calcular os valores de gtu em cada lado do intervalo [Lt1,Lt2], e então interpolar linearmente essa curva nos pontos ausentes do intervalo, e armazenar isso como uma LUT final para o processamento de luminância da tomada atual de imagens.

[0205] Com essas modalidades, o classificador pode, portanto, simplesmente definir uma estratégia de reclassificação de aparência bastante avançada para as várias telas possíveis no campo para qualquer codificação de cena HDR, mesmo uma complexa. Em casos simples, ele precisa apenas codificar um valor de gpm, uma vez que, por exemplo, por padrão, o valor maior de gpm_2 pode ser entendido por qualquer receptor para que tal cenário seja fixo em 1.0. Ou, sem importunar o classificador, mas para assegurar que nenhum receptor menos compatível entenda a intenção do classificador incorretamente, no caso de o classificador definir apenas, por exemplo, o valor de gpm_1 menor e um limiar Lt, então o codificador, por padrão insere o valor de gpm_2 = 1,0. No caso do classificador especificar apenas um valor de potência gpm_2 para luminâncias acima de Lt, o codificador insere, por padrão, o valor 1,0 para gpm_1. Geralmente, o codificador pode também determinar automaticamente uma estratégia de interpolação que ele considera boa (que produzirá curvas de classificação MDR crescentes ao menos monotonicamente), e o classificador pode aceitar a codificação dessa estratégia nos metadados (por exemplo, como um valor de Lt2) sem fazer nada, ou especificar uma estratégia de interpolação de aparência mais agradável (se necessário, o classificador pode também fazer um ajuste fino dos valores de gpm em cada lado de Lt). De modo geral, de acordo com os princípios da invenção, cada fator multiplicativo comum g codificando a diferença de classificação entre as classificações HDR e LDR pode ser usado para determinar uma reclassificação otimizada, mediante a definição de um valor de potência GP adequado para cada entrada Y_HDR, sendo que o valor de potência GP pode ser especificado por qualquer curva codificada como metadados de qualquer maneira, por exemplo, uma curva com três pontos Lt para regimes de brilho interessantes na atual tomada de imagens, e em vez de, por exemplo, valores fixos de gpm ou gpp em cada lado, por exemplo, uma evolução linear ou parabólica ao longo da subfaixa de luminâncias de entrada entre Lt2 e Lt3, etc., e então a imagem reclassificada é calculada com o uso gtu=POTÊNCIA(g, GT) para qualquer Y_HDR como entrada, e aplicando-se esse gtu a qualquer codificação de cor linear da cor de pixel sendo processada.

[0206] Assim, conforme explicado com referência à Figura 2, qualquer receptor que recebe os vários metadados pode implementar a modalidade desejada de otimização ajustada por tela conforme especificado pelo lado de criação de conteúdo. Para resumir, ao menos uma imagem classificada com cores de pixel é necessária como uma imagem realmente codificada e transmitida e como um ponto de partida, por exemplo, uma classificação de 2000 nits (a qual realmente transmitida e recebida, por exemplo, no formato MPEG comprimido, que chamaremos de imagem principal). Então, haverá uma definição de funções para se determinar ao menos uma classificação adicional (por exemplo, LDR se a imagem principal era, por exemplo, HDR de 2000 ou 5000 nits), de modo tão preciso quanto a definição do classificador com o uso de várias possíveis funções globais ou locais (explicamos em grande parte o aspecto do processamento de luminância que é o mais importante da reclassificação de faixa dinâmica de luminância - isto é, a determinação de outra aparência em uma cena para uma tela com diferentes recursos de faixa dinâmica que compreendem ao menos o brilho de pico - mas, geralmente, também as transformações de cor podem estar envolvidas, como o processamento de saturação de ao menos alguns objetos da imagem, e potencialmente, até mesmo de alterações de matiz). Essa transformação pode ser transmitida, por exemplo, ao menos através de um mapeamento arbitrário de Y_HDR para Y_L, definido como uma curva cc padronizada, por exemplo, definindo-se como transformar a classificação de 2000 nits em uma classificação que é teoricamente ideal para um brilho de pico 500 ou 10000 nits (tela de referência ou alvo) ou valores em torno desses. Então, se a transformação em uma imagem HDR recebida for necessária, por exemplo, porque uma tela com brilho de pico um pouco diferente está presente no lado de recepção ou, por exemplo, porque um usuário usa seu controle remoto para controlar o brilho máximo abaixo do limite teórico máximo de 10000 nits (similar à criação de um tipo novo de tela), pode haver diversas modalidades de sofisticação sobre como criar uma nova reclassificação, por exemplo para 8000 nits. As versões mais simples podem ser predominantemente automáticas, e até certo grau, ignorar as particularidades colorimétricas e semânticas de uma tomada de imagens de uma cena HDR, e mais precisamente o que o classificador tem ou teria a dizer sobre ela, isto é, como ele gostaria de ver as alterações, por exemplo, brilho mais baixo, acontecer na distribuição de brilhos relativos de vários objetos ao longo do eixo de luminância até o brilho de pico disponível. Essa distribuição dos vários brilhos de objetos de imagens determinará a assim chamada aparência da cena (por exemplo, se ela é uma cena melancólica, predominantemente escura, e ainda assim transmite uma visão suficiente dos formatos das casas), entre outras coisas, devido ao efeito de contrastes intraobjetos (por exemplo, um vitral que é colorido, mas que é suficientemente mais brilhante do que o interior da igreja), e, geralmente, algumas otimizações necessárias estarão envolvidas, porque mesmo que haja uma faixa dinâmica suficiente na tela para renderizar uma cena imageada particular, estaremos lidando geralmente com uma determinação artística de uma família de aparências, em vez da distribuição exata de luminâncias de objetos ao longo do eixo de luminância como ocorre na própria cena capturada original (isto é, por exemplo, o classificador pode escolher fazer um lado externo ensolarado apenas algumas paradas mais brilhante que o lado interno para ter uma simulação suficiente do efeito de ambiente externo, em vez, por exemplo, 5 paradas). Deve-se notar também que a arte está criando as aparências adequadas, e que a visão humana é altamente complexa, e, portanto, desejamos ter uma tecnologia que seja razoavelmente simples (ou não será adotada) e suficientemente poderosa para lidar com ao menos a maioria dos cenários de maneira suficiente (caso contrário, o criador de conteúdo não poderá usá-la satisfatoriamente), e é com isso que os inventores devem se ocupar. Conforme descrito anteriormente, o classificador pode usar parâmetros diferentes para ensinar como as reclassificações devem depender de uma classificação em ao menos um lado de um intervalo no qual está o brilho de pico da tela pretendida, isto é, como as curvas de reclassificações se transformam umas nas outras. Com um ou vários parâmetros, o classificador tem um controle rápido, mas poderoso, se como os receptores irão calcular as várias reclassificações potencialmente necessárias. Os receptores apenas aplicarão as funções matemáticas nas cores de entrada da imagem principal. Embora tenha-se descrito uma modalidade pragmaticamente simples operando em cores de pixel RGB lineares, o versado na técnica compreende que os princípios da invenção podem também ser aplicados de modo equivalente em, por exemplo, representações de cor Yu’v’, nas quais, por exemplo, os componentes uv são mantidos constantes, e Y é transformado conforme necessário, ou mediante o uso de correlatos Y como Valor V= max(R,G,B), que são ambos combinações lineares dos coeficientes de cor lineares que podem ser similarmente escalados de modo multiplicativo, etc. Desde que se possa aplicar os princípios de alteração de escala, e assim precisar de algum componente que seja indicativo do brilho da cor, e pode-se então alterar a escala (multiplicar) dos componentes de cor lineares ou não lineares (uma vez que o mesmo fator de escala pode ser definido fora da lei de potência, por exemplo potência(g*L; N)= potência(g;N)*potência(L;N), de modo que, caso se saiba como, por exemplo, a luminância é escalada, sabe-se também como um luma é escalado, e vice-versa; e, se for desejado, as mesmas podem ser formuladas com outros correlatos de brilho e/ou espaços de cor. Deve-se notar também que foram descritos os fundamentos das modalidades da presente invenção com base no PB_D da tela pretendida e, no caso de, por exemplo, um fornecedor de aparelhos de TV se interessar por um processamento mais complexo para aperfeiçoamento da espetacularidade do efeito HDR, como, por exemplo, aumentos do contraste local etc., ele poderá coordenar esse processamento no ajuste de tela resultante, mudando o que deve ser mudado com as informações fornecidas pelo criador de conteúdo, por exemplo, gradientes locais das funções de mapeamento de luminância, informações sobre segmentação de objetos etc.

[0207] A Figura 3 mostra um exemplo da tecnologia da presente invenção aplicada à criação de uma imagem ou vídeo e o lado de codificação, por exemplo, em um estúdio de pós- produção de uma produtora de filmes, ou um estúdio de produção de uma emissora, ou mesmo em sua forma mais simples em uma unidade móvel de produção de TV ao vivo etc. Um servidor de dados 301 tem espaço de armazenamento para fornecer uma imagem inicial Im_src (que é geralmente uma imagem HDR, isto é, com ao menos objetos de alto brilho, por exemplo, luminância acima de 1000 nits, a serem renderizados, e frequentemente também objetos escuros, embora em algumas modalidades a imagem original poderia ser uma imagem de alguma faixa dinâmica mais baixa na qual o classificador ainda precise criar efeitos HDR, mediante o cálculo, por exemplo, de uma bola de fogo com matemática de computação gráfica, sendo que a bola de fogo pode ser representada como uma ou mais pequenas imagens), ou sequência de vídeo através de uma entrada 302. Sem limitações, pode-se assumir que isso é, por exemplo, a filmagem original de câmera. Um conversor de imagem 303 está disposto para converter esses dados brutos em, por exemplo, uma imagem principal HDR de 5000 nits, cuja relação entre luminâncias renderizáveis e códigos de cor (compreendendo lumas, e dois outros componentes que codificam os aspectos cromáticos da cor) é determinada por uma função de transferência eletro- óptica (EOTF) pré-selecionada, geralmente fixa, mas potencialmente variável. Geralmente, o criador de conteúdo pode definir uma imagem de uma maneira referida em tela, isto é, definindo como ela deve ser exibida em uma tela de referência de 5000 nits, e a conversão das luminâncias da cena a partir da câmera, ou coordenadas de cor equivalentes, irá, geralmente, envolver uma classificação artística, que chamaremos de classificação mestra M_XDR (por exemplo, lâmpadas de 20000 nits podem ser codificadas como códigos para renderizar 5000 nits após a aplicação da EOTF, e tais fatores como os ajustes de exposição relativa da câmera deixam então de ser necessariamente importantes). Para este efeito, o conversor de imagem 303 compreende uma unidade de transformação de cor 304 disposta de modo a executar qualquer conjunto de transformações de cor desejadas para criar uma boa classificação mestra. Os parâmetros para essas transformações não precisam ser armazenados, uma vez que o sistema a partir desse ponto, isto é, também a decodificação em um lado de recepção, pode iniciar apenas a partir dessa classificação mestra (que será geralmente armazenada no sinal de imagem S_im, que pode ser formatado de acordo com, por exemplo, tecnologias convencionais de codificação de vídeo, como MPEG_HEVC, isto é, com a classificação mestra sendo a imagem principal armazenada como um conjunto de imagem de componentes YCbCr transformados por DCT, e os metadados, por exemplo, as mensagens SEI), mas algumas modalidades poderiam também armazenar alguns metadados dessa classificação mestra. Em segundo lugar, de acordo com nossa invenção, o classificador irá classificar também uma aparência de segunda faixa dinâmica IM_GRAD_LDR, por exemplo LDR para tela de 100 nits, uma vez que essa informação é necessária para otimizações reais de tela posteriores. As funções desse mapeamento não precisam ser armazenadas, isto é, a unidade de transformação de cor 304 irá gravar os parâmetros correspondentes (por exemplo, gai, cc) os metadados da S_im. A entrada necessária fornecida pelo classificador pode ser inserida por meio de uma entrada de dados 331 conectada à interface de usuário de especificação de cor 330, como, por exemplo, um teclado, que pode ser um console dedicado para classificação de cor, etc. Na modalidade exemplificadora assumimos que a classificação HDR mestra M_XDR é armazenada ou transmitida como imagem principal juntamente com funções de redução de classificação que possibilitam em um lado de recepção calcular a classificação LDR, mas, alternativamente, pode-se também armazenar/transmitir a classificação LDR classificada secundária como imagem principal, juntamente com funções de aumento da classificação para reconstruir ao menos uma aproximação suficientemente próxima da classificação HDR mestra em um lado de recepção, ou uma classificação intermediária poderia ser usada como imagem principal, com funções para se obter as classificações LDR e HDR criadas no lado de codificação, etc.

[0208] O processamento da imagem principal nas unidades 104, 105, 106, 102, etc., é, novamente, similar ao que foi explicado com referência à Figura 2, porque o codificador precisa simular para o classificador o que realmente acontecerá no lado de decodificação. Entretanto, agora, os valores dos parâmetros (gai, cc, etc.) de várias unidades de processamento de cores são, geralmente, inseridos como ajuste adequado pelo classificador humano, embora outras modalidades poderiam também fazer a leitura dos mesmos a partir dos metadados, de modo similar ao que ocorre com referência à Figura 1, por exemplo, se um classificador executou a redução de classificação com outra unidade de transformação de cor, possivelmente em outro momento. Por exemplo, ele pode ter usado um programa de conversão de cores com outras transformações matemáticas definindo uma segunda classificação, e uma unidade de conversão intermediária pode converter esses processamentos de cor em processamentos que resultam em aparências aproximadamente iguais com quaisquer das subunidades processamento de cores combinadas das modalidades da presente invenção para executar a conversão HDR para LDR, ou outra conversão de faixa dinâmica. A unidade de determinação do fator de alteração de escala 200 pode, geralmente, ser inicialmente pré-carregada com um único parâmetro gpm de valor 1. Nesse caso, a simulação se aplica à Equação 1 ou 2 para criar a classificação MDR. O classificador pode, por exemplo, olhar em paralelo (ou sequencialmente para adaptar sua visão de modo diferente, etc.) para três telas colocando as imagens relacionadas em uma saída de tela 311, ou seja, uma tela HDR 312 mostrando a classificação HDR que, nesse caso, era uma imagem principal também chamada de classificação mestra, uma tela LDR 314 mostrando a classificação LDR de 100 nits e, geralmente, sendo um monitor de referência de 100 nits, e uma tela MDR 313 adequadamente escolhida para mostrar a classificação intermediária ideal reclassificada de acordo com qualquer uma das modalidades da presente invenção. Essa tela MDR 313 pode, por exemplo, ser escolhida de forma logarítmica próximo da parte intermediária das duas classificações LDR e HDR típicas disponíveis. Se o classificador, por exemplo, trabalhar em um formato que usa geralmente e de maneira padronizada um brilho de pico de 2000 nits para a classificação HDR, ele poderá escolher uma tela MDR com um brilho de pico de 400 nits (4x 100, e aproximadamente 2000/4). Como a otimização é aproximada como um ajuste de aparência de segunda ordem, não é de importância crítica se a verificação for feita, por exemplo, em uma tela MDR de 500 ou de 600 nits. Além disso, o classificador pode preferir usar, por exemplo, uma tela popular no momento de criação de conteúdo. Se a maioria das telas disponíveis no campo tiver um brilho de pico de cerca de 800 nits, o classificador poderá escolher uma dessas telas MDR de 800 nits(embora ele possa estar classificando um material mestre de 5000 nits para um futuro no qual haverá telas melhores, mas, certamente, ele gostaria também que seus filmes tivessem também uma boa aparência na tela atual de 800 nits). Em geral é vantajoso estar em algum lugar próximo do ponto médio para a tela MDR, uma vez que esse é o local onde se espera que a maior quantidade de reclassificação será necessária. Mas o classificador pode, por exemplo, escolher também uma segunda tela LDR para verificar a criticalidade de qualquer aparência “mais LDR”, também em telas que podem ter aparências um pouco mais contrastantes, e, portanto, nesse caso a tela MDR pode, por exemplo, ser apenas 1 ou 1,5 paradas acima de 100 nits. Se o classificador estiver satisfeito com a aparência, ele poderá pressionar um botão “Finalizar”. No presente exemplo, essa ação pode, por exemplo, armazenar o sinal S_im (isto é, a imagem principal e os metadados de redução de classificação), e no exemplo anterior, um valor gpm de 1,0, mas em modalidades mais avançadas, dados de otimização de classificação MDR em um produto de memória 321, como, por exemplo, um disco blu-ray (BD), através de uma saída de imagem 320. O versado na técnica deve entender que, de modo similar, os dados podem, por exemplo, ser armazenados em um servidor para serem fornecidos posteriormente através, por exemplo, da internet, ou serem transmitidos em tempo real, etc. Em modalidades mais avançadas, o classificador pode usar o cálculo da classificação MDR, aplicando, por exemplo, a função 503 como um ponto de partida. Ele pode, então, fazer uma classificação adicional para obter uma terceira aparência precisa, obtendo melhorias a partir desse princípio simples de reclassificação (isto é, novamente ele usará pelo menos algumas ferramentas da tecnologia original de codificação de classificações, mas poderá começar a partir de uma reclassificação MDR ajustada por tela em vez de uma classificação mestra, para gerar uma terceira classificação original, e um conjunto de funções de transformação de cor, a serem transmitidas para um receptor). Por exemplo, ele pode determinar uma região das imagens da cena, e aplicar a ela uma curva padronizada adicional para lidar especificamente com essas sub-regiões/objetos. Isso pode ser usado, por exemplo, se um rosto no escuro tiver importância crítica, as funções de reclassificação simples o tornarão razoável, de modo que aspectos como os olhos e a impressão facial possam ser bem preservados, mas o agora classificador um tanto crítico ainda não está satisfeito (em todos os campos de atuação, algumas pessoas podem ser menos crítica, e outras altamente críticas). A função de reclassificação simples escolhida pode levar a uma boa classificação MDR para, por exemplo, 500 nits no que diz respeito aos ambientes circundantes - por exemplo, uma rua escura - porque eles não todos observados assim tão criticamente, mas o classificador pode desejar tornar o rosto mais saudável, e aplicar alguma outra função. Os metadados para essa terceira classificação (parcial) podem então também ser armazenados como uma ou mais funções no disco blu-ray, ou serem transmitidos como metadados adicionais etc. Uma ou mais unidades de formatação de sinal 310 podem ser usadas para formatar todos os dados no formato exigido. Por exemplo, para controlar uma tela, uma outra codificação pode ser usada após a limitada largura de banda da conexão da tela, para armazenamento em, por exemplo, um BD, caso em que uma imagem de alta faixa dinâmica formatada SF_X2DR pode ser codificada de acordo com qualquer esquema de codificação HDR, mas, de preferência, um esquema no qual uma imagem principal é complementada por metadados codificando transformações de cor para calcular uma segunda imagem de faixa dinâmica a partir da imagem principal, com as duas imagens sendo para telas com faixas dinâmicas significativamente diferentes, isto é, geralmente ao menos um fator de 2. No presente exemplo, assumimos que o “pipeline” de processamento de luminância (incorporado como 102) contém um mapeamento para um típico formato LDR (com o inverso 709 executado pela unidade 112), mas a tela MDR pode ter outro formato-fonte etc., com o qual a unidade de formação 310 poderá lidar. Apesar de esta não ser a parte dominante dos ensinamentos de nossa invenção, ela deve ser entendida pelo versado na técnica, e será agora ser elaborada adicionalmente.

[0209] A Figura 8 descreve como o princípio de otimização pode funcionar para obter a saturação correta de cores de pixel para controlar telas MDR de brilho de pico intermediário, de modo similar ao processamento de luminância explicado acima. Em algumas modalidades, pode-se preferir fazer uma alteração de escala otimizada tanto da luminância como da saturação, embora outras modalidades possam usar apenas a alteração de escala da luminância. As cores de entrada têm uma saturação de entrada ou, mais precisamente, um croma C_in, que é chamado de um valor zero sendo um branco. Existem várias definições de saturação, por exemplo, saturações normalizadas para [0,1 como em HVC, ou outras saturações como no espaço de cor CIE 1976 uv, mas todas tem a propriedade de que a saturação de uma cor é definida como um vetor começando em um branco predeterminado como D65, e estendendo-se por uma certa distância. Supondo- se que se tenha em uma imagem de entrada HDR um pixel com uma saturação Cs, e a qual será aumentada para um valor Cf. Esse valor pode ser definido por um fator multiplicativo, s, que é um fator similar ao fator multiplicativo comum inicial g descrito anteriormente. Se a LDR for mais saturada que a imagem HDR (o que pode ser devido, por exemplo, ao fato de que cada diminuição na luminância das regiões da imagem renderizada causada pelas capacidades mais baixas de brilho de pico de uma tela corresponde a uma diminuição em riqueza cromática que precisa ser corrigida por um processamento de saturação específico de classificador), será útil aumentar também a saturação das classificações MDR, mas em menor grau, ou seja, com um fator st, que é uma modalidade do fator gt. Aparelhos com recurso de processamento de saturação geralmente têm um processador de saturação de cor 106 que não é um simples processador que usa um multiplicador de saturação fixo, s, mas que, ao invés disso, está disposto para fornecer saturação adequadamente escalada. O processamento de saturação pode ser fixo para todas as luminâncias, o que pode ser feito com um único valor multiplicativo, s, mas ainda precisa de otimização de tela para um valor ideal para cada tela MDR conectada, mas geralmente para a conversão de faixa dinâmica, pode-se desejar um processamento de saturação mais sofisticado. Por exemplo, a saturação pode variar dependendo da luminância, ou de Valor menos a luminância, e/ou da saturação de entrada etc. O importante é que, embora a reclassificação de saturação necessária (isto é, entre a imagem HDR e a imagem LDR) para cada pixel de entrada seja especificada pelo classificador e comunicada nos metadados MET, ela pode ser determinada junto ao receptor, e então adequadamente escalada. Geralmente, o processador de saturação de cor 106 tem algum mecanismo de tabela de consulta para determinar s. Por exemplo, se a cor de entrada (Ri,Gi,Bi)=(0,2,0,3,0,7), a LUT fornece, por exemplo s=1,1, ou no caso de “dessaturação”, por exemplo s=0,5, e para outra cor de entrada pode haver o mesmo ou um valor diferente de s. O processador de saturação de cor 106 compreende, então, uma unidade para calcular um fator multiplicativo de saturação resultante (st) que é uma modalidade de um fator multiplicativo comum resultante gt, que é similar à unidade 200, e calcula: st= POTÊNCIA(s, sp). A razão sp para a saturação pode ser um pouco diferente do que para o processamento de luminância, mas geralmente ainda dependerá da relação entre PB_D, PB_H e PB_L, e, em geral, não há necessidade de torná-la diferente do modo como gp é calculado (porém é certo que se poderia usar valores de gpm diferentes para a saturação e o processamento de luminância, tornando as luminâncias da aparência MDR mais similares à aparência LDR, por exemplo, e ainda assim fazendo as saturações parecerem similares às saturações da imagem HDR etc.). Conforme visto na Figura 8, também pode fazer sentido usar regimes diferentes de saturação definidos, por exemplo, pelos demarcadores de saturação Lts (que podem, na verdade, ser quaisquer informações de demarcação que possibilitem classificar as cores de pixel em duas ou mais classes diferentes para processamentos de saturação diferentes), por exemplo, para especificar uma região de “dessaturação” para lidar com altos brilhos em reclassificações de baixo brilho de pico, e uma região para intensificar a riqueza cromática de cores mais escuras, etc.

[0210] Geralmente, é vantajoso executar o processamento de saturação como: Ro=st*(Rin-Y)+Y Go=st*(Gin-Y)+Y Bo=st*(Bin-Y)+Y [Eqs. 5] onde Ri, Gi, Bi são os componentes de entrada de cor lineares, e Ro, Go, Bo os componentes de cor de saída resultantes após o processamento de saturação, e Y é a luminância linear, isto é, uma combinação linear a*Ri+b*Gi+c*Bi, com as constantes a, b e c predeterminadas, embora outros processamentos equivalentes possam ser usados.

[0211] A Figura 9 fornece um exemplo adicional sobre como lidar com as peculiaridades, às vezes complexas, otimizadas em função da cena, da preferência de um classificador, mesmo com a mais simples das modalidades da presente invenção, que residem exclusivamente em um simples cálculo de reclassificação em um aparelho de recepção, e com a qual o classificador, por exemplo, não se importa em fazer uma verificação adicional. Para esse exemplo, usamos a alteração de escala logarítmica dependente do brilho de pico da tela de renderização pretendida das Equações 1. Vemos que esse método pode ajustar muito bem as luminâncias e contrastes necessários onde são exigidos na cena. Por exemplo, neste exemplo, as regiões acima de cerca de 60% (linear) do máximo (isto é, branco) - as quais presumiu-se serem definidas em uma imagem HDR - podem, geralmente, precisar de algum clareamento nesta renderização. Por outro lado, neste exemplo, há também uma região de imagem crítica em torno de 50%, que pode ser, por exemplo, o rosto de um ator em uma parte da cena que é relativamente brilhante. Por outro lado, nas regiões mais escuras da imagem, neste exemplo, não parece haver muitos objetos de alto interesse, porque a aparência LDR pode ter essas regiões mais escuras cortadas fortemente (corte suave). Isso pode ser uma cena onde, por exemplo, muitas coisas ocorrem no lado externo, como por exemplo uma paisagem iluminada pelo sol, e algum ambiente interno que pode-se artisticamente decidir escurecer razoavelmente, por exemplo, um celeiro ou o interior de um templo que é visto através de uma pequena porta, e, portanto, não é muito relevante o que existe lá dentro (devido ao tamanho pequeno da região, mesmo na renderização HDR em uma tela HDR o sistema visual pode rapidamente descartar isso como um “preto desinteressante”, e, portanto, com a mesma filosofia de classificação, o classificador pode decidir fazer também em LDR aproximadamente o que é visto como preto (deve-se observar que nossos métodos devem ser capazes de trabalhar com variantes de classificação mais precisas e menos críticas, e geralmente com cenas HDR mais fáceis e mais difíceis, as primeiras sendo, por exemplo, duas regiões espaciais da imagem da qual a luminância média exata não é absolutamente tão importante em qualquer renderização MDR, e as últimas tendo, por exemplo, requisitos de renderização muito precisos, como, por exemplo, um monstro parcialmente oculto na neblina). A propriedade importante é que, mesmo com a mais simples das modalidades da presente invenção, pode-se obter aproximadamente as aparências de brilho adequado e todos os contrastes determináveis correspondentes (isto é, entre a luminância dos pixels 1 e 2 interessantes selecionados, ou a luminância média das regiões 1 e 2 interessantes, por exemplo, um canto escuro e uma parte do ambiente externo visto através de uma janela de uma sala), para todas as faixas dinâmicas intermediárias (MDR). Na Figura 9, a curva 909 é a transformação de luminância a ser aplicada para transformar a aparência HDR de 5000 nits em uma aparência LDR de 100 nits; a HDR transformada em si mesma inalterada certamente corresponderia à diagonal, e as outras curvas são as transformações necessárias para reclassificar para várias classificações MDR, para telas de vários brilhos de pico entre 5000 e 100 nits para serem fornecidas com imagens de aparência otimizada.

[0212] A Figura 10 mostra outro exemplo mais avançado possibilitado pelas modalidades da presente invenção (seja de forma controlada (parcialmente) por um classificador humano no lado de criação de conteúdo, ou uma reclassificação feita automaticamente por um receptor específico, por exemplo um aparelho de TV HDR). Este exemplo mostra como se pode reclassificar de maneira inteligente se mais informações semânticas sobre várias regiões de imagens estiverem disponíveis, determinado de modo simples (por exemplo, pelo classificador e comunicadas, ou por uma unidade de análise de imagens residindo exclusivamente em um receptor) como um único demarcador Lrc luminância (ou luma). Nesse exemplo, a região mais brilhante pode ser de importância muito crítica, e a região mais escura pode ser difícil de otimizar simultaneamente (isto é, manter, por exemplo, contraste suficiente para toda a faixa escura de possíveis luminâncias de pixel em uma tomada de imagens, e, ao mesmo tempo, precisar de uma parte suficientemente grande da faixa de luminância para as imagens MDR de faixas mais baixas para renderizar com qualidade visual suficiente a região de imagem mais brilhante), isto é, pode-se decidir rapidamente optar pela redução da qualidade de uma forma específica. O termo “rapidamente” significa que, mesmo para brilhos de pico (PB) MDR que são próximos do PB HDR, por exemplo se o PB_H = 2800 nits e o PB_MDR for de 2500 nits, a faixa mais baixa será completamente ou quase toda mapeada de acordo com a estratégia que reproduz a aparência LDR de 100 nits. Entretanto, a região mais brilhante pode ajustar mais gradualmente em direção à aparência LDR, ao longo de vários PBs MDR entre 2800 e 100 nits. Essa estratégia pode ser determinada pelo classificador, ao menos parcialmente, ou como estratégia orientação inicial, mas também determinada (por exemplo, ignorando o que quer que o classificador tenha especificado, por exemplo ele pode ter especificado uma reclassificação suave em direção à aparência LDR para as regiões mais escuras e mais brilhantes das imagens da cena) pelo próprio receptor.

[0213] Nos exemplos acima, nos quais foi descrita a modalidade em que um classificador humano estava envolvido, isto é, podia participar, por exemplo, na renderização final de suas imagens pelo sistema de comunicação de imagens HDR, um algoritmo de computador poderia também ser utilizado como alternativa a um classificador automático. Isso pode ocorrer em um lado de criação, onde o algoritmo pode realizar uma análise bem precisa de imagens, porém não em tempo real, por exemplo identificando regiões, tipos específicos de texturas, ou até mesmo classes de objetos como seres humanos, certos animais, veículos ao sol com reflexos especulares no metal etc., e com base nas informações estatísticas sobre como um classificador geralmente iria preferir classificar esses tipos de cenas e seus objetos. Entretanto, uma unidade de classificação automática poderia também residir em um receptor, e aplicar um processamento de melhoria de imagens codificando o conhecimento sobre qualidade de imagens desenvolvido, por exemplo, por um fabricante de aparelhos de TV ao longo de décadas (e talvez constituindo sua aparência característica). A nova solução é agora incorporar isso em nossa tecnologia de classificação HDR. A Figura 11 mostra essa solução com uma modalidade exemplificadora da unidade de transformação de cor 1130 de um receptor, por exemplo incorporada em um aparelho de TV, ou um “settopbox”, ou um computador fornecendo uma tela comercial em um supermercado ou eventos promocionais etc.

[0214] As imagens do vídeo, e os metadados para fazer a reclassificação de cores nativas (por exemplo, de HDR de 5000 nits como imagens de entrada, Im_in, a LDR de 100 nits, por meio da alteração logarítmica de escala explicada com referência à Figura 1, com um parâmetro lg escolhido como sendo ideal para essa cena por um classificador humano no lado de criação, e também parâmetros P_CC definindo, por exemplo, um formato multilinear de uma curva de mapeamento de matiz personalizado) são recebidos através de uma rede de comunicação de imagens 1101 no presente exemplo (por exemplo, um servidor de vídeo conectado via internet, ou um serviço de radiodifusão por TV ou para vários destinatários via “multicast” por uma rede de telefonia móvel etc.). A unidade de determinação do fator de alteração de escala 1102 aplica, então, a especificação do mapeamento de matiz especificado como ideal para mapear uma aparência em um lado de uma faixa pretendida (embora os mesmos princípios possam, em tese, ser usados também para sair um pouco dos limites da faixa), por exemplo, HDR, para a aparência de referência no outro lado da faixa, por exemplo, LDR de 100 nits, e determinar um fator de alteração de escala inicial, g_nat, para realizar a alteração de escala RGB linear (ou potencialmente até mesmo não linear). Uma segunda unidade de determinação do fator de alteração de escala 1103 determina o fator de alteração de escala final, g_fin, a ser usado na presente situação, mas agora nessa modalidade, esse fator pode ser determinado com o conhecimento de melhoria de imagem do aparelho de recepção. Para este efeito, é incluída uma unidade de análise de imagens 1110 que pode compreender várias unidades de análise de imagens (que podem, geralmente, ser, por exemplo, vários componentes de software para análise de imagens, ou emulação por hardware dos mesmos). Em um exemplo explicativo simples descrevemos uma unidade de análise de histograma 1112, e uma unidade de reconhecimento de objeto 1112. A unidade de análise de histograma 1112 pode ser disposta de modo a analisar a distribuição de luminância da(s) imagem(ns), e determinar que há, por exemplo, muitos pixels escuros, ou talvez que pixels semanticamente importantes são escuros (porque as unidades podem trabalhar em conjunto). Ela pode, então, determinar, por exemplo, um demarcador da região escura, e uma estratégia de clareamento pretendida. A unidade de reconhecimento de objeto 1112 pode compreender, por exemplo, um detector de rosto, que pode detectar rostos com vários brilhos porque os atores se posicionam em várias partes da cena que são iluminadas diferentemente. A partir desse conhecimento, uma unidade de determinação de parâmetros de estratégia 1113 determina os parâmetros correspondentes e, de acordo com as várias modalidades reveladas, reside na segunda unidade de determinação do fator de alteração de escala 1103 (deve-se observar que parte dessa funcionalidade poderia residir em outros componentes em outros aparelhos ou sistemas, mas aqui descrevemos apenas sua funcionalidade). Por exemplo, uma maneira lógica da unidade de determinação de parâmetros de estratégia 1113 informar que ela deseja, por exemplo, clarear a cena e, em particular, as cores mais escuras em um grau mais elevado que o método nativo do classificador (que poderia ser tão simples quanto aplicar nossa Equação 1, sem nenhuma informação específica de reclassificação fornecida pelo classificador humano, ou uma estratégia mais avançada, que pode ser usada em parte, ou em grande parte ignorada), pode ser feita especificando-se um novo valor de gpm (certamente, em certas modalidades o aparelho poderia também definir novos valores para as funções que definem o mapeamento entre as classificações HDR e LDR originais, por exemplo, o declive da parte de fundo, mas algumas modalidades poderiam considerar essas informações sagradas fornecidas pelo fornecedor de conteúdo, que também não precisam ser modificadas, porque sua aparência exclusiva pode ser obtida em uma etapa de pós- processamento; se for necessária qualquer adaptação de formato funcional, então isso pode ser implementado apenas para a parte de cálculo da MDR, por exemplo, em vez da alteração de escala multiplicativa pura descrita na Figura 19, o aparelho de TV poderia aplicar uma mistura à função de mapeamento de luminância MDR resultante para os valores mais escuros, ou a redefinição de qualquer função alternativa, por exemplo, multiplicar pelos valores de correção de uma função específica fixa ou dependente de imagem determinada pelo aparelho de TV). Se a unidade de análise de imagens 1110 determinou - por exemplo, com sua análise de histograma e identificação de um ator nessa região mais escura - que, de acordo com o fabricante do receptor as partes mais escuras são originalmente escuras demais para renderizar, por exemplo, na tela conectada de 1100 nits, o valor de gpm pode ser elevado um pouco em direção à aparência LDR (uma vez que mover em direção à LDR pode, geralmente, ter um comportamento que, grosso modo, e agora de modo dependente de cena, corresponde ao clareamento). Um demarcador de luminância Ltr1 pode ser comunicado para executar essa estratégia apenas com a subfaixa mais escura da luminâncias HDR. Existem outras maneiras da unidade de análise de imagens 1110 comunicar seu desejo de reclassificação necessária, por exemplo, na forma de segundos metadados MET_2. Por exemplo, ela poderia “fingir” que a tela conectada não é de 1100 nits, mas, em vez disso, comunicar um valor PBF de, por exemplo, 1300, ou 900, e usá-lo de modo análogo ao PB_D no cálculo da razão logarítmica. Ou, ela poderia já comunicar uma razão logarítmica, e deixar a unidade 1103 aplicar a ela um valor de gpm etc. Ou, ela poderia ajustar os valores de PB_H e PB_L. Assim, qualquer combinação necessária de valores para calcular o g_fin final, com os valores corretos determinados pela unidade de análise de imagens 1110 pode ser comunicada nos MET_2 à unidade 1103. Além de analisar apenas as imagens Im_in, pode ser muito vantajoso verificar o tipo de “inteligência” que o classificador colocou no formato das funções de transformação de cor. Para este efeito, em algumas modalidades pode ser incluída uma unidade de análise de mapeamento de matiz 1114 disposta de modo a analisar o formato funcional do mapeamento total de matiz entre a primeira e a segunda aparências de referência, isto é, geralmente HDR e LDR. Por exemplo, essa unidade pode lidar com três regiões e verificar qual processamento (por exemplo, corte suave) é feito na cor mais brilhante, qual processamento é feito nas cores de faixa intermediária (por exemplo, um aumento de contraste), e qual processamento é feito nas cores escuras. Se, por exemplo, uma dobra rápida é encontrada no mapeamento de matiz, como no exemplo da Figura 9, a parte de inclinação brusca em torno de 50%, então a unidade de análise de mapeamento de matiz 1114 pode determinar um ponto de demarcação Ltr1. Essa informação pode, então, ser usada pela unidade 1113 para determinar uma reclassificação inteligente dos tons médios otimizando o contraste de acordo com as preferências do fabricante do receptor, e também levando em conta o conhecimento semântico sobre a cena presente na especificação de classificação do classificador, e, mantendo ao menos até certo ponto o alinhamento em várias modalidades com essa intenção de reclassificação do classificador, porque essas modalidades aplicam a reclassificação nas intenções de reclassificação originais codificadas em g_nat.

[0215] Deve-se notar que, neste exemplo mais simples, assumiu-se que não havia outros parâmetros de metadados indicando um desejo específico de reclassificação do classificador (por exemplo, um valor de gpm), mas, se o classificador especificar tais metadados no sinal de entrada S_im, ele também poderá ser comunicado à unidade 1110. Essa unidade pode, então, preencher essa necessidade, por exemplo, alterando o valor de gpm dentro de uma pequena tolerância, por exemplo, dentro de 5% ou 10%, ou apenas ao longo de uma subfaixa limitada da faixa de luminância, por exemplo, alterando apenas a aparência das cores 10% mais escuras, enquanto retém as preferências originais do classificador de criação de conteúdo para as cores mais brilhantes, ou, alternativamente, ignorar completamente o valor de gpm do classificador, e determinar seu próprio valor de gpm para a unidade 1103.

[0216] Algumas modalidades mais avançadas podem possibilitar também que um observador tenha uma participação na aparência final. Geralmente, através de uma conexão de entrada 1121 com um controle remoto 1122, e através de uma interface de usuário 1120, ele pode inserir alguns comandos simples de reclassificação. Por exemplo, ele pode ter uma escala de 5 pontos para clarear a imagem. Isso pode ser informado como um sinal b_rel = {-2, -1, 0, 1, 2}, que pode ser convertido pela unidade 1113 em, por exemplo, vários aumentos de brilho de paradas nas cores 10% mais escuras, e, por fim, um ou mais valores de gpm, e talvez um ou mais demarcadores (Ltr1, Ltr2) para realizar o clareamento correspondente que criará uma aparência adequada para o observador. Qualquer enlace como esse pode ser feito pelas várias modalidades de receptor, por exemplo -1 pode corresponder a um aumento de 10% no PB_D, transmitido como um valor PBF, etc.

[0217] Explicamos anteriormente como pode-se, com as presentes modalidades, determinar as reclassificações que se correlacionam com os parâmetros visuais importantes de brilho, e com referência à Figura 12 descrevemos de maneira simplificada um exemplo de como se pode determinar semanticamente por imagem as várias alterações de contraste da aparência de renderização MDR final com nossas várias modalidades. A faixa dinâmica ou, ao invés disso, a razão de contraste é um conceito simples: a cor mais escura na imagem em comparação com a mais brilhante. O contraste psico- visualmente relevante é um parâmetro mais complexo. Ainda assim, ele pode ser determinado de modo relativamente mais simples com as modalidades adaptáveis por imagem apresentadas e descritas acima. Geralmente, o contraste final em uma cena pode ser estimado aproximadamente a partir de dois fatores: os contrastes intraobjetos, que determinam quão bem as texturas de objetos são visíveis (por exemplo, uma expressão facial, ou a proximidade do rosto, ou os grãos de uma superfície de madeira), e, em particular, quando imagens de alta razão de contraste estão envolvidas: os contrastes interobjetos. Em muitas cenas HDR, pode haver apenas algumas, na maioria das vezes apenas 2, regiões iluminadas diferentemente. Por exemplo, a luminância média em ambientes internos, em comparação com a de ambientes externos. Ou a luminância média noturna em ruas em comparação com a de algumas lâmpadas. Na faixa HDR pode haver várias dessas subfaixas de luminância média, pois a faixa de luminância de, por exemplo, uma tela de 5000 nits é suficientemente grande. Por exemplo, pode haver vários brancos diferente, por exemplo ambientes internos brancos como papel, branco próximo de uma lâmpada, e o branco ainda mais brilhante da própria lâmpada, e talvez uma lâmpada ainda mais brilhante. Na faixa LDR, nem todas essas regiões de brilhos diferentes podem ser mapeadas fielmente. Na verdade, as codificações LDR já existentes são bem adequadas para codificar todas as cores em relação ao branco, ou de modo similar os 18% tons intermediários de cinza relacionados (e, em um nível mais profundo, pode-se chegar à quantização de ruídos e/ou código de um lado, mas também, por outro lado, o que o sistema visual adaptado verá como cores pretas, por exemplo abaixo de 5% linear de branco), mas não para tantas regiões iluminadas diferentemente. Para algumas imagens, o classificador pode, para a aparência LDR, precisar decidir cortar todas as regiões brancas diferentes para o mesmo branco LDR (R=G-B=255), em vez de correr o risco de que algumas lâmpadas terão aparência cinza. Assim, por exemplo, o equilíbrio entre a aparência de brilho médio para pixels em ambientes internos em um monitor LDR de 100 nits, e quão mais brilhante o ambiente externo é percebido (onde esse ambiente externo pode também precisar ser altamente saturado em vez de mais brilhante, mas “pastelizado”), isto é, o contraste intraobjetos para essas duas regiões pode ser de importância crítica dependendo da imagem processada.

[0218] A Figura 12 explica como o receptor poderia equilibrar os vários contrastes em tais regiões, e, portanto, a aparência de contraste total da imagem renderizada. A curva 1201 especifica como o classificador especificou o mapeamento de matiz para obter a imagem LDR de 100 nits. Vemos uma região que aplica corte suave nas cores mais brilhantes, uma região de faixa intermediária onde muita coisa parece estar acontecendo, isto é, onde pode haver vários objetos de importância crítica (por exemplo, 3 atores iluminados diferentemente), porque há vários pontos de dobra críticos nessa parte da curva de mapeamento de matiz, e um mapeamento preferencial para as cores mais escuras. Se a unidade de análise de imagens 1110 determinar dois demarcadores, Ltr1 e Ltr2, para essas sub-regiões importantes, ela poderá propor vários métodos de equilíbrio de contraste. Por exemplo, ela pode determinar que, para as cores mais brilhantes, a curva 1210 fornece um contraste mais ideal. Isso pode alterar a aparência, por exemplo, daquela região externa ensolarada, porque agora os pixels mais escuros dessa sub-região poderiam ser mais escuros, por exemplo, para uma imagem MDR de 1200 nits do que a reclassificação nativa para MDR de 1200 nits teria sido proposta, mas isso também pode ser desejável para o fabricante do receptor. Nesse exemplo, o receptor decidiu ignorar em grande parte os detalhes da classificação para a faixa intermediária (o que pode ou não ser mais adequado para a qualidade da aparência renderizada final, mas que, dependendo do cenário da aplicação, pode ou não ser feito), e que ainda assim há alguma capacidade de adaptação, uma vez que o declive da curva de mapeamento de matiz proposto pelo receptor muda aproximadamente na metade da parte de faixa intermediária 1211. Nesse exemplo, a razão de contraste para os pixels mais escuros é igual àquela para a aparência MDR proposta pelo receptor, mas para a aparência LDR proposta pelo classificador, entretanto, o contraste é distribuído diferentemente, pois o formato da curva da parte inferior 1212 é muito diferente da intenção do classificador (no exemplo, porque, idealmente, o receptor pode querer usar, ao menos em grande parte, o formato original). Com essas técnicas, os vários contrastes interobjetos e intraobjetos podem ser otimizados, de acordo com o desejo do receptor após sua análise das imagens de entrada Im_in. Por exemplo, a parte superior da curva 1210 (seja este o resultado para MDR de 1200 nits, conforme proposto pelo classificador, ou já derivado de uma primeira determinação da unidade 1110) pode não ser suficientemente contrastante, isto é, o ambiente externo parece brando demais. Então, outra curva parcial da parte brilhante 1220 pode ser determinada, com mais razão de contraste e mais contraste. Isso pode significar que pode ser necessário que a parte intermediária tenha menos contraste, embora, certamente, também poderia ser proposta uma estratégia para mapear diferentes valores Y_HDR para os mesmos valores Y_L. Dessa maneira, tanto o segundo contraste intraobjetos C_intR2 quanto o terceiro contraste intraobjetos C_intR3 podem ser otimizados. Mas isso irá também determinar o contraste interobjetos, como o primeiro contraste interobjetos C_gl (por exemplo, definido entre as luminâncias de ponto médio das sub-regiões mais brilhantes e mais escuras, ou ponderado por ocorrências de pixel, etc.), o que, por outro lado, pode também ser otimizado primariamente por si só, potencialmente sacrificando parte do contraste intraobjetos, por exemplo, C_intR3.

[0219] A Figura 13 mostra uma modalidade genérica para calcular o mapeamento de matiz. Um desformatador de sinal 1301 obtém todas as informações necessárias. COD_DIR e COD_METR especificam qual direção de interpolação (DIR) e métrica para calcular as posições dos brilhos de pico intermediários de tela devem ser usados (por exemplo, conforme especificado no lado de criação de conteúdo por um classificador), e assume-se que esses sejam 135 graus e a métrica baseada em OETF, que será explicada mais adiante com mais detalhes. Em algumas modalidades que não possibilitam variação, eles podem ser previamente construídos no layout do circuito, por exemplo, em uma modalidade de aparelho que executa apenas o ajuste vertical. A unidade de determinação de mapeamento de matiz 1302 recebe através de entrada de metadados 116 todas as informações para construir um mapeamento de matiz final entre as luminâncias da imagem de entrada (por exemplo, uma imagem HDR) e a segunda classificação correspondente (LDR). Pois a segunda parte do método apresentado é que precisa-se estabelecer funções de transformação de cor entre duas aparências típicas na cena HDR, geralmente uma aparência HDR e, por exemplo, uma aparência LDR 100 nits. Através da entrada 1308, ela pode fornecer essa função de mapeamento de luminância de uma forma adequada (TMF), ou, em outras modalidades, um conjunto de multiplicador g, mas assume-se aqui que o formato funcional entre as luminância HDR de entrada e a luminância LDR de saída classificada seja transmitido, isto é, que isso seja apenas uma função, que será explicada como um mapa gráfico entre as luminâncias, mas que pode pela tecnologia ser transmitido, por exemplo, como uma LUT. Essa TMF será entrada para a unidade de determinação do fator de alteração de escala (200), que fará o cálculo da transformação necessária para obter a imagem MDR, e apresentá-la para cada cor de pixel a ser processada como um fator gt adequado para multiplicação (por exemplo, 1,53, ou 0,872, etc.).

[0220] Antes que os detalhes sejam explicados, primeiramente é dada ao leitor uma compreensão do que acontece.

[0221] A Figura 17 mostra, por meio de um exemplo de classificação bastante simplista, o que se quer obter com o ajuste de tela. Mostra-se as funções matemáticas como uma vista absoluta nos eixos de luminâncias absolutas (de referência de 5000 nits), contudo, deve-se observar que elas foram perceptualmente uniformizadas de acordo com a função de transferência optoeletrônica (P-OETF) apresentada. Assim, o espaço de código nessa representação é linear, não o espaço de luminância relativa, como em outros gráficos. O leitor pode imaginar, aproximadamente, como se os eixos fossem logarítmicos, mas o mapeamento exato entre coordenadas de luma relativa [0,0, 1,0] de uma tela de referência de, nesse exemplo, 5000 nits e a saída correspondente real são determinados por (EOTF Philips): Y=Lm*potência((rhoAv-1)/(rho-1); gam) [Eq. 6]

[0222] Nessa equação, v é o luma relativo (o leitor pode comparar esse luma com os lumas de um sinal LDR, isto é, por exemplo os valores de imagem [0, 255] divididos por 255), o qual assume-se que seja um número real, rho é uma constante, por exemplo igual a 33, gam é uma constante igual a 2,4, Lm é, neste cenário o PB da codificação de imagem, ou seja, 5000, e A e potência indicam a função de potência. Deve-se notar que no caso de se querer definir uma EOTF que termina em outros valores de PH_H, por exemplo, mais altos (ou, nessa equação maior que Lm, por exemplo 10000), então, faz-se necessário calcular um outro valor de rho: rho_2 = (33-1)*(PB_H/5000)A(1/gam) +1 [Eq. 7]

[0223] Assim, os valores equidistantes em [0,0, 1,0] sobre, por exemplo, o eixo x da Figura 17 são convertidos em luminâncias reais pelo cálculo com a equação acima. Essa função tem a propriedade de que os valores v são mais uniformes para o olho humano não linear em relação a uma típica faixa de luminâncias de tela HDR, isto é, isso pode ser visto conceitualmente como uma aproximação psicológica de luminosidade.

[0224] A OETF HDR Philips (P-OETF) da Requerente é definida com o inverso dessa função: v= 1/log(rho) * log(1+ (rho-1) * (Y/Lm)A1/gam) [Eq. 8]

[0225] Agora, caso se queira fazer uma classificação para, por exemplo, uma tela de 100 nits, o leitor poderá ver isso conceitualmente como se a exibição fosse feita em uma tela de 5000 nits, mas sem criar nenhuma luminância acima de 100 nits (o que é possível em uma tela de 5000 nits, mas não em uma tela de 100 nits). Uma possível transformação de luminância (de qualidade um tanto ruim, mas boa para propósitos de explicação) para se obter a imagem de aparência LDR (classificada originalmente), é a curva 1702. Basicamente, renderizou-se com essa curva todas as luminâncias de pixel (de uma imagem HDR recebida como Im_in) até 100 nits exatamente como seriam renderizadas se se estivesse renderizando a imagem de entrada em sua tela de referência correspondente, para a qual, e geralmente na qual a imagem foi classificada, isto é, uma tela de 5000 nits. Mas, em todas as luminâncias mais altas, foi feito simplesmente um corte para 100.

[0226] Se (teoricamente) fosse aplicada uma transformação de luminância para se obter uma reclassificação de 5000 nits, a partir exatamente da imagem de entrada, Im_in, já de 5000 nits que já recebidos do classificador de cor, então, certamente, seria aplicada, geralmente, a transformação de identidade 1701. Contudo, o que acontece caso se queira determinar uma reclassificação intermediária para, por exemplo, uma tela MDR de 500 nits?

[0227] Certamente, seriam cortadas todas as luminâncias acima de 500, mas essa provavelmente não seria a melhor reclassificação que poderia-se fazer para essa tela, mesmo se houvesse uma transformação de luminância de corte HDR para LDR ruim definida pelo criador de conteúdo. Têm-se as informações de todas as texturas dos objetos mais brilhantes na imagem de entrada HDR, Im_in, assim, para telas de PB_D mais alto, isto é, caso houvesse a oportunidade, seriam mostradas algumas dessas informações, seja em uma versão de qualidade reduzida em comparação com a renderização de 5000 (isto é, menos aumento de brilho, menos contrastes impressionantes, menos cintilação e brilho dependendo do que é a cena ou imagem HDR). Uma opção seria calcular a curva 1711, se considerarmos que todos os objetos até 100 nits foram renderizados perfeitamente (e que isso foi “acidentalmente” um interessante ponto de demarcação, abaixo do qual os objetos deveriam ser renderizados com a mesma luminância em todas as telas reais). Mas poderia-se também aplicar outra estratégia (que corresponde ao cálculo com outra métrica, e/ou direção de interpolação, e/ou função de ajuste fino para agressividade de reclassificação (gpm, gpr)), que desloca o ponto onde se para de fazer o mapeamento de luminância igual e se começa a comprimir os objetos HDR mais brilhantes no ponto L_kn. Isso resulta em uma curva de mapeamento de luminância MDR 1703 para gerar a classificação MDR para um PB_D = tela real de 500 nits.

[0228] O leitor entenderá que o cenário que se deseja criar, e quanto se deseja deslocar para L_kn acima de 100 nits, dependerá do que é a imagem (ou imagens). Se não houver muitas coisas de interesse no lado externo, como frequentemente acontece com difusões (broadcasts), para as quais o que se vê através da janela geralmente já está cortado ou severamente cortado (sorte suave), pode-se viver com uma quantidade menor de luminâncias renderizáveis para esses objetos para ambientes externos (faixa R_sm). Isso pode ser especialmente verdadeiro caso as luminâncias dos objetos do ambiente interno não terminarem exatamente em 100 nits (o que poderiam, certamente, dependendo da cuidadosa classificação que o classificador fez), mas, por exemplo, ele precisou cortar (neste caso, um exemplo extremo de corte abrupto) algumas partes mais brilhantes de, por exemplo, alguns objetos refletivos sobre a mesa. Como isso pode ser a parte principal da cena, para onde o observador está olhando com atenção, pode fazer sentido realmente também dar a esses objetos belas luminâncias e contrastes de textura, incluindo-os na parte de equiluminância (diagonal), até sua luminância máxima, ou ao menos mais próximos dela, em detrimento da qualidade das cores das casas iluminadas pelo sol vistas através da janela, conforme visto na Figura 14. Isso também pode ser especialmente verdadeiro, caso não se saiba nada sobre a imagem (obviamente, se o classificador especifica um COD_METR e COD_DIR para usar, isso já transmite em certa medida a situação que se tem, mas assuma que o classificador fez apenas uma TMF, e o aparelho de recepção precisa determinar por si só o restante, em uma estratégia de ajuste de tela mais simples, mas que ainda assim poderia fornecer uma qualidade visual das imagens MDR tão razoável quanto possível), uma vez que, então, pode-se presumir que provavelmente haverá algumas luminâncias interessantes acima do valor de 100 nits de baixa qualidade, dado que esta é uma cena HDR, e, portanto, seria possível também dividir os erros colocando o ponto L_kn um pouco mais alto que os aleatórios 100 nits (o classificador poderia ter tratado das luminâncias do ambiente interno já presentes em sua classificação HDR mestra, isto é, iluminando-as satisfatoriamente, e como não é tão fácil fazê-las ajustar exatamente na estrutura LDR/HDR, classificar o ambiente interno às luminâncias adequadas, mas não é sempre certo que ele terá colocado os objetos do ambiente interno exatamente na subfaixa LDR já existente na classificação HDR mestra).

[0229] Entretanto, em um cenário alternativo onde o classificador sabe que todas as regiões de pixels mais escuros ficam dentro da parte de 100 nits, e que existem texturas importantes em algum lugar na parte acima de 100 nits, que precisam de contraste máximo ou uma quantidade máxima de possíveis códigos de luma e luminâncias utilizáveis (para funções de mapeamento de luminância arbitrária), o classificador pode querer manter o ponto L_kn em 100 nits para todas as reclassificações MDR. Dessa forma, o leitor entende que o ajuste de tela (também chamado de tunabilidade) pode ser simplificado se assim for desejado, mas que se pode querer algum meio técnico adicional para contemplar a complexidade de cenas e imagens HDR também nos casos mais difíceis, ainda que de uma forma tão simples quanto possível para o classificador, que pode precisar determinar todos os fatores e parâmetros.

[0230] Agora, caso se queira ver o que acontece na estrutura de referência de uma tela específica, seja, por exemplo, um PB_D = tela de 500 nits, pode-se cortar do mapa na Figura 17 apenas a parte que se aproxima de Y_out = 500 nits. O máximo dessa representação é, então, o máximo que se pode renderizar em uma tela de 500 nits, isto é, aquela que se deveria fazer apresentando a ela o código de luma máximo v = 1,0. Portanto, ignorando-se as identificações de nits que foram colocadas no mapa para fins de clareza, pode- se ver a especificação de reclassificação da Figura 17 como uma especificação no espaço de código de luma (ainda que, embora, no eixo de entrada pode-se ler adequadamente os códigos de luma equidistantes, obviamente no eixo y nesta representação, o v=1,0 estará situado em alturas diferentes para diferentes telas com diferentes PB_D (o leitor deve considerar para melhor entendimento que essas telas diferentes são todas emuladas em uma tela de 5000 nits, a qual, portanto, deve parar de renderizar em um certo vx de luma dependendo da capacidade de PB_D da tela emulada).

[0231] A Figura 18 mostra as mesmas transformações exemplificadoras, mas agora em um sistema de eixos que serve de ponto de partida para derivar a função de transformação de luminância HDR para MDR necessária a partir da especificação de transformação de cor HDR para LDR recebida nos metadados associados ao sinal de vídeo S_im. O eixo horizontal é o mesmo, uma vez que essas são as possíveis luminâncias de pixel de nossa imagem de entrada Im_in de 5000 nits. O eixo vertical deve determinar a luminância relativa de uma cor de pixel MDR reclassificada, novamente em uma escala perceptualmente uniformizada com nossa P-OETF, isto é, entre zero e um valor L1 (ou, em outras palavras, seu código de luma correspondente). Para a classificação de 100 nits, esse valor L1, que corresponde ao código de luma máximo, por exemplo 1023 em 10 bits, ou 4095 em 12 bits, será de 100 nits. Nota-se novamente que, para luminâncias HDR de até 100 nits, de acordo com o classificador, elas devem ser renderizadas em telas LDR de 100 nits com exatamente a mesma luminância que a imagem de 5000 nits prescreve, e acima disso a classificação LDR corta tudo para PB_L = 100 nits.

[0232] Nota-se, também, por exemplo, que nessa representação, para obter as mesmas luminâncias renderizadas para os tons de cinza escuro na tela LDR que na tela HDR, é preciso aumentar os lumas da imagem LDR (que nesse gráfico também podem ser lidos, uniformemente entre L1 correspondendo a v=1,0 e 0), isto é, precisa-se aumentar o declive escuro ou ganho em um ângulo b, em comparação com os valores de HDR relativa (aqui, no eixo “errado” de 100 nits mostrado como a diagonal, porque eles precisariam de um eixo terminando em 5000 nits para saber o que corresponde ao luma máximo, ou da imagem de entrada, ou da imagem de saída calculada teoricamente por uma transformação de identidade). Entretanto, como se pode derivar a necessidade da curva de mapeamento MDR 1803 para o controle relativo entre mínimo e máximo (lumas mínimo e máximo agora correspondendo, respectivamente, a esse PB_D = tela de 500 nits, a 0 e 500 nits, mostrado como Y_out_MDR à direita no gráfico), isto é, esse Y-out_MDR para qualquer Y_in da Im_in? A linha ortogonal foi desenhada à diagonal (o mapeamento HDR5000 para HDR5000 1701), e nela foi inserida uma métrica (1850). Essa métrica terá valores entre nenhuma alteração de luminância, ou “0”, e alteração “total” (ou “1”), resultando na classificação LDR. Agora pode-se localizar a posição M_PB_D correspondente a qualquer PB_D nessa métrica (vide exemplos de cálculos abaixo). No caso de querermos que uma aparência pareça (para esta tela real com PB_D, mas uma cena de importância crítica específica, que precisa parecer “mais LDR” por mais tempo quando o PB_D é aumentado a partir de PB_L = 100 nits) mais similar a LDR, pode-se determinar um outro ponto M_PB_U, por exemplo com as modalidades descritas abaixo. Pode-se ver que o ponto “médio” corresponde a uma tela que está, no que diz respeito ao seu PB_D (não linearmente) a cerca de meio caminho entre uma exibição de referência de PB_H e PB_L, no que diz respeito à sua aparência, isto é, suas capacidades de HDR. Agora, supondo-se que neste exemplo o ponto de dobra PBE não seja realmente apenas o local onde o corte começa devido ao valor limitado do PB_L de 100 nits, mas um ponto crítico especial em uma classificação (que pode ter sido informada por ao menos um parâmetro (um parâmetro nos metadados que especifica a relação de transformação de cor da classificação original LDR e HDR fornecida pelo classificador), por exemplo, seu local relativo no eixo Y_in entre 0,0 e 1,0, e sua altura no eixo Y_out_LDR). Nota-se agora que, nesta versão de interpolação rotacionada, esse ponto semanticamente importante não precisa permanecer na mesma posição Y_in como ocorre nas modalidades de interpolação vertical, mas pode se deslocar ao longo de um deslocamento dp, que torna este modo específico de ajuste de tela elegante para alguns cenários (ele pode, por exemplo, ser útil também para funções HDR para LDR que cortam os tons pretos abaixo de uma luminância HDR L_Hb para 0 na classificação LDR).

[0233] A Figura 19 mostra como se pode derivar a função de transformação de luminância MDR total 1803 para obter a imagem MDR a partir da função que define a classificação LDR (1802) em uma estrutura rotacionada. Deve ficar evidente para o versado na técnica como a unidade de interpolação direcional (1312) pode calcular uma nova coordenada de extensão rc ao longo do eixo x correspondendo à coordenada Y-in, e como se pode rotacionar uma função. Essa função pode ser mantida, por exemplo, em uma memória temporária. Precisa-se, agora, determinar um valor de alteração de escala multiplicativa S, por exemplo 0,63 (vide definição abaixo), e que fornecerá os pontos necessários da curva MDR. Como exemplo, foi mostrado como o ponto de dobra se move para o novo local (M_PB_D se inserirmos uma métrica), mas todos os outros pontos, qualquer que seja o formato da função, serão alterados pelo mesmo princípio multiplicativo. Assim, tomando-se uma coordenada de extensão rc, e a correspondente função de mapeamento de luminância LDR for FR_L(rc), então o valor necessário para a função de transformação de cor HDR para MDR será determinada como FR_M(rc)=S*FR_L(rc). Depois disso, a curva pode ser rotacionada novamente para obtermos os valores na estrutura da Figura 18, e esses valores podem ser novamente armazenados em uma memória. O que será realmente necessário para o processamento por pixel são valores de ganho, e, portanto, as modalidades da unidade de determinação do fator de alteração de escala (200) irão, geralmente, armazenar uma LUT de valores gt para todos os possíveis valores de Y_in (na verdade, em nossas modalidades preferenciais usamos valores RGBmax, mas eles variam de modo similar entre 0,0 e 1,0).

[0234] O cálculo desses valores gt pode ser feito comparando-se a altura da função de transformação de luminância MDR calculada para a tela de PB_D a ser servida com a altura da diagonal para todos os valores de entrada, e então obter o valor de multiplicação pela divisão das duas, conforme mostrado na Figura 16.

[0235] A Figura 20 mostra como definir uma métrica de bom desempenho para se obter o fator de alteração de escala S.

[0236] Supondo-se que se queira derivar uma imagem MDR (e a função que determina os valores de luma necessários quando se tem um valor de luminância ou luma de uma imagem de entrada) para uma tela de, por exemplo, PB_D = 500 nits. É preciso alterar a escala dos valores de controle para obter todas as luminâncias de objeto corretas em relação à curva de controle para a faixa LDR. Assim, foi feita referência na estrutura, geralmente, como 100 nits, dessa função de mapeamento de luminância SDR 2002 (porque este é um valor padronizado já existente, mas as coisas poderiam mudar no futuro e nossos princípios técnicos permaneceriam os mesmos). Supondo-se agora que se queira, por exemplo, manter os brilhos mais escuros com a mesma aparência para as três telas (HDR, LDR e MDR): quanto é preciso mudar um ponto P1 ou P2 para baixo e, em seguida, em direção à diagonal correspondendo à classificação HDR, ou em direção ao eixo de entrada horizontal, para obter o ponto P3 correto na curva MDR?

[0237] Como é preciso ler essa curva MDR no eixo 500 à direita, incluiu-se as seguintes equações matemáticas: A = P_OETF(Lm/PB_L, PB_L) B = P_OETF(Lm/PB_D, PB_D) [Eqs. 9]

[0238] Essas são as funções log-gama OETF HDR da Requerente, definidas anteriormente, mas agora não terminando em 5000 nits, mas no segundo valor após a vírgula, por exemplo, PB_L = 100 nits (geralmente). Ou seja, isso gera um eixo perceptual com uma coordenada de extensão que termina em 1,0 para, por exemplo, 100 nits, que é o eixo y desse mapa. Neste cenário, Lm é um valor de 5000 nits da Im_in, mas poderia ser diferente para outras codificações HDR mestras.

[0239] A Figura 23 mostra de outra maneira o significado físico dos fatores de escala de conversão elementar (A,B). Pode-se ver também P_OETF como uma função renormalizada que não termina em 1, mas segue, por exemplo, até 5,0 (e, então, posteriormente, como esta é apenas uma multiplicação do máximo, caso seja necessário razões, poderão ser obtidas em uma versão normalizada para 1). Assim, foi preciso transformar a curva de mapeamento de luminância de classificação HDR para LDR 2303, para obter a curva MDR adequada. Essa não deve ser a curva 2304, porque esta é meramente a aplicação da classificação LDR a uma tela de PB_D mais brilhante, que fornecerá uma aparência brilhante demais. Escalar as luminâncias mais escuras em uma imagem para uma equiaparência (isto é, tendo as mesmas luminâncias renderizadas para, por exemplo, as cores 10% mais escuras em qualquer tela MDR e telas de referência HDR e LDR), fornecerá o mesmo fator de expansão para o eixo perceptual em uma nova versão normalizada (isto é, 1,0 correspondendo, por exemplo, a 500 nits) que determinar esse valor a partir do branco (1,0). Aqui, é mostrado, agora, o comportamento de nossa transformação de cor não em um sistema de eixos relativos normalizado para 1,0, mas em um sistema absoluto em um eixo de luminância de referência de 5000 nits. Para transformar nativamente (apenas aplicar a curva LDR sem levar em conta o PB_D mais alto) uma luminância de 100 nits (por exemplo, branco) - puramente no que diz respeito à normalização de eixo, portanto, sem levar em conta nenhum detalhe da curva de transformação de luminância especificada pelo classificador, ou quaisquer parâmetros de controle referentes à interpolação de luminâncias como gpr - é preciso intensificar uma cor 2301 para seu equivalente de 5000 nits (isto é, sem levar em conta a resposta adequada da reclassificação inteligente).

[0240] Em outras palavras, é preciso determinar no eixo y perceptualizado pela P-OETF a quantidade com a qual expandir o vetor. Se 100 nits correspondem a 1,0, então encontra-se o valor 2302 mediante a multiplicação, por exemplo, por 1,7. Pode-se fazer o mesmo caso se esteja lendo pontos em uma representação referida de 500 nits das curvas, isto é, uma na qual 500 nits correspondem ao luma máximo possível (1,0). Caso essa luminância seja transformada em uma versão representada de 5000 nits, então será obtido o fator B de, por exemplo, 1,3. Mas, na verdade, o que interessa é como transformar uma cor 2305 que foi determinada para a classificação LDR, isto é, no sistema de 100 nits (por exemplo, uma luminância HDR de entrada de 500 nits deve ser renderizada para LDR como 30 nits) no sistema de referência de uma tela de 500 nits. Por exemplo, se não fosse preciso alterar os valores resultantes da transformação, o que eles significariam então na nova referência para 500 nits (que é o eixo no lado direito da Figura 18, Y_out_MDR)?

[0241] Pode-se notar que multiplicar o valor y 2305 por SA-1 para obter o valor 2306 corresponde a multiplicá-lo por A/B. Mas isso não forneceria uma equiaparência, porque, então, tudo simplesmente se tornaria 5x mais brilhante em uma escala linear, e X vezes em uma escala perceptualizada. Então, para manter a restrição de equiaparência, deve-se multiplicar o valor 2305 por S=B/A (para ter a curva MDR de controle corretamente escalada, quando a partir da curva LDR, mas agora referenciada no sistema de eixos onde 500 nits é o luma ou luminância relativa máxima, 1,0, que não fornece a curva pontilhada 2304, mas a curva 2303 que será a curva de classificação MDR desejada, agora interpretada no eixo 500, em vez de em seu eixo original y de 100 nits). Como todas são operações multiplicativas relativas, pode-se executá-las considerando que tudo acontece em um sistema de eixos onde 1,0 corresponde a 100 nits, mas se precisarmos de uma luminância renderizada real, a leitura será feita no eixo Y_out_MDR.

[0242] Assim, quando a alteração de escala é feita verticalmente em direção ao eixo x, obtém-se um fator de escala S=B/A.

[0243] O importante é que, qualquer que seja o valor de PB_D, pode-se definir o fator de escala (podendo até ser extrapolado, se desejado), e, portanto, pode-se fazer uma métrica.

[0244] Se a exibição alvo fosse PB_D= PB_H = 5000 (=Lm), seria preciso chegar ao ponto P4 da classificação HDR (transformação de identidade), isto é, quando visualizada de um ponto de vista multiplicativo, seria preciso alterar a escala do valor LDR para essa entrada (luminância da Im_in HDR 50 no eixo x), também para essa classificação A=50 nits no eixo y na LDR esquerda, em uma escala S=C/A, na qual C=P_OETF(Lm/PB_H, 5000). Pode-se notar que, como isso forneceria o valor v para uma entrada de luminância óptica (normalizada) de 1,0, e presumindo que essa classificação HDR diagonal faz todas as luminâncias fornecerem luminâncias iguais de saída (isto é, para luma 1,0 ao obter 5000 nits de entrada e de saída para a classificação HDR, obter-se-ia, de modo correspondente, o valor correto para todos os outros pontos na linha, isto é, também para esses, por exemplo 50 nits, que, por acaso, é o tamanho de vetor da escala HDR_5000 nits [não mostrado] no ponto de entrada cuja cor será transformada).

[0245] Agora, pode-se provar matematicamente que caso se deseje interpolar diagonalmente, mais especificamente em 135 graus, a função de alteração de escala torna-se SS= [(B-1)/(B+1) / (A-1)/(A+1)].

[0246] Pode-se também associar isso a uma posição de métrica em uma linha entre o ponto P4 da luminância HDR e o ponto P1 da luminância LDR, conforme representado na Figura 18. Isso corresponderia a um deslocamento da métrica, ou em geral, da coordenada de extensão MS, que, na modalidade vertical, pode escrita como Y_MDR= Y_HDR+MS*(Y_LDR-Y_HDR). Além disso, em uma situação genérica, tal coordenada MS se ficaria entre MS=0 para PB_D = PB_H, isto é, quando é necessária uma classificação MDR idêntica à classificação HDR, e 1,0 quando a classificação LDR é necessária.

[0247] Apenas com esta descrição simples o leitor pode entender que o mesmo esquema de transformação seria aplicado caso houvesse uma função TMF geral 2001 definindo a classificação LDR a partir da classificação HDR como entrada.

[0248] Portanto, no esquema de construção apresentado na Figura 13, a unidade de interpolação direcional (1312) irá rotacionar (executando a matemática correspondente, por exemplo, obtendo uma LUT de valores rotacionados para o eixo de entrada da Figura 19) a função recebida, determinar os fatores de alteração de escala SS adequados, calcular a função correspondente à reclassificação MDR na estrutura rotacionada conforme explicado acima, e rotacionar novamente para a estrutura na qual o eixo Y_in é horizontal. Tem-se, então, por exemplo em uma LUT, os valores de função Y_out_MDR para os valores de entrada Y_in. A unidade de determinação do multiplicador comum (1311) converterá essa função em um conjunto correspondente de multiplicadores (LUT de) gt, uma vez que a típica estrutura de transformação de cor apresentada trabalhará com os mesmos, conforme explicado.

[0249] Até agora foram descritas modalidades que independem da maneira como as funções de transformação de cor foram definidas, e, em particular, foram parametrizadas. O processamento acima pode operar em quaisquer valores de função, e os mesmos foram explicados como se fossem uma LUT pura.

[0250] Entretanto, pode haver informações semânticas interessantes na forma como o classificador define as funções. Por exemplo, ele pode definir uma função de processamento de luminância multissegmento com um segmento inferior para processar as cores mais escuras, por exemplo, cores em ambientes internos, e um segundo segmento, superior, especificando o que deve ser feito com um segmento mais brilhante, por exemplo, cores em ambientes externos. Esse comportamento de transformação de luminância pode ser informado ao receptor por meio, por exemplo, de um parâmetro Lt, que é também um demarcador entre as luminâncias externas e internas. Muitas filosofias de parametrização alternativas são possíveis. Pode ser necessário deslocar a posição de luminância desse limiar, ao menos em algumas classificações MDR, ao menos para alguns tipos de imagem HDR (por exemplo, em vez de desejar manter as cores em ambientes internos com a mesma aparência em todas as telas, o classificador pode decidir usar parte das capacidades mais altas de telas HDR, por exemplo, acima de 1500 nits, para clarear também essas cores em ambientes internos até certa medida). Os deslocamentos ao longo do eixo x e ao longo do eixo y podem ser vantajosos. Tudo depende de quais cores estão presentes na imagem, e quais contrastes de aparência o classificador deseja etc.

[0251] Segue abaixo um exemplo interessante para explicar uma possível modalidade paramétrica.

[0252] A Figura 21 mostra um exemplo de uma interessante estratégia de transformação de luminância HDR para LDR, a qual foi inserida no kit de ferramentas básicas da Requerente, que define sua tecnologia de codificação de conjunto de aparências HDR (que corresponderia a uma modalidade específica da curva padronizada da unidade 111, mas em vez de ser transmitida como uma LUT, essa função seria comunicada como 5 parâmetros; cuja curva de mapeamento da Figura 21 pode ser descrita com 3: um declive de velocidade de subida para as cores de imagens mais escuras a partir de 0,0 [controle de ganho de sombra]; um declive de descida dos realces isto é, o ângulo com o qual a parte linear superior vira para baixo, e uma largura, ou meia largura de uma seção parabólica entre: um ponto médio midx pode ser determinado de modo inequívoco onde as partes lineares se cruzam, e então a seção parabólica pode se estender de midx-largura/2 até midx+largura/2). Esse gráfico mostra os lumas normalizados (por exemplo, 10 bits), e em oposição as luminâncias correspondentes, na parte superior a imagem de entrada HDR de 5000 nits, e à direita as luminâncias da imagem de saída MDR de 500 nits que pode ser calculada a partir da imagem de entrada HDR, removendo-se agora os detalhes de 100 nits (que foram usados acima para explicar facilmente os conceitos da Requerente).

[0253] O classificador especifica novamente uma curva HDR para LDR 2100 (isto é, 100 nits), mas agora com essa formulação de função específica. Ela contém um ganho escuro (declive dg) que determina quão brilhante as cores mais escuras apareceriam na imagem LDR classificada. Isto é importante, porque se na cena HDR houver objetos muito brilhantes como lâmpadas que ainda são capturadas fielmente nos lumas HDR, as regiões sombrias da mesma cena podem cair muito profundamente no eixo normalizado, e, portanto, pode ser necessário intensificá-las consideravelmente na classificação LDR para que ainda se possa ver o que acontece lá. O regime escuro termina no ponto 2101. Para as cores mais brilhantes, há um segmento linear similar com ganho de realce hg. No intervalo existe um segmento parabólico de largura que corresponde aos pontos finais das partes lineares. Isso pode controlar o contraste de objetos de tons de cinza intermediários.

[0254] Observa-se agora que os pontos especiais comunicados parametricamente têm um local alterado na curva de transformação de luminância MDR 2103. Pode-se calcular locais modificados com o uso da direção DIR e, em particular, da métrica. midx=(1-hg)/(dg-hg)

[0255] pode-se, então, calcular um novo ponto médio Pm2 com coordenadas newMidx e newMidY: x0=midx; x1= dg*midx; y0=dg*midx; y1=midx m=(y1-y0)/(x1-x0) b=(x1*y0-x0*y1)/(x1-x0) newMidx= ((x1-x0)/2)*(1-SS) + x0 newMidy=m*newMidx+b

[0256] A partir disso, pode-se calcular a nova largura da região parabólica, e, portanto, os dois pontos de terminação dos segmentos lineares: newWidth=(1-P_OETF(SS, PB_H))*old_width

[0257] em que old_width (largura antiga) é um parâmetro dessa curva conforme determinado pelo classificador, isto é, a largura do segmento parabólico, ou seja, uma largura projetada simétrica ou assimetricamente para ambos os lados a partir de onde as continuações dos segmentos lineares encontram o assim chamado ponto médio. E, então, certamente, o novo ganho escuro e o ganho de realce podem ser recalculados: newGg= newMidy/newMidx nwHg= max((newMidy-1)/(newMidx-1),0)

[0258] O leitor pode entender que é possível elaborar estratégias de recálculo para pontos interessantes, ou outros parâmetros de funções de transformação de luminância para outros cenários. O fato interessante derivado desse exemplo reside em que o aparelho no lado de recepção pode calcular novos parâmetros para a curva final a serem aplicados para se obter a MDR a partir da HDR reconstruída (ou mesmo diretamente da SDR), e que isso depende do fator de escala SS estabelecido, o qual, por sua vez, depende não só do valor de PB_D que se tem no lado de recepção, portanto, quanto a imagem de aparência ideal corresponderia à aparência HDR ou SDR, mas também o ângulo selecionado para a determinação da curva (por exemplo, 45 graus virando à esquerda a partir da vertical). Assim, algumas das modalidades da presente invenção operam recalculando os parâmetros que definem a função de mapeamento de luminância, e de acordo com os princípios de métrica orientados.

[0259] Sabendo como realizar os cálculos básicos (que modalidades simples podem aplicar e que em grande parte desconhecem os detalhes da imagem e das preferências do classificador, mas que ainda precisam produzir imagens reclassificadas MDR razoáveis para a tela (ou telas) disponível), descreveremos agora algumas modalidades mais esclarecedoras sobre como o classificador pode aplicar variações, incorporando alguns parâmetros de controle técnico adaptados às particularidades da cena HDR atual.

[0260] A Figura 22 mostra como se pode, para uma cena HDR ou tomada de imagens específica, codificar imediatamente cujo valor de MS corresponderia ao PB_D disponível. Conforme deve-se compreender, a partir do exposto acima, para a derivação do mapeamento de luminância MDR (ou, de modo geral, das transformações de cor), precisa-se, primeiro, de um meio para posicionar na métrica (isto é, entre 0,0 e 1,0, ou mesmo fora dessa faixa de extrapolação) o ponto M_PB_U, o que pode ser feito com a coordenada MS normalizada. E, então, a partir desse valor, pode-se converter essa função de mapeamento de luminância formatada para executar a transformação de cor HDR para LDR (ou LDR para HDR em outros cenários como o modo 2) para a função necessária para calcular a imagem MDR. Mas se houver uma posição de métrica explícita determinando a função (2201), por exemplo, comunicada como uma LUT, ou uma equação simples, pode ser, em princípio, que nem mesmo se precise da definição de métrica básica. Pode ser vantajoso se o classificador puder determinar tal função de uma forma fácil, por exemplo, pode ser usada uma lei de potência para a qual o classificador pode alterar a potência, por exemplo, girando um botão. Ele verá imediatamente em sua tela MDR como a aparência total da imagem muda, ou, se concentrar em uma área crítica, como, por exemplo, um monstro no escuro que ele prefere que seja visível a um grau razoável, para assegurar que o mostro será, e modo similar, razoavelmente visível em todas as outras telas reais nas instalações do observador.

[0261] Porém, quando se tem uma boa métrica, pode-se também criar variações de ajuste fino, conforme mostrado com referência à Figura 15. Aqui, m_MT_norm_in é o valor de MS para a métrica específica escolhida, isto é, novamente ela se estenderá entre 0,0 e 1,0. Assim, pode-se calcular um valor para uma tela específica com brilho de pico PB_D. Se o classificador não especificar nada, um valor de m_MT_norm resultante como saída seria o mesmo, e o ajuste de tela automático padrão, como em qualquer uma das modalidades explicadas acima, seria aplicado. Entretanto, o classificador pode especificar funções que se desviam desse formato, de preferência suavemente, e terminar nas coordenadas 0,0 e 1,0. Por exemplo, ele pode projetar uma função de potência, cujo parâmetro de potência gpr determina quão fortemente uma reclassificação MDR deve parecer, por exemplo, como uma classificação LDR conforme mostrada, mesmo para telas com PB_D muito alto (isto é, m_MT_norm_in se aproximando de 0), ou de outro modo (conforme visto em uma posição do ponto M_PB_U resultante deslocado na quantidade do valor de dgr). Ele pode até mesmo fazer uma formulação para funções complexas, que têm, por exemplo, um comportamento diferente para telas com brilho acima de um pico específico, sendo que o comportamento pode ser codificado por um segundo parâmetro gptt, ou mesmo mais parâmetros, por exemplo, definindo uma parte inferior linear da curva, etc.

[0262] Dessa forma, o leitor compreenderá que a tecnologia da presente invenção pode empregar várias métricas (por exemplo, várias definições de OETF relativamente similares, que correspondem aproximadamente a etapas de luminosidade igual, ou outras funções que modelam tal comportamento de luminosidade das classificações), e também várias direções de interpolação e várias maneiras de determiná-las. Por exemplo, em um aparelho simples, a métrica pode ser fixada no hardware, e determinada como tal executando-se os cálculos, por exemplo, em um processador, e modalidades mais complexas podem, por exemplo, alternar entre a estratégia de cálculo MDR, por exemplo por tomada de imagens no filme (ou mesmo para partes de uma imagem, por exemplo os brilhos mais baixos podem ser interpolados com uma métrica, ou mesmo uma direção, e os brilhos mais altos com outra métrica, e, dependendo da cena, a métrica pode não ser tão crítica onde todas as cores interpoladas se projetam), por exemplo sob os princípios de controle comunicados pelo classificador humano e recebidos do lado de criação de conteúdo, geralmente como um ou dois parâmetros fáceis, mas que têm um grande primeiro impacto sobre a aparência das imagens MDR.

[0263] A Figura 24 mostra como se pode representar colorimetricamente qualquer mapeamento (dentro da mesma paleta, por exemplo normalizada para 1,0) a partir de uma primeira luminância de pixel ou, neste exemplo, luma (definida por meio de uma equação linear a partir da luminância linear, respectivamente a partir de componentes de cor R’G’B’ não lineares que estão relacionados aos componentes de cor aditivos lineares vermelho, verde e azul por meio de uma função de transferência optoelétrica não linear, OETF, isto é, R’=OETF(R), G’=OETF(G), B=OETF(B), com OETF, por exemplo a SDR, definida na Recomendação Rec. 709), por exemplo o luma Y’i HDR para um segundo luma, por exemplo o luma Y’da imagem LDR classificada correspondente, de duas maneiras. Primeiramente, conforme exemplificado acima, pode-se aplicar uma função multiplicativa com um valor multiplicador escalar g, dependente de cor (ou, no caso de um processamento local, talvez até dependente de pixel). Isso pode ser feito ao se multiplicar, de modo equivalente, os componentes de cor não lineares vermelho, verde e azul da cor HDR para obter a cor LDR (ou vice-versa, uma vez que nossos métodos podem operar na outra direção, por exemplo, derivar uma classificação HDR a partir de uma classificação LDR, o que é típico para sistemas de codificação HDR do modo 2 que codificam aparências HDR de uma cena mediante a transmissão de um conjunto de imagens SDR já existentes de 100 nits). Contudo, pode-se começar também a partir de qualquer luma (ou luminância) de referência Y’n de valor escalado, referido até certo nível, e alterar a escala desse valor (ou de modo equivalente seus componentes de cor R’G’B’ou RGB) por algum valor de alteração de escala de luminância Ls. No caso de Y’n ser o próprio luma Y’i LDR, tem- se novamente a etapa multiplicativa acima, conforme exemplificado, por exemplo, na Figura 1 (e não importa, em princípio, como o fator g foi calculado, isto é, qual cadeia de cálculos serviu de base para se obter, por exemplo, um valor f(Max)/Max, ou um valor F(Y’)/Y’, etc.).

[0264] Como dito, os princípios de ajuste de tela da Requerente são amplamente aplicáveis e podem ser incorporados em várias formas de circuitos para aparelhos, em particular, em vários espaços de cor. A seguir, são descritas algumas modalidades com base em um luma não linear de uma imagem de entrada SDR (isto é, brilho PB LDR de 100 nits) recebida por um decodificador HDR.

[0265] Na Figura 25, um divisor separa o componente luma da cor de pixel (Y’UV, que é geralmente uma representação YCbCr utilizada em codecs tipo MPEG como, por exemplo, HEVC). Uma trilha de processamento superior pode executar qualquer tipo de processamento de cores na cor de entrada pelo processador de cores opcional 2503, mas ela contém um conversor de cor 2504 para converter a cor em R’G’B’ não linear (isto é, um trio de componentes de cor definidos por OETF com uso da Rec. 709, ou um trio de componentes de cor não lineares definidos por raiz quadrada). Presume-se, para a descrição desta invenção, que o processador de cores realiza uma modificação de saturação das cores de pixel em execução a serem processadas com base na luminância dessas cores de pixel, conforme apresentado na Figura 15A do documento WO2014/128586. Pode haver uma unidade de determinação de função 2526 que usa um algoritmo para determinar uma função de saturação s(Y’), em que s é um multiplicador dependente de luma a ser multiplicado pelos componentes de croma Cb=B’-Y’e Cr=R’-Y’ (ou, com o uso, de modo similar, uma definição alternativa de processamento de saturação) de modo que o corte de cor não seja feito em muitas cores na faixa MDR, mas para esta aplicação presumiu- se apenas que exista tal função s(Y’), que será, então, usada pelo processador de cores 2503 para saturar ou “dessaturar” as várias cores na imagem inicial (isto é, nesta modalidade exemplificadora, a imagem SDR está sendo usada como imagem inicial, mas, mudando o que deve ser mudado, uma modalidade alternativa poderia derivar uma imagem MDR a partir de uma imagem HDR, por exemplo, Im_RHDR). Então, no conversor de luma 2501 é aplicada uma função definida pelos metadados de definição de função recebidos, isto é, esta parte é similar às modalidades descritas acima, por exemplo na Figura 1, a trajetória de processamento entre a entrada (R,G,B) proveniente da unidade de SAT opcional 106, e a saída do fator g para o multiplicador. Multiplica-se, novamente, pelo valor adequado de g para esta cor de entrada (ou, nas várias modalidades chamado de, por exemplo, gt), mas g é chamado Ls aqui. Os componentes R’s, G’s, B’s escalados podem ser apenas os componentes de cor não lineares da imagem LDR (isto é, a imagem da aparência LDR classificada do par HDR/LDR, que é, nesta modalidade, o que é recebido) (por exemplo, R’s = sqrt(R_linear_LDR), em que R_linear_LDR é o componentes de cor vermelha linear para a mistura para produzir a imagem corretamente renderizada em uma tela com PB de 100 nits). Os componentes R’s, etc., podem, geralmente, ser componentes sqrt(R)/Sqrt(Y), sendo Y alguma luminância característica, ou fator entre um valor de luminância ou luma HDR e LDR. Os componentes de cor não lineares de saída R’o, G’o, B’o são aqueles que definem a imagem de aparência HDR, por exemplo, geralmente como nesta modalidade também definidos com um padrão BT1886 inverso da Recomendação Rec. 709, ou definição de raiz quadrada da não-linearidade usada para a definição desse componente de cor. Isso significa que Ls pode, então, ser geralmente também visto (isto é, é definido) em uma forma não linear de raiz quadrada em comparação com a luminância (que é definida universalmente e em espaço linear de contagem de fótons). Pode haver uma transformação de formatação de cor adicional aplicada pelo formatador de cor 2506, produzindo uma representação de cor Rd,Gd,Bd adequada para transmissão à tela (por exemplo, através de uma conexão HDMI). Por exemplo, algumas telas podem ter um modo que aceita RGB linear e, neste caso, o formatador de cor 2506 aplicará uma operação de potência quadrada sobre os três componentes R’o, G’o, B’o. Mas outras telas podem ter outros formatos de comunicação de imagem HDR, por exemplo para comprimir as informações nos limites permitidos pelo conector, e então essa codificação final é aplicada pelo formatador 2506. No interior da tela conectada 2510, pode ser aplicada uma otimização de cor adicional pelo otimizador de cor 2511. Como resultado, as modalidades de ajuste de tela apresentadas pela Requerente no pré-condicionamento de imagens (ou especificamente de nossa unidade for uma parte direta de um decodificador de imagem HDR, imediatamente decodificando para algum formato de faixa dinâmica média intermediária adequado, isto é, para um brilho de pico de tela que não é igual ao PB da imagem HDR do par codificado em conjunto, nem ao PB da imagem LDR) irão aplicar apenas o ajuste de tela com base nas características do brilho de pico da tela de renderização, e/ou aplicar apenas o ajuste de tela para as luminâncias mais brilhantes, por exemplo 95% das luminâncias, ou, por exemplo, 80% dos lumas, e deixar a otimização medida e caracterizada do ambiente de renderização das cores mais escuras para os algoritmos dedicados do fabricante de TV. O aparelho de TV pode compreender, por exemplo, uma câmera que olha para a vizinhança do observador, aplicando detecção de rosto, e então caracteriza qual quantidade de luz brilha diretamente sobre ele (e potencialmente também sob qual ângulo, por exemplo alguns locais acima do sofá), e qual é a iluminação circundante genérica, isto é, a iluminação direta + indireta das paredes, estabelecendo um nível de escuridão geral para a sala de visualização etc. Esses parâmetros podem, então, onde não precisam ser necessariamente inseridos nos algoritmos de ajuste de tela de pré-condicionamento da Requerente (embora essas informações poderiam ser usadas para decidir o ajuste adequado das cores mais escuras), ser usados dentro do aparelho de TV para otimizar as cores mais escuras, por exemplo, torná-las um pouco brilhante pelo otimizador de cor 2511. Opcionalmente, algumas modalidades podem ter um pré-adicionador condicional (2555), que possibilita um ajuste mais versátil para processamento de cores multiplicativo, especialmente quando a otimização é feita para ambientes de visualização com iluminação muito brilhante, para os quais são necessárias versões clareadas das cores mais escuras da imagem. Por exemplo, esse pré- adicionador usa um valor de limiar YT fixo ou pré-calculado, e adiciona um valor k fixo ou pré-calculado, e modalidades similares podem fazê-lo nos três componentes RGB.

[0266] Várias modalidades podem ser feitas de acordo com esse princípio.

[0267] Por exemplo, pode ser útil fazer um cálculo da aparência dependente de tela otimizada, e dos correspondentes valores de gt ou Ls em um domínio de cores linearizado. Por exemplo, na modalidade da Figura 26, as funções de mapeamento de luminância (por exemplo, definidas pelo classificador de cor) que aumentam a classificação de LDR para HDR (ou de LDR para MDR) foram definidas em uma representação perceptualmente uniforme dos brilhos (o que possibilita ao classificador um controle mais rápido e mais relevante da aparência e dos brilhos de todos os objetos da imagem). Portanto, o bloco 2501 da Figura 25 compreende, nesta modalidade, em ordem sucessiva: uma unidade de potência quadrada 2601, ou, como alternativa, a aplicação de uma função EOTF de tela padrão BT1886, e então uma função que converte os valores de “brilho” Li (que então serão luminâncias, ao menos em uma aproximação muito boa) resultante da aplicação da transformação a valores de brilho P perceptualmente mais uniformes, conforme executado pela unidade de uniformização 2602 (que pode aplicar, por exemplo, uma OETF definida pela Philips: Eq. 8). A unidade de mapeamento de luminância 2801 aplica qualquer mapeamento desejado pelo criador de conteúdo, e que pode ser reconstruído a partir de sua codificação recebida em metadados. Por exemplo, ela pode criar essa aparência HDR exemplificadora a partir da aparência LDR intensificando as luminâncias em uma região intermediária, e nivelando algumas das luminâncias mais brilhantes. Ela cria uma luminância de aparência HDR (ou MDR) Pho, ainda no domínio perceptualizado, que pode ser convertida pelo linearizador 2604 em um valor de luminância de luz HDR linear do pixel correntemente processado, LL. Na representação desta modalidade, o conversor 2605 faz a conversão aplicando uma raiz quadrada, produzindo: Ls=sqrt(LL). A unidade de mapeamento de luminância 2801 pode ser das várias formas descritas acima, ou outras formas, isto é, ela pode assumir um valor de MS (seja determinado, por exemplo, pelas condições estabelecidas baseadas em STB no momento da renderização, ou especificado pelo criador de conteúdo, ou qualquer combinação dessas opções, isto é, MS=FUNCT(MS_1, MS_2) onde MS_1 e MS_2 são, respectivamente, um valor especificado pelo criador e um valor especificado pelo receptor [ou qualquer outra variante equivalente, por exemplo MS=MS_1+Delta_MS, etc.]), e determinar alguma nova função de mapeamento de luminância adequada para mapear LDR para MDR com o brilho de pico de tela em vez de para, por exemplo, a HDR de 5000 nits (conforme mostrado em tracejado pela curva sólida dentro de 2603).

[0268] A Figura 27 descreve outra modalidade na qual a maioria dos blocos é conforme descrito na Figura 26, mas agora é calculada uma divisão explícita da luminância HDR de luz linear e do luma de entrada SDR Y’I, e para essa modalidade particular essa divisão é elevada à potência MS, onde 0<=MS<=1, e MS novamente sendo especificado de acordo com qualquer método automático, semiautomático definido por um profissional humano.

[0269] A Figura 28 é uma modalidade útil para outras modalidades complexas de ajuste de tela. Aqui, a unidade de transformação de luminância incorporada como conversor de luma 2501 está usando primeiro uma unidade de mapeamento de luminância 2801 para converter as luminâncias de imagens LDR para as luminâncias de imagens HDR LLH (no domínio perceptual, mas o mesmo poderia ser feito em um domínio linear, ou de raiz quadrada, sqrt), e então um mapeamento de luminância de ajuste de tela (por exemplo, reduzindo a classificação de PB_HDR=5000 nits para PB_D= 2800 nits) é aplicado pelo remapeador de luminância de tela 2802, que fornece as luminâncias ajustadas por tela LLDA corretas. Tal modalidade possibilita, por exemplo, que a tela conectada carregue uma função de mapeamento de luminância F(LLH) que ela determinou em 2802 através da entrada 2888 (esteja essa unidade 2802 em uma STB separada, ou formando parte de um decodificador HDR em um aparelho de TV), em vez de apenas inserir um valor de MS e deixar que o remapeador de luminância de tela 2802 calcule uma função de mapeamento de luminância correspondente. Pode-se, então, usar também funções de mapeamento que não estão muito estreitamente relacionadas ao formato da(s) função(ões) de reclassificação, fazendo a conversão entre a(s) imagem(s) LDR recebida(s) e a(s) imagem(ns) HDR mestra(s) etc.

[0270] A Figura 30 mostra que nossa otimização de tela pela criação de imagens MDR ideais pode ser executada de várias maneiras. Por exemplo, na Figura 30A mostramos a possibilidade de usá-la como um processamento de imagens posterior, após a decodificação das imagens recebidas (presumindo que as imagens recebidas são imagens SDR) para uma versão HDR, Im_HDR (presumindo, para fins de simplicidade de entendimento, uma reconstrução da imagem HDR mestra, por exemplo com PB_C=5000 nits). A partir daí, o ajuste de tela reduz a classificação para a Im_MDR necessária, por exemplo, para a tela com PB_D de 700 nits ou de 1500 nits. Nessa topologia, o decodificador 3001 e o ajustador de cores 3002 das duas unidades podem, na verdade, ser incluídos em aparelhos diferentes, por exemplo, o decodificador pode ser incluído em um STB ou computador, e o ajustador de cores pode residir no aparelho de TV (caso em que, embora, receba as imagens HDR reconstruídas, ele ainda receberá as funções F_ct), ou eles pode estar no mesmo aparelho, ou mesmo uma ou mais unidades podem residir, por exemplo, em um computador em rede, que, por exemplo, fornece ao usuário conteúdo previamente otimizado.

[0271] Entretanto, uma outra topologia (mostra na Figura 30B) é o local onde o mapeamento para MDR é imediatamente levado em conta, isto é, quando a Im_SDR é inserida, não há necessidade para derivação imediata de uma imagem HDR, mas, por exemplo, a imagem de 700 nits pode ser derivada imediatamente a partir da imagem SDR. O mapeamento é aquele da combinação de todos os mapeamentos primeiro para, por exemplo 5000 nits, e então para 700 nits, e pode ser pré-calculado por uma unidade de otimização de software 3012. Especificamente, se todos os mapeamentos tiverem apenas sua alteração de escala multiplicativa, a combinação de todos esses multiplicadores para se chegar ao multiplicador final a ser usado para cada luminância de pixel é feita de maneira relativamente direta. A transformação necessária pode ser pré-calculada depois de recebidas as funções F_ct, e comunicada e carregada no decodificador 3010 como uma LUT (Y’_out=LUT(Y’_in)), para ser usada nas poucas próximas imagens de uma tomada, ou, em outras palavras, até o momento que novas funções recebidas são válidas para as poucas próximas imagens (algumas modalidades podem transmitir um conjunto de funções apenas para N imagens em uma cena, mas outras modalidades podem receber novas funções para cada imagem sucessiva do vídeo). Pode haver um atraso 3011 de 1 ou 2 imagens, no caso de a unidade de otimização de software 3012 precisar fazer um processamento mais complicado (por exemplo, compreendendo análise de conteúdo de imagem), porque, em geral, uma LUT de cores (CLUT) também pode ser comunicada para o processamento pelo processador de cores 2503, mas outras modalidades podem não ter esse atraso. A vantagem dessa topologia é que apenas 1 conjunto de hardware é necessário, e o ajuste de tela ideal é feito imediatamente na etapa de decodificação (agora alterável em vez de fixa, conforme estabelecido pelo paradigma normal de decodificação). A seguir, será explicado um pouco mais, considerando-se o uso dessa topologia útil (o versado na técnica entende como os vários componentes se aplicam a todas as variantes).

[0272] A Figura 31 mostra uma forma pragmaticamente muito útil de fazer o ajuste para obter a imagem MDR e suas luminâncias Y-MDRL (ou lumas equivalentes e modalidades similares).

[0273] As luminâncias SDR Y_SDRin são mapeadas pelo perceptualizador 3101 em uma representação de luma perceptualmente mais uniforme, por exemplo, por meio da seguinte função: Y’U=log(1+[rho(Y_SDRin)- 1]*potência(Y_SDRin;1/2.4))/log(rho(Y_SDRin)) [Eq. 10], em que rho é uma constante que depende do brilho de pico do codec usado para qualquer imagem (neste caso o PB_C=100 nits da SDR), que é determinado para Y_SDRin e Y’U normalizado para 1,0 de acordo com: rho(PB_C)=1+(33-1)*potência(PB_C/10000;1/2,4).

[0274] Como se trata apenas de um princípio, outros uniformizadores de luma também podem ser usados com o propósito de que etapas iguais nesse luma Y’U correspondem mais estreitamente às etapas de brilhos visualmente iguais.

[0275] O restante nesse algoritmo irá operar nesse domínio, que é desfeito pelo linearizador 3105 que converte novamente para a representação de luminância linear das cores de pixel.

[0276] O que é importante nessa modalidade é a abordagem de duas etapas do ajuste. Pode-se explicar melhor que, com a subparte de redução de classificação 3110, uma vez que esse esquema corresponde às transformações exemplificadoras para primeiro converter SDR em HDR (por exemplo, as luminâncias HDR YHL que se situam em uma faixa de até PB_C = 5000 ou 1000 nits) pela subparte de aumento da classificação 3100, e então essa HDR para as luminâncias MDR necessárias (Y_MDRL) mediante redução de classificação. Novamente, todas as operações serão realizadas no domínio de luma perceptualmente uniformizado (isto é, os lumas HDR relativos uniformes Y’H serão transformados). Pode haver um primeiro mapeamento de ganho opcional 3111, que mapeia uma certa luminância máxima realmente na imagem (por exemplo, embora o PB_C possa ser 5000 nits, tais altas luminâncias podem ser consideradas brilhantes demais para a presente cena de imagens, e, portanto, o classificador pode ter classificado o conteúdo até um limite de, por exemplo, 2000 nits, contudo, dada a faixa dinâmica de SDR significativamente reduzida, faz sentido um mapeamento até o máximo possível para 100 nits, isto é, o código 1023 correspondendo ao PB_C de 100 nits, mas, para sistemas que, por exemplo, codificam uma HDR como outra HDR esse mapeamento de ganho pode não estar presente; de modo similar, algumas modalidades podem realizar um mapeamento de tons pretos, mapeando alguns tons de preto dos lumas HDR Y’H para um preto dos lumas HDR normalizados Y’HN). Mas, de modo importante, nesses lumas HDR normalizados Y’HN, que ainda têm a aparência de distribuição de brilho de uma típica imagem HDR, a unidade de mapeamento aproximado de luma 3112 pode aplicar um mapeamento aproximado. Esse mapeamento controla de maneira aproximada o mapeamento de um par de subfaixas, nas quais serão mapeados posteriormente os lumas ideais desejados dos vários objetos da imagem. Por exemplo, percebeu-se que uma variante prática que funciona bem foi uma variante que aloca uma subfaixa para colocar todos os lumas escuros (SD), e uma subfaixa para os lumas mais brilhantes possível na imagem (SB), entre as quais pode-se então projetar facilmente uma faixa intermediária, por exemplo em uma das modalidades da presente invenção um segmento de conexão parabólico (que é, por exemplo, definido com base em um ponto médio, por exemplo onde segmentos de inclinação linear para os lumas mais escuros e os lumas mais brilhantes se encontram, e uma largura).

[0277] O que quer que um classificador queira fazer, independentemente, com os objetos reais que se encontram, por exemplo, na subfaixa dos tons escuros, por exemplo clarear um pouco os objetos mais escuros, o algoritmo de ajuste pode, com o método de duas etapas, controlar explicitamente o local onde as cores mais escuras devem estar, isto é, qual subfaixa elas devem abranger, e cada cenário de visualização (isto é, quão brilhante a tela é, seu PB_D, influenciará quão escuro esses tons escuros podem ser e/ou o brilho do ambiente de visualização que também influencia a visibilidade das regiões especificamente escuras da imagem). O classificador (ou o algoritmo de classificação automática no lado de criação) pode, então, nessas faixa ajustáveis posicionadas corretamente de modo automático (desde que o ajuste seja manipulado conforme explicado com referência à Figura 32), determinar suas classificações finas, por exemplo, se um rosto deve ficar um pouco mais brilhante, ou contrastante, ou se uma cadeira branca iluminada pelo sol deve brilhar um pouco mais, etc. A unidade de classificação fina 3113 controla esse ajuste final dos lumas aproximados Y’CG produzindo lumas de classificação fina Y’FG, que o linearizador 3114 converte então em luminâncias lineares de saída Y_MDRL, que são idealmente reclassificadas. O versado na técnica deve lembrar que essas funções foram inicialmente criadas no lado de criação para uma situação de redução de classificação a partir da HDR mestra de, por exemplo, 5000 nits, para SDR (100 nits), não como na presente modalidade, para 3000 nits, ou 700 nits, e portanto, elas precisam ser modificadas corretamente, que é o que fazem os algoritmos de ajuste ideais. Todas essas unidades serão espelhadas na subparte superior, com as mesmas funções, mas certamente, com ajustes diferentes. Isto é, agora, depois de passar para o domínio perceptual na ordem inversa, a primeira unidade de classificação fina 3102 irá transformar os lumas uniformes Y’U em lumas reclassificados Y’RG (que ainda têm aparência de faixa dinâmica SDR, mas com alguns dos objetos tendo lumas diferente), e então uma unidade de classificação aproximada 3103 aplicará uma função de alocação aproximada de ao menos três subfaixas (que implementa isso agora que os lumas dos objetos foram transformados de uma aparência de faixa dinâmica SDR para uma aparência HDR), e então, opcionalmente, pode haver uma alteração de escala de tons brancos pelos escalador 3104 que mapeia o máximo dos lumas HDR normalizados Y’HN (isto é, 1,0) para uma posição mais baixa dos lumas HDR finais Y’H, por exemplo o luma que corresponde a 2000 nits em uma representação de PB_C de 5000 nits (independentemente da função de alocação de código utilizada, a qual assumimos nessa modalidade ser nossa Equação [10] acima).

[0278] Como mencionado anteriormente, essas unidades podem não estar realmente presentes como tais em um aparelho de recepção, porque elas são a parte conceptual usada por software para determinar a LUT de luminância (LLUT) para pré-carregar na exclusiva unidade de mapeamento de luminância real, mas mostra como o ajuste pode funcionar vantajosamente.

[0279] A Figura 32 descreve isto com um pouco mais de detalhes. A Figura 32a mostra o que um classificador gostaria que acontecesse se ele tivesse, por exemplo, a situação de MDR de 600 nits disponível no lado de criação. Mas, como o PB_D pode assumir qualquer valor, ele jamais terá essa situação. Ainda assim, faz sentido como uma suposição operacional, que se ele quisesse clarear os pixels de, por exemplo, um assento em um carro, ele deveria clarear esses mesmos pixels mesmo se eles tivessem sido previamente clareados anteriormente por um mapeamento aproximado. Então, o que o classificador gostaria de fazer é um ajuste fino das luminâncias dos objetos que tiveram suas luminâncias definidas na MDR, por exemplo, eixo de 600 nits, isto é, por exemplo o pixel com luminância intermediária Y_im. Entretanto, o receptor não obtém nem a curva de mapeamento ideal HDR para MDR 3203, nem a posição alterada do pixel 3303. O que ele de fato tem disponível inicialmente é a curva HDR para SDR 3201, e uma especificação de como o classificador gostaria de fazer o ajuste fino no pixel no lado de criação 3304, isto é, que é algum pixel SDR (definido na parte de 0 a 100 nits da faixa de luminância). Porém, o que realmente deveria acontecer como segunda classificação fina é mostrado na curva CC da Figura 32b. Contudo, como dito acima, depois que o aparelho no lado de recepção definir uma curva de classificação aproximada ideal 3202, o que ainda estará disponível é uma curva de classificação fina definida em um sistema de eixos SDR e HDR. Mas, a perceptualização pode ser ignorada e, então, o fator estável em tudo isso, correspondendo ao luma SDR inicial Y_inL (presumiu-se novamente nesta descrição que a HDR é comunicada e recebida como imagens SDR, que precisam ser reclassificadas para MDR) e que a luminância intermediária aproximada correspondente na faixa de PB_D de 600 nits, ou seja, Y_im, é a luminância HDR Y_HDR. A relação entre as luminâncias Y_im e Y_in para qualquer valor de Y_HDR é o mapeamento aproximado. Assim, conforme mostrado na Figura 32, isso corresponde ao otimizador de software 3012 precisando interpolar a LUT, com o uso do mapeamento aproximado para determinar qual entrada na LUT referida pela SDR, ou seja, Y_in, corresponde à luminância referida na MDR necessária, ou Y_im. Depois disso, essa LUT pode ser usada no cálculo da LLUT final.

[0280] A Figura 33 mostra uma modalidade explicativa que pode ser usada para otimizar as partes mais escuras da imagem MDR, em particular, se estiver disponível uma tela que pode renderizar pixels muito escuros, especialmente quando vistos em um ambiente escuro. Presumimos aqui que uma imagem HDR com PB_C de 5000 nits, que continha dados de imagem de até luminâncias muito escuras (por exemplo, 0,001 nit ou menos), foi comunicada como uma imagem SDR. Havia uma necessidade de codificar as luminâncias mais baixas na SDR a partir de um ponto de vista baseado puramente em informações, isto é, fornecer-lhes uma renderização escura, mas com uma curva de mapeamento linear que tem um declive suficientemente grande, porque agora ela serve principalmente como uma função de alocação de código para as luminâncias HDR mais escuras (em vez de uma classificação LDR especificamente ideal). Pode-se assumir que isto transfira razoavelmente para dispositivos SDR já existentes que têm uma renderização mínima de pixels mais escuros de, por exemplo 0,1 nit, em um ambiente de visualização normal de TV (por exemplo, anoitecer com iluminação ambiente reduzida), isto é, ao que o código “0” corresponderá. Mas essa classificação linear não será ideal para dispositivos com melhores recursos para renderizar tons escuros. Portanto, o ajuste pode aplicar outra função de ajuste que fornece uma aparência melhor das regiões escuras, até o final dos tons escuros mais escuros (que ele conhece, por exemplo, como o limiar Thr_DH na faixa HDR, ou como Thr_DS na faixa SDR). Por exemplo, ele pode usar funções que incluem um contraste adicional dependendo de quão escuro o receptor sabe que o sistema pode renderizar (em função dos tons de preto mais escuros de DB_D da tela quando controlados na escuridão absoluta, e da iluminação circundante que influencia o reflexo na placa frontal da tela e a adaptação visual e a necessidade do observador de ver tons de preto profundos específicos). Por exemplo, funções simples podem ser extensões de função gama, mas funções mais avançadas podem ser usadas, por exemplo, após a determinação de quais sub-regiões semânticas ou objetos nelas estão nessa subfaixa de tons escuros mais escuros até Thr_DH. Em algumas modalidades, pode haver informações adicionais sobre as imagens ou qualquer outro dado sobre a criação das imagens além das variantes mais simples. Por exemplo, no caso de um nível de tons de preto mais escuro da tela na qual o conteúdo foi classificado por cor pelo operador humano, indicando quais luminâncias essa tela ainda pode renderizar de modo suficientemente diferente (levando em conta sua luz de vazamento ou reflexos da placa frontal) ou, de modo geral, quais luminâncias mais escuras ainda serão vistas diferentemente pelo classificador, essas indicação são úteis também para qualquer aparelho de recepção ao decidir qual ajuste de tela, ou em geral otimização de cor no lado de renderização, será usado. Por exemplo, se o observador tiver em uma sala de visualização escura uma tela OLED, a qual, supõe-se, tem recursos de renderização para as cores mais escuras melhores do que, por exemplo, a tela de referência de LCD do criador de conteúdo (conforme indicado no valor de nível de tons de preto mais escuro comunicado), então a modalidade de aparelho de processamento de cores de ajuste no lado de recepção poderá decidir aplicar as funções de extensão apenas até um certo grau, porque luminâncias pseudoescuras estão sendo criadas, nas quais o artista de criação realmente não se viu (mas até uma certa quantidade que pode ser feita, por exemplo, quando uma situação de renderização exige contraste adicional para ter uma aparência melhor). Assim, nessa modalidade, a determinação do fator multiplicativo comum resultante e todos os cálculos do formato de função ajustada ideal que forma a base dessa determinação nas várias modalidades dependerão também do valor do nível de tons de preto mais escuros da tela de criação comunicados.

[0281] Ainda assim, mesmo que sejam criados poderosos sistemas de ajuste automático no lado de recepção que façam o que for necessário para o usuário, o observador pode desejar ter algum controle sobre o sistema para inserir suas preferências. Entretanto, o observador não é um classificador profissional, e então, mesmo que ele tivesse o tempo e a vontade (em vez de querer assistir a um filme), não se deve incomodá-lo com todas essas questões complexas de colorimetria. É aqui que o sistema da Requerente se mostra muito útil, porque ele já implementa o método do artista criativo na tela, e o observador então precisa simplesmente fazer alguns poucos (e precisos) ajuste finos de acordo com suas preferências. Isso é mostrado de modo exemplificador na Figura 34, no caso do usuário achar que o filme HDR é um pouco escuro demais para seu gosto (de modo similar alguns usuários acham a HDR excessivamente brilhante, e então, pode ser feito um processamento similar, mas esse processamento irá operar principalmente nos pixels mais brilhantes, ou talvez nos de brilho médio em vez de nos pixels escuros). Se o observador considerar a imagem de uma cena ou filme específico escura demais, por exemplo, porque ele está em um ambiente bastante claro, então, provavelmente isso será devido ao fato de que as regiões mais escuras são muito difíceis de se ver. Então, em vez de fazer um aumento global de brilho, o que danificará a aparência HDR, o que, novamente, é indesejável, acoplou-se o botão de novo brilho apenas à faixa mais escura. Na classificação aproximada de três sub-regiões acima, a região mais baixa dos tons escuros foi geralmente definida e comunicada por um limiar superior de luminância, para o qual foi mostrado aqui o valor de HDR, Thr_BKS, nessa faixa HDR de 1000 nits. Se a curva de mapeamento otimizada inicial 3401 para uma tela MDR de 700 nits for a tela determinada automaticamente com base apenas nas preferências do classificador informadas nas funções de transformação de cor F_ct, e na situação de visualização (ao menos o PB_D), então o usuário poderá ajustar sua própria curva sendo capaz de, em algumas etapas de clareamento, elevar as subpartes da curva dos tons escuros, e a seção mediana então se moverá também, para ligar com um declive inalterado para os tons brilhantes.

[0282] A Figura 35 mostra um exemplo de um protocolo de ajuste, que é o que o classificador gostaria de ver renderizado no conjunto de todas as telas com brilhos de pico entre, por exemplo, 5000 nits e 100 nits.

[0283] Vide um exemplo de uma estação espacial, com luminâncias escuras no interior (subfaixa de luminâncias SL), que são renderizadas igualmente em todas as telas, porque a faixa SL até 60 nit encaixa na faixa SDR. A terra brilhante vista na parte externa (subfaixa BE) deveria ter luminâncias muito mais brilhantes, mas não há muito espaço livre disponível na SDR. Mesmo assim, não se deveria expandir infinitamente essa faixa de 40 nits em direção a telas HDR mais brilhantes, ou em algumas telas a imagem será desagradavelmente clara. Portanto, deve haver alguma flexibilidade na função de mapeamento para esses tons brilhantes de alguma tela MDRx em diante (PB_Cx= 600 nits). O lado de recepção pode estimar isso olhando a imagem HDR reconstruída, e que aparentemente o criador não queria que essas regiões tivessem mais que 600 nits, apesar de haver espaço disponível acima de 1000 nits. O ajuste pode, então otimizar entre requisitos, por exemplo, consistência temporal e a necessidade de espaço livre posteriormente para cenas mais brilhantes, mas, neste exemplo, ele mantém o mesmo limite superior para todas as telas com PB_C acima de 600 nits, e decidiu usar toda a faixa da tela de 600 nits disponível para renderizar as luminâncias dos planetas externos na subfaixa Be2 tão brilhantes quanto possíveis, e comprimir para, por exemplo, a subfaixa Be3 para PB_Ds mais baixos.

[0284] A Figura 36 ilustra outro possível exemplo de ajuste de tela desejado para uma típica imagem de cena HDR desafiadora. O observador vê uma sala iluminada de modo normal (com luminâncias de pixel na subfaixa MIDRM), no plano intermediário, a partir de uma sala escura em primeiro plano (DRK), na qual todas as luzes estão apagadas. No lado externo, através das janelas, nota-se o mundo externo claro, talvez iluminado pelo sol (subfaixa OUTS). Ao fazer as medições físicas de luminância, pode-se descobrir que as luminâncias “normais” na sala intermediária são geralmente de cerca de 1/100 daquelas do lado externo, porque, levando- se em conta fatores geométricos como o tamanho das janelas e a proximidade de construções no outro lado da rua etc., a iluminação local pode, geralmente, ser de 1/100 da iluminação de ambientes externos (dependendo certamente, do que tal ambiente é, e se a sala intermediária está iluminada exclusivamente por luz externa). A parte escura sombria pode, por exemplo, ser 10 vezes mais escura. Dessa forma, já existe uma razão de iluminação de 1000:1, e supondo-se que as reflectâncias típicas dos objetos estejam entre 90% e 1%, isto significa que pode-se esperar na cena uma razão de luminância de 100.000:1 (sem considerar os reflexos especulares do sol sobre objetos metálicos). Obviamente, na classificação HDR mestra pode-se não encontrar o objeto no ambiente externo iluminado pelo sol codificado como, por exemplo, 10.000 nits, uma vez que a imagem deve, geralmente, ser vista em um ambiente menos iluminado, e diretamente em um pequeno retângulo de tela e não de forma tão brilhante na cronologia de um filme (pode-se, por exemplo, decidir desviar o olhar de objetos em uma cena que são muito brilhantes, mas supostamente assistir ao filme confortavelmente, e principalmente os atores, e não ficarmos irritados por um letreiro comercial fluorescente no ambiente externo, por exemplo). Portanto, dependendo do artista que cria a imagem HDR mestra, os pixels dos objetos na imagem podem ter valores um pouco diferentes para suas luminâncias. Assumiu-se, neste exemplo, que foi codificada uma imagem de 1000 nits, e o ajuste é necessário para PB_Ds mais baixos, e também PB_Ds mais altos (os quais, geralmente, podem seguir outros princípios que artisticamente não precisam ser explicados aqui, mas tecnicamente poderia-se usar componentes técnicos similares para fazer algum ajuste de tela de aumento da classificação). Como se pode ver a partir desse protocolo de ajuste e dos vários ângulos das linhas de conexão que conectam telas exemplificadoras do conjunto de telas de PB_D possivelmente contínuo, esta imagem pode exigir um ajuste de tela muito mais sofisticado. Por exemplo, para uma imagem HDR de complexidade tão alta, uma opção muito mais crítica que uma mera estratégia de compressão não linear pode ser necessária para adequar uma imagem de aparência razoável em uma faixa dinâmica SDR tão pequena. Por exemplo, se a imagem SDR não for necessária para calcular imagens adicionais, pode-se optar por fazer um corte abrupto em algumas sub-regiões de luminância (que chamamos também de regimes), isto é, mapear todas as luminâncias da imagem COD_HDR de 1000 nits recebida para um único valor de luminância, ou muito poucos valores. Conforme mencionado acima, em nossas várias modalidades, vários componentes podem decidir. Por exemplo, o aparelho de TV pode decidir fazê-lo em seus algoritmos heurísticos inteligentes pré-programados realizando o cálculo HDR para SDR. Ou, o classificador de conteúdo pode indicar se ele prefere manter as regiões mais escuras (porque algo de interesse poderá acontecer na sala escura um pouco depois), mas sacrificando o ambiente externo, fazendo as janelas um branco uniforme (o que ele irá, geralmente, comunicar pelo formato de suas funções de redução de classificação HDR para LDR, mas ele pode também comunicar isso com metadados adicionais, por exemplo, conforme mostrado na Figura 6, enviando alguns parâmetros que prescrevem ou orientam como várias sub-regiões de luminância podem ou devem ser ajustadas). Mas é importante entender que um algoritmo de ajuste que realiza tal comportamento não pode simplesmente funcionar mediante a aplicação de um formato simples de função de mapeamento de luminância às luminâncias de pixel SDR, porque então a única luminância branca na imagem SDR (os pixels do ambiente externo vistos através das janelas) não irá expandir em um conjunto de várias luminâncias, por exemplo, na imagem ajustada MDR de 400 nits. Além disso, como se pode ver, as regiões escuras podem ser ajustadas de acordo com um protocolo de equiluminância para todas as telas entre 400 nits e 5000 nits (e potencialmente além disso), mas para faixas dinâmicas ainda menores do que aquelas com PB_D=400 nits, é preciso escurecer os pixels da sala não iluminada (DRK). Especialmente quando iluminadas naturalmente, as imagens HDR podem ser bastante complexas. Tomando-se, por exemplo, um carro de polícia fazendo uma perseguição através de uma floresta escura à noite. Os faróis do carro iluminam as árvores em padrões complexos, e para complicar, haverá as luzes vermelhas e azuis da sirene do carro. Além disso, aprofundando-se na floresta pode haver lugares muito escuros, especialmente se não for noite de lua cheia. Quando se adapta as cores/luminâncias dos objetos da imagem para se obter uma imagem com aparência mais ideal (de preferência similar à aparência da classificação mestra em sua tela de referência) em qualquer tela específica, isso pode estar longe de ser trivial, exigindo um conjunto de boas soluções técnicas para tratar da imagem, de preferência de modo pragmático. Fazer nada resultará, geralmente, em algumas partes da imagem parecendo desagradavelmente escuras demais e/ou outras partes claras demais, neste último caso, por exemplo, quando se usa o processamento inverso que é simples demais. Para complicar, deseja-se, em princípio, soluções que possam tratar das muitas variantes práticas da criação e uso de imagens, por exemplo, um estúdio capturando o que é bem projetado colorimetricamente, uma produção no campo por uma equipe pequena, um grande filme de Hollywood a ser distribuído em disco BD, conteúdo de consumidor etc.

[0285] A Figura 37 mostra como variantes de ajuste de tela mais complexas podem fazer cálculos mais complexos, por exemplo, levando em conta preferências específicas sobre os pixels mais brilhantes possível nas imagens, ou, por outro lado, os mais escuros, em particular no caso de os mesmos serem difíceis de serem visualizados quando vistos em um ambiente de visualização mais claro (por exemplo, você está assistindo à TV, mas sua esposa quer ler um livro no mesmo ambiente, isto é, há uma certa quantidade de lâmpadas acesas, e o ajuste poderia atender a qualquer configuração de ativação de uma combinação das lâmpadas presentes na sala de visualização). É possível construir técnicas de ajuste mais avançadas, determinando-se funções adequadas offline, e carregando-se a(s) função(ões) de transformação de luminância, por exemplo, SDR para MDR_1650 nits em uma unidade de cálculo de núcleo, que então deriva os multiplicadores gt. A unidade de determinação de função ideal 3701 que faz todas as várias determinações pode ser executada como um software, e analisar as funções SDR para HDR recebidas, características das imagens (embora isso possa não ser necessário se, idealmente, forem usadas as informações nos formatos de função de mapeamento de luminância de reclassificação), particularidades do ambiente de renderização, preferências adicionais do criador de conteúdo comunicadas em segundos metadados, ou escolhas do fabricante do aparelho, ou preferências do observador. Isso tudo pode levar a diferentes funções ideais F*, já transformadas na faixa de saída MDR necessária, ou formuladas na faixa HDR mestra e ainda serem ajustadas no núcleo de processamento de cores, exemplificado pelas unidades à direita da unidade 3701.

[0286] A Figura 38 mostra um exemplo de como funções auxiliares podem ser usadas para determinar novamente o ajuste, por exemplo, controlando-se o formato de apenas parte, isto é, para uma subfaixa dos lumas de entrada, da função de mapeamento de luminância SDR para MDR final. É mostrado um ajuste diferente daquele da Figura 17, no qual, embora o mapeamento HDR para SDR naquele exemplo precise realizar uma quantidade considerável de corte, as imagens MDR reclassificadas ou ajustadas agora exibem corte abrupto. Entretanto, essa curva exemplificadora para derivar a imagem MDR a partir da imagem HDR 1703 (seja transmitida ou reconstruída como Im_RHDR) mostra uma longa cauda de corte suave, que corresponde a deixar precocemente a curva HDR, isto é, a diagonal. Pode ser preferencial, para alguns tipos de ajuste, permanecer por um longo tempo na diagonal, isto é, ter luminâncias idênticas àquelas da imagem HDR. Para luminâncias escuras, por exemplo abaixo de 40 nit, pode-se entender que em alguns cenários pode ser útil fazer a renderização com uma luminância de saída idêntica em qualquer tela PB_D, isto é, na tela SDR, ou qualquer tela HDR. Às vezes, pode ser preferencial manter esse requisito alto até mesmo para luminâncias HDR muito altas, isto é, para derivar uma curva 3801 ajustada (onde, neste exemplo, a imagem HDR forma a imagem de entrada para a transformação de cor para se obter a imagem MDR dependente de PB_D como imagem de saída). Certamente, uma imagem de 4700 nits não pode jamais conter exatamente todas as mesmas luminâncias que uma imagem com PB_C de 5000 nits, portanto, em algum momento, será necessário deixar a curva de transformação de identidade por luminância (isto é, a diagonal), e iniciar um corte suave ou um corte abrupto. Nesse exemplo, há uma faixa RLB que pode ser selecionada para corte abrupto, e uma faixa de transição RT para corte suave, que pode ser selecionada pequena pelo aparelho (por suas próprias regras internas de cálculo, ou sob a orientação da entrada do criador de conteúdo e/ou observador) de modo que a classificação MDR pareça tão exequível quanto possível para a imagem de aparência HDR, isto é, como se a tela disponível fosse de 5000 nits em vez de uma tela de 4500 nits. Isso pode ser entendido pelo criador de conteúdo, embora, talvez, menos pelo fabricante do aparelho, e funcionar muito bem no caso de as luminâncias mais altas serem, por exemplo, realces de reflexo metálico etc.

[0287] A Figura 39 ilustra como isso pode ser indicado por uma função de posicionamento de métrica (por exemplo, por um criador de conteúdo que quer instruir o aparelho a ajustar de acordo com tal comportamento). No eixo horizontal, são dados os possíveis valores de PB_D, bem como um limiar TPERF acima do qual as telas devem se comportar como telas de referência de acordo com a classificação HDR mestra criada (isto é, como se PB_D=PB_C = 5000 nits, por exemplo). No eixo y há uma distância na métrica, que, neste caso, é indicada como uma diferença a partir da classificação SDR (ou aproximação da classificação HDR mestra). Certamente, para uma tela SDR, a distância deve ser 0, isto é, a tela seria servida com uma imagem SDR. Quando um aparelho detecta que ele deve se comportar como a tela HDR acima do limiar TPERF, ele pode decidir sobre uma estratégia para manter tantas luminâncias MDR quanto possível iguais à luminância HDR (o que seria obtido quando o processamento de cores é feito em uma luma de entrada SDR), e, então, em uma estratégia de corte (suave) necessária, por exemplo, conforme mostrado na Figura 38. Ou até uma pequena compressão das luminâncias abaixo do limiar TPERF poderia ser feita para criar para espaço para o corte suave dos pixels mais brilhantes (por exemplo, luminâncias de 4700 a 5000 nits que não podem ser renderizadas em uma tela com PB_D de 4700 nits), conforme mostrado pela curva mais espessa que se desvia ligeiramente da diagonal.

[0288] A Figura 40 ilustra outro exemplo que possibilita um ajuste de tela computacionalmente simples na direção vertical. Ela mostra, também, alguns blocos opcionais (linhas pontilhadas) para uma modalidade detalhada muito útil, como o princípio geral, com a unidade de adaptação 4025 sendo a mais interessante.

[0289] Presume-se (sem limitação) que uma imagem SDR Y’CbCr seja recebida através de uma entrada 4001. A parte superior representa uma cadeia de processamento de luminância, de acordo com um método prático e versátil da Requerente. Primeiramente, os lumas SDR Y’_SDR são linearizados com a EOTF do padrão BT.1886 (esta é uma definição de uma tela SDR arquetípica, e considerou-se um deslocamento de tons de preto igual a zero, assim esta equação é aproximadamente uma potência quadrada). Em seguida, o perceptualizador 4003 transforma as luminâncias lineares que são produzidas pelo linearizador 4002 anterior em lumas Y’P mais visualmente uniformes. Embora outras equações sejam possíveis, assumiu-se o uso da OETF HDR Philips (Equação 8 acima) da Requerente, com os parâmetros indicados, por exemplo, rho igual a 5,7, que é o valor adequado para telas SDR, isto é, uma curva normalizada para um PB_C de 100 nits. É muito útil fazer ajustes de telas em tal representação de cor, embora não necessário, e pode-se até ignorar o linearizador e fazer cálculos diretamente nos lumas SDR (aproximadamente a raiz quadrada). Então, uma unidade de curva padronizada 4004 aplica uma curva de reclassificação. Na modalidade genérica, isso fará toda a classificação LDR para HDR necessária, mas na modalidade específica com todas as unidades pontilhadas presentes, essa unidade pode carregar a partir dos metadados uma curva que realiza o ajuste fino (a partir de uma representação normalizada SDR para uma saída que ainda será uma SDR normalizada). A unidade de reclassificação aproximada 4005 aplica uma função Fcrs para mover ao menos três subfaixas dos lumas criados pela unidade 4004 para posições HDR adequadas no que é agora uma faixa HDR (posições relativas, isto é, em comparação com PB_C de, por exemplo, 5000 nits, uma vez que os cálculos ainda funcionam em representações normalizadas até um máximo de 1,0). No exemplo especifico, o formato dessa função é determinado por um parâmetro SSL, que determina o declive de uma parte linear da função para os tons de preto, isto é, começando em 0, a representação HSL determina, de modo similar, a inclinação do declive para os lumas mais brilhantes, e a MIDW determina a largura de uma região de transição entre as duas subfaixas, por exemplo, de formato parabólico. Finalmente, em algumas situações pode haver uma unidade de adaptação de faixa 4006, que pode mapear o valor máximo, 1,0, para algum valor relativo dW de HDR, por exemplo 0,7, e, de modo similar, o valor 0 pode ser mapeado para dB, por exemplo 0,0001. Isso fornece finalmente os lumas HDR normalizados, Y’CH, que têm uma classificação adequada (em um domínio de lumas perceptuais). Os lumas perceptuais Y’P são multiplicados por uma constante 1/kb, e o mínimo de Y’P/kb e Y’CH é usado como o luma HDR final, Y’FH, com a aparência de brilho correta.

[0290] Então, esses lumas normalizados são linearizados para luminâncias HDR normalizadas pelo linearizador 4009, que, devido ao fato de se ter usado a OETF Philips na unidade 4003, será uma OETF Philips correspondente, conforme dado pela Equação 6. O parâmetro rho_H dependerá agora do tipo de imagem HDR que o sistema deve reconstruir, e estará, geralmente, entre 13,2 (para PB_C HDR de 1000 nits) e 33 (para HDR de 5000 nits), mas poderia, obviamente, ter outros valores também.

[0291] Finalmente, as luminâncias HDR lineares são geralmente convertidas de volta ao formato de raiz quadrada para estar em conformidade com o formato de entrada, Y’_SDR, por uma unidade de cálculo de luma 4010 que aplica a função inversa da EOTF BT.1886 (em princípio, este padrão prescreve apenas uma tela e sua EOTF de referência, mas o versado na técnica podem imaginar como determinar o formato de função inversa por espelhamento na diagonal).

[0292] Agora a unidade de adaptação 4025 escala para as luminâncias relativas adequadas aplicando o cálculo abaixo.

[0293] Primeiramente, ela calcula um valor gp que corresponde ao PB_D da tela MDR para a qual a imagem deve ser reclassificada a partir da aparência HDR como ponto de partida, de modo similar ao que foi descrito anteriormente. Assim, geralmente, outra unidade calculou gp=log(PB_D/100)/log(PB_C/100), onde PB_C é o brilho de pico das imagens HDR reconstruídas, as quais, certamente, correspondiam ao tipo de codec HDR, isto é, o que o lado de criação selecionou como um valor PB_C útil para as imagens HDR do par HDR/SDR (que pode ser determinado por acordos de um padrão específico, por exemplo, discos blu-ray iriam preferir usar PB_C de 1000 nits, ou necessidades típicas de uma aplicação, isto é, os tipos de imagens que ocorreriam, por exemplo, para um programa de notícias que pode ter realces, mas que é, em gera, iluminado de maneira relativamente uniforme em vez de iluminado exoticamente - isto é, não há cavernas escuras ou espadas laser - poderia-se considerar que 1000 nits deveriam ser suficientes, e qualquer valor acima disso poderia sofrer um corte abrupto para esse branco).

[0294] A unidade de adaptação 4025 multiplicará a função de transformação de luminância total aplicada ao luma SDR de entrada, isto é, F_tot(Y’_SDR), que é primeiro elevado à potência gp, por aquele luma elevado à potência (1-gp).

[0295] Logo, em outras palavras, ela calcula um luma MDR adequadamente classificado Y’M=potência(Y’GH;gp)* potência(Y’_SDR;1-gp). De modo similar ao descrito acima, poderia-se converter as várias técnicas e modalidades mais avançadas em uma formulação desse tipo, bem como converter essa alteração de escala multiplicativa final em outros domínios de luma.

[0296] Finalmente, os lumas MDR opcionalmente não lineares definidos de acordo com uma função de formato BT.1886 poderiam ser convertidos em outro formato de luma, por exemplo, versões de raiz quadrada exata das luminâncias, pela unidade 4033, que é apenas uma das definições de modalidade que a Requerente usa (portanto, opcionalmente).

[0297] Os lumas MDR adequadamente classificados, L’M, são usados para multiplicar (pelo multiplicador 4032) por três valores RGB não lineares normalizados, R’s, etc., (fornecidos pelo matriciador de cores 4031 (“matrixer”), conforme mostrado na Figura 25, produzindo valores RGB MDR finais corretos (RGB_MDR), que poderiam ser transmitidos diretamente par uma tela com esse PB_D correspondente.

[0298] Esse modo de ajuste de tela é muito útil no caso de ser feito um processamento cromático correspondente por um ajuste de saturação na unidade de saturação 4030, que pode, geralmente, ser executado multiplicando-se Cb e Cr por um fator Sat(Y’_SDR) que depende dos lumas de entrada. Uma típica boa escolha para essas funções pode ser um desvio de Sat(Y’_SDR)=k/ Y’_SDR, em que k é uma constante, com, para valores mais altos de Y’_SDR, um valor Sat menor que essa função linear inversa, para criar uma “dessaturação”. Isto fornece imagens MDR adequadamente reclassificadas de acordo com todos os aspectos de otimização (porque nunca é possível renderizar perfeitamente a imagem HDR mestra em qualquer tela MDR, especialmente se ela tiver, por exemplo, um PB_D=500 nits).

[0299] A Figura 41 mostra um exemplo de como o ajuste funcionaria, geralmente, caso houvesse uma iluminação circundante acima da média. Se a iluminação circundante se tornar suficientemente alta, o que antes teria parecido - sob iluminação normal de visualização do aparelho de TV ou computador - como uma área cinza claro na tela, poderia parecer cinza escuro ou mesmo preto em comparação com os objetos brilhantes que circundam a tela.

[0300] A Figura 41b começa com uma imagem que foi idealmente reclassificada para uma tela MDR de, por exemplo, PB_D = 1200 nits (a imagem HDR mestra original pode ter contido conteúdo de imagem, isto é, objetos brilhantes de até 5000 nits, mas as luminâncias correspondentes para esses objetos já haviam sido calculadas na faixa de luminância MDR, com o uso qualquer uma das estratégias acima). Supondo-se, agora, que o nível de iluminação circundante seja aumentado, então, faria sentido que as luminâncias dos vários objetos (ao longo da diagonal) tivessem de ser clareadas novamente. Certamente, isso seria idealmente diferente dependendo do real conteúdo de imagem. Por exemplo, um tipo de problema típico, porém não exclusivo ou exaustivo, é que o observador tem dificuldade de perceber o que exatamente reside nas regiões mais escuras da imagem. Contudo, teoricamente, poderia se pensar que se a iluminação circundante aumentasse em um fator, por exemplo 2, isso resultaria em uma situação de mesma aparência se todas as luminâncias renderizadas por tela aumentassem linearmente (e, portanto, a imagem MDR de controle como entrada) pelo mesmo fator 2 (se isso for mesmo possível, por exemplo, devido à retroiluminação limitada de uma tela LCD). Isso poderia ser verdadeiro se a visão humana fosse perfeitamente adaptável, mas, na prática, essa não é necessariamente a melhor abordagem para tal clareamento contra-circundante para assegurar a melhor renderização aparente para qualquer combinação de conteúdo de imagem/limitações de visualização. A Figura 41a mostra alguns dos princípios. Uma renderização de imagem teria, teoricamente, uma aparência ideal se a luminância média representativa dos pixels da imagem (AVGIM) fosse idêntica à luminância média representativa dos objetos circundantes (AVGSURR), a qual, por sua vez, é, através das reflexividades dos objetos, dependente do nível de iluminação circundante. Por exemplo, na renderização de uma cena noturna em uma casa com paredes escurecidas na qual um policial entra com sua lanterna voltada para o observador, a aparência seria espetacularmente realista se a cena continuasse com regiões e objetos circundantes tendo aproximadamente as mesmas luminâncias para os objetos que na imagem, como se fossem uma continuação da casa. Deve ser enfatizado que a HDR mudou todas as regras, e que a luminância média da imagem HDR não é de modo algum geralmente igual a 0,18*PB_C, como ocorria na era do vídeo SDR. Isso não se deve apenas ao fato de que o PB_C pode ter qualquer valor e que os máximos mais brilhantes para as possibilidades de codificação de objetos geralmente resultarão em médias relativamente mais baixas, mas também porque as cenas HDR podem conter simplesmente qualquer coisa, mas têm, frequentemente, boas aparências porque podem ter pequenos realces que são muito mais brilhantes do que a média (com qualquer relação com AVGIM, certamente nem sempre 5x mais brilhante). Certamente, o leitor entenderá que este modelo não é perfeito, e pode existir apenas se a iluminação circundante variar dinamicamente com o conteúdo da imagem, o que pode nem sempre ser preferencial. Assim, geralmente, a renderização da tela poderia ser mais escura que o ambiente circundante quando são renderizadas cenas noturnas, e em certa medida mais clara quando são renderizadas cenas diurnas (resultando na aparência de caixa de luz das telas, mas com o foco do observador predominantemente na tela, isto é, adaptação a um grau maior com base nas cores da tela em vez de nas cores circundantes). Para imagens HDR, essas diferenças poderiam ser um pouco mais impressionantes, e, portanto, poderiam ser úteis para uma experiência ideal que, quando, por exemplo, uma cena noturna precisar ser renderizada, que a iluminação circundante sejam por algum tempo ao menos diminuídas ao mesmo grau com lâmpadas coordenadas, para assegurar que as regiões escuras da imagem não pareçam escuras demais, mas, em geral, não há garantia de que qualquer sistema de renderização agirá dessa forma.

[0301] Entretanto, dispor de métodos de ajuste de tela que focalizam precisamente em uma região principal de luminâncias geralmente “médias”, e não apenas um fator global que intensifica o brilho de pico e tudo abaixo de modo colinear, ainda é uma forma de manusear de modo ideal o ajuste de aparência para diferentes ambientes circundantes.

[0302] A Figura 41b ilustra esquematicamente essa transformação de luminância no gráfico 4110, que, portanto, pode ser caracterizada na faixa de luminância MDR normalizada, L_MDR (por exemplo, PB_D=1200 nits), com as luminâncias de saída, L*_MDR, abrangendo a mesma faixa (que corresponderia ao que pode-se enviar como cores de controle para a tela MDR).

[0303] A média representativa de imagem AVGIM pode, novamente, ser obtida de várias maneiras, e em vários graus de precisão representativa (por exemplo, ela poderia ser transmitida em conjunto nos terceiros metadados, ou estimada, por exemplo, heuristicamente, pelo aparelho no lado de recepção a partir de um conjunto de amostras de luminâncias de imagens MDR). No método ilustrado, essa média é aumentada em uma quantidade dAV. Um primeiro aspecto a ser observado é que isso não precisa ser 2x para uma iluminação aumentada 2x, ao contrário, deve-se levar em conta, entre outras coisas, a quantidade de faixa que é necessária para objetos mais brilhantes (isto é, com luminâncias acima do máximo AM da região de luminâncias médias 4111). Vários efeitos visuais práticos organizaram as escolhas. De um lado, como já mencionado anteriormente, na prática, uma renderização em uma tela não precisa ser exatamente (igual) coordenada com a luminância média circundante. Logo, a luminância média AVGIM poderia ser intensificada sendo deslocada por um valor de deslocamento estabelecido, dAV (o que se resume em um simples controle da curva de transformação de luminância final 4112 com base em uma elevação dessa posição-chave), de modo a clareá-la, mas talvez menos do que para a adaptação visual multiplicativa teoricamente perfeita. Por exemplo, se a tela já estiver um brilho acima da média em comparação com o meio circundante, intensificar essa média em uma quantidade dAV, que corresponde a um valor L*_MDR que é apenas 1,5x AVGIM, ainda resultará numa renderização um tanto clara e colorida, talvez um pouco menos, mas provavelmente boa o bastante para as circunstâncias (uma vez que, para muitas imagens, a renderização das regiões escuras pode ser um problema crítico no que diz respeito à visibilidade, contudo, o clareamento das cores médias fornece uma aparência clara, brilhante e colorida para a renderização em qualquer situação de ambiente circundante). Além disso, o algoritmo pode usar regras heurísticas no que diz respeito ao que é preciso para os contrastes nessa região principal. Novamente, alguns metadados de especificação do lado de criação poderiam indicar o que é desejado, mas algoritmos heurísticos automáticos no lado do receptor poderiam usar - dependendo da capacidade de cálculo disponível - uma análise de cena para a tomada de imagens, e determinar a complexidade das regiões com base em aspectos como quantidade de submodos de histograma na região de médias 4111, medidas locais como valores representativos de textura, ou mesmo segmentação rápida e consideração do padrão geométrico dos objetos etc., ou medidas da qualidade das imagens como estimativas de bandas, ou estimativas de erros de compressão. Os algoritmos poderiam usar isso para calcular onde o valor mínimo de Am deveria ser mapeado no eixo de luminância de saída, L*_MDR, ou, neste caso, o algoritmo decidiu que alguma redução de contraste era permitida (para equilibrar com as necessidades dos objetos mais brilhantes da imagem, acima de AM), reduzindo a F(AM) para a luminância de saída MXA em comparação com um deslocamento linear de todas as luminâncias da região de médias. Adicionalmente, os pixels brilhantes seguem algumas lições psicovisuais importantes. Deve-se ter cuidado para não apenas deslocar ou flexionar com uma função arbitrária, como uma função gama, porque, então, a aparência de faixa dinâmica poderia ser gravemente destruída, a qual foi anteriormente tão cuidadosamente criada pelo criador de conteúdo e ajustada com dependência do PB_D. Os pixels mais brilhantes são necessários para criar alguma cintilação. Novamente, é certo que pode haver alguma redução inevitável da faixa dinâmica, devido à quantidade de iluminação circundante, e a tela, embora com PB_D mais alto que 100 nits, começa a executar em seus valores máximos. Todavia, isso não significa que não se possa fazer também essa otimização tão cuidadosamente quanto possível, para reter tanto quanto possível a aparência originalmente pretendida pelo artista, a qual ele criou na classificação HDR mestra, em função das atuais limitações no lado da renderização. E a aparência ideal dependerá novamente do conteúdo. Por exemplo, se em toda a faixa de brilhos acima de AM houver, para essa imagem, apenas algumas pequenas lâmpadas vistas como lâmpadas tipo bulbo, ou algumas pequenas regiões de reflexo metálico, será mais possível renderizá-las em uma razão absoluta mais baixa da média dessa região local dividida por AVGIM e, ao mesmo tempo, ainda fornecer uma aparência psicológica de boa cintilação. Entretanto, quando se tem para os tons brilhantes uma vista através da janela (neste caso, o ambiente interno que forma a região de luminâncias médias) de construções iluminadas pelo sol, é preciso tomar mais cuidado com a compressão dessa região acima de um valor calculado MXA equilibrado, para que essa região não perca muito contraste e riqueza cromática, especialmente se algo importante estiver acontecendo no filme também no ambiente externo. Neste exemplo, elevou-se os pixels mais escuros a uma estimativa de nível de tons de preto BKEst. De modo geral, um algoritmo chegará a uma realocação equilibrada dos mesmos em ao menos três regiões, e algoritmos mais avançados podem até ajustar o formato da função 4112 em pelo menos uma dessas regiões para se tornar não linear.

[0304] Conforme apresentado, uma forma muito útil de se fazer o ajuste de tela consiste em um método ou aparelho para calcular cores resultantes de uma imagem MDR para uma tela com brilho de pico (PB_D) que não é igual ao brilho de pico de uma imagem recebida (PB_IM1) ou de uma imagem que pode ser calculada a partir daquela aplicando a ela funções de mapeamento de cor F_ct recebidas em conjunto, compreendendo ao menos funções de mapeamento de luminância, que compreendem uma função de mapeamento de luminância aproximado (Fcrs) e uma função de mapeamento de luminância fino (CC), caracterizado pelo fato de que a primeira função de mapeamento aproximado otimizada (FCrs_opt) é determinada com base em ao menos o PB_D para determinar subfaixas ideais das luminâncias dada a situação real de renderização da tela, e esse mapeamento aproximado é aplicado à imagem de entrada fornecendo lumas aproximados (Y’CG), e então uma função de mapeamento fino é otimizada com base na função de mapeamento de luminância fino (CC) e ao menos o PB_D, e este é aplicado aos lumas aproximados. O mapeamento aproximado possibilita criar versões adequadas de subfaixas dependendo dos requisitos de uma imagem, que podem então ser usadas para a classificação fina dos objetos na imagem. Por exemplo, uma cena do interior de uma casa em um dia nublado com uma vista externa pode, a partir dos primeiros princípios matemáticos ter aparência similar à de uma cena noturna com uma vitrine bem iluminada contendo objetos, e uma região escura de um beco adjacente fracamente iluminado no qual há algumas bicicletas. Embora as bicicletas mal possam ser visíveis, e essa pode ser a intenção artística, ambas as imagens contêm uma região mais clara e uma região mais escura. Entretanto, o interior iluminado com luz natural é idealmente renderizado com luminâncias mais brilhantes do que qualquer cena noturna. Além disso, como cenas noturnas geralmente não serão vistas como contrastantes, elas podem não precisar de uma grande sub-região de lumas, mesmo que nelas ocorra alguma ação, ao passo que o interior da casa, por outro lado, pode precisar de uma subfaixa considerável da faixa de luminâncias disponível para muitas telas MDR. O mecanismo de mapeamento inicial aproximado de luminância não apenas possibilita, de modo geral, onde colocar as subfaixas necessárias, isto é, com qual luminância inicial ou luminância MDR média, mas também em qual medida, isto é, quantidade de luminâncias MDR cada subfaixa pode ter. Ambos os mapeamentos otimizados podem ser determinados de várias maneiras, por exemplo, o mapeamento aproximado para criar versões adequadamente iluminadas pode ser expandido na direção diagonal com um fator de escala idealmente determinado, e o mapeamento fino na direção vertical. Mas outras variantes são possíveis, por exemplo, uma alteração da direção de expansão aproximada para a parte mais escura das luminâncias de entrada ou lumas da imagem de entrada para serem convertidas em uma imagem MDR.

[0305] Devido ao fato dos conceitos inovadores da Requerente poderem ser incorporados como diversas variantes e em muitas formas (por exemplo, cálculo direto de 1 etapa na decodificação em comparação com pós-processamento, métricas diferentes e ajuste ao longo de métricas, diferentes representações de cor, etc.), incluiu-se a Figura 42 para mostrar de maneira mais simples (resumir) os conceitos fundamentais de algumas das modalidades da presente invenção. A parte superior se refere à codificação pura de vídeo, e será usada apenas para introduzir a possibilidade do lado de criação formular a imagem de cena HDR (e, em particular, os requisitos quando é feita a reclassificação para exigências diferentes de luminâncias, para obter uma imagem com brilhos ideias de objetos para uma tela com uma dada capacidade HDR, em particular seu brilho de pico de tela PB_D), por exemplo, por um classificador humano especificando uma função de transformação de tom ou de luminância, TMF, que mapeia as luminâncias relativas HDR de uma imagem HDR mestra classificada (M_HDR) com as luminâncias SDR relativas de uma imagem SDR correspondente (RG_SDR). Questões sobre como essa função foi determinada, qual era seu formato, ou mesmo como exatamente ela é representada em metadados (MET) transmitidos para um receptor, não são necessárias para explicar os ensinamentos da presente invenção. A primeira coisa que será geralmente feita (de várias maneiras nas várias possíveis implementações de modalidades), é que essa função (que faz o mapeamento entre SDR e HDR, por exemplo, codificando uma representação PB_C = 1000 nits) TMF é novamente estabelecida no lado de recepção. Isso se deve ao fato de seu formato ser altamente importante, pois ele determina (de acordo com, por exemplo, o classificador humano) como as luminâncias para os objetos da imagem devem ser “reorganizadas”. Será, portanto, um fator importante de orientação para qualquer algoritmo que determina uma reclassificação para uma tela específica. Em muitas das modalidades da presente invenção, consideramos essa função de reclassificação, por exemplo, HDR para SDR, como o extremo das possíveis reclassificações no caso uma imagem HDR ter sido comunicada (e vice-versa para modalidades de comunicação SDR). Então, é determinada uma direção de interpolação no gráfico de relação entre as luminâncias da imagem de entrada (eixo x) e as luminâncias de saída (que poderia, em princípio, ser qualquer representação de, por exemplo, como as luminâncias de entrada estão relacionadas às luminâncias da outra imagem classificada original no lado de criação, ou a imagem necessária para a tela específica). Algumas modalidades podem ter uma direção especificada, isto é, inserida na unidade de determinação do fator de alteração de escala (4205), por exemplo, por uma unidade de leitura de dados que a lê a partir dos metadados transmitidos em conjunto com as informações de imagem (coeficiente DCT etc.), ou, em algumas modalidades ela pode ser definida no aparelho, por exemplo, como um padrão de fábrica de 45 graus, etc. O valor de 45 graus é especialmente interessante, uma vez que este método reduz para o comportamento mínimo da diagonal, quando qualquer representação mapeia a luminância máxima da representação da primeira imagem (por exemplo, SDR) para a segunda (por exemplo, PB_C da imagem otimizada da tela de 500 nits). Em segundo lugar, juntamente com essa direção, pode ser posicionada uma métrica, geralmente com um dos pontos finais situados na diagonal do gráfico (vide, por exemplo, a Figura 21), ou seja, aquela imagem que é uma imagem de entrada comunicada, Im_in. A direção determinará as funções matemáticas de como versões intermediárias da função de mapeamento de luminância exigida a partir da imagem de entrada para qualquer imagem otimizada por tela ocorrerão e, em particular, por qual métrica. Ter uma métrica possibilita, até onde necessário ou desejado, fazer determinações precisas do comportamento da reclassificação intermediária, em contraste, por exemplo, com métodos mais aproximados ou genéricos. Como mostrado, existem várias maneiras de se obter métricas equivalentes, mas certamente a unidade terá uma métrica predefinida ou recebida que seja sensata para o comportamento de qualidade boa ou razoável de otimização de telas. Mostrou- se também que é possível ajustar métricas ou posições em métricas. A única coisa que o leitor precisa saber nesta discussão simplificada e resumida é que uma métrica pode ser posicionada ao longo da direção DIR, onde quer que ela seja necessária, por exemplo, começando em cada ponto da diagonal (que corresponde a uma luminância de entrada específica). Certamente, as modalidades alternativas podem preferir determinar apenas vários pontos ao longo da diagonal para determinar um local de um ponto correspondente da função de reclassificação (F_M) a ser usada para calcular a imagem de saída de PB_D otimizada, e então determinar os outros pontos, por exemplo, por conexão linear etc. Os princípios dessas modalidades diferentes são os mesmos. Assim, como mostrado no desenho esquemático inferior, geralmente o outro ponto final termina na curva TMF conforme transmitido nos metadados (isto é, a função necessária para, por exemplo, calcular a imagem classificada SDR a partir da imagem de entrada HDR recebida, que corresponde à diagonal representando a transformação de identidade). Dessa forma, o leitor pode entender que, se várias versões da métrica METR escaladas puderem ser posicionadas dessa maneira, as quais têm posições que correspondem aos vários possíveis brilhos de pico ao menos entre a HDR, por exemplo, posição de 1000 nits na diagonal e a posição SDR de 100 nits na TMF, isto é, a qual desenhamos com um segmento de linha para, por exemplo, a posição de PB_D de 200, 400, 600, 800 nits, então em cada local da diagonal uma posição (M_PB_D) também pode ser determinada na métrica, correspondendo à tela real disponível no lado de recepção, e para a qual precisa ser calculada uma imagem de saída adequada com boas luminâncias de objetos/pixels da imagem reclassificada. Conceitualmente, o leitor pode entender a determinação da função F_M necessária final, isto é, para calcular não a classificação SDR a partir da imagem HDR recebida (como imagem de entrada neste aparelho), mas a imagem MDR para a tela de PB_D, pode ser obtida conectando-se todas as posições nas métricas. Mas, certamente na prática, esse comportamento pode ser formulado matematicamente no aparelho de várias maneiras, por exemplo, como uma equação que calcula diretamente um novo parâmetro ou parâmetros necessários de alguma função específica que o classificador usou para ligar as classificações SDR e HDR como vídeo codificado e transmitido (por exemplo, para uma função TMF que conecta em espaço perceptual uniforme dois segmentos lineares nos lados brilhante e escuro, respectivamente, da faixa de luma com um segmento parabólico, para a função F_M os parâmetros que determinam os declives das partes lineares e também do local da parte parabólica podem precisar ser recalculados, e tais cálculos podem, por exemplo, ser incorporados como código de software executado em um processador no aparelho, por exemplo, um STB ou TV, desde que realizem o comportamento geral descrito). Finalmente, a função é, de preferência, e vantajosamente transformada em um valor multiplicador, com o uso de uma técnica que é explicada em detalhes com referência à Figura 16.

[0306] Explicou-se, também, como uma coordenada de extensão vLin que se estende na diagonal corresponde às luminâncias de entrada através de uma projeção geométrica P, e o mesmo pode ser dito sobre o eixo y rotacionado das luminâncias de saída. Assim, geralmente, a metodologia de ajuste determinaria a função F_M conectando pontos nas métricas posicionadas que correspondem a M_PB_D, mas pode haver variantes que se desviam disso, porém, em geral, o posicionamento dependerá da posição M_PB_D identificada, e do formato das funções TMF. Por exemplo, uma modalidade simples mas poderosa altera a escala das métricas, conforme estabelecido, por exemplo, com um único e simples pré- estabelecimento dos “ticks” que correspondem a passos iguais no PB_D (por exemplo, cada passo de 100 nits), de modo que o outro PB_C das duas classificações de imagem se conecta àquela função TMF representando essa transformação de luminância (isto é, por exemplo, a curva SDR para calcular as luminâncias da imagem SDR no ponto final da métrica de 100 nits a partir das imagens HDR, e como essa curva se situaria além da diagonal, por exemplo, elevando-se acima dela quando a diagonal fosse rotacionada para uma direção horizontal).

[0307] A Figura 43 mostra outra visão técnica útil para adaptar uma imagem reclassificada de acordo com as necessidades das capacidades de tons de preto de um sistema de renderização (isto é, uma tela em um ambiente de visualização), e dependente de tais fatores (os quais, por exemplo, um fabricante de tela pode usar no processamento interno na TV, ou comunicar os dados para um STB ou computador de pré-processamento, etc.), em particular, fatores como a típica luz de vazamento de retroiluminação quando um pixel de LCD é controlado como completamente fechado, ou um embaçamento na placa frontal da tela correspondendo a uma quantidade específica de iluminância da sala de visualização, etc. O leitor deve entender que com a classificação, existe o que se poderia ver como uma situação teórica. Supondo-se que a classificação mestra tenha sido feita em uma tela HDR específica no lado de criação (que se tornará a tela de referência para as imagens HDR mestras comunicadas). Em particular, se a tela de classificação não puder renderizar uma luminância mais brilhante que seu PB_ref_grad=5000 nits, então seria de se esperar que, embora uma imagem HDR específica pudesse conter pixels de luminância mais baixa, nada na imagem teria mais de 5000 nits. De modo similar, se o classificador de criação não puder ver fielmente quaisquer luminâncias abaixo de, por exemplo, 0,01 nit, pode-se esperar que nada abaixo de 0,01 existia na imagem codificada, ou ao menos não com um significado preciso. Algumas modalidades, entretanto, poderiam derivar classificações ajustadas secundárias para telas com melhor capacidade para tons de preto do que o monitor de referência do artista que cria conteúdo, mas nosso foco aqui é um cenário mais típico que é, de outro modo: o observador no lado de recepção tem uma tela com pior comportamento de tons de preto. Se o classificador especificar com suas funções como a luminância mais brilhante irá mapear entre a imagem HDR mestra, M_HDR, e sua classificação SDR correspondente, I_SDR, então ele especificará também um comportamento ideal desejado de como deve ser a aparência desse pixel mais brilhante em uma imagem I_MDR, por exemplo, mapear para seu PB_C = 700 nits. Conforme explicado anteriormente, existe uma relação ajustável similar para todos os tons de cinza abaixo do brilho de pico, e aqui pode-se nos concentrar nos tons de preto mais pretos. Se o classificador especificar como os tons de preto mais pretos de conteúdo serão mapeados para preto SDR (geralmente 0,1 nit), ele 'também definirá algo sobre como pode-se esperar que o preto se expanda para imagens reclassificadas MDR. Ou seja, pode-se calcular um (conteúdo) preto virtual, Bvirt. É isso que se esperaria que a imagem MDR reclassificada produzisse se houvesse uma tela ideal que pudesse renderizar tons de preto incrivelmente escuros. Contudo, como mencionado anteriormente, devido a várias razões, a tela pode ser capaz de renderizar apenas um preto real, Bactl, e/ou o observador pode ser capaz de discernir apenas suficientemente bem o conteúdo de imagem até esse nível de preto. Isso exigiria um ajuste de tela adicional de ao menos as cores mais escuras da imagem em direção a e em torno do preto real.

[0308] Um bom método para isso é espalhar um pouco o deslocamento necessário, de acordo com o seguinte método:

[0309] Para propósitos de explicação, é desejável que a adaptação do nível de tons de preto ocorra depois de uma etapa de classificação fina (apenas exemplificadamente, ou depois da aplicação de uma função de mapeamento de luminância exclusiva em outra modalidade), isto é, existe uma unidade BLA, por exemplo, conforme mostrado na Figura 26, entre as unidades 2603 e a unidade de linearização 2604. Primeiramente, a unidade BLA determina o nível virtual de tons de preto Bvirt, por exemplo, com o uso do seguinte cálculo:

[0310] Bvirt=B_SDR+(B_src-B_SDR)*(PB_D- PB_L)/(PB_src-PB_L)

[0311] Neste exemplo, PB_src é o brilho de pico do conteúdo da fonte HDR, isto é, por exemplo, 1000 nits ou 5000 nits, e o brilho de pico PB_L SDR é normalmente 100 nits.

[0312] Em seguida, é determinado um delta. Delta=Bvirt-Bactl (Bactl pode ser determinado de várias maneiras, por exemplo, o fabricante pode determinar esse valor na fábrica e armazená-lo, ou ele pode ser determinado no local de visualização antes da visualização do conteúdo do vídeo, etc.).

[0313] Esse valor é convertido em um delta no espaço de luma uniformizado: Del_PU= — P_OETF(abs(Delta)/PB_D; PB_D),

[0314] Sendo P_OETF a luminância relativa para a função de alocação de código luma uniformizado conforme indicado acima na Equação 8.

[0315] Em seguida, o deslocamento real das várias possíveis luminâncias de entrada, isto é, depois de submetidas ao pré-processamento e ser fornecidas pela unidade 2603, pode ser feito, por exemplo, de acordo com a relação:

[0316] LL=P_EOTF(Pho*(1+Del_PU) - Del_PU; PB_D), [Eq.11],

[0317] Sendo EOTF a função inversa da OETF Philips, conforme descrito acima (Eq. 6).

[0318] Alternativamente, várias outras modalidades são possíveis, por exemplo, executar a BLA apenas em uma região das cores mais escuras, abaixo de, por exemplo, uma faixa de tons de preto superior delimitada, BK_D_U comunicada ou determinada pelo receptor: LL=P_EOTF[max(Pho*(1+{Del_PU/max(BK_D_U, abs(Del_PU))},Pho) - Del_PU; PB_D] etc.

[0319] A Figura 44 mostra como um exemplo de como esse ajuste pode se comportar. Aqui, é mostrado um exemplo de como uma imagem SDR pode ser convertida em uma imagem HDR ou ao menos uma imagem DR mais alta (MDR) por uma função que reduz as partes mais escuras da imagem em comparação com as mais brilhantes. A função normal a aplicar seria a função 4401, que funcionaria bem no intervalo (0,0;0,0). Como uma equação como, por exemplo, a Equação 11 acima, pode-se fazer uma curva final que tem um deslocamento para a entrada mais preta (isto é, nesta modalidade, isso seria as luminâncias codificadas para SDR correspondendo originalmente às luminâncias HDR mestras, e que precisam ser transformadas em luminâncias adequadas (suficientemente visíveis) MDR, para uma tela que tem uma renderização de tons pretos relativamente ruim. Isso fornece a função 4402. É mostrado, também, que o algoritmo poderia operar na outra direção (função 4403) redefinindo-se ligeiramente as funções, mas também outros métodos podem ser aplicados na atual estrutura técnica e filosofia para criar tons de pretos ultra adequados.

[0320] O leitor deve entender que esse comportamento de ajuste de tons de preto pode operar sem muitos detalhes do restante do ajuste de tela comportamento, por exemplo, sem o princípio de métrica orientada direcionalmente. O que, em geral, estará envolvido em uma otimização inicial da imagem MDR no caso da cor preta não ser levada em conta, isto é, por exemplo, a classificação aproximada, tratando-se, predominantemente, das limitações dos pixels mais brilhantes, e então executando-se um passe de otimização de tons de preto, em uma unidade de otimização de tons de preto.

[0321] Os componentes algorítmicos revelados neste texto podem (inteiramente ou em parte) ser realizados na prática como hardware (por exemplo, partes de um CI específico de aplicativo) ou como software executado em um processador de sinal digital especial, ou um processador genérico etc. Um produto de memória pode, por exemplo, ser uma memória portátil como um disco blu-ray ou um bastão de memória de estado sólido, mas também, por exemplo, uma memória em um servidor remoto a partir do qual vídeo ou imagem pode transferido para um local remoto de uso do vídeo ou imagem.

[0322] O versado na técnica compreenderá, a partir da presente 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 do circuito 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.

[0323] O denotação de produto de programa de computador deve ser entendida como abrangendo qualquer concretização física de um conjunto de comandos que permitem que um processador para fins genéricos ou especiais, após uma série de etapas de carga (que podem 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.

[0324] 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.

[0325] 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.

[0326] 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 aspectos não mencionados em qualquer uma das reivindicações. O artigo indefinido “um” ou “uma” antes de um elemento não exclui a presença de uma pluralidade de tais elementos.

Claims (20)

1. APARELHO DE TRANSFORMAÇÃO DE COR (201), para calcular as cores resultantes (R2, G2, B2) de pixels de uma imagem de saída (IM_MDR) que é ajustada para uma tela com um brilho de pico de tela (PB_D) a partir de cores de entrada (R,G,B) de pixels de uma imagem de entrada (Im_in) que tem um código de luma máximo correspondente a um brilho de pico de primeira imagem (PB_IM1), que é diferente do brilho de pico de tela (PB_D), sendo que o aparelho de transformação de cor é caracterizado por compreender: - uma unidade de determinação de transformação de cor (4201, 102; 2501) disposta de modo a determinar uma transformação de cor (TMF) a partir de dados de especificação de processamento de cores (MET_1) compreendendo ao menos uma função de mapeamento de luminância (CC) recebidos através de uma entrada de metadados (116), sendo que os dados de especificação de processamento de cores especificam como as luminâncias dos pixels da imagem de entrada (Im_in) devem ser convertidos em luminâncias para os pixels de uma segunda imagem (Im_RHDR) que tem, correspondendo ao seu código de luma máximo, um brilho de pico de segunda imagem (PB_IM2), que é diferente do brilho de pico de tela (PB_D) e do brilho de pico de primeira imagem (PB_IM1), e sendo que a divisão do brilho de pico de primeira imagem pelo brilho de pico de segunda imagem é maior que 2 ou menor que 1/2; - uma unidade de determinação do fator de alteração de escala (4205, 200; 1310) disposta de modo a determinar um fator multiplicativo comum resultante (gt; Ls), sendo que a unidade é disposta de modo a determinar esse fator multiplicativo comum resultante mediante as etapas de: primeiro estabelecer ao longo de uma direção predeterminada (DIR), que tem um ângulo em sentido anti-horário diferente de zero em relação à direção vertical sendo ortogonal a uma direção que abrange as luminâncias da imagem de entrada, uma métrica preestabelecida (1850, METR) para localizar os brilhos de pico de tela, e uma posição (M_PB_D) nessa métrica que corresponde ao valor do brilho de pico de tela (PB_D), sendo que a métrica começa na posição de uma diagonal representando uma função de transformação de identidade, e, segundo, estabelecer uma transformação de segunda cor (1803; F_M) para determinar ao menos luminâncias das cores resultantes (R2, G2, B2) dos pixels da imagem de saída (IM_MDR), sendo que a transformação de segunda cor está baseada na transformação de cor (TMF) e na posição (M_PB_D); e, terceiro, determinar o fator multiplicativo comum resultante (gt; Ls) com base na transformação de segunda cor (1803; F_M); e sendo que o aparelho de transformação de cor (201) compreende adicionalmente - um multiplicador de alteração de escala (114) disposto para multiplicar cada um dos três componentes de cor de uma representação de cor das cores de entrada pelo fator multiplicativo comum resultante (gt) para obter as cores resultantes (R2, G2, B2).

2. APARELHO, de acordo com a reivindicação 1, caracterizado pela direção (DIR) ser de 45 graus em sentido anti-horário a partir da direção vertical.

3. APARELHO, de acordo com a reivindicação 1 ou 2, caracterizado pelos dois pontos externos (PBEH, PBE) da métrica corresponderem a um brilho de pico (PB_H) da imagem de entrada (im_in) recebida pela imagem codificada conjuntamente pelas funções de transformação de cor de outro brilho de pico (PB_L) que pode ser reconstruída a partir daquela imagem mediante aplicação das funções de transformação de cor recebidas nos metadados compreendendo a ao menos uma função de mapeamento de matiz (CC) para ela, e sendo que o aparelho calcula uma imagem de saída (IM_MDR) para uma tela com um brilho de pico de tela (PB_D) que se situa dentro dessa faixa de brilhos de pico (PB_L para PB_H).

4. APARELHO, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pela métrica ser baseada em uma representação logarítmica dos brilhos de pico de tela.

5. APARELHO, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pela métrica ser definida em uma representação de cor perceptualmente uniformizada, como a representação de luma que pode ser obtida aplicando-se a função Y=log10(1+(rho(PB)-1)*potência(L;1/2,4))/log10(rho(PB), onde Y é um valor de luma perceptualmente uniformizado, L é uma luminância, PB é uma constante de brilho de pico e rho é um parâmetro de formatação de curva determinado com a equação rho(PB)=1+32*potência(PB/10000; 1/(2,4)).

6. APARELHO, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pela unidade de determinação do fator de alteração de escala (200) estar adicionalmente disposta de modo a obter um parâmetro de ajuste (gpr; gpm) a partir dos segundos dados de especificação de processamento de cores (MET_2) que foram determinados anteriormente no momento da criação da imagem de entrada (Im_in), e disposta de modo a calcular um fator multiplicativo comum resultante (gtu) correspondendo a uma posição na métrica diferente da posição para o brilho de pico de tela (PB_D), sendo que a posição diferente se baseia no valor do parâmetro de ajuste.

7. APARELHO, de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pela unidade de determinação do fator de alteração de escala (200) estar disposta de modo a determinar a posição diferente aplicando uma função monotônica que fornece como resultado uma posição normalizada na métrica como função de ao menos um parâmetro de entrada (gpr), sendo que a função monotônica pode ser determinada pelo aparelho de transformação de cor de modo autônomo, ou com base nos metadados de prescrição que prescrevem qual formato de função será usado, o qual foi determinado anteriormente em um momento da criação da imagem de entrada (Im_in).

8. APARELHO, de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo multiplicador de alteração de escala (114) multiplicar três componentes de cor não lineares, que são definidos como uma função de potência de seus respectivos componentes de cor lineares, como, por exemplo, componentes de cor Y’CbCr.

9. APARELHO, de acordo com qualquer uma das reivindicações 1 a 8, caracterizado por compreender uma unidade de análise de imagens (1110) disposta de modo a analisar as cores de objetos na imagem de entrada (Im_in), e, a partir daí, determinar um valor para ao menos um dos parâmetros que controlam o cálculo da imagem de saída (IM_MDR), por exemplo, o parâmetro de ajuste (gpm), ou a direção (DIR), ou o formato da função monotônica que fornece como saída uma posição normalizada na métrica a ser usada no cálculo do fator multiplicativo comum resultante (gt).

10. APARELHO, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado por compreender uma unidade de determinação da quantidade de corte (3710) disposta de modo a determinar uma quantidade mínima de corte abrupto (“hard clipping”) aplicada ao brilho de pico de tela (PB_D) para uma subfaixa das luminâncias mais brilhantes da imagem de entrada (Im_in), sendo que o cálculo do fator multiplicativo comum resultante (gt) é determinado para luminâncias da imagem de entrada dentro da subfaixa para mapear a luminância de entrada para o brilho de pico de tela (PB_D).

11. APARELHO, de acordo com qualquer uma das reivindicações 1 a 10, em que o cálculo do fator multiplicativo comum resultante (gt) é baseado em uma função de mapeamento de luminância aproximado (Fcrs) e uma função de mapeamento de luminância fino (CC), sendo o aparelho de transformação de cor caracterizado por uma função de mapeamento aproximado otimizada (FCrs_opt) ser primeiramente determinada com base em pelo menos o brilho de pico de tela (PB_D) para se determinar subfaixas ideais das luminâncias que correspondem à situação real da tela de renderização, e esse mapeamento aproximado é aplicado à imagem de entrada produzindo lumas aproximados (Y’CG), e por uma função de mapeamento fino ser então otimizada com base na função de mapeamento de luminância fino (CC) e ao menos no brilho de pico de tela (PB_D), e essa função de mapeamento fino ser aplicada aos lumas aproximados.

12. APARELHO, de acordo com a reivindicação 11, caracterizado pelos mapeamentos de luminância aproximado e fino correspondendo ao brilho de pico de tela serem determinados ao longo de uma métrica (1850) com uma direção (DIR) diferente, sendo que o mapeamento aproximado é executado diagonalmente e o mapeamento fino verticalmente.

13. APARELHO, de acordo com qualquer uma das reivindicações 1 a 12, caracterizado por compreender uma unidade de estimativa de nível de tons de preto (3702) para estabelecer uma estimativa de um nível de tons de preto de uma tela, sendo que o cálculo do fator multiplicativo comum resultante (gt) depende do nível de tons de preto.

14. APARELHO, de acordo com a reivindicação 13, caracterizado por uma função de mapeamento de luminância ser primeiramente estabelecida de acordo com uma situação de visualização de referência com um nível de iluminação fixo, e subsequentemente essa função ser ajustada para o valor do nível de tons de preto, sendo que a partir da função ajustada o fator multiplicativo comum resultante (gt) é calculado.

15. DECODIFICADOR DE IMAGEM HDR, caracterizado por compreender um aparelho de transformação de cor (201), conforme definido em qualquer uma das reivindicações 1 a 14.

16. MÉTODO PARA CALCULAR CORES RESULTANTES (R2, G2, B2), de pixels de uma imagem de saída (IM_MDR) que é ajustada para uma tela com um brilho de pico de tela (PB_D) a partir de cores de entrada (R,G,B) de pixels de uma imagem de entrada (Im_in) que tem um código de luma máximo correspondente a um brilho de pico de primeira imagem (PB_IM1) que é diferente do brilho de pico de tela (PB_D), sendo que o método é caracterizado por compreender: - determinar uma transformação de cor (TMF) a partir de dados de especificação de processamento de cores (MET_1) compreendendo ao menos uma função de mapeamento de luminância (CC) recebidos através de uma entrada de metadados (116), sendo que os dados de especificação de processamento de cores (MET_1) especificam como as luminâncias dos pixels da imagem de entrada (Im_in) devem ser convertidos em luminâncias para os pixels de uma segunda imagem (Im_RHDR) que tem, correspondendo ao seu código de luma máximo, um brilho de pico de segunda imagem (PB_IM2), que é diferente do brilho de pico de tela (PB_D) e do brilho de pico de primeira imagem (PB_IM1), e sendo que a divisão do brilho de pico de primeira imagem pelo brilho de pico de segunda imagem é maior que 2 ou menor que 1/2; - determinar um fator multiplicativo comum resultante (gt; Ls) mediante as etapas de: a) estabelecer ao longo de uma direção predeterminada (DIR), que tem um ângulo em sentido anti-horário diferente de zero em relação à direção vertical sendo ortogonal a uma direção que abrange as luminâncias da imagem de entrada, uma métrica preestabelecida (1850, METR), e uma posição (M_PB_D) nessa métrica que corresponde ao valor do brilho de pico de tela (PB_D), sendo que a métrica começa na posição de uma diagonal entre os eixos de luminância de entrada e de saída, b) estabelecer uma transformação de segunda cor (1803; F_M) para determinar ao menos luminâncias das cores resultantes (R2, G2, B2) dos pixels da imagem de saída (IM_MDR), sendo que a transformação de segunda cor está baseada na transformação de cor (TMF) e na posição (M_PB_D), e c) calcular o fator multiplicativo comum resultante (gt; Ls) com base na transformação de segunda cor (1803; F_M); e - multiplicar cada um dos três componentes de cor de uma representação de cor das cores de entrada pelo fator multiplicativo comum resultante (gt) para obter as cores resultantes (R2, G2, B2).

17. MÉTODO, de acordo com a reivindicação 16, caracterizado pela direção (DIR) ser de 45 graus em sentido anti-horário a partir da direção vertical.

18. MÉTODO, de acordo com a reivindicação 16, caracterizado pela métrica ser baseada em uma representação logarítmica dos brilhos de pico de tela.

19. MÉTODO, de acordo com a reivindicação 16, caracterizado pelo cálculo da posição (M_PB_D) depender do cálculo de um fator de escala (SS) que é igual a ((B-1)/(B+1)) / ((A-1)/(A+1)), em que A é um valor de saída de uma função logarítmica predeterminada cujo formato é determinado pelo brilho de pico da segunda imagem, quando, como entrada, é usada uma luminância relativa que é igual ao valor do brilho de pico da primeira imagem dividido pelo brilho de pico da segunda imagem, e sendo que B é um valor de saída da função logarítmica predeterminada cujo formato é determinado pelo brilho de pico da tela, quando, como entrada, é usada uma luminância relativa que é igual ao valor do brilho de pico de primeira imagem dividido pelo brilho de pico de tela.

20. MÉTODO, de acordo com a reivindicação 16, caracterizado por uma segunda posição (M_PB_D2) ser determinada para ao menos algumas luminâncias de entrada, que não é igual à posição (M_PB_D).