Codificação sem perda e transparência no WebP

Jyrki Alakuijala, Ph.D., Google, Inc.
Vincent Rabaud, Ph.D., Google, Inc.
Última atualização: 01/08/2017

Resumo: comparamos o uso de recursos do codificador/decodificador WebP com o do PNG nos modos sem perda e com perda. Usamos um corpus de 12.000 imagens PNG translúcidas escolhidas aleatoriamente na Web e medições mais simples para mostrar a variação na performance. Recomprimimos os PNGs no nosso corpus para comparar imagens WebP com PNGs otimizados para tamanho. Em nossos resultados, mostramos que o WebP é uma boa substituição do PNG para uso na Web em relação ao tamanho e à velocidade de processamento.

Introdução

O WebP oferece suporte a imagens sem perda e translúcidas, o que o torna uma alternativa ao formato PNG. Muitas das técnicas fundamentais usadas na compactação PNG, como codificação de dicionário, codificação Huffman e transformação de indexação de cores, também são compatíveis com o WebP, o que resulta em velocidade e densidade de compactação semelhantes no pior dos casos. Ao mesmo tempo, vários novos recursos, como códigos de entropia separados para diferentes canais de cores, localidade 2D de distâncias de referência para trás e um cache de cores usadas recentemente, permitem melhorar a densidade de compactação na maioria das imagens.

Neste trabalho, comparamos o desempenho do WebP com PNGs altamente compactados usando pngcrush e ZopfliPNG. Recompactamos nosso corpus de referência de imagens da Web usando as práticas recomendadas e comparamos a compactação WebP sem perda e com perda com esse corpus. Além do corpus de referência, escolhemos duas imagens maiores, uma fotográfica e outra gráfica, para comparar o uso de velocidade e memória.

As velocidades de decodificação mais rápidas que o PNG foram demonstradas, bem como 23% de compactação mais densa do que o que pode ser alcançado usando o formato PNG atual. Concluímos que o WebP é uma substituição mais eficiente para o formato de imagem PNG atual. Além disso, a compactação de imagens com perda e suporte a Alfa sem perda oferece mais possibilidades para acelerar sites da Web.

Métodos

Ferramentas de linha de comando

Usamos as seguintes ferramentas de linha de comando para medir o desempenho:

  1. cwebp e dwebp. Essas ferramentas fazem parte da biblioteca libwebp (compilada a partir da cabeça).

  2. converter. Essa é uma ferramenta de linha de comando que faz parte do software ImageMagick (6.7.7-10 2017-07-21).

  3. pngcrush 1.8.12 (30 de julho de 2017)

  4. ZopfliPNG (17 de julho de 2017)

Usamos as ferramentas de linha de comando com as respectivas flags de controle. Por exemplo, se nos referirmos a "cwebp -q 1 -m 0", significa que a ferramenta cwebp foi evocada com as flags -q 1 e -m 0.

Imagem Corpora

Três corpora foram escolhidos:

  1. Uma única imagem fotográfica (Figura 1),

  2. Uma única imagem gráfica com transparência (Figura 2) e

  3. Um corpus da Web: 12.000 imagens PNG escolhidas aleatoriamente com transparência ou sem, rastreadas na Internet. Essas imagens PNG são otimizadas usando convert, pngcrush, ZopfliPNG, e a versão menor de cada imagem é considerada para o estudo.

Figura 1. Imagem fotográfica, 1.024 x 752 pixels. Fogo de artifício "Jaipur Maharaja Brass Band" Chassepierre Bélgica, Autor: Luc Viatour, Foto licenciada sob a licença Atribuição-CompartilhaIgual 3.0 da Creative Commons. O site do autor está aqui.

Figura 2. Imagem gráfica de 1.024 x 752 pixels. Colagem de imagens das Ferramentas de gráficos do Google

Para medir a capacidade total do formato PNG, recompactamos todas essas imagens PNG originais usando vários métodos:

  1. Limitar a 8 bits por componente: converter input.png -depth 8 output.png

  2. ImageMagick(1) sem preditores: convert input.png -quality 90 output-candidate.png

  3. ImageMagick com preditores adaptativos: convert input.png -quality 95 output-candidate.png

  4. Pngcrush(2): pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png output-candidate.png

  5. ZopfliPNG(3): zopflipng --lossy_transparent input.png output-candidate.png

  6. ZopfliPNG com todos os filtros: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparent input.png output-candidate.png

Resultados

Calculamos a densidade de compactação de cada uma das imagens no corpus da Web em relação aos tamanhos de imagem PNG otimizados para três métodos:

  1. WebP sem perdas (configurações padrão)

  2. WebP sem perda com o menor tamanho (-m 6 -q 100)

  3. O melhor do WebP sem perda e WebP com perda com Alfa (configurações padrão).

Classificamos esses fatores de compactação e os plotamos na Figura 3.

Figura 3. A densidade de compactação PNG é usada como referência, em 1,0. As mesmas imagens são compactadas usando métodos sem perdas e com perdas. Para cada imagem, a proporção de tamanho para PNG compactado é calculada, e as proporções são classificadas e mostradas para compactação sem perda e com perda. Para a curva de compactação com perda, a compactação sem perda é escolhida nos casos em que ela produz uma imagem WebP menor.

O WebP vai além da densidade de compactação PNG para libpng com qualidade máxima (convert) e ZopfliPNG (tabela 1), com velocidades de codificação (tabela 2) e decodificação (tabela 3) aproximadamente comparáveis às do PNG.

Tabela 1. Bits por pixel médios para os três corpora usando os diferentes métodos de compactação.

Conjunto de imagens convert -quality 95 ZopfliPNG WebP sem perdas -q 0 -m 1 WebP sem perdas (configurações padrão) WebP sem perdas -m 6 -q 100 WebP com perda e Alfa
foto 12,3 12.2 10,5 10.1 9,83 0,81
explícito 1,36 1,05 0,88 0.71 0,70 0,51
web 6,85 5,05 4,42 4,04 3,96 1,92

Tabela 2. Tempo médio de codificação para os corpos de compactação e para diferentes métodos de compactação.

Conjunto de imagens convert -quality 95 ZopfliPNG WebP sem perdas -q 0 -m 1 WebP sem perdas (configurações padrão) WebP sem perdas -m 6 -q 100 WebP com perda e Alfa
foto 0,500 s 8,7 s 0,293 s 0,780 s 8,440 s 0,111 s
explícito 0,179 s 14,0 s 0,065 s 0,140 s 3,510 s 0,184 s
web 0,040 s 1,55 s 0,017 s 0,072 s 2,454 s 0,020 s

Tabela 3. Tempo médio de decodificação para os três corpora de arquivos de imagem compactados com diferentes métodos e configurações.

Conjunto de imagens convert -quality 95 ZopfliPNG WebP sem perdas -q 0 -m 1 WebP sem perdas (configurações padrão) WebP sem perdas -m 6 -q 100 WebP com perda e Alfa
foto 0,027 s 0,026 s 0,027 s 0,026 s 0,027 0,012 s
gráficos 0,049 s 0,015 s 0,005 s 0,005 s 0.003 0,010 s
web 0,007 s 0,005 s 0,003 s 0,003 s 0.003 0,003 s

Criação de perfil de memória

Para o perfil de memória, registramos o tamanho máximo do conjunto residente, conforme informado por /usr/bin/time -v.

Para o corpus da Web, o tamanho da imagem maior define o uso máximo de memória. Para manter a medição de memória mais definida, usamos uma única imagem fotográfica (Figura 1) para dar uma visão geral do uso de memória. A imagem gráfica mostra resultados semelhantes.

Medimos de 10 a 19 MiB para libpng e ZopfliPNG e 25 MiB e 32 MiB para codificação sem perdas WebP nas configurações -q 0 -m 1 e -q 95 (com um valor padrão de -m), respectivamente.

Em um experimento de decodificação, o comando convert -resize 1x1 usa 10 MiB para os arquivos PNG gerados pelo libpng e pelo ZopfliPNG. Com o cwebp, a decodificação sem perdas do WebP usa 7 MiB, e a decodificação com perdas usa 3 MiB.

Conclusões

Mostramos que as velocidades de codificação e decodificação estão no mesmo domínio do PNG. Há um aumento no uso de memória durante a fase de codificação, mas a fase de decodificação mostra uma diminuição saudável, pelo menos ao comparar o comportamento do cwebp com o convert do ImageMagick.

A densidade de compactação é melhor para mais de 99% das imagens da Web, o que sugere que é possível mudar de PNG para WebP com relativa facilidade.

Quando o WebP é executado com as configurações padrão, ele compacta 42% melhor do que libpng e 23% melhor do que ZopfliPNG. Isso sugere que o WebP é promissor para acelerar sites com muitas imagens.

Referências

  1. ImageMagick

  2. Pngcrush (link em inglês)

  3. ZopfliPNG

Os estudos a seguir não são patrocinados pelo Google, e o Google não necessariamente endossa a precisão de todo o conteúdo deles.

  1. Blog do Yoav Weiss (em inglês)