JPEG del 35% più piccoli grazie al nuovo algoritmo di Google

JPEG del 35% più piccoli grazie al nuovo algoritmo di Google

Un nuovo algoritmo open-source di Google permette di risparmiare il 35% di spazio con i file JPEG. La sua implementazione però è attualmente poco pratica, ma i risultati assolutamente convincenti

di Nino Grasso pubblicata il , alle 16:31 nel canale Web
Google
 

Google ha rivelato i primi dettagli di un nuovo encoder JPEG, chiamato Guetzli, che può ridurre le dimensioni delle immagini fino ad un massimo del 45% senza un evidente degrado nella qualità finale. L'obiettivo della compagnia è rendere il caricamento delle pagine il più rapido possibile in modo da migliorare l'esperienza d'utilizzo (e rendere più piacevoli le sue pubblicità). Con una ricerca la società ha appurato che la stragrande maggioranza delle immagini sul web è in formato JPEG, e queste immagini rappresentano all'incirca i due terzi delle dimensioni dell'intera pagina.


Da sinistra verso destra: non compresso, libjpeg e Guetzli

Diminuire le dimensioni delle immagini JPEG è da tempo una missione per la compagnia, che nel 2014 debuttava con un nuovo formato, WebP, che riusciva a ridurre l'impronta sul disco dei contenuti visivi di circa il 10%. La modalità di funzionamento del nuovo Guetzli è simile a quella di Zopfli con i file PNG e gzip, e riprende il vantaggio di poter continuare a sfruttare lo stesso formato e la stessa estensione che da anni è sinonimo di immagini sul web. Del resto sebbene WebP sia utilizzato da alcune realtà, non possiamo dire purtroppo che sia diventato popolare.

Guetzli viene descritto come "Perceptually Guided JPEG Encoder": ottimizza le immagini e poi utilizza un modello di visione umana sviluppato da Google, chiamato Butteraugli, che punta a individuare pattern di compressione tali che il file compresso non sia distinguibile da quello originale per l'occhio umano. Secondo documento redatto da diversi ricercatori, Butteraugli si basa su una metrica "psicovisiva" che prende come riferimento il funzionamento della vista umana. Ad esempio l'occhio umano ha una risoluzione spaziale inferiore nel blu, rispetto a verde e rosso, e il numero di recettori nell'area ad "alta risoluzione" del blu della retina è prossimo allo zero.

Eventuali variazioni di piccola entità nei colori tendenti al blu possono essere calcolate in maniera meno precisa, "errore" che non può essere accettato ad esempio con altre tonalità. Nel documento si legge anche che l'algoritmo fa riferimento al modo in cui il cervello si adatta a quello che recepisce dagli occhi, il tutto con l'unico fine di risparmiare anche quello che sembra il più insignificante kilobyte di dati in eccesso. Guetzli produce quindi una compressione "omogenea" e non occasionale come altri encoder, e non provoca i consueti artefatti JPEG.

Al momento però c'è un problema evidente nell'uso di Guetzli sui siti web. Gli autori del documento ammettono che il suo uso non potrebbe essere così conveniente perché i tempi di elaborazione delle immagini potrebbero controbilanciare il tempo guadagnato nel download delle stesse. In altre parole Guetzli è più pesante da decodificare rispetto ad altre opzioni di compressione JPEG (libjpeg ad esempio), e la sua implementazione ad oggi non porterebbe benefici in termini di tempo. Ma potrebbe essere l'inizio di un nuovo corso nella ricerca sugli algoritmi di compressione.

Gli autori del documento di cui sopra lo sperano vivamente, e infine scrivono: "Nonostante Guetzli sia troppo lento per molti utilizzi pratici, speriamo che possa mostrare la direzione per il futuro della progettazione dei formati di immagine".

16 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Anderaz17 Marzo 2017, 18:14 #1
Io, solo guardando quegli ingrandimenti, noto un'evidente perdita di dettaglio cromatico. E non sul blu...
blackshard17 Marzo 2017, 19:45 #2
Al lavoro oggi ho compilato il codice e provato l'eseguibile su una comunissima immagine jpeg di 1600x1200 pixel. Risultato: il processo è stato ucciso perché ad un certo punto ha superato il limite dei 4gb di memoria concesso ad un processo.

Riprovato con una immagine da 220x156 pixel, ha impiegato 6 secondi per comprimerla.

Le jpeg prodotte saranno anche il 35% più piccole, ma così come è ora è totalmente inservibile.
nastys17 Marzo 2017, 20:54 #3
Originariamente inviato da: blackshard
Al lavoro oggi ho compilato il codice e provato l'eseguibile su una comunissima immagine jpeg di 1600x1200 pixel. Risultato: il processo è stato ucciso perché ad un certo punto ha superato il limite dei 4gb di memoria concesso ad un processo.

Riprovato con una immagine da 220x156 pixel, ha impiegato 6 secondi per comprimerla.

Le jpeg prodotte saranno anche il 35% più piccole, ma così come è ora è totalmente inservibile.


Limite dei 4 GB? Prova a compilarlo a 64 bit.
Sorgiva17 Marzo 2017, 22:36 #4

Troppi inutili formati

Chissà che fine avrà fatto il famoso JPEG 2000 e perché, nonostante l'evidente efficienza conclamata, la sua diffusione sia rimasta nel tempo limitata con bastoni in mezzo alle ruote da chi non lo voleva non si sa per quali ragioni…
Hiei360018 Marzo 2017, 03:53 #5
I formati compressi dovrebbero essere aboliti...non siamo più ai tempi delle connessioni a 56k(almeno per la maggior parte del mondo).

Si dovrebbe incoraggiare la diffusione di formati loseless come il PNG(anche se questo ha un livello di compressione alquanto scarso),o alternative migliori.
cdimauro18 Marzo 2017, 07:09 #6
I formati lossy (perché anche PNG è compresso, per l'appunto) hanno ancora oggi il loro perché, e dunque non vedo perché dovrebbero essere eliminati.

Piuttosto è un peccato che JPEG 2000 non si sia diffuso, ma avendone sviluppato un decoder una dozzina d'anni fa, capisco che, almeno all'epoca, era troppo complesso e richiedeva troppe risorse. Ma oggi la questione è diversa, e dovrebbe essere tenuto in considerazione, IMO.

Quanto alla notizia, credo che ci sia un errore nel testo: non è certamente la decompressione a richiedere tante risorse, ma soltanto la compressione.
lucusta18 Marzo 2017, 08:46 #7
Per rendere più veloce il caricamento delle pagine, basta eliminare la pubblicità, almeno quella fatta male.

Ho dovuto mettere sotto proxy il browser del telefonino, sennò molte pagine saturavano la memoria.

Altro che compressione... Beato adblock.
danieleg.dg18 Marzo 2017, 08:52 #8
Originariamente inviato da: blackshard
Al lavoro oggi ho compilato il codice e provato l'eseguibile su una comunissima immagine jpeg di 1600x1200 pixel. Risultato: il processo è stato ucciso perché ad un certo punto ha superato il limite dei 4gb di memoria concesso ad un processo.

Riprovato con una immagine da 220x156 pixel, ha impiegato 6 secondi per comprimerla.

Le jpeg prodotte saranno anche il 35% più piccole, ma così come è ora è totalmente inservibile.


Sulla pagina del progetto c'è scritto che richiede circa 300MB di Ram per ogni megapixel dell'immagine. Sicuramente molto esoso, ma un'immagine 1600x1200 non dovrebbe creare grossi problemi.
globi18 Marzo 2017, 10:21 #9

Guetzli

significa biscotto in dialetto svizzero, pare infatti sia stato sviluppato a Zurigo.
Hiei360018 Marzo 2017, 14:51 #10
Originariamente inviato da: cdimauro
I formati lossy (perché anche PNG è compresso, per l'appunto) hanno ancora oggi il loro perché, e dunque non vedo perché dovrebbero essere eliminati.


No PNG non è un formato lossy,la compressione si riferisce alla riduzione dei dati che l'informazione dell'immagine occupa nel file,che varia a seconda dell'algoritmo usato,ma il formato PNG in se non è lossy.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^