Formato de imagem Ultra HDR v1.0

Introdução

Este documento define 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 oferecem suporte ao novo formato, leia e exiba a baixa dinâmica convencional de intervalo de imagens do arquivo de imagem.Os leitores compatíveis com o formato combinam a imagem principal com o mapa de ganho e renderizar uma imagem de High Dynamic Range monitores compatíveis.

O restante deste documento descreve os métodos dos processos necessários para fazer uso desse formato. De modo geral, o ciclo de vida de uma imagem em conformidade para este formato é:

1. Codificação

   1. Gerar mapas
   2. Conseguir compactação de mapas
   3. Obter 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 na imagem SDR que podem ser usados em combinação com a técnica de exibição para produzir as produções HDR ideal, 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 é exibido.
• 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 pode variar significativamente entre dispositivos, ou até mesmo temporariamente em um único dispositivo.

E, finalmente, a técnica deve ser capaz de fazer todas as ações anteriores sem nunca:

• Recorte de destaques.
• Sombras esmagadoras.
• Mudar ou comprimir o contraste local.
• Alterar as 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
• Especificação XMP ISO 16684-1:2019 Parte 1
• Formato de arquivo de mídia ISO/IEC 14496-12
• T.81 (09/92) Compressão digital e codificação de imagem estática de tom contínuo imagens
• Artigo do formato de várias imagens CIPA DC-x 007-2009

Definições

• Tela SDR

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

• Tela HDR

  • Uma tela projetada para conteúdo HDR. Essas telas normalmente produzem uma com brilho nominal máximo maior que o de um monitor SDR, normalmente 800 cd/m² ou maior e geralmente também têm melhor contraste proporções maiores que as telas SDR.

• Imagem principal

  • A primeira instância de uma imagem em um arquivo GContainer com mídia secundária arquivos anexados a ele. A imagem principal contém metadados XMP do GContainer a definição da ordem e das propriedades do item de mídia secundário subsequente 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, cenas do mundo real costumam ter mais alcance dinâmico do que O visor SDR pode representar. Operações como a compressão de intervalo também chamado mapeamento de tom local, são necessários para reduzir a faixa dinâmica de um imagem. Esta redução precisa evitar recorte de destaques ou esmagamento com sombra, preservando o contraste local o máximo possível.Você tenta reduzem o tamanho das grandes bordas de luminância na imagem, o que contribui mais ao contraste global, enquanto tenta preservar o tamanho do pequenas bordas de luminância, que são os detalhes.Embora existam muitos diferentes implementações. Essa operação é padrão na maioria câmeras digitais hoje.

• Ponto branco do SDR

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

• Ponto branco em HDR

  • A luminância linear máxima do conteúdo HDR em uma tela em um determinado em um determinado momento. Normalmente, esse valor é maior do que o ponto branco do SDR.

• Aumentar

  • O ponto branco HDR dividido pelo ponto branco do SDR.

• Otimização máxima de conteúdo (max_content_boost nas equações)

  • Com esse valor, o criador do conteúdo pode restringir o brilho de uma imagem. pode obter, quando mostrado em uma tela HDR, em relação à renderização SDR.
  • Esse valor é uma constante para uma determinada imagem. Por exemplo, se o for quatro, então, para qualquer pixel determinado, a luminância linear do a reprodução em HDR exibida precisa ter no máximo quatro vezes a luminância linear do a interpretação do SDR. Na prática, isso significa que as partes mais brilhantes a cena pode ser até quatro vezes mais brilhante.
  • Na prática, esse valor normalmente é maior que 1,0.
  • Sempre maior ou igual a Valor mínimo de otimização de conteúdo.

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

  • Com esse valor, o criador de conteúdo restringe o nível de brilho imagem pode obter, quando exibida em uma tela HDR, em relação ao SDR versão.Esse valor é uma constante para uma determinada imagem.
  • Se, por exemplo, o valor for 0,5, para qualquer pixel determinado, o valor linear a luminância da reprodução HDR exibida precisa ser de, no mínimo, 0,5x a luminância linear da interpretação de SDR.
  • Na prática, esse valor costuma ser igual ou apenas menor que 1,0.
  • Sempre menor ou igual ao reforço máximo de conteúdo.

• Otimização máxima da tela (max_display_boost nas equações)

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

• Otimização da Rede de Display

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

• Rendição HDR de destino

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

• Execução adaptada de HDR

  • A execução final em HDR mostrada na tela, depois adaptando a execução de HDR de destino para a otimização atual da tela.

• Ganhar mapa (recovery(x, y) em equações)

  • Um mapa que indica o quanto iluminar cada pixel, na renderização SDR, para produzir a execução em HDR. 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 no 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 registro₂(x)

• pow(b, x)

  • Exponenciação b^x.

• XMP

  • Extensible Metadata Platform. Um padrão que define um método para codificando metadados em um contêiner de imagem, definida pela ISO 16684-1:2011(E) XMP Specification Part 1 (em inglês).

• Formato de várias imagens

  • Formato de várias imagens é uma técnica desenvolvida pelas equipes de 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, Artigo da CIPA Formato de várias imagens DC-x 007-2009.

• Contêiner do Google

  • GContainer é um método para armazenar várias imagens em uma imagem em que uma imagem é considerada a principal. Qualquer um imagens adicionais são consideradas versões alternativas ou auxiliares. Os metadados XMP são utilizados para comunicar a presença e o significado de qualquer imagens adicionais. Para mais informações, consulte a documentação do GContainer detalhes.

Codificação

Esta seção descreve como codificar um arquivo JPEG compatível. Consulte a T.81 (09/92) Compressão digital e codificação de tons contínuos images, 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 alcance para os dados de luminância de maior intervalo dinâmico para um intervalo menor O SDR é exibido. O mapa de ganho é um mecanismo para armazenar dados suficientes para recuperam 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.

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

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

A função Ysdr(x, y) é definida no intervalo de 0,0 a 1,0 e é o luminância linear da imagem principal no 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) é o não linear de três canais, ou seja, um componente codificado em PQ ou HLG. imagem.
• 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 cores do 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 é 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 com base em duas imagens lineares que contêm a imagem HDR desejada luminância (Yhdr(x, y)), e a imagem de luminância no intervalo padrão, Ysdr(x, y).

A função pixel_gain(x, y) é definida como a proporção entre 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 O zero é definido pela implementação.

Por exemplo, as implementações podem lidar com o caso em que Ysdr(x, y) e offset_sdr são definidos como zero quando pixel_gain(x, y) é definido como 1,0. Como alternativa, 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, relativo à otimização máxima e mínima 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 é implementação definida, porque log2(0) é indefinido.

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

Os valores de otimização máxima e mínimo de conteúdo são é definido pela implementação e pode ser decidido arbitrariamente pelo criador do conteúdo. A otimização de conteúdo máxima precisa ser maior ou igual a 1,0. A otimização mínima 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ário e, portanto, deve ser codificado usando valores inteiros de 8 bits e não assinados, portanto, no intervalo [0, 255]. Cada valor representa um valor recovery(x, y) e é armazenado em um pixel do bloco secundário imagem.

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

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

O cálculo da função de codificação é feito em um ponto flutuante e convertido em o final para o resultado de número inteiro não assinado de 8 bits, arredondando-se conforme indicado.

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

Depois que o mapa de ganho é armazenado em uma imagem secundária, ele é anexado a uma imagem com metadados MPF e GContainer XMP. A imagem principal do GContainer deve 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 modelo de ganho O mapa é dimensionado para uma resolução diferente da imagem principal para armazenamento. A deve ser bilinear ou superior, e a implementação está definida.

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

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

Coletar contêiner do mapa

Perfil de cor

O perfil de cor da imagem deve ser indicado por um perfil ICC para o imagem principal.

Atributos XMP

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

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

Os valores de atributo descritos nas tabelas a seguir são armazenados como XMP simples valores dos tipos de valores básicos de XMP 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 de HDR

Os metadados do mapa de ganho codificam informações sobre como interpretar e aplicar o 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 padrão do namespace é hdrgm:

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

Exemplo de mapa de ganho XMP

O exemplo a seguir de um pacote XMP de mapa de ganho válido contém metadados coletados do arquivo de exemplo ilustrado na seção Introduction (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 adicional, conforme definido no CIPA Formato de várias imagens DC-x 007-2009, conforme mencionado nos Seção Dependências.

Decodificar

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

Localizar a imagem do mapa de ganho

Para mais detalhes sobre como analisar e decodificar a imagem, consulte a documentação do GContainer detalhes. Um "GainMap" um item semântico dentro do XMP O rdf:Directory é usado para sinalizar o local de uma imagem do mapa de ganho. Como alternativa, o IFD do índice MPF e a verificação de imagens O XMP é usado para determinar a localização 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 está presente com um valor inválido. Um valor pode ser inválido porque não é analisável para o tipo especificado ou porque está fora do intervalo esperado.

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

Tela

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

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 não assinado de canal único de 8 bits. da imagem do mapa de ganho.

Se o mapa de ganho tiver uma resolução diferente da imagem principal, Em vez disso, encoded_recovery(x, y) é determinado por uma amostragem filtrada do ganhar a imagem do mapa para x e y sobre o intervalo da largura e altura da imagem primária, respectivamente. O método de filtragem precisa ser bilinear ou superior e ter implementação definida.

map_gamma é determinado pelo campo de metadados hdrgm:Gamma.

log_recovery(x, y) é o ganho de pixel de ponto flutuante normalizado em uma 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 exibição é um valor de ponto flutuante escalar definido como a proporção entre o ponto branco HDR atual e dividido pelo ponto branco atual do SDR. Isso é 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 for "True", a segunda equação será:

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 pode aplicar uma transformação a HDR(x, y), para colocar a no espaço esperado pela tela. Essas transformações precisam ser está de acordo com as cores.

Detalhes do GContainer

Esta seção especifica requisitos adicionais para que o formato esteja em conformidade com metadados XML do GContainer. Os metadados são serializados seguindo a norma ISO 166841:2011(E) XMP Specification Part 1 (Parte 1) e incorporado no arquivo de imagem principal, conforme descrito na Especificação do Adobe XMP Parte 3 Storage em Arquivos. O arquivo de imagem principal contém as itens a seguir, formatados como RDF/XML.

Requisitos do pacote XMP

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

O pacote XMP deve 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 padrão do namespace é Container:

A imagem principal contém um elemento Container:Directory nos metadados XMP definir a ordem e as propriedades do arquivo de mídia subsequente no arquivo contêiner do Docker. Cada arquivo no contêiner tem um item de mídia correspondente na Container:Directory: O item de mídia descreve o local no arquivo. contêiner 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. É necessário localizar os itens de mídia no arquivo do contêiner na mesma ordem que os elementos do item de mídia no e precisa ser compactado.

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

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 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 tamanho do item da imagem principal é determinado pela análise da principal baseada no tipo MIME dela, começando no início do contêiner do arquivo.

Os itens de mídia podem conter um atributo Item:Padding especificando outros padding entre o fim do item de mídia e o início da próxima mídia do item de linha. Quando presente no último item de mídia na Container:Directory, Item:Padding indica padding entre o fim do item e o fim da .

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

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

O local dos recursos de item de mídia no contêiner é determinado pela soma o comprimento da codificação da imagem principal, os valores Item:Length do recursos de item de mídia secundários anteriores e todos os Item:Padding anteriores e a distribuição dos valores dos dados. Item:Padding é considerado 0 nos recursos de item de mídia que não especificar seu valor.

Valores do tipo MIME do item

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

Exemplo de GContainer XMP

O exemplo a seguir de um pacote GContainer XMP válido tem metadados extraídos de no arquivo de exemplo ilustrado na seção Introduction (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>