E’ di pochi giorni la notizia che Google ha realizzato un nuovo formato di compressione delle immagini. Sulla carta dovrebbe rappresentare il santo Graal, e a tesserne le lodi ovviamente non poteva che essere lo stesso colosso di Mountain View, ormai lanciato nella ridefinizione degli strumenti che utilizziamo nella nostra quotidianità.
In realtà WebP nasce per soddisfare un’esigenza che BigG sente pesante, com’è attestato nel blog in cui è stata comunicata la notizia: il 65% dei dati scaricati da pagine web è costituito da immagini. Poiché il core business di quest’azienda è incentrato in questo settore, si fa presto a comprendere il suo interesse nella riduzione dello spazio da esse occupato.
L’idea alla base è piuttosto semplice: impiegare il codice del codec video VP8 (di cui di recente ha rilasciato i sorgenti) sfruttandone la parte dedicata alla compressione dei cosiddetti intra-frame (chiamati spesso anche key frame; per semplicità: immagini che non hanno bisogno di altre informazioni per poter essere codificate), incapsulando il risultato in un file RIFF di appena 20 byte.
Si tratta, quindi, di due aspetti diversi, che sono stati combinati per ottenere la migliore soluzione dal punto di vista del mero spazio occupato. Da una parte c’è l’esigenza di risparmiare quanti più byte possibili per la mera informazione dell’immagine, e dall’altra la necessità di impacchettare questi dati in un contenitore minimale (ma estendibile) per poterli leggere.
Ognuno presenta pregi e difetti nella propria area di competenza, ma è chiaro che la parte del leone è costituita dal primo tipo. Non può certo essere il contenitore il problema principale da risolvere, anche se ha sicuramente il suo peso (per le limitazioni che ne possono derivare, e per il parser che dovrà leggerlo e interpretarne il contenuto; ne parleremo in futuro).
La qualità dell’immagine dipende dal tipo di codifica utilizzata e, dai test effettuati in casa, Google dichiara che, su un campione di 1 milione di immagini prese a caso fra JPEG, GIF e PNG, il risultato ottenuto da WebP è di una riduzione media del 39%, “senza aver compromesso in maniera percettibile la qualità visiva”.
Questa metodologia di test è, però, ampiamente criticabile. In primo luogo non si prendono immagini a caso. Lo sanno bene le aziende che operano nel settore, che nel tempo hanno creato archivi di foto che riproducono gli ambienti e le situazioni più comuni, in modo da avere un campione realmente rappresentativo da utilizzare per effettuare confronti durante la sperimentazione di nuovi algoritmi.
Secondo, ricomprimere immagini già compresse con JPEG dovrebbe essere evitato, perché l’operazione ha distrutto il segnale originale, introducendo tra l’altro artefatti visivi. Inoltre esistono diversi codec JPEG, implementati in maniera diversa (e magari con diverse tabelle di quantizzazione), ma soprattutto chi ha prodotto l’immagine avrà usato un diverso livello di quantizzazione (il famoso parametro “qualità”). Quindi è bene partire sempre dal segnale originale, e vedere come si comporta il nuovo codec.
Terzo, è vero che il formato di per sé è lossless (senza perdita), ma le GIF hanno già subito una pesante operazione di quantizzazione, dovuta alla riduzione della palette dei colori ai soli 256 permessi da questo formato. Per cui parecchia dell’informazione del segnale è andata perduta.
Rimane il PNG quale formato utile allo scopo, che è lossless e non opera alcuna operazione sull’immagine di partenza, preservando quindi il segnale.
L’operazione corretta, quindi, dovrebbe essere quella di comprimere le sole immagini PNG con un buon codec JPEG e il nuovo WebP, assicurandosi che le immagini risultanti siano quasi del tutto indistinguibili visivamente, e comparando poi la dimensione dei file ottenuti.
Da quanto riportato da Google sembra, però, che sia stata “bovinamente” eseguita una compressione di tutte le immagini campione, conteggiando poi la dimensione dei file e tirando fuori la famigerata media del 39%. Tutto ciò mi sembra insensato, alla luce di quanto esposto finora e dal fatto che il conteggio su file GIF e PNG andava assolutamente evitato.
Il che è a dir poco lapalissiano, visto che un’immagine lossless occuperà generalmente di gran lunga più spazio rispetto alla medesima, ma compressa in un formato lossy. Il tutto falsando le statistiche, ovviamente, ed è tanto più importante sottolinearlo, quanto maggior enfasi sia stata data ai “numeri”, appunto.
Leggendo lo studio comparativo saltano fuori altre cose interessanti. Vediamo che è stato scelto un PSNR di 42 come target per la “qualità” delle immagini risultati, ma questa è una misura ampiamente opinabile. Ne esistono di migliori (come la SSIM), ma il giudizio finale di un occhio esperto lo ritengo insostituibile.
La seconda è che, non paghi di aver usato immagini già compresse in JPEG, queste sono state a loro volta ricompresse per ottenere il suddetto PSNR di 42… No comment.
Detto ciò, i risultati sembrano lusinghieri, numeri alla mano, ma non eccezionali, e presentano artefatti visivi che sono tutt’altro che “impercettibili”, come si può vedere anche dal set di immagini scaricabile dal sito (il pacchetto si trova qui) .
In particolare si può notare una distorsione dei colori originali che sembrano più opachi (che vengono invece preservati da altri codec, come quello del JPEG 2000), l’evidenza di alcuni “blocchi” (dovuti alla suddivisione in blocchi, appunto, usata dall’algoritmo), ma soprattutto la presenza di texture “smussate” (come ad esempio l’increspatura della corteccia di un albero, che risulta invece “liscia”).
Riguardo a quest’ultima ho letto in giro ottimi giudizi da gente che trova il risultato “morbido” e più gradevole alla vista. Mi ricorda un proverbio arabo, di come un cammello possa trovare gustosi i rovi che mastica, non curandosi del sangue della sua bocca che fa da condimento…
E’ chiaro che da un formato lossy ci aspettiamo un “taglio” delle informazioni, e quindi dei dettagli: non si otterrebbero altrimenti fattori di compressione così elevati. Ma compiacersi della perdita di dettaglio lo trovo, diciamo, “singolare”.
Per il momento mi fermo, e invito chi fosse interessato a scaricare l’archivio con le immagini e visionarle (magari con l’aiuto dello zoom) per rendersi conto di quanto esposto finora. Nel prossimo articolo riguardo a WebP parlerò del contenitore e delle problematiche che si devono affrontare quando parliamo di formati per memorizzare immagini, alla luce anche della mia esperienza nello sviluppo di un decoder JPEG 2000.
segnalo questo post che approfondisce la questione tecnica:
http://x264dev.multimedia.cx/archives/541
Se i test sulla compressione sono realmente taroccati, il motivo della spinta di google su questo formato NON PUO’ essere quello della riduzione della banda e dello spazio di storage! Mi pare ovvio!
Probabilmente provano a fare lo sgambetto a qualcun’altro, anche se mi pare una cosa un po’ assurda…
Credo di aver capito il perchè google stia spingendo su questo formato.
Siccome è diventata un competitor in ambito mobile,questo darebbe una spinta verso i suoi dispositivi android che avrebbero nativamente webp nel codice……
quindi risulterebbe che i dispositivi che montano android con webp,risulterebbero molto più veloci e più parchi in termini di risorse,sbaglio????
forse, ma webP ha anche un costo in risorse sicuramente superiore a jpeg al momento della visualizzazione, non so l’ambito mobile quanto ne gioverebbe. secondo me sono solo problemi di spazio
In effetti siamo un po’ sul vago…
Fare “salva per il web” jpg con qualità 60 da una versione recente di Photoshop e compiere la stessa operazione da Irfanview da origine a dei risultati parecchio differenti. Per non parlare di una convert su unix…
Il jpg è vecchio e superato, punto, non ci piove, lo era già 10 anni fa ma il jpg2000 non è stato digerito.
E comunque Google è nostro amico…
Perché invece non estendere il formato PNG che mi sembra ricordare essere nato proprio come alternativa open al formato GIF?
Ci sono già implementazioni di PNG con compressione lossy. A parte il contenitore, non dovrebbe cambiare nulla in termini di qualità finale usare lo stesso algoritmo di compressione nel formato PNG e risulterebbe disponibile in maniera automatica a tutti quei programmi che fanno uso della libreria PNG per decodificare le immagini.
Sul WebP sono in parecchi ad avere dubbi sulla buona riuscita, anche considerata la (penosa) fine che ha fatto il Jpeg2000, superiore al progenitore, ma bistrattato dagli utenti. Non so perché ma mi vengono in mente anche altri standard del passato che non hanno visto prevalere la qualità ma una “sequela di eventi fortuiti” che ne hanno decretato il successo, benché tecnicamente siano stati inferiori alla concorrenza.
Però questa volta non è un formato creato e lasciato al caso in balia degli eventi. Il fatto che ci sia Google a gestirlo non è mica cosa da poco! Stiamo parlando di un’azienda che in internet predomina a livello mondiale su tutte le concorrenti ed ha le mani in tutti i servizi del web. In Google Docs c’è una funzione di “conversione al volo” per gli standard de facto. Di sicuro verrà adottato lo stesso metodo “trasparente” anche per il WebP, dove all’utente sarà chiesto di “spuntare” una casellina dopo l’upload. Se Picasa et similia integreranno questo sistema di conversione al volo, si avrà una diffusione capillare del WebP molto più veloce di quanto si pensi. Questo lato software, ma rimane la questione hardware: tutto ciò che oggi “produce” immagini usa Jpeg. Pensare di usare il WebP come sostituto immediato è impossibile. Per prendere una piega favorevole ci vorranno minimo cinque anni buoni, sempre che il WebP diventi de facto il successore del Jpeg.
Comunque l’evoluzione tecnologica non consente ad uno standard di durare troppo a lungo… Jpeg è sulla cresta dell’onda da più di 25 anni (me lo ricordo dai tempi dell’Amiga!). Quanti anni credete possa riuscire a reggere ancora? E’ giunta l’ora che lasci il passo a qualcosa di più innovativo ed evoluto, che occupi meno spazio e consenta di sfruttare le peculiarità di altri formati, ad es. il canale alpha per le trasparenze…
@supertigrotto: ed ecco che basterebbero immagini di qualità minore per un piccolo schermo, come quelle da codec VP8.
Sono perplesso perché comunque JPEG è affermato nessuno è riuscito a scalzarlo finora e per quanto confido nella potenza di google, mi pare un obiettivo fuori portata se le motivazioni non sono buone.
E quelle ufficiali non paiono esserlo …
resto con jpg.. sia perchè ho tonnellate di jpg sia perchè è uno standard ovunque ormai e non è che sia tutto questo pesante..
il nuovo sistema riduce il peso del X% ?.. mah.. tutti a fare miracoli.. io resto dell’idea che jpg ormai si è affermato ed è stabilmente al suo posto.. pesa poco.. semplicemente chi manda in giro immagini dovrebbe postarle della dimensione che serve e non sempre dimensioni enormi e poi riscalare il tutto..
se tutti muovessero immagini a risoluzione normale 1:1 per lo schermo il problema sarebbe già molto minore..
cmq.. mia opinione.. in fin dei conti io tutte le foto le ho in raw e in jpg e occupano un pochino :-D
@ Zeirus:, la fine di formati nuovi e “più meglio” è legata a un solo fatto: chi li sviluppa vuole mangiarci, e nessuno paga per un prodotto migliore se quello precedente e gratis fa la stessa cosa. Facesse cose diverse….. vedi mp3, serve per ascoltarsi musica in giro o sui computer con casse spesso discutibili, fa il suo mestiere, ha dei limiti che pesano a poca gente e soprattutto pesano solo a chi vorrebbe usarli in altri contesti rispetto a quelli per cui è stato inventato (vuoi l’alta qualità in metrò nell’ora di punta? o in macchina dentro un’ingorgo mentre tutti suonano il clacson?).
Qua le premesse sono differenti. L’interesse economico di introdurre il formato c’è: meno banda più risparmio, sia da parte dei servers di google sia da parte dei terminali mobili (durerà di più la decodifica, ma risparmi piccioli e tempo nel download, vuoi mettere?) e quindi degli utenti. Io dico che la possibilità per google di introdurre un formato nuovo e diffonderlo, ce l’ha e ci spero fortemente, e basterà che non lo ammazza con licenze assurde, e si diffonderà in fretta.
Chiaro, dev’essere prima almeno a livello di jpeg. Da quel che si discute non c’arriva manco per il c…
@Giuliano Galea: grazie per il link. Invito gli utenti a dargli un’occhiata per rendersi ulteriormente conto dei limiti del formato a livello di qualità dell’immagine finale.
Nel prossimo articolo aggiungerò altre considerazioni non specificamente legate alla qualità, per completare il discorso.
@TheKaneB: onestamente non mi ha mai sfiorato per la testa che Google potesse “taroccare” i risultati. Anche se, adesso che lo hai scritto, è una possibilità che potrebbe verificarsi (ma ritengo poco plausibile).
Piuttosto da quel che ho letto mi sono fatto l’idea che i test siano stati condotti con quella leggerezza tipica di chi non ha molta esperienza in questo campo.
@supertigrotto: non credo assolutamente che WebP possa essere un formato adatto al settore mobile. Magari di qualche smartphone di fascia alta sì, ma in generale richiede troppe risorse computazionali, come ha sottolineato il lettore floc.
@Nessuno: estendere il PNG significa cambiarlo in maniera consistente.
Un conto è aggiungere uno schema di predizione a quelli esistenti, e tutt’altra cosa utilizzare una “pipeline” completamente diversa per la de/codifica dell’immagine.
Perché quella esistente non è certo utilizzabile allo scopo, se vogliamo utilizzare degli algoritmi di compressione più avanzati.
@Zeirus: proprio il canale alpha al momento manca da WebP, anche se ne è prevista l’integrazione.
Al momento, quindi, WebP non può certo prendere il posto di PNG e GIF, che riescono a gestire la trasparenza, caratteristica molto utile per chi sviluppa siti web.
Avevo ancora un pentium MMX quando (credo 12-15 anni fa) quando sul cd di una rivista trovavi la demo di un programmino che comprimeva in modo eccezionale le immagini sfruttando algoritmi basati sui frattali, a parità di qualità si ottenevano dimensioni del 40-50% rispetto a una jpg! Il formato era *.fif, che fine hanno fatto? Se portavano avanti tecnologie simili, a quest’ora chissà chi avrebbe più sentito parlare di jpg?!
Richiedeva tempi di compressione ENORMI, e si basava su tecnologie proprietarie.
Per cui non ha avuto seguito (e non penso che l’avrebbe anche oggi).
Tempi di compressione lunghi per il mio vecchio pentium mmx 166mhz, non certo per i mostri da un 1ghz multicore che ci sono oggi perfino sui cellulari e poi ricordo che era molto impegnativa la compressione molto meno la decompressione. Purtoppo era proprietario e se la ditta è fallita non credo che sia un problema per BigG, andare a trovare quel vecchio progetto e portarlo avanti. Cmq la nostalgia mi ha spinto ad una piccola ricerchina: http://www.fortunecity.it/lunapark/sagra/5/fif.htm
Riguardo la qualità di compressione, ho controllato il set di immagini postato e, a parte la foto n. 7, le altre non hanno una differenza percettibile. Ho ripetutamente gaurdato le 2 versioni di ogni foto senza vedere differenze di nota.
Riguardo il formato GIF, c’è da precisare che è stato concepito alla fine degli anni 90 per utilizzare le palette di colori fino a 256. La quantizzazione per rappresentare fotografie invece che disegni è stato come voler portare al limite un formato di immagini che andava bene per l’epoca. Il PNG è stato invece concepito per il web e per l’eterogeneità delle immagini utilizzate dalle pagine web.
A parte questo, non trovo necessità di aggiungere un ulteriore formato.
Bella però la compressione frattale. C’è una libreria open dal nome infelice di Fiasco:
http://www.linuxjournal.com/node/4367/print
@Saverio Russo: la prima immagine (1_original.jpg e 1_webp.png) risulta già molto ricca di imperfezioni. Per notarle meglio, ti consiglio di usare uno zoom tipo 400%, aprire le due immagini con lo stesso programma su due finestre diverse, e alternarle velocemente con Alt-Tab.
Balzeranno immediatamente all’occhio quelle sulle texture (che sono veramente grossolane; si notano subito anche senza zoom) e sull’aberrazione del colore (nelle parti in cui sono presenti colori un po’ accesi).
@Flare: sui tempi di compressione non ho trovato nulla. Per caso hai qualche dato?
WebP, se non ho capito male, non vuole sostituire in toto jpeg ma solo per quanto riguarda il web.
Infatti non sono presenti alcune caratteristiche utili per i fotografi, canale alfa ecc.
Considerando che le immagini sono circa il 65% del traffico internet, diminuire di circa il 40% questo valore sarebbe un buon passo avanti.
Se si pensa al solo Facebook , se al momento di caricare le immagini le convertisse al volo , avremmo un guadagno immediato praticamente invisibile all’utente.
Ci sono altre considerazioni tecniche da fare, che preferisco rimandare al prossimo articolo.
Dico soltanto che tanta gente tende ormai a memorizzare sul web i propri dati, comprese le foto, e personalmente non vorrei che fossero artefatte più di quanto non faccia la fotocamera o magari il filtro per eliminare gli occhi rossi.
probabilmente i problemi di qualità visiva del webp sono dovuti al fatto che viene usato un metodo di compressione creato e ottimizzato per i fotogrammi video.. la strada da battere secondo me dovrebbe essere un’altra, come ripescare e rilanciare il jpeg2000 o la compressione frattale citata più su.
@ Avve
Sono pienamente d’accordo sulla questione economica (quoto il tuo “meno banda più risparmio”). In ambito licenze non credo che Google abbia intenzione di piantare dei paletti, con il rischio di rallentare la diffusione. Credo piuttosto che abbia l’obbligo morale di adottare delle facilitazioni a riguardo, limitando la burocrazia al massimo.
@ Cesare Di Mauro
Sapere che nel WebP manca proprio il canale alpha mi lascia deluso e perplesso, benché Google abbia intenzione di aggiungerlo più avanti.
Attendiamo l’articolo con le tue considerazioni tecniche per trarre conclusioni più approfondite. Certo è che il WebP, in questa prima fase, più che convincere delude parecchio. Se il buongiorno si vede dal mattino…
@ Del Viero
Quoto il tuo: “… WebP, se non ho capito male, non vuole sostituire in toto jpeg ma solo per quanto riguarda il web.
Infatti non sono presenti alcune caratteristiche utili per i fotografi, canale alfa ecc…”
Questo spiega le tante mancanze nel WebP attuale. Quindi Google ha intenzione di ottimizzare solo il lato “web” delle immagini, escludendo le features di foto-ritocco? Allora si che si spiegano le lacune… appare chiaro che puntano a ricavare principalmente un risparmio sullo spazio occupato dalle immagini, ponendo in secondo piano tutto il resto.
tecnicamente l’osservazione sui test di google è giusta, ma bisogna considerare l’ambito di utilizzo di questo formato: chi ha siti web ha tutte immagini in jpg, gif e png, e finché programmi come photoshop non supporteranno il nuovo formato l’unica cosa che sarà possibile fare sarà convertire le vecchie immagini e vedere quanto spazio si guadagna; stessa cosa per le macchine fotografiche e le foto prese dai cellulari, non è che la gente butterà improvvisamente via tutte le macchine che fanno foto in jpg, quindi anch’esse dovranno essere convertite.
Anche le critiche sulla qualità lasciano il tempo che trovano: la ragione del nuovo formato è il risparmio di banda, non la qualità, se sei un fotografo professionista sarai abbastanza esperto da pubblicare foto di buona qualità in un formato adatto, ma altrimenti se le tue immagini sono semplice grafica di siti o foto che posti su facebook o sul tuo blog personale non noterai mai la differenza di qualità rispetto a jpg, e anche notandola non te ne fregherebbe niente.
La difficoltà principale non è creare un algoritmo più efficiente, visto che dopo tanti anni non dovrebbe essere difficile superare una tecnologia così vecchia, ma fare in modo che sia conosciuta e che si affermi, e Google è forse l’unica, assieme forse a Microsoft, che possa provare a proporre un nuovo formato. Basta vedere cosa è accaduto con Chrome: grazie al fatto che Google l’ha pubblicizzato dopo il primo giorno l’1% dei browser era un Chrome, mentre Opera, che esiste forse da una ventina d’anni, è al 2%…
Questa idea di Google, al di là della realizzazione che per il momento suscita qualche dubbio (ma comunque è un progetto ancora non finito), non può suscitare critiche o sospetti perchè è uno di quei rari casi in cui l’interesse dell’azienda coincide con l’interesse del resto del mondo, Google potrebbe risparmiare qualche milione di dollari di banda nei prossimi anni (ma così anche microsoft e yahoo), ma anche gli isp risparmierebbero, e così anche il costo delle connesioni a internet potrebbe diventare un pochino più economico, e la gestione dei server che usano molta banda sarebbe facilitata. Inoltre sotto un progetto simile non può nascondersi nessun secondo fine, anche perchè il fine principale ha vantaggi economici tali da giustificare più che abbondantemente i costi di sostenimento del progetto.
In tal caso già da 10 anni esiste un formato standardizzato (e disponibile con codec open source) che soddisfa le esigenze di praticamente tutti: JPEG 2000.
Formato utilizzato abbondantemente anche da Adobe coi PDF da qualche anno a questa parte, e infatti i file con immagini pesano decisamente di meno, se c’avete fatto caso.
Quindi se il problema era il risparmio di banda, la soluzione a portata di mano c’era già.
Questo nuovo formato serve soltanto a Google per questioni di banda, e coi problemi di qualità che ha non è plausibile utilizzarlo per la massa.
Non mi aspetto, pertanto, che le immagini esistenti o nuove verranno salvate in questo formato, ma lo scenario che vedo è che Google internamente converta tutto quello che ha e che scarica in WebP, confidando nella diffusione dei plug-in e in generale nel supporto dei browser in modo che la gente le possa visualizzare.
In soldoni: se rimane vincolato al web, ma in maniera monodirezionale (da Google o dai siti verso gli utenti finali, e non il viceversa), non lo vedo male. Esteso all’universo conosciuto no, decisamente.
@Giacomo: esatto, è un formato pensato per il video, e probabilmente ne risente.
Ma lo stesso discorso lo si potrebbe fare anche con l’H.264, solo che la qualità degli intra-frame in questo caso è decisamente più elevata e, a primo acchito (ma servono estese verifiche qualitative!), papabile per l’uso anche in altri ambiti (fotografico incluso).
Come dice Max, questo formato per la grafica normale va più che bene e secondo me stai esagerando con l’evidenziare eventuali problemi di qualità. Per la grafica di alta qualità (vedi foto) si possono sempre usare i vecchi formati, ma la maggior parte delle persone senza avere un termine di confronto non si rende conto della differenza.
‘La massa’ ha acquisito le tv LCD tra le abitudini domestiche, eppure i primi LCD non avevano la fedeltà di colori dei CRT (e mi sa neanche adesso)…
‘La massa’, secondo me, è proprio quella che non si renderà conto della differenza…
>”Questo nuovo formato serve soltanto a Google per questioni di >banda, e coi problemi di qualità che ha non è plausibile >utilizzarlo per la massa.”
Sulla qualità mi sono già espresso ed è stato fornito anche un link piuttosto eloquente nel primo commento.
Altre considerazioni sono state fatte, altre ancora ne farò nel prossimo articolo.
@ Cesare Di Mauro
Cesare potresti includere anche il “Jpegmini” nelle tue prossime considerazioni?
http://jpegmini.com/
Nella pagina menziona il 75% di compressione (contro il 40% di WebP), fast encoding oltre ad essere pienamente compatibile con lo standard jpeg. Inoltre fa un confronto diretto con il WebP utilizzando le medesime foto utilizzate per il test di quest’ultimo.
dal titolo speravo potesse essere una svolta, dopo aver letto l’articolo e i commenti in effetti WebP mi sembra un pò una cappellata… possibile che Big G abbia fatto così male i calcoli?
Cmq ottimo topic, seguirò prossime uscite, spero presto :)
Mah… io vedo solo dei guadagni da questo nuovo algoritmo di compressione.
Vorrei capire chi, su una foto di di un sito web o di un amico su facebook si mette a fare lo zoom 400% alla ricerca di un’aberrazione o di un artefatto.
Alla fin fine una qualità accettabilisima per una risoluzione “da web” fà risparmiare molto spazio rispetto al jpg. fosse anche un solo 10% sarebbe gia tanto, ai miracoli non ci credo ma ai miglioramenti successivi si.
Troverei comunque molto piu interessante un confronto sulla qualità a parità di grandezza.
In questo modo non sappiamo quantificare la percentuale di ‘qualità’ (rispetto a quale scala di giudizio?) in rapporto alla grandezza del file…
@Cesare: è possibile scaricare i pacchetto netpbm nei repo di varie distro (c’è anche per altri SO), che contiene, tra i vari programmi di conversione, anche pnmtofiasco e fiascotopnm, quindi è possibile provare e constatare i tempi direttamente. :) …tempo permettendo.
Per ora ho fatto giusto una prova veloce su un Core Duo a 1,6 Ghz, con un’immagine 640×400. Da ppm a fiasco, con qualità 20, ha richiesto 21 secondi, con qualità 100 ce ne sono voluti 39; mentre il contrario avviene in un istante. C’è da dire che fiasco non si prefigge una resa di qualità, ma a parità di byte del file risultante, l’immagine ottenuta con fiasco è decisamente migliore rispetto a jpeg, proprio come dice l’articolo. Inoltre è interessante come la compressione frattale si comporta ingrandendo l’immagine. Bisognerebbe fare un vero test, provando più parametri e diversi tipi di immagini, comunque è già un’indicazione e potete provare anche voi.
Jpeg 2000 è un formato su cui si pagano le licenze, Jpeg no. E’ questa l’unica ragione per cui non ha avuto successo.
Per quanto riguarda WebP immagino che come con tutti i progetti abbia bisogno di venire affinato. E’ chiaro che più si riduce lo spazio occupato e più contenti siamo tutti.. si consuma meno energia, meno traffico, etc., ma la questione fondamentale oggi è che bisogna fare meno figli.
Non mi risulta assolutamente che esistano delle licenze, per giunta a pagamento, per JPEG 2000. Hai delle fonti ufficiali in merito?
@Flare: com’era prevedibile, è lento perfino oggi che abbiamo a disposizione dei supercomputer (rispetto a quelli di una ventina d’anni fa). :|
E’ chiaro che la compressione frattale ha i suoi vantaggi (oltre allo spazio c’è anche la possibilità di scalare meglio le immagini rispetto a un’immagine bitmap compressa), ma al momento continua a essere fuori dalla portata della massa, a mio avviso.
@Zeirus: di JPEGMini ne ho sentito parlare, ma al momento non ho avuto tempo per documentarmi.
Però i guadagni superiori a WebP, continuando a generare file JPEG non mi sembrano realistici. Vedrò un po’ come funziona.
@Mauro: infatti i confronti in genere si fanno in quel modo. Si sceglie un target per la dimensione del file (più o meno: non si va a spaccare il byte, per intenderci), si comprimono le immagini. Poi si valutano con metriche standard (come la SSIM che ho citato nell’articolo), e infine si vanno a esaminare le immagini per vedere che tipo di errori sono stati introdotti rispetto all’originale. Ovviamente in quest’ultimo caso conta l’occhio e l’esperienza.
Le immagini di JpegMini saranno anche più piccole ma io ho notato che hanno meno dettagli rispetto a WebP. Mentre le immagini WebP sono quasi indistinguibile dall’originale.
Per un confronto giusto bisognerebbe affiancare immagini con la stessa dimensione, magari la stessa immagine compressa in percentuali via via maggiori, e vedere chi mostra l’immagine migliore.
Non è detto infatti che comprimendo una immagine maggiormente con algoritmo JPEG non si ottenga una qualità simile con dimensione equivalente.
‘However, the JPEG committee has also noted that undeclared and obscure submarine patents may still present a hazard:
It is of course still possible that other organizations or individuals may claim intellectual property rights that affect implementation of the standard, and any implementers are urged to carry out their own searches and investigations in this area.
Because of this statement, controversy remains in the software community concerning the legal status of the JPEG 2000 standard.’
Io, fossi un produttore di fotocamere, non implementerei uno standard con queste basi.
Con queste basi i produttori di fotocamere dovrebbero spaventarsi a implementare qualunque cosa, anche un banale BMP.
Hanno scelto JPEG, che è soggetto esattamente alle stesse problematiche, e… è ancora lì il supporto.
@Nessuno: concordo. JPEG Mini taglia ben più dettagli di WebP, per cui è ovvio che i risultati siano migliori.
Tanto per fare un esempio grossolano, basta prendere la solita prima immagine (1_original.*) e guardare la scala antincendio che c’è nel palazzo un po’ a sinistra in alto: la parte finale è quasi del tutto sparita nel file 1_JPEGmini.jpg.
Credo che la scelta di google di inventare un nuovo formato non sia tanto di carattere tecnico quanto pubblicitario e commerciale: nel senso che se google avesse deciso di rispolverare un vecchio formato come jpg 2000 la cosa non sarebbe stata psicologicamente positiva, nel senso che è già stato un fiasco in passato non riuscendo ad affermarsi, anche avesse scelto qualche formato già esistente più valido ma semisconosciuto ci sarebbe stata una certa diffidenza; un formato totalmente nuovo invece ispira più curiosità e più fiducia rispetto a qualcosa di già esistente e che non ha avuto successo, in più il fatto che sia google a progettare il formato e non l’aziendina sconosciuta xyz ispira ancora più fiducia nel possibile successo del progetto (anche se alla fine non vuol dir molto, nel senso che è possibilissimo che esistano diversi formati migliori del webp anche nella sua versione finale, non è che il fatto che sia google a ideare il formato sia garanzia assoluta che sarà la cosa migliore del mondo). Inoltre per Google c’è anche una questione di immagine, in effetti mi stupisce molto che abbiano deciso di chiamare il formato webp e non googleimage, g-img, o qualcosa del genere, per ricordare come il formato sia stato creato da Google (tipo i file wmv di microsoft che sono WINDOWS media video, a ricordare che è stata microsoft a creare il formato); comunque anche senza nome aziendale il fatto che si affermi come tipo di immagine standard nei prossimi anni un formato creato da google avrebbe anche un certo ritorno di immagine per l’azienda.
@Alessandro Pedarra
è perchè no? al momento nessuna ryalties…alla fine siamo nella situazione dell’h264…anke quello è royalty free…ma per concessione del consorzio che lo ha creato, ma nulla vieta a tale soggetto di cambiare politica
Non nel caso di JPEG 2000, che è stato rilasciato completamente senza royalty. Quindi non c’è nulla da temere anche per il futuro. ;)
Il problema dei patent-troll che aspettano in silenzio che una tecnologia si diffonda per battere cassa, invece, è un problema comune a qualunque tecnologia, come dicevo prima.
Tanto per essere chiari, c’è gente che è convinta che OGG, Theora, e adesso VP8, siano a posto da questo punto di vista, semplicemente perché SEMBRA che non utilizzino roba coperta da brevetti.
Ma non c’è NESSUNA garanzia in merito. Gli sviluppatori o le aziende che li hanno realizzati non hanno mai sottoscritto alcun documento che attesti che siano formati liberi da qualunque brevetto o proprietà intellettuale altrui.
Esempio: http://en.wikipedia.org/wiki/Ogg_vorbis#Licensing
E ricordiamoci che questo è il codec audio utilizzato da WebM, che dovrebbe diventare il formato video standard per il web…