Link alla notizia: http://www.hwupgrade.it/news/web/mozilla-lancia-mozjpeg-per-ridurre-dimensione-e-tempo-di-caricamento-delle-pagine-web_51324.html

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

Click sul link per visualizzare la notizia.

http://it.wikipedia.org/wiki/JPEG_2000

http://it.wikipedia.org/wiki/JPEG_2000

Royalties. Ruota tutto intorno ai soldi.

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.

http://it.wikipedia.org/wiki/JPEG_2000
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.

io per certi versi sul lato qualitativo trovo buono il PNG.
Lo credo bene, è un formato lossless. :p

nel caricamento delle pagine web, mozilla ha sempre fatto schifo rispetto a chrome

Cata81 wrote:
> 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.



DJfix13 wrote:
> [...] 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... :rolleyes:



Pincapobianco wrote:
> 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?! :muro:

Cata81 wrote:
> 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.



DJfix13 wrote:
> [...] 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... :rolleyes:



Pincapobianco wrote:
> 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?! :muro:

ma chi 'Zzo vuoi che usi il GIF? la tua è pura fantascienza :sofico:

ma chi 'Zzo vuoi che usi il GIF? la tua è pura fantascienza :sofico:

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?

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.

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.

nel caricamento delle pagine web, mozilla ha sempre fatto schifo rispetto a chrome

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

ma chi 'Zzo vuoi che usi il GIF? la tua è pura fantascienza :sofico:

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

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

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

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 (https://tools.ietf.org/html/rfc1945#section-3.5) ) a prescindere dall'eventuale tunnel SSL/TLS :)
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 (https://github.com/mozilla/mozjpeg/commit/c31dea21188b48498d471650ec1f18bc727c9a36) commit sembrerebbe tutt'altro...
La redazione potrebbe fornire le fonti della supposizione sopracitata?