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

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

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

Introdução

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

Nesse trabalho, comparamos o desempenho de WebPs com PNGs que são 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 a outra gráfica, para a comparação de uso de velocidade e memória.

Foi demonstrado que velocidades de decodificação mais rápidas que o PNG foram demonstradas, bem como uma compactação de 23% mais densa do que o que pode ser alcançado com 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 compressão de imagem com perda com suporte a Alfa sem perda oferece ainda mais possibilidades para acelerar sites.

Métodos

Ferramentas de linha de comando

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

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

  2. converter. Esta é uma ferramenta de linha de comando 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, isso significa que a ferramenta cwebp foi evocada com as sinalizações -q 1 e -m 0.

Imagem corporativa

Três corpora foram escolhidos:

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

  2. uma única imagem gráfica com translucidez (Figura 2).

  3. Um corpus da Web: 12.000 imagens PNG selecionadas aleatoriamente, com translucidez ou não, rastreadas da Internet. Essas imagens PNG são otimizadas por converter, pngcrush, ZopfliPNG e a menor versão de cada imagem será considerada para o estudo.

Figura 1. Imagem fotográfica, 1.024 x 752 pixels. Fogo "Jaipur Maharaja Brass Band" Chassepierre, Bélgica, Autor: Luc Viatour, Foto licenciada de acordo com a Licença Creative Commons Attribution-Share Alike 3.0 Unported. O site do autor está aqui.

Figura 2. Imagem gráfica, 1024 x 752 pixels. Colagens 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. Fixar em 8 bits por componente: convert input.png -depth 8 output.png.

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

  3. ImageMagick com preditores adaptáveis: 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 para 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 perda (configurações padrão)

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

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

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

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

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

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

Conjunto de imagens converter -qualidade 95 ZopfliPNG WebP sem perda -q 0 -m 1 WebP sem perda (configurações padrão) WebP sem perda -m 6 -q 100 WebP com perda com 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 do corpora e para diferentes métodos de compactação.

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

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

Conjunto de imagens converter -qualidade 95 ZopfliPNG WebP sem perda -q 0 -m 1 WebP sem perda (configurações padrão) WebP sem perda -m 6 -q 100 WebP com perda com 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,010s
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 a criação de 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 maior imagem define o uso máximo de memória. Para manter a medição de memória melhor definida, usamos uma única imagem fotográfica (Figura 1) para fornecer uma visão geral do uso de memória. A imagem gráfica fornece resultados semelhantes.

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

Em um experimento de decodificação, a conversão de redimensionamento de 1 x 1 usa 10 MiB para os arquivos libpng e ZopfliPNG gerados em PNG. Com o cwebp, a decodificação do WebP sem perda usa 7 MiB e a decodificação com perda de 3 MiB.

Conclusões

Mostramos que as velocidades de codificação e de decodificação estão no mesmo domínio das 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 de cwebp ao da conversão do ImageMagick.

A densidade de compactação é melhor para mais de 99% das imagens da Web, o que sugere que é fácil mudar de PNG para WebP.

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

Referências

  1. ImageMagick

  2. Pngcrush (link em inglês)

  3. ZopfliPNG

Confira a seguir estudos independentes não patrocinados pelo Google, que não garante a exatidão de todo o conteúdo.

  1. Blog de Yoav Weiss