WebP è il nuovo formato per le immagini creato da Google per sostituire JPEG: supportando il canale alpha, potrebbe anche essere un’alternativa a PNG. Recentemente WebP è approdato su Picasa Web Albums, la piattaforma di Google per l’upload e la condivisione delle fotografie. Ciò nonostante Mozilla ha fatto sapere di non “gradirlo”.
Il nuovo formato è già compatibile con Chrome e Opera: all’appello manca giusto Firefox, perché Internet Explorer può visualizzare le immagini in WebP grazie a un codec per Windows. Il successo del formato dipende dalla sua adozione e Mozilla non ritiene che, al momento, WebP sia un’alternativa valida a JPEG. Non sarà su Firefox 5.
Jeff Muizelaar di Mozilla aveva già espresso un parere contrario a WebP il mese scorso. Tuttavia, il formato di Google è in uso su Instant Preview, GMail ed è compatibile con programmi come ImageMagick e Adobe Photoshop CS5. In sostanza, siccome WebP non è “perfetto”, Mozilla preferisce privilegiare l’altrettanto “imperfetto” JPEG.
Via | Ars Technica
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
(1 Voti | Media: 4 su 5)
Kim Allamandola
25 mag 2011 - 11:33 - #1Il motivo, almeno apparente, del rigetto di WebP è che questi non supporta i
metadati exif (che jpeg supporta) e sopratutto non supporta una cosa che non
ha manco jpeg: la gestione del canale alpha ovvero le trasparenze (che sono
strà usate) e che supporta invece il lossless (e un quindi un po’ più pesante
png). In ultimo WebP non ha una bella struttura dati iow non ha un bel modo di
mettere i bit in file dentro il file…
Per ora aspettano che WebP cresca, al momento rende anche meglio del jpeg ma
non risolve i problemi del jpeg né aggiunge caratteristiche per cui si possa
pensare a sostituire quest’ultimo.
Per mia opinione invece sia WebP che WebM sono formati giovani ed incompleti
ma visto cosa accadde con le gif (question brevetti) un po’ di eoni fa non mi
dispiace per nulla avere qualcosa sicuro su questo piano…
ekerazha
25 mag 2011 - 11:39 - #2WebM e WebP sono il futuro dei formati lossy per il web, molto male Mozilla.
Herod2k
25 mag 2011 - 13:03 - #3perché ekerazha? Non è che bisogna sempre seguire incodizionatamente google sempre e comunque.
Cesoia
25 mag 2011 - 13:19 - #4/OT
Ciao Kim,faccio uno strappo alla regola scusandomi in anticipo con tutti i lettori e con ossblog ma volevo chiederti in quali lidi giace la comunita’ OSOL-it….
In openindiana?!
OT/
Siamo sicuri che mozilla stia facendo la cosa piu’ giusta???!
ekerazha
25 mag 2011 - 13:27 - #5Bisogna quando è buona cosa farlo, sono decenni che si prova a rottamare JPEG (JPEG2000, JPEG-XR ecc.) ora c’è un formato aperto che viene già supportato da due popolari browser (Chrome e Opera) e volendo anche da IE con Google Frame, potrebbe essere l’occasione per riuscire dove in passato si è fallito… e cosa fa Mozilla? Ferma il progresso.
ubu
25 mag 2011 - 14:12 - #6Per adesso alla Mozilla non frega nulla di webp, tanto meno ora che Firefox supporta jpeg-turbo. Non appena ci saranno performance e caratteristiche di nota, non presenti in jpeg, il passaggio sarà quasi obbligatorio.
edward.81
25 mag 2011 - 14:37 - #7Secondo me il web manca di un formato universale.
Per le animazioni gif con trasparenza 8bit
per gli alpha channel png24
per immagini pesanti jpeg.
dovrebbero riunire il meglio di questi formati in un unico tipo di immagine.
Mi ricordo che ci sono già stati esperimenti strani. come ad esempio le jpeg con il canale alpha. oppure le png animate. Esistevano anche dei plugin per mozilla ma non hanno mai preso piede.
Giurato
25 mag 2011 - 14:42 - #8Non capisco perché mai Mozilla debba mettersi di traverso. Ma cosa gliene frega di bocciare WebP? Metti dentro il supporto CHETTEFREGA? Mi sembra un puntare i piedi come gli scolaretti. Ma non è Opensource?
Se WebP sarà una ciofeca il mercato lo rigetterà senza che debbano esserci paladini anti google.
aska
25 mag 2011 - 15:22 - #9come detto anche nei commenti sembra che questo webP non sia un formato comodo/semplice.
mozilla non vuole supportarlo? allora che sia google a scrivere e aggiornare un plugin per firefox, sicuramente mozilla non lo impedirà…
poi quando il formato verrà migliorato e inizierà a diffondersi, mozilla potrà includerlo nel browser.
Non vedo dove stia la polemica.
Kim Allamandola
25 mag 2011 - 15:27 - #10@Cesoia #4
Scusandomi a mia volta per l’OT (cmq il mio nome o nik @gmail funziona sempre)
ad ITLOSUG siamo ancora quasi tutti iscritti ma non c’è attività, al gruppo
google siamo iscritti in pochi e non c’è mai stata attività, idem su
IllumOS-it… In pratica siam troppo pochi per far qualcosa e abbiamo tutti
altro da fare :-(
Solaris è sulla via di Irix purtroppo, spero cmq che lo zfs, dtrace, l’smf,
l’fma, … possano fare la stessa cosa delle OpenGL di Irix, almeno non buttare
nel cesso le più avanzate tecnologie che abbiamo… Per ora IllumOS e Nexenta
tengono viva la base di codice, gli altri direi siano a far altro…
@Giurato #8
WebP non è proprio una ciofeca, purtroppo Google negli ultimi tempi pur avendo
ampliato i suoi orizzonti non ha adeguato il suo stile di sviluppo… WebP è
tutto sommato sicuro sul piano delle lotte di copyright ma non è uno standard
né de jure né de facto, non è “pronto” un po’ come non lo è WebM (prova
youtube html5 rispetto al flash e vedi cosa te ne pare)… Penso che Mozilla
sbagli ma non penso che WebP sia La Soluzione® a tutti i mali. IMVHO Mozilla
dovrebbe supportare WebP/WebM (costa poco in termini di lavoro/codice) ma
anche spingere per trovare una reale alternativa a jpeg (un formato *open* con
supporto exif/ICC *standard* iow senza strambe implementazioni personali, con
supporto alle trasparenze anch’esso *standard*)
Personalmente *non mi piace* html5 e non vedo implementazioni decenti… Chrome
nel tempo ha degradato in maniera spaventosa le performance, tanto che l’ho
abbandonato per FF (provate solo Chrome e FF con GMail, Maps ed Ossblog poi
ditemi che percettibile differenza vedete); Youtube/HTML5 non è né funzionale
né più “leggero” né meno scomodo di flash; WebP è carino, ma non dà nulla in
più di jpeg… So che non attira gente ma dire: “’siori per fare un bel lavoro
ci vuol tempo, non facciamo come multics/plan9 ma vediamo di non voler far
tutto in casa in 3 mesi, grazie.” non mi dispiacerebbe…
C’è bisogno di un fottuto *standard* per l’web come per il desktop, magari
qualcosa che riprenda l’idea *originale* di java; non l’implementazione né
la sintassi, l’idea, ovvero avere un’applicazione che fa da {j,py,pl,rb}vm e
due linguaggi, uno per la grafica (qualcosa che copra da svg a css), uno per
far conti (es. python/ruby/perl) separati ed intercomunicanti al posto di tutti
i $butto-fuori-html/js-a-partire-da-altro che ci sono oggi. Questo
consentirebbe sia il famoso “The network is the computer” della Sun che è poi
anche quello che da eoni *tutti* cercano di realizzare e *risolverebbe* tutti
i problemi di lentezza/compatibilità/* dell’web attuale…
guiodic
25 mag 2011 - 18:54 - #11Devo purtroppo notare the il design di Windows in questo caso è vincente. Vuoi che IE supporti un nuovo codev video? scrivi un filtro. Vuoi che supporti un nuovo formato audio? scrivi un filtro. Vuoi che supporti un nuovo formato immagini? scrivi in filtro.
Cosa più importante, quando lo hai installato non solo IE ma tutte le applicazioni che si basano sui framework Direct*le supporteranno.
Su GNU/Linux non ci sono framework prevalenti e quelli che esistono sono o magari ottimi ma sottoutilizzati o in certi casi carenti.
E’ triste, ma bisogna dirlo se si vuole battere il software proprietario in qualità, sono queste le cose che contano non certo Unity. Poi certo se uno pensa solo all’estetica…
Kim Allamandola
25 mag 2011 - 21:10 - #12X è un megalite da rifare, si parla di Wayland anche per questo… Cmq la
struttura di Windows ha direi un bel po’ di problemi di sicurezza, non lo
vedo certo come una cosa da copiare…
guiodic
26 mag 2011 - 02:17 - #13kim, cosa cavolo c’entra X? Nulla. Spari commenti a caso. Sai quanto è megalite X? La bellezza di 5 megabyte. Cerca di non sparare fesserie.
Quanto a Windows ho parlato di un aspetto specifico che andrebbe copiato, la sicurezza non c’entra assolutamente nulla.
Kim Allamandola
26 mag 2011 - 08:14 - #14@guiodic #13
No, certo, X non c’entra nulla… Ahem com’è che girano le componenti grafiche
di Windows? Com’è che ActiveX è da tutti, salvo i Cinesi e SudCoreani evitata
come la peste?
Su GNU/Linux la grafica è “meno reattiva” di Windows poiché questa gira con
vari rimpalli tra X (applicazione userspace) le varie librerie grafiche, i
composite manager ecc. ogni livello pesa. Certo la grafica a-la-Windows in
kernel space è più leggera e scattante, tutti gli altri problemi che comporta
evidentemente non ti interessano.
Ps il supporto a WebP per firefox è già stato prodotto in varie patch che non
sono né complicate né voluminose, su Windows *non è* più facile supportare un
nuovo formato anzi con le WinAPI è *assai più complicato* a causa della
sporcizia e “scarsa intelligenza nel design” delle stesse.
guiodic
26 mag 2011 - 10:38 - #15@kim: no, davvero, no sai di cosa stai parlando. ActiveX cosa c’entra con le “componenti grafiche” (termine generico che non vuole dire nulla) o con WIC? Niente. Visto che parli di “componenti grafiche” forse tu credi che ActiveX c’entri con DirectX… io non ho parlato di DirectX ma dei framework Direct*. Mi riferivo in particolare a DirectShow. Con l’argomento WebP il sistema grafico non ha nulla a che vedere in realtà. Così come del resto non ha molto a che vedere neppure con DirectShow e DirectX. Sia in Windows che in Linux, il sistema grafico viene saltato quando si tratta di grafica 3D, come del resto accade anche per il playback dei video tramite xv o vdpau o xvba o xvmc. Il sistema grafico si occupa solo di rinchiudere l’output nelle finestre.
In Windows, la grafica non è più tutta in kernel space a partire da Vista. Quindi parli di cose che non conosci. In secondo luogo X non è affatto più lento del sistema grafico di Windows: i test su schede nvidia professionali dicono *esattamente* il contrario.
Infine le API Win32/64 non c’entrano *assolutamente nulla nulla nulla* col discorso che stiamo facendo. Scrivere un filtro per Windows Imaging Component non coinvolge affatto le Win32. Anche qui parli di cose che non hanno nulla a che vedere.
Mi dici che bisogna patchare Firefx e ricompilarlo… bene, è questo il problema se ancora non l’hai capito. Su Windows non devi patchare IE e ricompilarlo (peraltro il codice sorgente non ce l’hai…) ma semplicemente installare un filtro che permette al WIC di trattare le immagini WebP e questo darà il supporto a quel formato sia in IE che nel visualizzatore di immagini che persino in MS Office. Hai capito adesso?
E’ come quando per vedere i filmati codificati con xvid o divx o h264, installi gstreamer-plugins-bad. Mica devi ricompilare Totem! Una volta installati quei plugin, non solo totem visualizzerà quei filmati, ma potrai editarli con pitivi, masterizzarli con brasero, ecc.
La stessa cosa si dovrebbe fare con le immagini: un framework a cui tutti i programmi accedano. Che è ciò che ha fatto Windows. Hai capito adesso?
Davvero, parla di quello che conosci, che mi pare poco.
guiodic
26 mag 2011 - 23:50 - #16aggiungo: e non solo su nvidia: http://guiodic.wordpress.com/2011/05/26/finalmente-i-driver-video-intel-per-gnulinux-piu-veloci-di-quelli-per-windows/