Formato de imagem Ultra HDR v1.1

Introdução

Neste documento, definimos o comportamento de um novo formato de arquivo que codifica uma imagem do mapa de ganho de intervalo logarítmico em um arquivo de imagem JPEG. Leitores legados que não têm suporte ao novo formato leem e exibem a imagem convencional de gama dinâmica baixa do arquivo de imagem. Os leitores compatíveis com o formato combinam a imagem principal com o mapa de ganho e renderizam uma imagem de alto alcance dinâmico em telas compatíveis.

O restante deste documento descreve os métodos dos processos necessários para usar esse formato. De modo geral, o ciclo de vida de uma imagem que obedece a esse formato é o seguinte:

1. Codificação

   1. Geração de mapa de ganho
   2. Conseguir compactação de mapas
   3. Obter a geração de contêineres de mapa

2. Decodificação

Figura 1. Exemplo de layout de arquivo e metadados relevantes.

Motivação

O objetivo desse formato de arquivo é codificar informações adicionais em arquivos de imagem SDR que podem ser usados em combinação com a técnica de exibição para produzir as renderizações HDR ideais em um único arquivo.

Para que isso seja prático, o formato do arquivo precisa:

• Ser compatível com versões anteriores para que, entre espectadores simples, a imagem SDR convencional seja exibida.
• Não ocupe muito espaço extra.

Além disso, a técnica de exibição precisa:

• Não exigem processamento pesado para decodificação.
• Adaptar-se a qualquer proporção entre os pontos brancos de HDR e SDR de uma tela, que podem variar significativamente entre dispositivos ou até mesmo temporariamente em um único dispositivo.

Por fim, a técnica precisa ser capaz de realizar todas as ações anteriores sem:

• Clipe de destaques.
• Trituração de sombras.
• Alterar ou compactar o contraste local.
• Alterar relações tonais relativas (entre objetos na cena).

Dependências

Confira a seguir as referências normativas para esta especificação:

• Especificação do Adobe XMP Parte 3: armazenamento em arquivos
• ISO 16684-1:2019 XMP Specification Part 1
• Formato de arquivo de mídia base ISO ISO/IEC 14496-12
• T.81 (09/92) Compressão e codificação digital de imagens estáticas em tons contínuos
• Documento técnico do formato de várias imagens da CIPA DC-x 007-2009

Definições

• Tela SDR

  • Uma tela convencional, não projetada para exibir conteúdo HDR. Essas telas geralmente produzem um brilho máximo nominal de cerca de 400 cd/m² ou menos.

• Tela HDR

  • Uma tela projetada para conteúdo HDR. Essas telas normalmente produzem um pico de brilho nominal maior que o de uma tela SDR, geralmente 800 cd/m² ou mais, e normalmente também têm taxas de contraste melhores do que as telas SDR.

• Imagem principal

  • A primeira instância de uma imagem em um arquivo GContainer com arquivos de mídia secundários anexados. A imagem principal contém metadados XMP do GContainer que definem a ordem e as propriedades dos arquivos de itens de mídia secundários no contêiner de arquivos.

• Imagem secundária

  • Arquivos de itens de mídia subsequentes anexados à imagem principal em um arquivo GContainer.

• Compactação de intervalo

  • Na fotografia, as cenas do mundo real geralmente têm mais alcance dinâmico do que uma tela SDR pode representar. Operações como a compactação de faixa, também chamada de mapeamento de tom local, são necessárias para reduzir a faixa dinâmica de uma imagem. Essa redução precisa evitar recorte de destaques ou sombras esmagadoras, preservando o contraste local o máximo possível. Você tenta reduzir o tamanho das bordas de luminância grandes na imagem, que contribuem mais para o contraste global, enquanto tenta preservar o tamanho das bordas de luminância pequenas, que são os detalhes.Embora existam muitas implementações diferentes, essa operação é padrão na maioria das câmeras digitais modernas atualmente.

• Ponto branco SDR

  • É a luminância linear máxima do conteúdo SDR em uma tela em um determinado momento.

• Ponto branco em HDR

  • É a luminância linear máxima do conteúdo HDR em uma tela em um determinado momento. Esse valor geralmente é maior que o ponto branco SDR.

• Aumentar

  • O ponto branco HDR dividido pelo ponto branco SDR.

• Aumento máximo de conteúdo (max_content_boost nas equações)

  • Com esse valor, o criador de conteúdo restringe o nível de brilho de uma imagem em relação à reprodução em SDR.
  • Esse valor é uma constante para uma imagem específica. Por exemplo, se o valor for quatro, para qualquer pixel, a luminância linear da representação HDR exibida precisa ser, no máximo, 4 vezes a luminância linear da representação SDR. Na prática, isso significa que as partes mais claras da cena podem ser mostradas até quatro vezes mais brilhantes.
  • Na prática, esse valor geralmente é maior que 1,0.
  • Sempre maior ou igual a Valor mínimo de otimização de conteúdo.

• Otimização mínima do conteúdo (min_content_boost nas equações)

  • Esse valor permite que o criador de conteúdo restrinja o quanto uma imagem pode ficar mais escura quando exibida em uma tela HDR, em relação à renderização SDR.Esse valor é uma constante para uma determinada imagem.
  • Se, por exemplo, o valor for 0,5, para qualquer pixel, a luminância linear da renderização HDR exibida precisa ser (pelo menos) 0,5x a luminância linear da renderização SDR.
  • Na prática, esse valor costuma ser igual ou apenas menor que 1,0.
  • Sempre menor ou igual ao Aumento máximo de conteúdo.

• Aumento máximo de tela (max_display_boost nas equações)

  • A otimização máxima disponível para uma tela em um determinado momento. Esse valor pode mudar ao longo do tempo com base nas configurações do dispositivo e em outros fatores, como condições de luz ambiente ou a quantidade de pixels brilhantes na tela.
  • Por exemplo, se esse valor for 4,0, a tela poderá exibir um pixel com até quatro vezes mais brilho do que o ponto branco SDR. Esse valor é sempre >= 1,0, já que a tela sempre pode exibir o branco HDR pelo menos tão brilhante quanto o branco SDR.

• Otimização da Rede de Display

  • Igual ao menor aumento máximo de conteúdo e de exibição. Esse valor é sempre >= 1,0.
  • Por exemplo, se a otimização de conteúdo máxima for de 4,0 e a otimização máxima de exibição for 3,0, a otimização de tela será de 3,0. Os pixels são exibidos até três vezes mais brilhantes que o SDR, já que os recursos da tela são o fator limitante.
  • Em outro exemplo, se a otimização máxima do conteúdo for 4,0 e a otimização máxima da tela for 5,0, a otimização da tela será 4,0. Os pixels são mostrados até quatro vezes mais brilhantes que o SDR, já que a intenção do conteúdo é o fator limitante.

• Renderização HDR desejada

  • A execução ideal em HDR, de acordo com o criador de conteúdo.

• Renderização HDR adaptada

  • É a execução final em HDR mostrada na tela, após adaptar a renderização de HDR de destino para a otimização atual da tela.

• Mapa de ganho (recovery(x, y) nas equações)

  • Um mapa que indica o quanto iluminar cada pixel, na renderização SDR, para produzir a renderização HDR de destino. Esse mapa pode ser de canal único ou multicanal. Um mapa multicanal indica um ganho separado para cada canal de cor, como vermelho, verde e azul. Este documento ilustra o caso de um mapa de canal único.

• clamp(x, a, b)

  • Fixe o valor x no intervalo [a, b].

• exp2(x)

  • Exponenciação de base 2; 2^x.

• floor(x)

  • Retorna o número inteiro mais próximo igual ou menor que x.

• log2(x)

  • logaritmo de base 2; log₂(x)

• pow(b, x)

  • Exponenciação: b^x.

• XMP

  • Plataforma de metadados extensível. Um padrão que define um método para codificar metadados em um contêiner de imagem; definido pela ISO 16684-1:2011(E) XMP Specification Part 1.

• Formato multiimagem

  • O formato de multi-imagens é uma técnica desenvolvida pela Associação de Produtos de Câmeras e Imagens (CIPA, na sigla em inglês) para armazenar várias imagens codificadas em JPEG em um único arquivo JPEG.
  • Para mais informações, consulte a dependência relacionada, Artigo sobre o formato CIPA DC-x 007-2009.

• GContainer

  • O GContainer é um método para armazenar várias imagens em um contêiner de imagens, em que uma imagem é considerada a principal. Todas as imagens adicionais são consideradas versões alternativas ou auxiliares. Os metadados XMP são usados para comunicar a presença e o significado de qualquer imagem adicional. Para mais informações, consulte a seção Detalhes do GContainer.

Codificação

Esta seção descreve como codificar um arquivo JPEG compatível. Consulte T.81 (09/92) Compactação e codificação digital de imagens estáticas de tons contínuos, na seção "Dependências" para mais informações sobre o formato JPEG.

Gerar mapas

Os pipelines de imagem da câmera geralmente executam uma operação de compactação de faixa para compactar dados de luminância de faixa dinâmica mais alta para a faixa mais baixa de telas SDR convencionais. O mapa de ganho oferece um mecanismo para armazenar dados suficientes para recuperar os dados originais de luminância de intervalo dinâmico mais alto.

Os cálculos a seguir nesta seção pressupõem a aritmética de ponto flutuante.

Observação: para ilustrar as fórmulas abaixo, este documento pressupõe que você esteja usando um mapa de ganho de canal único. Caso contrário, as fórmulas relacionadas a essas propriedades podem ser extrapoladas para cada canal de cor. Você pula a conversão de SDR(x, y) e HDR(x, y) para Ysdr(x, y) e Yhdr(x, y), respectivamente, e define pixel_gain(x, y) como uma função de vetor relativa a SDR(x, y) e HDR(x, y). Você também usa valores de metadados por canal, conforme necessário. Use um mapa de ganho de canal único sempre que possível.

As funções a seguir descrevem a imagem SDR:

• SDR'(x, y) é a imagem principal de três canais, não linear (geralmente codificada em gama).
• SDR(x, y) é a versão linear da imagem principal de três canais, obtida pela transformação em uma versão linear do espaço de cores da imagem principal. Por exemplo, de um espaço de cores com uma função de transferência sRGB para um espaço de cores linear que preserva cores primárias sRGB.

A função Ysdr(x, y) é definida no intervalo de 0,0 a 1,0 e é a luminância linear da imagem principal do intervalo dinâmico padrão:

Ysdr(x, y) = primary_color_profile_to_luminance(SDR(x, y))

Existem definições semelhantes para a imagem HDR.

• HDR'(x, y) é a não linear de três canais, ou seja, uma imagem codificada por PQ ou HLG.
• HDR(x, y) é a imagem HDR linear de três canais.

Yhdr(x, y) é a luminância em um determinado ponto da imagem HDR:

Yhdr(x, y) = primary_color_profile_to_luminance(HDR(x, y))

Yhdr(x, y) é definido no intervalo de 0,0 até a otimização máxima do conteúdo.

As imagens SDR e HDR precisam ter a mesma resolução. O perfil de cor da imagem SDR define o espaço de cores da imagem HDR.

Por exemplo, se a imagem principal do SDR tiver um perfil de cores Display-P3, a imagem HDR será definida em relação às cores primárias desse perfil. Isso significa que a imagem HDR também tem cores primárias do Display-P3.

O mapa de ganho é calculado com base em duas imagens lineares que contêm a luminância da imagem HDR desejada, Yhdr(x, y), e a imagem de luminância do intervalo padrão, Ysdr(x, y).

A função pixel_gain(x, y) é definida como a proporção entre as funções Yhdr(x, y) e Ysdr(x, y):

pixel_gain(x, y) = (Yhdr(x, y) + offset_hdr) / (Ysdr(x, y) + offset_sdr)

O comportamento da função pixel_gain(x, y), em que Ysdr(x, y) e offset_sdr são zero, é definido pela implementação.

Por exemplo, as implementações podem processar o caso em que Ysdr(x, y) e offset_sdr são zero definindo pixel_gain(x, y) como 1.0. Como alternativa, as implementações também evitam esse cenário usando um offset_sdr diferente de zero.

A implementação pode escolher os valores de offset_sdr e offset_hdr.

Dica: use um valor de 0,015625 (1/64) para offset_sdr e offset_hdr. O objetivo desses valores é equilibrar a capacidade de aumentar aproximação de pretos com a capacidade de codificar precisamente valores de ganho menores. Aumentar esses valores de deslocamento aumenta a capacidade de recuperação perto de pretos, mantendo um valor razoável para map_max_log2. Aumentar demais os valores pode reduzir a precisão do mapa.

O mapa de ganho é uma função escalar que codifica pixel_gain(x, y) em um espaço logarítmico, em relação ao aumento máximo e mínimo de conteúdo:

map_min_log2 = log2(min_content_boost)
map_max_log2 = log2(max_content_boost)

log_recovery(x, y) = (log2(pixel_gain(x, y)) - map_min_log2)
                   / (map_max_log2 - map_min_log2)
clamped_recovery(x, y) = clamp(log_recovery(x, y), 0.0, 1.0)
recovery(x, y) = pow(clamped_recovery(x, y), map_gamma)

O comportamento da função recovery(x, y) em que pixel_gain(x, y) é zero é definido pela implementação, porque log2(0) é indefinido.

Dica: defina recovery(x, y) como 0,0, em que pixel_gain(x, y) é zero. Isso ocorre porque recovery(x, y) de 0,0 representa a maior atenuação possível que pode ser armazenada no mapa de ganho.

map_gamma é um número de ponto flutuante que precisa ser maior que 0,0 e é escolhido pela implementação.

Dica: use um map_gamma de 1,0. É possível usar um valor diferente se o mapa de ganho tiver uma distribuição muito desigual de valores de log_recovery(x, y). Por exemplo, isso pode ser aplicado se um mapa de ganho tiver muitos detalhes logo acima do intervalo SDR (representado como valores log_recovery(x, y) pequenos) e um map_max_log2 muito grande na extremidade superior do brilho desejado da renderização em HDR (representado por valores log_recovery(x, y) grandes). Nesse caso, é possível usar um map_gamma maior que 1,0 para que recovery(x, y) possa codificar com precisão os detalhes nos limites inferior e superior de log_recovery(x, y).

Os valores de otimização máxima e mínima de conteúdo são definidos pela implementação e podem ser decididos arbitrariamente pelo criador do conteúdo. O aumento máximo de conteúdo precisa ser maior ou igual a 1,0. O aumento mínimo de conteúdo precisa estar no intervalo (0,0, 1,0].

Observação: por exemplo, digamos que a imagem venha de uma câmera e que o pipeline de processamento de imagem gere a imagem SDR realizando a compactação de intervalo em uma entrada de intervalo dinâmico mais alto. Assim, a otimização máxima e mínima de conteúdo podem ser funções da quantidade de compactação de intervalo realizada e das regiões de luminância afetadas.

Esses pipelines podem escolher uma otimização mínima de conteúdo de 1,0 se não quiserem codificar nenhuma atenuação da imagem HDR em relação à imagem SDR. Como alternativa, se você gerar o mapa de ganho com base nas versões SDR e HDR, a otimização máxima e mínima de conteúdo poderão ser determinadas com base nos ganhos máximo e mínimo necessários para converter entre as duas execuções.

Os criadores ou editores de conteúdo também podem ajustar a otimização máxima para controlar a diferença máxima permitida entre a luminância SDR e HDR quando a imagem é mostrada.

Os valores em recovery(x, y) são limitados ao intervalo [0,0, 1,0].

Observação: as áreas mais claras da imagem normalmente têm valores de recovery(x, y) próximos de 1,0, enquanto as áreas mais escuras da imagem têm valores em torno de 0,0.

O mapa de ganho é armazenado em um JPEG de imagem secundário e, portanto, precisa ser codificado usando valores inteiros não assinados de 8 bits, portanto, no intervalo [0, 255]. Cada valor representa um valor recovery(x, y) e é armazenado em um pixel da imagem secundária.

Para armazenamento de números inteiros não assinados de 8 bits, o valor codificado é definido da seguinte forma:

encoded_recovery(x, y) = floor(recovery(x, y) * 255.0 + 0.5)

O cálculo da função de codificação é feito em ponto flutuante e convertido no final para o resultado de número inteiro não assinado de 8 bits por arredondamento conforme indicado.

Essa codificação resulta em uma representação de número inteiro não assinado de 8 bits de valores recovery(x, y), de 0,0 a 1,0. O mapa de ganho codificado precisa ser armazenado em um item de imagem secundário como JPEG. A implementação escolhe a quantidade de compressão a ser usada durante a codificação JPEG.

Dica: comece com um parâmetro de qualidade do algoritmo JPEG definido pela implementação de 85 a 90 de 100 ou algo semelhante para a maioria das implementações de codificação JPEG.

Depois que o mapa de ganho é armazenado em uma imagem secundária, ele é anexado a uma imagem principal com metadados XMP do MPF e do GContainer. O diretório GContainer da imagem principal precisa conter um item para a imagem do mapa de ganho.

A resolução do mapa de ganho armazenado é definida pela implementação e pode ser diferente da resolução da imagem principal. Caso o mapa de ganho seja dimensionado para uma resolução diferente da imagem principal para armazenamento, o método de amostragem precisa ser bilinear ou superior, e tem a implementação definida.

Dica :reduza a amostragem do mapa de ganhos para 1⁄16 do tamanho (1⁄4 em cada dimensão) da imagem principal antes do armazenamento, como um mapa de ganho de 480 x 270 para uma imagem principal de 1920 x 1080. O mapa de ganho precisa ter uma proporção semelhante à imagem principal.

A orientação do mapa de ganho precisa corresponder à da imagem principal. Se presente, nenhum metadado de orientação na imagem do mapa de ganho armazenada, como em EXIF, não será usado.

Se presente, o perfil de cor do mapa de ganho não será usado.

Coletar contêiner do mapa

Perfil de cor

O perfil de cor da imagem precisa ser indicado por um perfil ICC para a imagem principal.

Dica: use um perfil de cores Display-P3.

Atributos XMP

A imagem principal contém metadados XMP para definir pelo menos duas imagens com informações semânticas extras para o formato do mapa de ganho HDR.

As subseções a seguir contêm detalhes específicos desse formato. Outras informações sobre a conformidade geral com o GContainer estão especificadas na seção Detalhes do GContainer.

Os valores de atributo descritos nas tabelas a seguir são armazenados como valores simples do XMP dos tipos de valor básicos especificados.

Valores semânticos do item

A propriedade Item:Semantic define o significado específico do aplicativo de cada item de mídia no diretório do contêiner.

Valor	Descrição
Principal	Indica que o item de mídia é a imagem principal, pronta para exibição, no contêiner. O diretório precisa conter um item "Principal".
GainMap	Indica que o item de mídia é um mapa de ganho. O diretório pode conter no máximo um item "GainMap".

Metadados do mapa de ganho de HDR

Os metadados do mapa de ganho codificam informações sobre como interpretar e aplicar o mapa de ganho para produzir a representação HDR da imagem principal.

O URI do namespace XMP para a extensão XMP de metadados do mapa de ganho é http://ns.adobe.com/hdr-gain-map/1.0/. O prefixo de namespace padrão é hdrgm.

Esses metadados são armazenados no pacote XMP da imagem do mapa de ganho, e as seguintes propriedades precisam aparecer no rdf:Description do XMP da imagem do mapa de ganho:

Nome	Tipo	Descrição
hdrgm:Version	Texto	A versão do formato de mapa de ganhos em uso. Essa versão é "1.0". Obrigatório.
hdrgm:BaseRenditionIsHDR	Booleano	Indica o intervalo dinâmico da imagem principal. "Falso" indica que a imagem principal é SDR e o mapa de ganho pode ser combinado com ela para produzir uma execução em HDR. "True" indica que a imagem principal é HDR e o mapa de ganho pode ser combinado com ela para produzir a reprodução em SDR. Precisa ser "Falso". Opcional. O valor padrão é "Falso".
hdrgm:GainMapMin	Matriz real ou ordenada de reais	Armazena os valores de map_min_log2. Isso é log2 da otimização de conteúdo mínima, que é a proporção mínima permitida de luminância linear para a renderização HDR de destino em relação à (dividida por) a imagem SDR em um determinado pixel. Pode ser um real único ou uma matriz ordenada de reais. Quando uma matriz ordenada de valores reais, ela pode conter um item que se aplica a todos os canais ou três itens para os canais vermelho, verde e azul, respectivamente. Precisa ser menor ou igual a hdrgm:GainMapMax. Opcional.O valor padrão é 0,0.
hdrgm:GainMapMax	Matriz de reais reais ou ordenados	Armazena os valores de map_max_log2. Isso é log2 do aumento máximo de conteúdo, que é a proporção máxima permitida da luminância linear para a renderização HDR de destino em relação a (dividida por) a da imagem SDR, em um determinado pixel. Pode ser um real único ou uma matriz ordenada de reais. Quando uma matriz ordenada de reais pode conter um item que se aplica a todos os canais ou três itens para os canais vermelho, verde e azul, respectivamente. Precisa ser maior ou igual a hdrgm:GainMapMin. Obrigatório.
hdrgm:Gama	Matriz real ou ordenada de reais	Armazena os valores de map_gamma. Essa é a gama a ser aplicada aos valores de mapa armazenados. Pode ser um real único ou uma matriz ordenada de reais. Quando uma matriz ordenada de valores reais, ela pode conter um item que se aplica a todos os canais ou três itens para os canais vermelho, verde e azul, respectivamente. Precisa ser maior que 0,0. Opcional. O valor padrão é 1.0.
hdrgm:offsetSDR	Matriz de reais reais ou ordenados	Armazena os valores de offset_sdr. Esse é o deslocamento a ser aplicado aos valores de pixel SDR durante a geração e aplicação do mapa de ganho. Pode ser um único Real ou uma matriz ordenada de Reals. Quando uma matriz ordenada de reais pode conter um item que se aplica a todos os canais ou três itens para os canais vermelho, verde e azul, respectivamente. Precisa ser 0,0 ou maior. Opcional.O valor padrão é 0,015625 (1/64).
hdrgm:offsetHDR	Matriz de reais reais ou ordenados	Armazena os valores de offset_hdr. Esse é o deslocamento a ser aplicado aos valores de pixel HDR durante a geração e aplicação do mapa de ganho. Pode ser um real único ou uma matriz ordenada de reais. Quando uma matriz ordenada de reais pode conter um item que se aplica a todos os canais ou três itens para os canais vermelho, verde e azul, respectivamente. Precisa ser 0,0 ou maior. Opcional.O valor padrão é 0,015625 (1/64).
hdrgm:HDRCapacityMin	Reais	Armazena o valor de hdr_capacity_min. Esse é o log2 do valor mínimo do aumento de exibição para o qual o mapa é aplicado. Esse valor também afeta o quanto o mapa de ganho precisa ser aplicado com base na otimização da tela. Precisa ser 0,0 ou maior. Opcional. O valor padrão é 0,0.
hdrgm:HDRCapacityMax	Real	Armazena o valor de hdr_capacity_max. Esse é o log2 do valor máximo da otimização de exibição para o qual o mapa é completamente aplicado. Esse valor também afeta o quanto o mapa de ganho precisa ser aplicado com base na otimização da tela. Precisa ser maior que hdrgm:HDRCapacityMin. Obrigatório.

Dica :sempre que possível, use apenas um valor real para cada propriedade anterior que permita um valor ou uma matriz de valores, com um para cada canal de cor. Defina HDRCapacityMax como GainMapMax e HDRCapacityMin como o maior de GainMapMin ou 0,0. O restante deste documento pressupõe que você esteja usando um único valor real para todas as propriedades que possam ter uma matriz de valores reais. As fórmulas sobre essas propriedades podem ser extrapoladas para cada canal de cor quando não for esse o caso na prática.

Exemplo de XMP do mapa de ganho

O exemplo a seguir de um pacote XMP de mapa de ganho válido contém metadados retirados do arquivo de exemplo ilustrado na seção Introdução.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0"
     hdrgm:GainMapMin="-0.57609993"
     hdrgm:GainMapMax="4.7090998"
     hdrgm:Gamma="1"
     hdrgm:OffsetSDR="0.015625"
     hdrgm:OffsetHDR="0.015625"
     hdrgm:HDRCapacityMin="0"
     hdrgm:HDRCapacityMax="4.7090998"
     hdrgm:BaseRenditionIsHDR="False"/>
  </rdf:RDF>
</x:xmpmeta>

Armazenamento de MPF do mapa de ganho

A imagem do mapa de ganho precisa ser armazenada como uma imagem extra, conforme definido no Formato CIPA DC-x 007-2009 Multi-Picture, conforme referenciado na seção Dependências.

Decodificação

Esta seção descreve como decodificar o mapa de ganho de um arquivo JPEG em conformidade.

Indicador do formato

Um arquivo JPEG em conformidade com esse formato pode ser identificado pela presença de hdrgm:Version="1.0" no pacote XMP da imagem principal, em que hdrgm é o URI do namespace http://ns.adobe.com/hdr-gain-map/1.0/.

Localize a imagem do mapa de ganho

Para detalhes sobre como analisar e decodificar a imagem, consulte a seção Detalhes do GContainer a seguir. Um item semântico "GainMap" no XMP rdf:Directory é usado para indicar o local de uma imagem do mapa de ganho. Como alternativa, o IFD do índice de MPF e a verificação do XMP das imagens são usados para determinar o local de um mapa de ganho.

Processar metadados inválidos

Os metadados são considerados inválidos se um campo obrigatório não estiver presente ou se houver algum campo com um valor inválido. Um valor pode ser inválido porque não pode ser analisado para o tipo especificado ou porque está fora do intervalo esperado.

Se metadados inválidos forem encontrados, o mapa de ganho será ignorado e a imagem SDR será exibida.

Tela

Os arquivos codificados no formato de mapa de ganho em HDR podem ser renderizados em telas SDR convencionais ou em HDR com saída de maior luminância.

Use o mapa de ganho para criar a execução adaptada de HDR

Os cálculos a seguir nesta seção pressupõem a aritmética do ponto flutuante.

encoded_recovery(x, y) é o valor inteiro de 8 bits de um único canal da imagem do mapa de ganho.

Se o mapa de ganho tiver uma resolução diferente da imagem principal, encoded_recovery(x, y) será determinado por uma amostragem filtrada da imagem do mapa de ganho para x e y no intervalo da largura e altura da imagem principal, respectivamente. O método de filtragem precisa ser bilinear ou melhor e é definido pela implementação.

map_gamma é determinado pelo campo de metadados hdrgm:Gamma.

log_recovery(x, y) é o ganho de pixel de ponto flutuante normalizado em um espaço logarítmico:

recovery(x, y) = encoded_recovery(x, y) / 255.0
log_recovery(x, y) = pow(recovery(x, y), 1.0 / map_gamma)

O aumento máximo de tela é um valor escalar de ponto flutuante definido como a proporção entre o ponto branco HDR atual e dividido pelo ponto branco SDR atual. Esse valor é fornecido pelo sistema de exibição e pode mudar com o tempo.

hdr_capacity_max é determinado pelo campo de metadados hdrgm:HDRCapacityMax. hdr_capacity_min é determinado pelo campo de metadados hdrgm:HDRCapacityMin.

weight_factor é determinado da seguinte maneira quando hdrgm:BaseRenditionIsHDR é "Falso":

unclamped_weight_factor = (log2(max_display_boost) - hdr_capacity_min)
                        / (hdr_capacity_max - hdr_capacity_min)
weight_factor = clamp(unclamped_weight_factor, 0.0, 1.0)

Quando hdrgm:BaseRenditionIsHDR é "True", a segunda equação é:

weight_factor = 1.0 - clamp(unclamped_weight_factor, 0.0, 1.0)

gain_map_max é determinado pelo campo de metadados hdrgm:GainMapMax. gain_map_min é determinado pelo campo de metadados hdrgm:GainMapMin. offset_sdr é determinado pelo campo de metadados hdrgm:OffsetSDR. offset_hdr é determinado pelo campo de metadados hdrgm:OffsetHDR.

A renderização HDR adaptada linear pode ser calculada da seguinte maneira:

log_boost(x, y) = gain_map_min * (1.0f - log_recovery(x, y))
                + gain_map_max * log_recovery(x, y)
HDR(x, y) = (SDR(x, y) + offset_sdr) * exp2(log_boost(x, y) * weight_factor)
          - offset_hdr

Se necessário, a implementação pode aplicar uma transformação a HDR(x, y) para colocar os dados no espaço esperado pela tela. Todas essas transformações precisam ser corretas em termos de colorimetria.

Observação: o mapa de ganho precisa ser aplicado conforme mostrado anteriormente (usando a exponenciação) para produzir adequadamente as relações tonais relativas necessárias (entre áreas de brilhos diferentes na imagem) em qualquer aumento de exibição desejado.Se o Gain Map for aplicado de outra maneira, como por interpolação linear simples, as relações tonais relativas na imagem vão ficar corretas apenas na otimização máximo de conteúdo e serão comprometidas por outros fatores de otimização.

O método descrito para recuperar a execução adaptada de HDR significa que os resultados de exibição fazem a transição perfeita à medida que o aumento máximo da tela muda. Esse método sempre produz um resultado de exibição que corresponde o máximo possível à intenção do criador de conteúdo e que atende a todos os requisitos de qualidade da imagem enumerados na seção Motivação.

A quantidade de atenuação aplicada nos casos em que o aumento mínimo de conteúdo é menor que 1,0 também é dimensionada com base na relação entre o aumento máximo de exibição e o aumento máximo de conteúdo. Por exemplo, se a otimização de conteúdo máxima for 4,0, a otimização mínima de conteúdo for 0,5 e a otimização máxima de exibição for 2,0, a atenuação máxima da imagem mostrada será 0,7071, em vez de 0,5 se a otimização máxima da tela for 4,0 ou mais.

Detalhes do GContainer

Esta seção especifica outros requisitos para que esse formato esteja em conformidade com os metadados XML do GContainer. Os metadados são serializados de acordo com a ISO 166841:2011(E) XMP Specification Part 1 e incorporados no arquivo de imagem principal, conforme descrito na Adobe XMP Specification Part 3 Storage in Files. O arquivo de imagem principal contém os itens a seguir, formatados como RDF/XML.

Requisitos de pacotes XMP

O pacote XMP precisa incluir a extensão XMP de metadados do mapa de ganho pelo URI de namespace http://ns.adobe.com/hdr-gain-map/1.0/. O prefixo do namespace padrão é hdrgm.

O pacote XMP precisa definir hdrgm:Version="1.0".

Elemento Container

O namespace XMP para a extensão GContainer XMP é http://ns.google.com/photos/1.0/container/. O prefixo de namespace padrão é Container.

A imagem principal contém um elemento Container:Directory nos metadados XMP que definem a ordem e as propriedades do arquivo de mídia seguinte no contêiner de arquivos. Cada arquivo no contêiner tem um item de mídia correspondente no Container:Directory. O item de mídia descreve o local no contêiner de arquivos e as propriedades básicas de cada arquivo concatenado.

O elemento de contêiner é codificado nos metadados XMP da imagem principal e define um diretório de itens de mídia no contêiner. Os itens de mídia precisam estar localizados no arquivo do contêiner na mesma ordem dos elementos do item de mídia no diretório e precisam ser compactados.

O diretório pode conter apenas um item de imagem "Principal" e ele precisa ser o primeiro item no diretório.

Nome do elemento	Tipo	Descrição
Contêiner:diretório	Matriz ordenada de estruturas	Matriz ordenada de estruturas, cada uma contendo um struct Container:Item que define o layout e o conteúdo do contêiner.

Elemento do item

Os elementos de item descrevem como cada item de mídia é usado pelo aplicativo.

O URI do namespace XMP para a extensão XMP do item do GContainer é http://ns.google.com/photos/1.0/container/item/. O prefixo de namespace padrão é Item.

O primeiro item de mídia precisa ser a imagem principal.Ele precisa especificar Item:Semantic = "Primary" e um Item:Mime listado em Valores de tipo MIME do item.

O comprimento do item de imagem principal é determinado pela análise da imagem principal com base no tipo MIME, começando no início do contêiner de arquivos.

Os itens de mídia podem conter um atributo Item:Padding que especifica um padding adicional entre o final do item de mídia e o início do próximo item de mídia. Quando presente no último item de mídia no Container:Directory, Item:Padding indica o preenchimento entre o final do item e o final do arquivo.

Cada item de mídia precisa conter o tipo Item:Mime e os atributos Item:Semantic. Os itens de mídia de imagem secundários precisam conter atributos Item:Length.

Os itens de mídia sequenciais podem compartilhar dados de recursos no contêiner de arquivos. O primeiro item de mídia determina a localização do recurso no contêiner de arquivos e os itens de mídia compartilhados subsequentes têm Item:Length definido como 0. Caso os dados do recurso sejam um contêiner, Item:URI pode ser usado para determinar o local dos dados do item de mídia no recurso.

A localização dos recursos de item de mídia no contêiner é determinada pela soma do tamanho da codificação da imagem principal, dos valores Item:Length dos recursos de item de mídia secundários anteriores e de todos os valores Item:Padding anteriores. Item:Padding é considerado 0 em recursos de itens de mídia que não especificam o valor.

Nome do atributo	Tipo	Descrição
Item:Mime	Texto	String simples que indica o tipo MIME do item de mídia no contêiner. Para uma definição, consulte a seção de valores de tipo MIME do item. Obrigatório.
Item:Semantic	Texto	String simples que indica o significado específico do aplicativo para o item de mídia. Para uma definição, consulte a seção "Valores semânticos do item". Obrigatório.
Item:Comprimento	Número inteiro	String simples que contém um comprimento de número inteiro positivo em bytes do item. O tamanho 0 indica que o recurso de item de mídia é compartilhado com o item de mídia anterior. Obrigatório para itens de mídia secundários. Opcional para o item de mídia de imagem principal.
Item:rótulo	Texto	String definida de implementação usada para remover a ambiguidade de vários elementos de itens com o mesmo Item:Semantic. Opcional.
Item:padding	Número inteiro	Uma string que contém um tamanho inteiro positivo em bytes de padding extra entre o fim do item de mídia e o início do próximo item de mídia ou o fim do arquivo quando usado no último item de mídia no Container:Directory. Um valor de 0 é usado quando não está presente. Opcional.
Item:URI	Texto	Uma string de URI em conformidade com a seção 8.11.9 da ISO/IEC 14496-12, contendo o URI relativo dos dados de mídia dentro do recurso de item de mídia. O padrão é o recurso de imagem principal. Opcional para tipos MIME de formato de arquivo de mídia base ISO ISO/IEC 14496-12. Não pode ser usado de outra forma.

Valores do tipo MIME do item

O atributo Item:Mime define o tipo MIME de cada item de mídia.

Valor	Descrição
imagem/jpeg	Imagem JPEG.

Exemplo de XMP do GContainer

O exemplo a seguir de um pacote XMP GContainer válido tem metadados retirados do arquivo de exemplo ilustrado na seção Introdução.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.2">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
     xmlns:Container="http://ns.google.com/photos/1.0/container/"
     xmlns:Item="http://ns.google.com/photos/1.0/container/item/"
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0">
      <Container:Directory>
        <rdf:Seq>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="Primary"
             Item:Mime="image/jpeg"/>
          </rdf:li>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="GainMap"
             Item:Mime="image/jpeg"
             Item:Length="66171"/>
          </rdf:li>
        </rdf:Seq>
      </Container:Directory>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

Compatibilidade com ISO 21496-1

A ISO 21496-1 fornece um mecanismo de encapsulamento alternativo para codificar metadados do mapa de ganho em um arquivo de imagem. É possível codificar os metadados Ultra HDR e ISO 21496-1 em um arquivo JPEG usando uma única imagem de mapa de ganho no arquivo.

Figura 2. Exemplo de layout de arquivo com metadados Ultra HDR e ISO 21496-1.

Para máxima compatibilidade multiplataforma, as implementações do Android e os apps que implementam a própria codificação ou decodificação de arquivos JPEG com mapas de ganho precisam oferecer suporte à codificação e decodificação de metadados Ultra HDR v1 e ISO 21496-1. Durante uma operação de codificação, a implementação ou o app precisa codificar os dois formatos de metadados. Se os dois tipos de metadados estiverem presentes durante uma operação de decodificação, a implementação ou o app precisará usar os metadados ISO 21496-1.

Observação: o Android oferece suporte à codificação e decodificação ISO 21496-1 para Bitmap para JPEG a partir do Android 15 (nível 35 da API). O Android 15 codifica os metadados Ultra HDR v1 e ISO 21496-1 ao codificar arquivos JPEG Ultra HDR de objetos Bitmap. Além disso, a biblioteca libultrahdr no AOSP oferece suporte à codificação ISO 21496-1 quando a flag adequada está ativada.

Registro de alterações

Esta seção contém informações sobre as mudanças entre as versões desta especificação.

v1.1

Todas as mudanças nesta versão da especificação Ultra HDR são informativas e sobre a compatibilidade com a ISO 21496-1. Não há mudanças no formato do arquivo.

• Adicione a seção Compatibilidade com a ISO 21496-1.

v1.0

A publicação inicial da especificação Ultra HDR.