Mozilla lancia mozjpeg per ridurre dimensione e tempo di caricamento delle pagine web

Mozilla lancia mozjpeg per ridurre dimensione e tempo di caricamento delle pagine web

Mozilla ha annunciato oggi un nuovo progetto chiamato mozjpeg, con l'obiettivo di realizzare una nuova compressione JPEG che permette un risparmio del 10% a parità di qualità rispetto al formato originale

di Nino Grasso pubblicata il , alle 08:31 nel canale Web
Mozilla
 

Mozilla ha lanciato un nuovo encoder JPEG, chiamato mozjpeg, che permette di offrire rapporti di compressione superiori rispetto al passato. Al tempo stesso, la società si è prefissata l'obiettivo di mantenere la compatibilità con i decoder attualmente disponibili, anche per gli aggiornamenti futuri.

Nel corso degli anni il numero di immagini medie presenti nei siti web è cresciuto esponenzialmente, così come le dimensioni di ogni singola immagine. Dal momento che gli standard più diffusi (HTML, CSS, JS) sono sensibilmente meno "pesanti", in relazione, Mozilla sottolinea come siano proprio le immagini a rappresentare la maggior parte del traffico di rete per ogni singola pagina visitata.

L'obiettivo di Mozilla con il nuovo encoder è quello di ridurre notevolmente le dimensioni delle pagine, utilizzando un processo nuovo per lo standard JPEG, utilizzato dal 1992 e ancora oggi il formato di compressione più utilizzato sul web. JPEG è inoltre praticamente l'unico formato che ha raggiunto una compatibilità pressoché universale, non solo con i browser web, ma anche con una folta schiera di software per la visualizzazione e l'editing delle immagini.

Vale la pena, pertanto, cercare di ottimizzarlo piuttosto che creare standard di compressione del tutto nuovi, anche se più efficienti, come fatto da altre società: "Rimpiazzare il formato JPEG con qualcosa di migliore è stato un frequente argomento di discussione. Lo svantaggio principale di allontanarsi da JPEG è che sarebbe necessario attraversare un periodo pluriennale in cui quello nuovo sarebbe scarsamente compatibile con il software distribuito globalmente", scrive la società sul blog proprietario.

Non dubitiamo che ci sarà un momento in cui varrà la pena fare questo sacrificio, e potrebbe anche avvenire fra breve. Tuttavia, anche dopo che la transizione avrà inizio, sarà ancora JPEG il formato ad essere maggiormente utilizzato". Secondo la compagnia il formato JPEG può essere ulteriormente "spremuto" rispetto a quanto non viene fatto ad oggi dopo decenni dal suo rilascio iniziale.

La versione 1.0 di mozjpeg non è altro che un fork di libjpeg-turbo con in aggiunta la funzionalità "jpgcrush", ovvero uno script Perl scritto da Loren Merritt che riduce le dimensioni dei file in modo "lossless", ovvero senza alcuna perdita nella qualità dell'immagine creando il file in formato Progressive. Utilizzando mozjpeg si avranno vantaggi sulle dimensioni dal 2 al 6% da PNG convertiti in JPEG con libjpeg-turbo, e circa il 10% su un campione di circa 1.500 sample del database Wikimedia, senza perdere assolutamente sulla qualità del file compresso.

Mozilla ammette che non è a conoscenza di altri progetti di encoder che incorporano tale funzionalità, mentre il prossimo obiettivo della società è di migliorare ulteriormente l'encoding utilizzando la trellis quantization.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

10 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Hal200108 Marzo 2014, 11:36 #2
Originariamente inviato da: cata81


Royalties. Ruota tutto intorno ai soldi.
djfix1308 Marzo 2014, 12:31 #3
io per certi versi sul lato qualitativo trovo buono il PNG.
poi a mio parere sarebbe opportuno ampliare invece il GIF a più colori perchè oggi 256 colori è veramente penoso.
calabar08 Marzo 2014, 12:59 #4
Originariamente inviato da: cata81

Al di la della questione royalties, dato che non ben compreso come funzioni la compatibilità del nuovo formato mozilla, la differenza potrebbe stare tutta li.
JPEG2000 è fallito anche perchè scarsamente supportato, se questo formato risolvesse il problema sarebbe un bel passo avanti.

Originariamente inviato da: djfix13
io per certi versi sul lato qualitativo trovo buono il PNG.

Lo credo bene, è un formato lossless.
pincapobianco08 Marzo 2014, 15:58 #5
nel caricamento delle pagine web, mozilla ha sempre fatto schifo rispetto a chrome
DKDIB09 Marzo 2014, 10:31 #6
[color=red]Cata81 wrote:[/color]
> http://it.wikipedia.org/wiki/JPEG_2000

Qua si parla di migliorare JPEG, non di creare un nuovo formato.
Come scritto nell'articolo, sarebbe improponibile rimpiazzare JPEG ed IMHO non verrà mai fatto.



[color=red]DJfix13 wrote:[/color]
> [...] sarebbe opportuno ampliare invece il GIF a più colori perchè oggi 256
> colori è veramente penoso.

Come ha già scritto Calabar, qua si parla di formati lossy, non lossless.
A parte questo, aumentare i colori usabili nel formato GIF significherebbe creare un formato completamente nuovo e fra i lossless esiste già PNG.

Se poi si volessero creare delle immagini animate a 32 bit, anche lì esiste già un'alternativa a GIF89a: MNG. Un formato nuovo che, guardacaso, nessuno si è mai cagato...



[color=red]Pincapobianco wrote:[/color]
> nel caricamento delle pagine web, mozilla ha sempre fatto schifo rispetto a
> chrome

Eh sì, è vero: fra l'altro, lo sai che oggi mia nonna ha preparato il tiramisù?
...
'Zzo c'entra?!
pincapobianco09 Marzo 2014, 14:48 #7
Originariamente inviato da: DKDIB
[color=red]Cata81 wrote:[/color]
> http://it.wikipedia.org/wiki/JPEG_2000

Qua si parla di migliorare JPEG, non di creare un nuovo formato.
Come scritto nell'articolo, sarebbe improponibile rimpiazzare JPEG ed IMHO non verrà mai fatto.



[color=red]DJfix13 wrote:[/color]
> [...] sarebbe opportuno ampliare invece il GIF a più colori perchè oggi 256
> colori è veramente penoso.

Come ha già scritto Calabar, qua si parla di formati lossy, non lossless.
A parte questo, aumentare i colori usabili nel formato GIF significherebbe creare un formato completamente nuovo e fra i lossless esiste già PNG.

Se poi si volessero creare delle immagini animate a 32 bit, anche lì esiste già un'alternativa a GIF89a: MNG. Un formato nuovo che, guardacaso, nessuno si è mai cagato...



[color=red]Pincapobianco wrote:[/color]
> nel caricamento delle pagine web, mozilla ha sempre fatto schifo rispetto a
> chrome

Eh sì, è vero: fra l'altro, lo sai che oggi mia nonna ha preparato il tiramisù?
...
'Zzo c'entra?!


ma chi 'Zzo vuoi che usi il GIF? la tua è pura fantascienza
Cunctator8610 Marzo 2014, 09:54 #8
Originariamente inviato da: pincapobianco
ma chi 'Zzo vuoi che usi il GIF? la tua è pura fantascienza


Beh per cominciare tu, o pensi che quella simpatica faccina con il pesce sia un'illusione ottica? Del resto stava rispondendo a djfix, mi sembrava abbastanza evidente ( lo ha pure quotato ).
Sul fatto che firefox abbia perso un po di sprint ( per usare un eufemismo ) hai ragione, ma come la storia della nonna di dkdib e' decisamente offtopic.

Se non ho capito male comunque si tratta di applicare una compressione tipo zlib al jpeg, che mi sembra abbastanza inutile tenendo presente che HTTP 1.1 prevede una compressione simile "on the fly" sulla connessione e che lo stesso draft jpeg contempla una codifica a la Huffman come ultimo stadio...

Ho capito male?
Zenida11 Marzo 2014, 00:43 #9
Originariamente inviato da: djfix13
io per certi versi sul lato qualitativo trovo buono il PNG.


Hanno già risposto... ma fidati non è un parere soggettivo, anzi, è oggettivo che il PNG sia qualitativamente superiore al JPEG per TUTTI I VERSI, appunto perchè, come è stato già detto, è un formato lossless (quindi senza perdita di informazioni, ovvero una compressione non distruttiva). Il prezzo da pagare è ovviamente un maggior peso del file.

Originariamente inviato da: djfix13
poi a mio parere sarebbe opportuno ampliare invece il GIF a più colori perchè oggi 256 colori è veramente penoso.


Non avrebbe senso perchè il formato GIF nasce proprio per essere estremamente leggero ed aumentare il numero di colori andrebbe contro questo obiettivo, poi a quello ci pensano già MPEG, H264, ecc.. ovvero i formati video. Un numero superiore di colori significa creare una sequenza di fotogrammi ad alta qualità... quindi a questo punto meglio sfruttare i formati video già esistenti.

Originariamente inviato da: pincapobianco
nel caricamento delle pagine web, mozilla ha sempre fatto schifo rispetto a chrome


Premetto che uso quasi esclusivamente Chrome... ma la fonte?

Originariamente inviato da: pincapobianco
ma chi 'Zzo vuoi che usi il GIF? la tua è pura fantascienza


Originariamente inviato da: Cunctator86
Beh per cominciare tu, o pensi che quella simpatica faccina con il pesce sia un'illusione ottica?


ahahah ti stimo
beh a quanto pare si fa critica giusto per dare fiato alla bocca

Originariamente inviato da: Cunctator86
Se non ho capito male comunque si tratta di applicare una compressione tipo zlib al jpeg, che mi sembra abbastanza inutile tenendo presente che HTTP 1.1 prevede una compressione simile "on the fly" sulla connessione e che lo stesso draft jpeg contempla una codifica a la Huffman come ultimo stadio...

Ho capito male?

Non sono molto ferrato in materia... ma il fatto della compressione tramite protocollo non avviene solo tramite HTTPS? Ad ogni modo non credo si tratti di applicare una compressione zlib al jpeg, lo sanno tutti che la compressione di un formato compresso in realtà non porta alcun beneficio reale, bisogna solo riscriverne l'algoritmo in maniera più efficiente, migliorando sia la parte lossy che lossless.
Anche se non capisco come faranno a mantenerne la compatibilità se a parte l'estensione del file la decodifica avrà bisogna di un nuovo encoder
Cunctator8612 Marzo 2014, 10:38 #10
Originariamente inviato da: Zenida
Non sono molto ferrato in materia... ma il fatto della compressione tramite protocollo non avviene solo tramite HTTPS?

In realta' no, la compressione viene fatta ( SE viene fatta ) sul payload HTTP ( anche 1.0 ) a prescindere dall'eventuale tunnel SSL/TLS
Originariamente inviato da: Zenida
Ad ogni modo non credo si tratti di applicare una compressione zlib al jpeg, lo sanno tutti che la compressione di un formato compresso in realtà non porta alcun beneficio reale, bisogna solo riscriverne l'algoritmo in maniera più efficiente, migliorando sia la parte lossy che lossless.
Anche se non capisco come faranno a mantenerne la compatibilità se a parte l'estensione del file la decodifica avrà bisogna di un nuovo encoder

Mi riferivo a quanto scritto nell'articolo
La versione 1.0 di mozjpeg*non è altro che un fork di libjpeg-turbo con in aggiunta la funzionalità "jpgcrush", ovvero uno script Perl scritto da Loren Merritt che riduce le dimensioni dei file in modo "lossless"

Anche se a giudicare da questo/i commit sembrerebbe tutt'altro...
La redazione potrebbe fornire le fonti della supposizione sopracitata?

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.
 
^