Formato de imagem Ultra HDR v1.1

Introdução

Este documento define o comportamento de um novo formato de arquivo que codifica uma imagem de mapa de ganho de alcance 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 High Dynamic Range 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. Ganhar compactação de mapa
   3. Geração de contêineres de mapa de ganho

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 usadas em combinação com a técnica de exibição para produzir renderizações em 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 ocupa muito espaço extra.

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

• Não exigem processamento intenso para decodificação.
• Ser capaz de se adaptar a qualquer proporção entre os pontos brancos HDR e SDR de uma tela, que podem variar significativamente entre os dispositivos ou até mesmo de forma temporária em um único dispositivo.

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

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

Dependências

Confira a seguir 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 geralmente produzem um brilho nominal máximo maior do que o de uma tela SDR, normalmente 800 cd/m² ou mais, e geralmente também têm melhores relações de contraste 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 intervalo, também chamadas de mapeamento de tom local, são necessárias para reduzir o intervalo dinâmico de uma imagem. Essa redução precisa evitar recortes de destaques ou esmagamento de sombras, 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 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)

  • Esse valor permite que o criador de conteúdo restrinja o brilho máximo de uma imagem quando mostrada em uma tela HDR em relação à renderização 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 Aumento mínimo de conteúdo.

• Otimização mínima de 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 mostrada em uma tela HDR, em relação à renderização SDR. Esse valor é uma constante para uma imagem específica.
  • 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 geralmente é igual ou um pouco 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 com o 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.

• Melhoria de tela

  • Igual ao menor valor entre o aumento máximo de conteúdo e o aumento máximo de exibição. Esse valor é sempre >= 1,0.
  • Por exemplo, se o aumento máximo de conteúdo for 4,0 e o aumento máximo de exibição for 3,0, o aumento de exibição será 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.
  • Por exemplo, se o impulso máximo de conteúdo for 4,0 e o impulso máximo de exibição for 5,0, o impulso de exibição será 4,0. Os pixels são exibidos até 4x 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 renderização HDR final que aparece na tela depois de adaptar a renderização HDR de destino para o aumento de tela atual.

• 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 um ou vários canais. 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)

  • Limite o valor x ao 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 Especificação ISO 16684-1:2011(E) XMP Specification Part 1.

• Formato multiimagem

  • O formato de várias imagens é uma técnica desenvolvida pela Camera and Imaging Products Association (CIPA) para armazenar várias imagens codificadas em JPEG em um único arquivo JPEG.
  • Para mais informações, consulte a dependência relacionada, White Paper of CIPA DC-x 007-2009 Multi-Picture Format.

• Contêiner do Google

  • O GContainer é um método para armazenar várias imagens em um contêiner de imagens, em que uma imagem é considerada a principal. Quaisquer 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.

Codificar

Esta seção descreve como codificar um arquivo JPEG compatível. Consulte T.81 (09/92) Digital compression and coding of continuous-tone still images, na seção "Dependências", para mais informações sobre o formato JPEG.

Geração de mapa de ganho

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 fornece um mecanismo para armazenar dados suficientes para recuperar os dados originais de luminância de faixa dinâmica mais alta.

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

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 primária de três canais, obtida pela transformação em uma versão linear do espaço de cor da imagem primária. 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 as 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 imagem não linear de três canais, ou seja, uma imagem codificada em 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 a "aumento máximo de conteúdo".

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

Por exemplo, se a imagem principal 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 Display-P3.

O mapa de ganho é calculado a partir de duas imagens lineares que contêm a luminância da imagem HDR desejado, 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 a função Yhdr(x, y) e a função 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.

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.

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

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

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

O mapa de ganho é armazenado em um JPEG de imagem secundária e, portanto, precisa ser codificado usando valores inteiros não assinados de 8 bits, 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.

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 melhor e é definido pela implementação.

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 armazenado, como no EXIF, será usado.

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

Contêiner do mapa de ganho

Perfil de cores

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

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.

Metadados do mapa de ganho 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:

Exemplo de XMP do mapa de ganho

O exemplo a seguir de um pacote XMP de mapa de ganho válido contém metadados extraídos 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 compatível.

Sinal do formato

Um arquivo JPEG que obedece a esse formato pode ser identificado pela presença de hdrgm:Version="1.0" no pacote XMP da imagem principal, em que hdrgm é o URI de 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 MPF e o XMP das imagens de digitalização 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 algum campo estiver presente 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 HDR podem ser renderizados em telas SDR convencionais ou em telas HDR com saída de luminância mais alta.

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

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 normalizado de pixels de ponto flutuante 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)

A otimização máxima da tela é um valor de ponto flutuante escalar definido como a proporção entre o ponto branco HDR atual e dividido pelo ponto branco do SDR atual. Esse valor é fornecido pelo sistema de exibição e pode mudar ao longo do 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 execução em HDR linear adaptada pode ser calculada da seguinte forma:

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 poderá aplicar uma transformação a HDR(x, y) para colocar os dados no espaço esperado pela tela. Todas essas transformações precisam estar colorimetricamente corretas.

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 seguindo a Especificação ISO 166841:2011(E) XMP Parte 1 e incorporados ao arquivo de imagem principal, conforme descrito em Armazenamento em arquivos da especificação XMP, parte 3. 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 de namespace padrão é hdrgm.

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

Elemento de contêiner

O namespace XMP da extensão XMP do GContainer é 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 define a ordem e as propriedades do arquivo de mídia subsequente 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.

Elemento de 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 sequencial podem compartilhar dados de recursos no contêiner de arquivos. O primeiro item de mídia determina o local 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 poderá 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.

Valores de tipo MIME do item

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

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 a ISO 21496-1

A ISO 21496-1 fornece um mecanismo de encapsulamento alternativo para codificar metadados de 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.

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.