Questa pagina è stata tradotta dall'API Cloud Translation.

Domande frequenti

Che cos'è WebP? Perché dovrei utilizzarlo?

WebP è un metodo di compressione con e senza perdita di dati che può essere utilizzato su un'ampia varietà di immagini fotografiche, traslucide e grafiche presenti sul web. Il grado di compressione con perdita è regolabile, quindi un utente può scegliere il compromesso tra dimensioni del file e qualità dell'immagine. In genere, WebP raggiunge una compressione media superiore del 30% rispetto a JPEG e JPEG 2000, senza perdita di qualità dell'immagine (vedi Studio comparativo).

Il formato WebP mira essenzialmente a creare immagini più piccole e dall'aspetto migliore che possono contribuire a rendere il web più veloce.

Quali browser web supportano WebP in modo nativo?

I webmaster interessati a migliorare le prestazioni del sito possono creare facilmente alternative WebP ottimizzate per le loro immagini attuali e pubblicarle in modo mirato sui browser che supportano WebP.

Supporto con perdita di WebP
- Google Chrome (computer) 17+
- Google Chrome per Android versione 25 o successive
- Microsoft Edge 18+
- Firefox 65 e versioni successive
- Opera 11.10+
- Browser web nativo, Android 4.0+ (ICS)
- Safari 14+ (iOS 14+, macOS Big Sur+)
Supporto di WebP con perdita, senza perdita e con canale alfa
- Google Chrome (computer) 23+
- Google Chrome per Android versione 25 o successive
- Microsoft Edge 18+
- Firefox 65 e versioni successive
- Opera 12.10+
- Browser web nativo, Android 4.2+ (JB-MR1)
- Pale Moon 26+
- Safari 14+ (iOS 14+, macOS Big Sur+)
Supporto dell'animazione WebP
- Google Chrome (computer e Android) 32+
- Microsoft Edge 18+
- Firefox 65 e versioni successive
- Opera 19+
- Safari 14+ (iOS 14+, macOS Big Sur+)

Vedi anche:

Come faccio a rilevare il supporto del browser per WebP?

Ti consigliamo di pubblicare immagini WebP solo per i client che possono visualizzarle correttamente e di utilizzare i formati legacy per i client che non possono. Fortunatamente, esistono diverse tecniche per rilevare il supporto di WebP, sia lato client che lato server. Alcuni provider CDN offrono il rilevamento del supporto WebP come parte del loro servizio.

Negoziazione dei contenuti lato server tramite le intestazioni Accept

È normale che i client web inviino un'intestazione della richiesta "Accept", che indica i formati dei contenuti che sono disposti ad accettare nella risposta. Se un browser indica in anticipo che "accetterà" il formato image/webp, il server web sa che può inviare in sicurezza immagini WebP, semplificando notevolmente la negoziazione dei contenuti. Per saperne di più, consulta i seguenti link.

Modernizr

Modernizr è una libreria JavaScript per rilevare facilmente il supporto delle funzionalità HTML5 e CSS3 nei browser web. Cerca le proprietà Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha e Modernizr.webp.animation.

Elemento HTML5 `<picture>`

HTML5 supporta un elemento <picture>, che consente di elencare più immagini alternative di destinazione in ordine di priorità, in modo che un client richieda la prima immagine candidata che può visualizzare correttamente. Consulta questa discussione su HTML5 Rocks. L'elemento <picture> è supportato da sempre più browser.

Nel tuo JavaScript

Un altro metodo di rilevamento consiste nel tentare di decodificare un'immagine WebP molto piccola che utilizza una funzionalità particolare e verificare se l'operazione è riuscita. Esempio:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

Tieni presente che il caricamento delle immagini non è bloccante e asincrono. Ciò significa che qualsiasi codice che dipende dal supporto WebP deve essere inserito preferibilmente nella funzione di callback.

Perché Google ha rilasciato WebP come open source?

Crediamo profondamente nell'importanza del modello open source. Grazie alla natura open source di WebP, chiunque può lavorare con il formato e suggerire miglioramenti. Con il tuo contributo e i tuoi suggerimenti, riteniamo che WebP diventerà un formato grafico ancora più utile nel tempo.

Come faccio a convertire i miei file di immagini personali in WebP?

Puoi utilizzare l'utilità a riga di comando WebP per convertire i tuoi file di immagini personali nel formato WebP. Per maggiori dettagli, consulta la sezione Utilizzo di WebP.

Se hai molte immagini da convertire, puoi utilizzare la shell della tua piattaforma per semplificare l'operazione. Ad esempio, per convertire tutti i file JPEG in una cartella, prova quanto segue:

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Come faccio a valutare personalmente la qualità delle immagini WebP?

Al momento, puoi visualizzare i file WebP convertendoli in un formato comune che utilizza la compressione lossless, ad esempio PNG, e poi visualizzare i file PNG in qualsiasi browser o visualizzatore di immagini. Per farti un'idea rapida della qualità di WebP, consulta la Galleria di questo sito per i confronti affiancati delle foto.

Come faccio a ottenere il codice sorgente?

Il codice del convertitore è disponibile nella sezione dei download della pagina del progetto open source WebP. Il codice del decodificatore leggero e la specifica VP8 sono disponibili sul sito WebM. Consulta la pagina Contenitore RIFF per la specifica del contenitore.

Qual è la dimensione massima di un'immagine WebP?

WebP è compatibile con il bitstream VP8 e utilizza 14 bit per larghezza e altezza. Le dimensioni massime in pixel di un'immagine WebP sono 16383 x 16383.

Quali spazi colore supporta il formato WebP?

In linea con il bitstream VP8, WebP con perdita funziona esclusivamente con un formato immagine Y'CbCr 4:2:0 a 8 bit (spesso chiamato YUV420). Per maggiori dettagli, consulta la sezione 2, "Panoramica del formato" della RFC 6386, Guida alla decodifica e al formato dei dati VP8.

WebP senza perdita funziona esclusivamente con il formato RGBA. Consulta la specifica del flusso di bit senza perdita di WebP.

Perché il mio file WebP senza perdita è diverso dall'originale?

Le funzioni Simple Encoding API (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) utilizzano le impostazioni predefinite della libreria. Per la compressione lossless, "esatto" è disabilitato. I valori RGB nelle aree completamente trasparenti (ovvero aree con valori alfa pari a 0) verranno modificati per migliorare la compressione. Per evitare questo problema, utilizza WebPEncode() e imposta WebPConfig::exact su 1. Consulta la documentazione dell'API Advanced Encoding.

Un'immagine WebP può diventare più grande dell'immagine di origine?

Sì, di solito quando si esegue la conversione da un formato con perdita a WebP senza perdita o viceversa. Ciò è dovuto principalmente alla differenza di spazio colore (YUV420 vs ARGB) e alla conversione tra questi.

Esistono tre situazioni tipiche:

Se l'immagine di origine è in formato ARGB lossless, il sottocampionamento spaziale a YUV420 introdurrà nuovi colori più difficili da comprimere rispetto a quelli originali. Questa situazione può verificarsi in genere quando l'origine è in formato PNG con pochi colori: la conversione in WebP con perdita (o, in modo simile, in un JPEG con perdita) potrebbe comportare un aumento delle dimensioni del file.
Se la sorgente è in formato con perdita, l'utilizzo della compressione WebP lossless per acquisire la natura con perdita della sorgente in genere comporta un file più grande. Questo problema non riguarda solo WebP e può verificarsi, ad esempio, quando si converte una sorgente JPEG nei formati WebP o PNG senza perdita di dati.
Se l'origine è in formato con perdita e stai tentando di comprimerla come WebP con perdita con un'impostazione di qualità superiore. Ad esempio, il tentativo di convertire un file JPEG salvato con qualità 80 in un file WebP con qualità 95 di solito comporta un file più grande, anche se entrambi i formati sono con perdita. Valutare la qualità della sorgente è spesso impossibile, pertanto è consigliabile ridurre la qualità WebP di destinazione se le dimensioni del file sono costantemente maggiori. Un'altra possibilità è evitare di utilizzare l'impostazione della qualità e, invece, scegliere una dimensione del file specifica utilizzando l'opzione -size nello strumento cwebp o l'API equivalente. Ad esempio, il targeting dell'80% della dimensione del file originale potrebbe rivelarsi più efficace.

Tieni presente che la conversione di una sorgente JPEG in WebP con perdita di dati o di una sorgente PNG in WebP senza perdita di dati non è soggetta a sorprese di questo tipo per quanto riguarda le dimensioni del file.

WebP supporta la visualizzazione progressiva o interlacciata?

WebP non offre un aggiornamento della decodifica progressiva o interlacciata nel senso di JPEG o PNG. È probabile che ciò eserciti una pressione eccessiva sulla CPU e sulla memoria del client di decodifica, poiché ogni evento di aggiornamento comporta un passaggio completo attraverso il sistema di decompressione.

In media, la decodifica di un'immagine JPEG progressiva equivale alla decodifica di quella di base 3 volte.

In alternativa, WebP offre la decodifica incrementale, in cui tutti i byte in entrata disponibili del bitstream vengono utilizzati per cercare di produrre una riga di esempio visualizzabile il prima possibile. In questo modo si risparmiano memoria, CPU e sforzi di ridisegno sul client, fornendo al contempo indicazioni visive sullo stato del download. La funzionalità di decodifica incrementale è disponibile tramite l'API Advanced Decoding.

Come faccio a utilizzare i binding Java di libwebp nel mio progetto Android?

WebP include il supporto per i binding JNI alle interfacce semplici di codifica e decodifica nella directory swig/.

Creazione della libreria in Eclipse:

Assicurati di aver installato il plug-in ADT insieme agli strumenti NDK e che il percorso NDK sia impostato correttamente (Preferenze > Android > NDK).
Crea un nuovo progetto: File > Nuovo > Progetto > Progetto di applicazione Android.
Clona o decomprimi libwebp in una cartella denominata jni nel nuovo progetto.
Aggiungi swig/libwebp_java_wrap.c all'elenco LOCAL_SRC_FILES.
Fai clic con il tasto destro del mouse sul nuovo progetto e seleziona Android Tools > Add Native Support ... per includere la libreria nella build.
Apri le proprietà del progetto e vai a C/C++ Build > Behaviour. Aggiungi ENABLE_SHARED=1 alla sezione Build (Incremental build) per creare libwebp come libreria condivisa.

Nota: l'impostazione NDK_TOOLCHAIN_VERSION=4.8 in genere migliora le prestazioni delle build a 32 bit.
Aggiungi swig/libwebp.jar alla cartella del progetto libs/.
Crea il tuo progetto. In questo modo verrà creato libs/<target-arch>/libwebp.so.
Utilizza System.loadLibrary("webp") per caricare la libreria in fase di runtime.

Tieni presente che la libreria può essere creata manualmente con ndk-build e Android.mk inclusi. Alcuni dei passaggi descritti sopra possono essere riutilizzati in questo caso.

Come faccio a utilizzare libwebp con C#?

WebP può essere creato come DLL che esporta l'API libwebp. Queste funzioni possono poi essere importate in C#.

Crea libwebp.dll. In questo modo, WEBP_EXTERN verrà impostato correttamente per esportare le funzioni API.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Aggiungi libwebp.dll al tuo progetto e importa le funzioni che ti interessano. Tieni presente che se utilizzi l'API semplice, devi chiamare WebPFree() per liberare i buffer restituiti.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Perché dovrei utilizzare WebP animato?

Vantaggi del formato WebP animato rispetto al formato GIF animato

WebP supporta il colore RGB a 24 bit con un canale alfa a 8 bit, rispetto al colore a 8 bit e all'alfa a 1 bit di GIF.
WebP supporta la compressione con perdita e senza perdita di dati; infatti, una singola animazione può combinare frame con perdita e senza perdita di dati. Il formato GIF supporta solo la compressione lossless. Le tecniche di compressione con perdita di dati di WebP sono adatte alle immagini animate create da video reali, una fonte sempre più popolare di immagini animate.
WebP richiede meno byte rispetto a GIF¹. Le GIF animate convertite in WebP con perdita di dati sono più piccole del 64%, mentre le WebP senza perdita di dati sono più piccole del 19%. Ciò è particolarmente importante sulle reti mobili.
WebP richiede meno tempo per la decodifica in presenza di ricerca. In Blink, lo scorrimento o il cambio di scheda possono nascondere e mostrare le immagini, causando la pausa delle animazioni e il loro avanzamento rapido a un punto diverso. Un utilizzo eccessivo della CPU che comporta la perdita di frame delle animazioni può anche richiedere al decodificatore di avanzare nell'animazione. In questi scenari, WebP animato richiede 0,57 volte il tempo totale di decodifica² rispetto a GIF, con conseguente riduzione dei problemi durante lo scorrimento e recupero più rapido dai picchi di utilizzo della CPU. Ciò è dovuto a due vantaggi di WebP rispetto a GIF:
- Le immagini WebP memorizzano i metadati che indicano se ogni frame contiene alpha, eliminando la necessità di decodificare il frame per determinare questo aspetto. Ciò porta a un'inferenza più accurata dei frame precedenti da cui dipende un determinato frame, riducendo così la decodifica non necessaria dei frame precedenti.
- Come un moderno codificatore video, il codificatore WebP aggiunge in modo euristico i fotogrammi chiave a intervalli regolari (cosa che la maggior parte dei codificatori GIF non fa). Ciò migliora notevolmente la ricerca nelle animazioni lunghe. Per facilitare l'inserimento di questi frame senza aumentare in modo significativo le dimensioni dell'immagine, WebP aggiunge un flag "metodo di fusione" per ogni frame, oltre al metodo di eliminazione dei frame utilizzato da GIF. In questo modo, un fotogramma chiave può essere disegnato come se l'intera immagine fosse stata cancellata con il colore di sfondo senza forzare il frame precedente a essere a grandezza naturale.

Svantaggi di WebP animato rispetto a GIF animate

In assenza di ricerca, la decodifica in linea retta di WebP richiede più CPU rispetto a GIF. WebP con perdita di dati richiede 2,2 volte il tempo di decodifica di GIF, mentre WebP senza perdita di dati ne richiede 1,5 volte.
Il supporto di WebP non è diffuso come quello delle GIF, che è praticamente universale.
L'aggiunta del supporto WebP ai browser aumenta l'impronta del codice e la superficie di attacco. In Blink si tratta di circa 1500 righe di codice aggiuntive (incluse la libreria demux WebP e il decodificatore di immagini WebP lato Blink). Tieni presente che questo problema potrebbe essere ridotto in futuro se WebP e WebM condividono un codice di decodifica più comune o se le funzionalità di WebP sono incluse in quelle di WebM.

Perché non supportare semplicemente WebM in <img>?

A lungo termine, potrebbe essere utile supportare i formati video all'interno del tag <img>. Tuttavia, farlo ora, con l'intenzione che WebM in <img> possa ricoprire il ruolo proposto di WebP animato, è problematico:

Quando decodifica un frame che si basa su frame precedenti, WebM richiede il 50% di memoria in più rispetto a WebP animato per contenere il numero minimo di frame precedenti³.
Il supporto di codec video e contenitori varia notevolmente a seconda dei browser e dei dispositivi. Per facilitare la transcodifica automatica dei contenuti (ad es. per i proxy che consentono di risparmiare larghezza di banda), i browser dovrebbero aggiungere intestazioni Accept che indicano i formati supportati dai tag immagine. Anche questo potrebbe non essere sufficiente, poiché i tipi MIME come "video/webm" o "video/mpeg" non indicano ancora il supporto del codec (ad es. VP8 e VP9). D'altra parte, il formato WebP è effettivamente bloccato e se i fornitori che lo distribuiscono accettano di distribuire WebP animato, il comportamento di WebP in tutti gli user agent dovrebbe essere coerente. Inoltre, poiché l'intestazione Accept "image/webp" viene già utilizzata per indicare il supporto di WebP, non sono necessarie nuove modifiche all'intestazione Accept.
Lo stack video Chromium è ottimizzato per una riproduzione fluida e presuppone che venga riprodotto solo uno o due video alla volta. Di conseguenza, l'implementazione consuma in modo aggressivo le risorse di sistema (thread, memoria e così via) per massimizzare la qualità della riproduzione. Un'implementazione di questo tipo non è adatta a molti video simultanei e dovrebbe essere riprogettata per essere adatta all'uso con pagine web ricche di immagini.
Al momento WebM non incorpora tutte le tecniche di compressione di WebP. Di conseguenza, questa immagine viene compressa molto meglio con WebP rispetto alle alternative:

¹ Per tutti i confronti tra GIF animate e WebP animate, abbiamo utilizzato un corpus di circa 7000 immagini GIF animate prese a caso dal web. Queste immagini sono state convertite in WebP animati utilizzando lo strumento "gif2webp" con le impostazioni predefinite (create dall'albero di origine libwebp al 10/08/2013). I numeri comparativi sono i valori medi di queste immagini.

² I tempi di decodifica sono stati calcolati utilizzando l'ultima versione di libwebp + ToT Blink al 10/08/2013 utilizzando uno strumento di benchmarking. "Tempo di decodifica con ricerca" viene calcolato come "Decodifica i primi cinque frame, svuota la cache del buffer dei frame, decodifica i cinque frame successivi e così via".

³ WebM mantiene in memoria 4 frame di riferimento YUV, con ogni frame che memorizza (larghezza+96)*(altezza+96) pixel. Per YUV 4:2:0, abbiamo bisogno di 4 byte per 6 pixel (o 3/2 byte per pixel). Quindi, questi frame di riferimento utilizzano 4*3/2*(width+96)*(height+96) byte di memoria. WebP, d'altra parte, avrebbe bisogno solo del frame precedente (in RGBA), che occupa 4*width*height byte di memoria.

⁴ Il rendering WebP animato richiede Google Chrome versione 32 o successive

Domande frequenti Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.