Jyrki Alakuijala, Ph.D., Google, Inc.
Vincent Rabaud, Ph.D., Google, Inc.
Ultimo aggiornamento: 1/08/2017
Riassunto: confrontiamo l'utilizzo delle risorse dell'encoder/decoder WebP con quello di PNG in modalità senza perdita di dati e con perdita di dati. Utilizziamo un corpus di 12.000 immagini PNG traslucide scelte casualmente dal web e misurazioni più semplici per mostrare una variazione del rendimento. Abbiamo ricompresso i file PNG nel nostro corpus per confrontare le immagini WebP con i PNG con dimensioni ottimizzate. Nei nostri risultati mostriamo che WebP rappresenta una valida alternativa al formato PNG per l'utilizzo sul web per quanto riguarda dimensioni e velocità di elaborazione.
Introduzione
WebP supporta immagini senza perdita di dati e traslucidi, che lo rendono un'alternativa al formato PNG. Molte delle tecniche fondamentali utilizzate per la compressione PNG, come la codifica dei dizionari, la codifica di Huffman e la trasformazione dell'indicizzazione dei colori, sono supportate anche in WebP, il che si traduce in velocità e densità di compressione simili nel peggiore dei casi. Allo stesso tempo, una serie di nuove funzionalità, come codici entropia separati per diversi canali di colore, località 2D delle distanze di riferimento a ritroso e una cache dei colori per i colori utilizzati di recente, consentono una migliore densità di compressione per la maggior parte delle immagini.
Confrontiamo le prestazioni di WebP con quelle dei file PNG altamente compressi con pngcrush e ZopfliPNG. Abbiamo ricompresso il nostro corpus di riferimento di immagini web utilizzando le best practice e confrontato la compressione WebP sia senza perdita di dati che con perdita di dati con questo corpus. Oltre al corpus di riferimento, abbiamo scelto due immagini più grandi, una fotografica e l'altra grafica, per il benchmarking di velocità e memoria dell'utilizzo.
È stata dimostrata una velocità di decodifica maggiore rispetto al formato PNG, nonché una compressione più densa del 23% rispetto a quella che si può ottenere utilizzando il formato PNG odierno. Concludiamo che WebP sostituisce in modo più efficiente il formato dell'immagine PNG attuale. Inoltre, la compressione delle immagini con perdita di dati con supporto alpha senza perdita offre ulteriori possibilità per accelerare i siti web.
Metodi
Strumenti a riga di comando
Per misurare le prestazioni, utilizziamo i seguenti strumenti a riga di comando:
cwebp e dwebp. Questi strumenti che fanno parte della libreria libwebp (compilata dall'head).
converti. Questo è uno strumento a riga di comando che fa parte del software ImageMagick (6.7.7-10 2017-07-21).
pngcrush 1.8.12 (30 lug 2017)
ZopfliPNG (17 luglio 2017)
Utilizziamo gli strumenti a riga di comando con i rispettivi flag di controllo. Ad esempio, se facciamo riferimento a cwebp -q 1 -m 0, significa che lo strumento cwebp è stato evocato con i flag -q 1 e -m 0.
Corpora immagine
Sono stati scelti tre corpora:
Una singola immagine fotografica (Figura 1),
Una singola immagine grafica con traslucenza (Figura 2) e
Un corpus web: 12.000 immagini PNG scelte casualmente con o senza traslucenza, sottoposte a scansione da internet. Queste immagini PNG sono ottimizzate tramite convert, pngcrush, ZopfliPNG e la versione più piccola di ogni immagine viene presa in considerazione per lo studio.
Figura 1. Immagine fotografica, 1024 x 752 pixel. Respirazione del fuoco "Jaipur Maharaja Brass Band" Chassepierre Belgio, Autore: Luc Viatour, Foto concessa con licenza Creative Commons Attribuzione-Condividi allo stesso modo 3.0 Unported. Il sito web dell'autore si trova qui.
Figura 2. Immagine grafica, 1024 x 752 pixel. Collage di immagini di Google Chart Tools
Per misurare la capacità completa del formato esistente, PNG, abbiamo ricompresso tutte queste immagini PNG originali utilizzando diversi metodi:
Imposta 8 bit per componente: converti input.png - depth 8 output.png
ImageMagick(1) senza predittori: convert input.png -quality 90 output-candidate.png
ImageMagick con predittori adattivi: convertire input.png -quality 95 output-candidate.png
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.
ZopfliPNG(3): zopflipng --lossy_transparency input.png output-candidate.png
ZopfliPNG con tutti i filtri: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparency input.png output-candidate.png
Risultati
Abbiamo calcolato la densità di compressione per ciascuna delle immagini nel corpus web, in relazione alle dimensioni ottimizzate delle immagini PNG, per tre metodi:
WebP lossless (impostazioni predefinite)
WebP senza perdita di dati con la dimensione più piccola (-m 6 -q 100)
il meglio di WebP senza perdita di dati e WebP con perdita di dati con alpha (impostazioni predefinite).
Abbiamo ordinato questi fattori di compressione e li abbiamo tracciati nella Figura 3.
Figura 3. Viene utilizzata come riferimento la densità di compressione PNG, che è pari a 1,0. Le stesse immagini vengono compresse utilizzando sia metodi senza perdita di dati che con perdita di dati. Per ogni immagine, viene calcolato il rapporto delle dimensioni rispetto al formato PNG compresso, mentre i rapporti relativi alle dimensioni vengono ordinati e mostrati per la compressione sia senza perdita di dati che con perdita. Per la curva di compressione con perdita di dati, la compressione senza perdita di dati viene scelta nei casi in cui produce un'immagine WebP più piccola.
WebP va oltre la densità di compressione PNG sia per libpng alla massima qualità (conversione) che per ZopfliPNG (Tabella 1), con velocità di codifica (Tabella 2) e di decodifica (Tabella 3) sostanzialmente paragonabili a quelle di PNG.
Tabella 1. Media di bit per pixel per i tre corpora utilizzando i diversi metodi di compressione.
| Set di immagini | qualità di conversione 95 | ZopfliPNG | WebP senza perdita di dati -q 0 -m 1 | WebP lossless (impostazioni predefinite) | WebP senza perdita di dati -m 6 -q 100 | WebP con perdita di dati con alpha |
|---|---|---|---|---|---|---|
| foto | 12.3 | 12.2 | 10.5 | 10.1 | 9.83 | 0.81 |
| esplicito | 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 |
Tabella 2. Tempo di codifica medio per corpora e per diversi metodi di compressione.
| Set di immagini | qualità di conversione 95 | ZopfliPNG | WebP senza perdita di dati -q 0 -m 1 | WebP lossless (impostazioni predefinite) | WebP senza perdita di dati -m 6 -q 100 | WebP con perdita di dati con alpha |
|---|---|---|---|---|---|---|
| foto | 0,500 sec | 8,7 sec | 0,293 sec | 0,780 sec | 8,440 sec | 0,111 s |
| esplicito | 0,179 sec | 14 sec | 0,065 sec | 0,140 sec | 3,510 sec | 0,184 sec |
| Web | 0,040 s | 1,55 sec | 0,017 s | 0,072 sec | 2,454 sec | 0,020 sec |
Tabella 3. Tempo di decodifica medio dei tre corpora per i file immagine compressi con metodi e impostazioni diversi.
| Set di immagini | qualità di conversione 95 | ZopfliPNG | WebP senza perdita di dati -q 0 -m 1 | WebP lossless (impostazioni predefinite) | WebP senza perdita di dati -m 6 -q 100 | WebP con perdita di dati con alpha |
|---|---|---|---|---|---|---|
| foto | 0,027 s | 0,026 sec | 0,027 s | 0,026 sec | 0,027 | 0,012 sec |
| Grafica | 0,049 s | 0,015 s | 0,005 sec | 0,005 sec | 0.003 | 0,010 sec |
| Web | 0,007 s | 0,005 sec | 0,003 sec | 0,003 sec | 0.003 | 0,003 sec |
Profilazione della memoria
Per la profilazione della memoria, abbiamo registrato la dimensione massima del set residente come riportata da /usr/bin/time -v
Per il corpus web, solo le dimensioni dell'immagine più grande definiscono l'utilizzo massimo della memoria. Per definire meglio la misurazione della memoria, utilizziamo una singola immagine fotografica (Figura 1) per offrire una panoramica dell'utilizzo della memoria. L'immagine grafica fornisce risultati simili.
Abbiamo misurato da 10 a 19 MiB per libpng e ZopfliPNG e 25 MiB e 32 MiB per la codifica WebP senza perdita di dati con le impostazioni -q 0 -m 1 e -q 95 (con un valore predefinito di -m).
In un esperimento di decodifica, la dimensione Converti -ridimensiona 1 x 1 utilizza 10 MiB per i file PNG generati da libpng e ZopfliPNG. Con cwebp, la decodifica senza perdita di dati WebP usa 7 MiB e la decodifica con perdita di 3 MiB.
Conclusioni
Abbiamo dimostrato che le velocità di codifica e decodifica sono nello stesso dominio di quelle in formato PNG. C'è un aumento dell'utilizzo della memoria durante la fase di codifica, ma la fase di decodifica mostra una diminuzione soddisfacente, almeno quando si confronta il comportamento di cwebp con quello della conversione di ImageMagick.
La densità di compressione è migliore per oltre il 99% delle immagini web, il che significa che è possibile passare relativamente facilmente da PNG a WebP.
Quando viene eseguito con le impostazioni predefinite, WebP comprime il 42% in modo migliore rispetto a libpng e il 23% in meglio rispetto a ZopfliPNG. Ciò suggerisce che WebP promette di accelerare i siti web con molte immagini.
Riferimenti
Link esterni
Di seguito sono riportati studi indipendenti non sponsorizzati da Google e Google non garantisce necessariamente la correttezza di tutti i loro contenuti.