Questa pagina è stata tradotta dall'API Cloud Translation.

Domande frequenti (FAQ)

Che cos'è WebP? Perché dovrei utilizzarlo?

WebP è un metodo di compressione con perdita di dati e senza perdita di dati che può essere utilizzato su una vasta gamma di immagini fotografiche, traslucide e grafiche trovate sul web. Il grado di compressione con perdita di dati è regolabile, in modo che l'utente possa scegliere un compromesso tra dimensioni del file e qualità dell'immagine. WebP in genere raggiunge in media il 30% in più di compressione rispetto a JPEG e JPEG 2000, senza perdita di qualità delle immagini (consulta lo studio comparativo).

Il formato WebP punta 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 mostrarle in modo mirato ai browser che supportano WebP.

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

Vedi anche:

Come posso rilevare il supporto del browser per WebP?

Ti consigliamo di pubblicare immagini WebP solo per i clienti che sono in grado di visualizzarle correttamente e di utilizzare i formati precedenti per i clienti che non possono farlo. Fortunatamente esistono diverse tecniche per rilevare il supporto WebP, sia sul lato client sia sul 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

Spesso i client web inviano un'intestazione della richiesta "Accetta", che indica quali formati di contenuti sono disposti ad accettare in risposta. Se un browser indica in anticipo che "accetterà" il formato immagine/webp, il server web saprà che può inviare immagini WebP in modo sicuro, semplificando notevolmente la negoziazione dei contenuti. Per saperne di più, consulta i seguenti link.

Modernizzato

Modernizr è una libreria JavaScript che consente di rilevare comodamente 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 `<picture>` HTML5

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

Nel tuo codice JavaScript

Un altro metodo di rilevamento è tentare di decodificare un'immagine WebP molto piccola che utilizza una determinata funzionalità e verificare l'efficacia. 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 è bloccato e asincrono. Ciò significa che qualsiasi codice che dipende dal supporto WebP dovrebbe preferibilmente essere inserito nella funzione di callback.

Perché Google ha rilasciato WebP come open source?

Crediamo fermamente nell'importanza del modello open source. Con WebP in open source, chiunque può lavorare con il formato e suggerire miglioramenti. Con il tuo contributo e i tuoi suggerimenti, riteniamo che WebP diventerà sempre più utile come formato grafico 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 file immagine personali in formato WebP. Per ulteriori dettagli, consulta Utilizzare 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 di una cartella, prova a procedere nel seguente modo:

Windows:

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

Linux / Mac OS:

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

Come faccio a valutare la qualità dell'immagine WebP personalmente?

Attualmente, puoi visualizzare i file WebP convertendoli in un formato comune che utilizza la compressione senza perdita di dati, ad esempio PNG, e visualizzare i file PNG in qualsiasi browser o visualizzatore di immagini. Per farti un'idea rapida della qualità di WebP, visita la Galleria su questo sito per confrontare foto affiancate.

Come faccio a ottenere il codice sorgente?

Il codice del convertitore è disponibile nella sezione relativa ai download della pagina del progetto open source WebP. Il codice per il decoder leggero e la specifica VP8 si trovano sul sito WebM. Consulta la pagina Contenitore RIFF per la specifica del container.

Quali sono le dimensioni massime di un'immagine WebP?

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

Quali spazi colore sono supportati dal formato WebP?

Coerentemente con il flusso di bit VP8, lossy WebP funziona esclusivamente con un formato dell'immagine Y'CbCr 4:2:0 a 8 bit (spesso chiamato YUV420). Per ulteriori dettagli, consulta la sezione 2, "Panoramica del formato" di RFC 6386 e Guida al formato e alla decodifica dei dati VP8.

WebP senza perdita di dati funziona esclusivamente con il formato RGBA. Consulta la specifica WebP Lossless Bitstream.

Un'immagine WebP può crescere più grande della sua immagine di origine?

Sì, in genere quando si converte da un formato con perdita di dati a WebP senza perdita di dati o viceversa. Ciò è dovuto principalmente alla differenza dello spazio colore (YUV420 rispetto ad ARGB) e alla conversione tra i due.

Esistono tre situazioni tipiche:

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

Tieni presente che la conversione di un'origine JPEG in WebP con perdita di dati o di un'origine PNG in WebP senza perdita di dati non è soggetta a sorprese relative alle dimensioni dei file.

WebP supporta la visualizzazione progressiva o interlacciata?

WebP non offre un aggiornamento della decodifica progressivo o interlacciato in senso JPEG o PNG. Questo potrebbe applicare troppa pressione sulla CPU e sulla memoria del client di decodifica, poiché ogni evento di aggiornamento prevede un passaggio completo nel sistema di decompressione.

In media, decodificare un'immagine JPEG progressiva equivale a decodificare la base di riferimento una per 3 volte.

In alternativa, WebP offre una decodifica incrementale, in cui tutti i byte in entrata disponibili del flusso di bit vengono utilizzati per provare a produrre una riga di esempio visualizzabile il più presto possibile. Ciò consente di risparmiare memoria e CPU, nonché di eseguire il ritocco 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 le associazioni Java libwebp nel mio progetto Android?

WebP include il supporto per le associazioni JNI alle semplici interfacce encoder e decoder nella directory swig/.

Creazione della raccolta 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 > Android Application Project.
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 pulsante destro del mouse sul nuovo progetto e seleziona Strumenti Android > Aggiungi supporto nativo ... per includere la libreria nella build.
Apri le proprietà del progetto e vai a C/C++ Build > Comportamento. Aggiungi ENABLE_SHARED=1 alla sezione Build (Incremental build) per creare libwebp come libreria condivisa.

Nota: l'impostazione di NDK_TOOLCHAIN_VERSION=4.8 in genere migliora le prestazioni della build a 32 bit.
Aggiungi swig/libwebp.jar alla cartella del progetto libs/.
Crea il tuo progetto. Verrà creato un evento di tipo 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 l'elemento Android.mk incluso. In tal caso, alcuni dei passaggi descritti sopra possono essere riutilizzati.

Come faccio a utilizzare libwebp con C#?

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

Crea libwebp.dll. WEBP_EXTERN verrà impostato correttamente per l'esportazione delle funzioni API.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Aggiungi libwebp.dll al progetto e importa le funzioni desiderate. Nota: se usi l'API semplice, devi chiamare WebPFree() per liberare eventuali 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 usare WebP animato?

Vantaggi del WebP animato rispetto alla GIF animata

WebP supporta il colore RGB a 24 bit con un canale alfa a 8 bit, rispetto al colore a 8 bit e a 1 bit alpha delle GIF.
WebP supporta la compressione con e senza perdita di dati; infatti, una singola animazione può combinare frame con perdita di dati e frame senza perdita di dati. GIF supporta solo la compressione senza perdita di dati. Le tecniche di compressione con perdita di dati di WebP sono particolarmente adatte per immagini animate create da video reali, una fonte sempre più diffusa per le immagini animate.
WebP richiede meno byte rispetto al 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 per le reti mobili.
WebP impiega meno tempo per la decodifica in presenza della ricerca. In Lampeggiante, puoi nascondere e mostrare le immagini scorrendo o cambiando le schede. Le animazioni vengono quindi messe in pausa e poi saltate in avanti a un punto diverso. Un eccessivo utilizzo della CPU, che porta all'eliminazione dei frame da parte delle animazioni, può richiedere al decoder di andare avanti nell'animazione. In questi scenari, il WebP animato richiede un tempo di decodifica totale di 0,57 volte maggiore² rispetto a quello del GIF, il che comporta un minore strappo durante lo scorrimento e un recupero più rapido dai picchi di utilizzo della CPU. Ciò è dovuto a due vantaggi di WebP rispetto al GIF:
- Le immagini WebP archiviano i metadati relativi alla presenza di alpha in ogni frame, eliminando la necessità di decodificare il frame per effettuare questa determinazione. Ciò porta a un'inferenza più accurata da quali frame precedenti dipende da un determinato frame, riducendo così la decodifica non necessaria dei frame precedenti.
- Proprio come un codificatore video moderno, il codificatore WebP aggiunge in modo euristico i fotogrammi chiave a intervalli regolari (cosa che la maggior parte dei codificatori GIF non fa). Questa funzionalità migliora notevolmente la ricerca nelle animazioni lunghe. Per facilitare l'inserimento di questi frame senza aumentare significativamente le dimensioni dell'immagine, WebP aggiunge un flag "metodo di combinazione" per ogni frame oltre al metodo di eliminazione dei frame utilizzato dalla GIF. In questo modo un fotogramma chiave può disegnare come se l'intera immagine fosse stata cancellata con il colore di sfondo senza forzare il frame precedente a grandezza originale.

Svantaggi del WebP animato rispetto alla GIF animata

In assenza di ricerca, la decodifica in linea diretta di WebP richiede più CPU rispetto alla GIF. Lossy WebP impiega 2,2 volte il tempo di decodifica del GIF, mentre WebP senza perdita di dati ne richiede 1,5 volte di più.
Il supporto WebP non è diffuso quanto il supporto per le GIF, che è effettivamente universale.
L'aggiunta del supporto WebP ai browser aumenta l'ingombro 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 ridursi in futuro se WebP e WebM condividono codice di decodifica più comune o se le funzionalità di WebP saranno incluse in WebM.

Perché non supportare semplicemente WebM in <img>?

Potrebbe avere senso a lungo termine supportare i formati video all'interno del tag <img>. Tuttavia, farlo ora, con l'intento che WebM in <img> possa ricoprire il ruolo proposto di WebP animato, è problematico:

Durante la decodifica di un frame che si basa sui frame precedenti, WebM richiede il 50% di memoria in più rispetto al WebP animato per contenere il numero minimo di frame precedenti.³
Il supporto dei contenitori e dei codec video varia notevolmente in base al browser e al dispositivo. Per facilitare la transcodifica automatica dei contenuti (ad esempio, per i proxy che consentono di risparmiare larghezza di banda), i browser devono aggiungere intestazioni che indichino quali formati sono supportati dai tag immagine. Anche questo potrebbe essere insufficiente, poiché i tipi MIME come "video/webm" o "video/mpeg" non indicano ancora il supporto dei codec (ad es. VP8 rispetto a VP9). D'altra parte, il formato WebP è effettivamente bloccato e, se i fornitori che lo distribuiscono accettano di spedire WebP animato, il comportamento di WebP in tutte le UA deve essere coerente e, poiché l'intestazione di accettazione "immagine/webp" è già utilizzata per indicare il supporto WebP, non sono necessarie nuove modifiche all'intestazione di accettazione.
Lo stack di video Chromium è ottimizzato per una riproduzione uniforme e presuppone che vengano riprodotti solo uno o due video alla volta. Di conseguenza, l'implementazione è aggressiva nell'utilizzo delle risorse di sistema (thread, memoria e così via) per massimizzare la qualità di riproduzione. Questa implementazione non si adatta bene a molti video simultanei e dovrebbe essere riprogettata per poter essere utilizzata con pagine web con molte immagini.
Al momento WebM non incorpora tutte le tecniche di compressione di WebP. Di conseguenza, questa immagine si comprime molto meglio con WebP rispetto alle alternative:

¹ Per tutti i confronti tra GIF animate e WebP animati, abbiamo utilizzato un corpus di circa 7000 immagini GIF animate tratte dal web in modo casuale. Queste immagini sono state convertite in WebP animato utilizzando lo strumento "gif2webp" utilizzando le impostazioni predefinite (realizzate dall'albero di origine libwebp più recente in data 08/10/2013). I valori comparativi sono i valori medi di queste immagini.

² I tempi di decodifica sono stati calcolati utilizzando le ultime versioni di libwebp + ToT Blink a partire dal 08/10/2013 utilizzando uno strumento di benchmark. Il "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, in cui ogni frame viene archiviato (larghezza + 96)*(altezza + 96) pixel. Per lo standard YUV 4:2:0, sono necessari 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, invece, dovrebbe avere disponibile solo il frame precedente (in RGBA), ovvero 4*width*height byte di memoria.

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