Lost your password?

Compreendendo os métodos de compressão do formato openEXR

Matheus GalvãoAfter Effects CCDestaque

Ao usar o formato OpenEXR, pode ser difícil determinar qual é a melhor compressão de dados a ser usada. Este artigo é uma tentativa de resposta, dependendo da sua necessidade com o arquivo.

O desempenho dos arquivos openEXR no After Effects 2020 foi bastante aprimorado. Pode parecer um pouco complicado no começo, e muitas pessoas ainda afirmam que o “Quicktime Animation tem a melhor compactação ou desempenho“, que “nada é igual ao ProRes” ou “PNG é mais fácil de usar“, por exemplo. Está tudo errado. Vamos explicar!

Tipos de imagens

Vídeo ou animação granulados
Imagens fotográficas (incluindo CGI realista) ou animação com granulado

Vídeo
Fotográficas de vídeo (incluindo CGI realista) sem granulado

Animação, Motion Graphics
Altamente estilizadas, como Animação 2D, Motion Graphics, Animação 3D estilizada ou 3D passes como Z Depth, Normal…

Cores sólidas, grandes áreas planas
Imagens consistindo principalmente de cores sólidas, como canais alfa ou id

Mapas de textura
Arquivos de alta resolução

Sumário

Exportação final com perdas (Lossy)

Especialmente para exportações finais, você provavelmente não precisa de compactação sem perdas e, com as configurações corretas, o tamanho do arquivo exportado pode ser muito pequeno com apenas uma redução muito pequena da qualidade, e a Master ou o backup do seu filme podem ser armazenados dessa maneira.

Nesse caso, o DWA (com um pequeno nível de compactação) é muito eficiente em todos os casos. Cuidado, o DWA ainda não é suportado pelo ffmpeg . Nesse caso, o PXR24 é uma boa alternativa sem perdas (lossless).

Cores sólidas (por exemplo, canais alfa) podem ser compactadas com muita eficiência usando o RLE sem perder a qualidade.

Se você não estiver exportando para composição complexa (por exemplo, codificação choma) e, especialmente, de uma fonte de vídeo ou se a exportação for usada como master para outras exportações de vídeo YUV 422 ou 421 (como h.264), o Luminance / Chroma dividirá o tamanho do arquivo por dois, com apenas uma redução muito pequena da qualidade. Cuidado, o ffmpeg ainda não suporta a opção Luminance / Croma.

Exportação sem perdas (intermediária)

Se o arquivo deve ser usado em um software de composição, por exemplo, convém exportar sem perder a qualidade.

De qualquer forma, se você estiver renderizando uma imagem com AOV (provavelmente de um software 3D) e puder aceitar uma perda de qualidade (muito pequena), o DWA é a melhor opção, pois compactará apenas os canais RGB (ou Y, RY, BY no caso de Luminance / Chroma) e use RLE para alfa e ZIP para qualquer outro canal.
Nesse caso, tenha cuidado para que o DWA use os nomes do canal (diferencia maiúsculas de minúsculas):

  • Canais com perdas: R, G, B, Y, RY, BY
  • RLE: A
  • ZIP: qualquer outro nome (Red, red, r, Green, green, g, Blue, blue, b, x, y, z, U, u, V, v, etc…)

Cuidado com os nomes do canal. Por exemplo, usar XYZ resultará em perda do canal Y. Você pode usar “xyz”.

Quando as imagens não têm granulado :

  • Se você não precisar de full 32-bit float precision, o PXR24 é a melhor compactação que você pode usar.
  • Se você precisar de full 32-bit float precision, o ZIP é a melhor opção.

Quando as imagens têm granulado, o PIZ é sempre a melhor opção.

Para imagens stereo, o melhor é o ZIP .

Para cores sólidas, como canais alfa, é melhor usar o RLE.

Casos especiais

Existem usos mais específicos para o OpenEXR:

  • Em sistemas para a reprodução em tempo real, B44 é preferido (ou B44A para canal alfa e cores sólidas).
  • Se você precisar renderizar proxies com perda pequena e tamanho pequeno, poderá usar o DWAA com um alto nível de compactação.
  • As imagens em escala de cinza se beneficiarão muito com a opção Luminance / Chroma, sem perder a qualidade.

Imagens Luminance / Chroma

A codificação de imagens planas com uma luminância e dois canais de croma, em vez de dados RGB, permite uma forma simples, porém eficaz, de compactação com perda de dados, independente dos métodos de compactação listados aqui. Os canais de croma podem ser armazenados em resolução mais baixa que o canal de luminância. Isso leva a arquivos significativamente menores, com apenas uma pequena redução na qualidade da imagem.

Este é o mesmo método que é chamado YUV 422 para vídeo.
Isso significa que você pode usar esta opção se estiver exportando para um vídeo YUV 422 ou 421 padrão sem perder a qualidade.

Se você estiver exportando para YUV 444 ou RGB, a redução na qualidade ainda será muito pequena.

Como a luminância é armazenada em qualidade total usando a opção Luminance / Chroma, ela pode armazenar imagens em escala de cinza muito melhor que o RGB padrão sem perder nenhum dado.

Nota: esta opção não é suportada pelo ffmpeg (ainda).

Formatos que você não conhece, você já conhece

  • ZIP é o método de compactação usado nos arquivos Portable Network Graphics (.png) . NÃO é baseado no formato de arquivo Zip, apesar do nome). Se você não precisa de precisão de 32bpc, ou seja, quando este documento declara que você pode usar o ZIP, ele pode ser substituído por arquivos PNG (se você não precisar do AOV, tendo em mente que a maioria dos softwares é mais lenta no manuseio do PNG, especialmente no After Effects )
  • O RLE é uma compactação usada em arquivos TGA e está próximo da maneira como os dados são compactados com o Quicktime Animation, às vezes usado em arquivos .mov . Se você não precisa de precisão de 32bpc, isso significa que você pode substituir o RLE por arquivos TGA (se você não precisar do AOV)
  • O DWA está próximo da maneira como os dados são compactados nos arquivos JPEG . Se você não precisar de precisão de 16 ou 32bpc, o DWA poderá ser substituído por uma sequência de arquivos JPEG, se você for cuidadoso com a taxa de compactação (e não precisar de alfa ou AOV).

Resumo por uso e tipo de imagem

Render/export Final

Animação, motion graphics ou Vídeo

  • DWA, com perdas (um pouco). (use um pequeno nível de compactação) – ainda não é suportado pelo ffmpeg.
  • PXR24, sem perdas *
  • Se estiver exportando para vídeo YUV 422 ou 421 (e.g.h.264) ou em escala de cinza, use a opção Luminance / Chroma – não suportada pelo ffmpeg (ainda).

* No caso específico de uma exportação final, o PXR24 é considerado sem perdas, pois não deve haver necessidade de 32-bit float.

Vídeo ou animação granulados

  • DWA, com perdas (um pouco) – não suportado pelo ffmpeg (ainda).
  • PIZ, sem perdas
  • Se estiver exportando para vídeo YUV 422 ou 421 (e.g.h.264) ou em escala de cinza, use a opção Luminance / Chroma . – não suportado pelo ffmpeg (ainda).

Cores sólidas, grandes áreas planas (canais alfa e id)

  • RLE

Intermediário de 32-bit float

Mapas de texturas, animação, motion graphics ou vídeo

  • ZIP
  • DWA se você puder dispor de uma pequena perda de qualidade
    Observe que o DWA comprime apenas os canais R, G, B (ou Y, RY, BY no caso de Luminance / Chroma) e seleciona automaticamente RLE para alfa ou ZIP para AOV (Z, U , V, Normal …). – não suportado pelo ffmpeg (ainda).

Vídeo ou animação granulados

  • PIZ

Cores sólidas, grandes áreas planas (canais alfa e id)

  • RLE

Intermediário de 16/24-bit, float, 16/32-bit inc

Mapas de texturas, animação, gráficos ou vídeo

  • PXR24, se indisponível: ZIP
  • DWA se você puder dispor de uma pequena perda de qualidade
    Observe que o DWA comprime apenas os canais R, G, B (ou Y, RY, BY no caso de Luminance / Chroma) e seleciona automaticamente RLE para alfa ou ZIP para AOV (Z, U , V, Normal …) – ainda não é suportado pelo ffmpeg.

Vídeo granulado ou animação

  • PIZ

Cores sólidas, grandes áreas planas (canais alfa e id)

  • RLE

Imagens stereo

Mapas de texturas, animação, motion graphics ou vídeo

  • ZIP

Cores sólidas, grandes áreas planas (canais alfa e id)

  • RLE

Reprodução em tempo real

  • B44A ou B44
  • Se indisponível: PXR24

Proxies

  • DWAA (use um alto nível de compactação)
  • Se indisponível: PXR24, ZIP, PIZ

Detalhes

As descrições são retiradas da introdução técnica oficial em https://www.openexr.com

PIZ

Sem perdas (lossless)

Uma transformação wavelet é aplicada aos dados de pixel e o resultado é Huffman-encoded. Esse esquema tende a fornecer a melhor taxa de compactação para os tipos de imagens normalmente processados ​​na Industrial Light & Magic (ILM). Os arquivos são compactados e descompactados aproximadamente na mesma velocidade. Para imagens fotográficas com granulado, os arquivos são reduzidos para entre 35 e 55% do tamanho não compactado. (Os dados compactados em PIZ começam com um cabeçalho relativamente longo; se a entrada no compressor for curta, a adição do cabeçalho tende a compensar qualquer redução de tamanho da entrada.) A compactação PIZ é suportada apenas para imagens planas.

  • Relação *: 35 ~ 55% (foto com granulado)
  • Velocidade de gravação = velocidade de leitura
  • Melhor para imagens granuladas

Bom para**:

  • Foto / Vídeo (com granulado)
  • Animação 3D (com granulado)

ZIP

Sem perdas (lossless)

As diferenças entre os pixels adjacentes horizontalmente são compactadas usando a biblioteca zlib de código aberto. A descompactação ZIP é mais rápida que a descompactação PIZ, mas a compactação ZIP é significativamente mais lenta. As imagens fotográficas tendem a encolher entre 45 e 55% do tamanho não compactado. Arquivos de resolução múltipla são frequentemente usados ​​como mapas de textura para renderizadores 3D. Para este aplicativo, os acessos de leitura rápida geralmente são mais importantes do que gravações rápidas ou compactação máxima. Para mapas de textura, o ZIP é provavelmente o melhor método de compactação. Em arquivos baseados em scan-line, 16 linhas de pixels são acumuladas e compactadas juntas como um único bloco.

  • Relação *: 45 ~ 55% (foto sem granulado)
  • Leitura mais rápida, escrita significativamente mais lenta
  • Igual ao PNG
  • Suportado para imagens stereo

Bom para ** (Somente quando 32bpc float é necessária – caso contrário, o PXR24 é melhor) :

  • Mapas de textura
  • Foto / Vídeo (sem granulado)
  • Animação 3D (sem granulado)
  • Animação 2D, motion graphics

ZIPS

Sem perdas (lossless)

Usa a biblioteca zlib de código aberto para compactação. Como a compactação ZIP, mas opera em uma linha de digitalização por vez.

  • Igual ao PNG
  • Suportado para imagens stereo

RLE

Sem perdas (lossless)

As diferenças entre os pixels adjacentes horizontalmente são codificadas no comprimento da execução. Esse método é rápido e funciona bem para imagens com grandes áreas planas, mas para imagens fotográficas, o tamanho do arquivo compactado é geralmente entre 60 e 75% do tamanho não compactado.

  • Relação *: 60 ~ 75% (foto)
  • Rápido
  • Igual o TGA
  • Melhor com grandes áreas planas (canais alfa e id)
  • Suportado para imagens stereo

Bom para**:

  • Cores sólidas, grandes áreas planas (canais alfa e id)

PXR24

Sem perdas (lossless)

(16-bit float, 16/32-bit int)
Ligeiramente com perdas (3x10E-5)
(32-bit float)

Após reduzir os dados de 32-bit float para 24 bits, arredondando (mantendo os dados de 16-bit float inalterados), as diferenças entre os pixels adjacentes horizontalmente são compactadas com zlib, semelhante ao ZIP. A compactação PXR24 preserva exatamente os canais de imagem do tipo HALF e UINT, mas o erro relativo dos dados do FLOAT aumenta. Esse método de compactação funciona bem para buffers de depth e imagens semelhantes, onde o intervalo possível de valores é muito grande, mas onde a precisão total de 32-bit float não é necessária. O arredondamento melhora significativamente a compactação, eliminando os 8 bits menos significativos dos pixels, que tendem a ser muito ruidosos e, portanto, difíceis de compactar. A compactação PXR24 é suportada apenas para imagens planas.

  • Proporção *: melhor que ZIP para 32bpc, o mesmo que ZIP, caso contrário
  • Leitura mais rápida, escrita significativamente mais lenta
  • Transforma 32-bit float em 24 bits

Bom para ** (Somente para 16bpc float ou 16 / 32bpc int ou quando 24bpc float é suficiente em vez de 32bpc) :

  • Foto / Vídeo (sem granulado)
  • Animação 3D (sem granulado)
  • Animação 2D, motion graphics
  • Mapas de textura

B44

Com perdas (lossy)

Canais do tipo HALF são divididos em blocos de quatro por quatro pixels ou 32 bytes. Cada bloco é compactado em 14 bytes, reduzindo os dados para 44% do tamanho não compactado. Quando a compactação B44 é aplicada às imagens RGB em combinação com a codificação de luminance / chroma (veja abaixo), o tamanho dos pixels compactados é de cerca de 22% do tamanho dos dados RGB originais. Canais do tipo UINT ou FLOAT não são compactados. A decodificação é rápida o suficiente para permitir a reprodução em tempo real de sequências de imagens OpenEXR compactadas em B44 em hardware comum. O tamanho de um arquivo compactado em B44 depende do número de pixels na imagem, mas não dos dados nos pixels. Todas as imagens com a mesma resolução e o mesmo conjunto de canais têm o mesmo tamanho. Isso pode ser vantajoso para sistemas que suportam a reprodução em tempo real de sequências de imagens; o tamanho previsível do arquivo facilita a alocação de espaço na mídia de armazenamento com eficiência. A compactação B44 é suportada apenas para imagens planas.

  • Relação *: 44%
  • Tamanho de arquivo fixo
  • Velocidade de leitura muito rápida

Bom para**:

  • Sistemas que precisam de reprodução em tempo real

B44A

Com perdas (lossy)

Como B44, exceto blocos de quatro por quatro pixels em que todos os pixels têm o mesmo valor, que são compactados em 3 em vez de 14 bytes. Para imagens com grandes áreas uniformes, o B44A produz arquivos menores que a compactação B44. A compactação B44A é suportada apenas para imagens planas.

  • Relação *: <44%
  • Velocidade de leitura muito rápida
  • Melhor com grandes áreas planas (canais alfa e id)

Bom para**:

  • Sistemas que precisam de reprodução em tempo real

DWAA

Com perdas (lossy)

Formato de compactação com perda semelhante ao JPEG, contribuído pela DreamWorks Animation. Compacta 32 linhas de digitalização juntas.
No código-fonte:
primeiro, tentamos descobrir qual estratégia de compactação deve ser tomada com base no nome do canal. Para canais RGB, queremos um método com perdas descrito abaixo. Mas, se tivermos alfa, devemos fazer algo diferente (e provavelmente usando o RLE). Se tivermos depth, velocity ou qualquer outra coisa, volte ao ZIP.

  • Proporção *: varia dependendo do nível de compactação escolhido
  • Igual ao JPEG

Bom para**:

  • Proxies
  • Exportações finais quando uma compactação pequena é aceitável
  • Renderização 3D com AOV (com um pequeno nível de compactação)

DWAB

Com perdas (lossy)

O mesmo que o DWAA, mas compacta blocos de 256 linhas de digitalização.

  • Proporção *: varia dependendo do nível de compactação escolhido

Bom para**:

  • Proxies
  • Exportações finais quando uma compactação pequena é aceitável

* Comprimido / descompactado. Uma proporção mais baixa é melhor. Por exemplo, 45% significa que o tamanho do arquivo compactado é 45% do tamanho não compactado.

** Um arquivo é adequado para um determinado uso quando a velocidade de leitura ou gravação se ajusta melhor à forma como será usado e possui a melhor taxa de compactação disponível.

Uma observação sobre sequências de frames

Algumas pessoas afirmam que usar arquivos de vídeo é mais fácil do que sequências de frames. Achamos que é realmente muito fácil se acostumar com isso. Se você precisar de apenas um motivo para alternar para sequências de imagens, lembre-se: se o processo de renderização falhar ou se você precisar fazer alterações em apenas uma parte do vídeo, não será necessário renderizar novamente os quadros renderizados ou quadros em que você não fez nenhuma alteração. Eles também são mais fáceis de sincronizar com serviços como o Dropbox ou seu próprio NAS, pois são arquivos mais pequenos enviados com mais facilidade pela rede. Estes são apenas dois exemplos das vantagens das sequências de imagens.
Obviamente, você precisará exportar o som separado do vídeo, mas isso é feito muito rapidamente e geralmente pode ser automatizado com predefinições de renderização.

> Este documento está disponível em pdf. Clique aqui!

Foto de capa via makeuseof.com

Fonte: Rainbox Lab. – Understanding OpenEXR Image Compression

Comentários

comments