Questa pagina è stata tradotta dall'API Cloud Translation.

Domande frequenti

Che cos'è WebP? Perché dovrei utilizzarlo?

WebP è un metodo di compressione senza perdita di dati che può essere utilizzato su un varietà di immagini fotografiche, traslucide e grafiche presenti 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à delle immagini. WebP in genere raggiunge del 30% in più di compressione rispetto a JPEG e JPEG 2000, senza perdita di immagine (consulta lo 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 immagini attuali e pubblicarle su un una base mirata ai browser che supportano WebP.

Supporto per perdita di dati WebP
- Google Chrome (computer) 17 e versioni successive
- Google Chrome per Android versione 25 e 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)
WebP con perdita di dati, lossless supporto alpha
- Google Chrome (computer) 23 e versioni successive
- Google Chrome per Android versione 25 e successive
- Microsoft Edge 18 e versioni successive
- Firefox 65 e versioni successive
- Opera 12.10 e versioni successive
- Browser web nativo, Android 4.2 o versioni successive (JB-MR1)
- Luna pallida dai 26 anni in su
- Safari 14 e versioni successive (iOS 14 e versioni successive, macOS Big Sur e versioni successive)
Supporto di animazione WebP
- Google Chrome (computer 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 client che possono visualizzarle i formati precedenti, per i clienti che non possono farlo. Fortunatamente esistono diverse tecniche per rilevare il supporto WebP, sia sul sito lato client e lato server. Alcuni fornitori CDN offrono il rilevamento del supporto WebP nell'ambito del loro servizio.

Negoziazione dei contenuti lato server tramite le intestazioni Accept

Capita spesso che i client web inviino un messaggio di accettazione che indica l'intestazione della richiesta quali formati di contenuti sono disposti ad accettare in risposta. Se il browser indica in anticipo che accetterà il formato image/webp, il server web sa di poter inviare in sicurezza immagini WebP, semplificando notevolmente nella negoziazione dei contenuti. Per saperne di più, consulta i seguenti link.

Modernizr

Modernizr è una libreria JavaScript per rilevare comodamente HTML5 e Supporto delle funzionalità 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ù elementi, target di immagini alternativi in ordine di priorità, in modo che il client richieda la prima immagine candidata che può visualizzare correttamente. Consulta questa discussione su HTML5 Rocks. L'elemento <picture> è supportato sempre da più browser.

Nel tuo codice JavaScript

Un altro metodo di rilevamento è tentare di decodificare un'immagine WebP molto piccola che utilizza una particolare funzionalità e verificane 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 blocca e è asincrono. Ciò significa che qualsiasi che il codice che dipende dal supporto WebP dovrebbe essere preferibilmente inserito nel callback personalizzata.

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 i vostri contributi e suggerimenti, riteniamo che WebP diventerà ancora più utile come formato grafico nel tempo.

Come posso convertire i miei file di immagini personali in WebP?

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

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

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?

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

Come faccio a ottenere il codice sorgente?

Il codice del convertitore è disponibile nella sezione dei download del progetto open source WebP . Il codice per il decoder leggero e la specifica VP8 sono il sito WebM. Consulta le Pagina Contenitore RIFF per il contenitore e la specifica del prodotto.

Quali sono le dimensioni massime di un'immagine WebP?

WebP è compatibile con bitstream con 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 sono supportati dal formato WebP?

Coerentemente con il bitstream VP8, lossy WebP funziona esclusivamente con una Formato immagine Y'CbCr 4:2:0 (spesso chiamato YUV420) a 8 bit. Consulta la Sezione 2, "Panoramica del formato" di RFC 6386, Guida al formato e alla decodifica dei dati VP8 per ulteriori dettagli.

WebP senza perdita di dati funziona esclusivamente con il formato RGBA. Consulta le Specifica per i bitstream senza perdita di dati WebP.

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

Sì, di solito durante la conversione da un formato con perdita di dati a WebP senza perdita di dati vice versa. Ciò è dovuto principalmente alla differenza dello spazio colore (YUV420 e ARGB) e la conversione tra questi.

Esistono tre situazioni tipiche:

Se l'immagine di origine è in formato ARGB senza perdita di dati, il downgrade spaziale a YUV420 introdurrà nuovi colori più difficili da comprimere rispetto quelle originali. Questa situazione solitamente può verificarsi quando l'origine è in formato PNG con pochi colori: la conversione avviene in WebP con perdita di dati (o, a un file JPEG con perdita di dati) potrebbe comportare dimensioni del file maggiori.
Se l'origine è in formato con perdita di dati, viene utilizzata la compressione WebP senza perdita di dati per catturare la natura con perdita di dati dell'origine, in genere si un file più grande. Questo non è specifico di WebP e può verificarsi quando ad esempio convertendo un'origine JPEG in formati WebP o PNG senza perdita di dati.
Se l'origine è in un formato con perdita di dati e stai tentando di comprimerla come WebP con perdita di dati e impostazione di qualità superiore. Ad esempio, se provi a convertire un file JPEG salvato a qualità 80 in un file WebP con qualità 95 di solito si traduce in un file di dimensioni maggiori, anche se entrambi i formati hanno perdita di dati. Valutare la qualità della fonte è spesso impossibile, quindi ti consigliamo di abbassa la qualità WebP target se le dimensioni del file sono costantemente maggiori. Un'altra possibilità è evitare di utilizzare l'impostazione di qualità e scegliere come target una determinata dimensione di file utilizzando l'opzione -size nello strumento cwebp, o l'API equivalente. Ad esempio, scegliere come target l'80% del file originale potrebbe rivelarsi più robusta.

Nota che la conversione di un'origine JPEG in WebP con perdita di dati o di un'origine PNG in senza perdita di dati WebP non è incline a sorprese di dimensioni simili.

WebP supporta la visualizzazione progressiva o interlacciata?

WebP non offre un aggiornamento con decodifica progressiva o interlacciata nei file JPEG o PNG Sense. Questo potrebbe applicare troppa pressione alla CPU e alla memoria del di decodifica del client poiché ogni evento di aggiornamento prevede un passaggio completo sistema di decompressione.

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

In alternativa, WebP offre la decodifica incrementale, in cui tutte le risorse in entrata byte del flusso di bit vengono utilizzati per provare a produrre una riga di esempio visualizzabile il prima possibile. Ciò consente di risparmiare memoria, CPU e attività di revisione client fornendo al contempo segnali visivi sullo stato del download. L'incrementale di decodifica è disponibile tramite API Advanced Decoding.

Come faccio a utilizzare le associazioni Java libwebp nel mio progetto Android?

WebP include il supporto per le associazioni JNI all'encoder e al decoder semplici nella directory swig/.

Creando la libreria in Eclipse:

Assicurati di avere plug-in ADT installato insieme agli strumenti NDK e il percorso NDK sia impostato correttamente (Preferenze > Android > NDK).
Crea un nuovo progetto: File > Nuovo > Progetto > Android progetto di applicazione.
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 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 NDK_TOOLCHAIN_VERSION=4.8 migliorerà in generale Prestazioni della build a 32 bit.
Aggiungi swig/libwebp.jar alla cartella del progetto libs/.
Crea il tuo progetto. Questa operazione creerà 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. In questo caso, alcuni dei passaggi descritti sopra possono essere riutilizzati.

Come faccio a utilizzare libwebp con C#?

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

Creare libwebp.dll. Questa operazione imposterà correttamente WEBP_EXTERN per esportare l'API funzioni.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Aggiungi libwebp.dll al progetto e importa le funzioni desiderate. Tieni presente che se utilizzi 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 di WebP animato rispetto alle GIF animate

WebP supporta il colore RGB a 24 bit con un canale alfa a 8 bit, rispetto a Colore GIF a 8 bit e alfa a 1 bit.
WebP supporta la compressione con perdita e senza perdita di dati. di fatto, un singolo può combinare frame con perdita di dati e frame senza perdita di dati. Il formato GIF supporta solo e una compressione senza perdita di dati. Le tecniche di compressione con perdita di dati di WebP sono particolarmente adatte alle immagini animate create a partire da video del mondo reale, un'esperienza sempre più fonte di immagini animate.
WebP richiede meno byte rispetto al formato GIF¹. Le GIF animate convertite in WebP con perdita di dati sono più piccole del 64%, mentre senza perdita I WebP sono più piccoli del 19%. Ciò è particolarmente importante sulle reti mobili.
WebP richiede meno tempo per la decodifica in presenza di ricerca. Nella La funzionalità lampeggiare, scorrere o cambiare scheda può nasconde e mostra le immagini, mettendo in pausa le animazioni e è saltato avanti fino a un altro punto. Utilizzo eccessivo della CPU, con conseguente le animazioni la perdita di frame può richiedere anche al decoder di andare avanti l'animazione. In questi scenari, WebP animato prende 0,57 volte il totale decodificare il tempo² come GIF, con un conseguente minore blocco durante lo scorrimento e un recupero più rapido dai picchi di utilizzo della CPU. Questo è grazie ai due vantaggi di WebP rispetto al GIF:
- Le immagini WebP memorizzano i metadati che indicano se ogni frame contiene alfa, eliminando la necessità di decodificare il frame per effettuare questa determinazione. Ciò porta a un'inferenza più accurata di quali frame precedenti dipende dal frame, riducendo così la decodifica non necessaria delle i frame.
- Proprio come un moderno codificatore video, quello WebP aggiunge euristicamente fotogrammi chiave a intervalli regolari (cosa che la maggior parte dei codificatori GIF non fa). Questo migliora notevolmente la ricerca nelle animazioni lunghe. Per facilitare inserendo questi frame senza aumentare significativamente le dimensioni dell'immagine, WebP aggiunge un 'blending method' (metodo di combinazione) segnala per ogni frame, oltre al metodo di smaltimento dei frame utilizzato dalla GIF. In questo modo un fotogramma chiave può tracciare come se l'intera immagine fosse stata cancellata. al colore di sfondo senza forzare il frame precedente a grandezza originale.

Svantaggi di WebP animato rispetto a GIF animata

In assenza di ricerca, la decodifica in linea retta di WebP è più Utilizzo di CPU elevato rispetto al formato GIF. Lossy WebP richiede un tempo di decodifica 2,2 volte maggiore rispetto a GIF, mentre WebP senza perdita prende 1,5 volte di più.
Il supporto di WebP non è altrettanto diffuso di quello delle GIF, che è di fatto universale.
L'aggiunta del supporto WebP ai browser aumenta l'ingombro del codice e superficie di attacco. In Blink corrispondono circa 1500 righe aggiuntive di codice (incluse la libreria WebP demux e l'immagine WebP lato Blink decoder). Tieni presente che questo problema potrebbe essere ridotto in futuro se WebP e WebM condividono codice di decodifica più comune o se in WebM.

Perché non supportare semplicemente WebM in <img>?

Potrebbe essere opportuno supportare formati video a lungo termine in <img> del tag. Tuttavia, farlo ora, con l'intento che WebM in <img> possa soddisfare il ruolo proposto di WebP animato, è problematico:

Quando decodifica un frame che si basa su frame precedenti, WebM richiede 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 da browser a browser e dispositivi mobili. Per facilitare la transcodifica automatica dei contenuti (ad es. per il risparmio di larghezza di banda), i browser dovrebbero aggiungere intestazioni che indicano i formati supportati dai tag immagine. Anche questo potrebbe essere insufficiente, in quanto tipi MIME come "video/webm" o "video/mpeg" fermo Non indicano il supporto del codec (ad es. VP8 rispetto a VP9). Dall'altra parte mano, il formato WebP è effettivamente congelato e se i fornitori che spediscono accetta di distribuire WebP animato, il comportamento di WebP in tutti gli UA devono essere coerenti; e poiché il file "image/webp" intestazione Accetta è già utilizzato per indicare il supporto WebP, nessuna nuova accettazione di modifiche all'intestazione sono necessarie.
Lo stack di video Chromium è ottimizzato per una riproduzione fluida e ipotizza la riproduzione di uno o due video nel tempo. Di conseguenza, l'implementazione è aggressiva nel consumare il sistema risorse (thread, memoria e così via) per massimizzare la qualità di riproduzione. Un tale di implementazione non è scalabile su molti video simultanei e devono essere riprogettate per essere adattate all'utilizzo con pagine web ricche di immagini.
WebM al momento non incorpora tutte le tecniche di compressione da WebP. Di conseguenza, questa immagine si comprime in modo significativo con WebP rispetto alle alternative:

¹ Per tutti i confronti tra GIF animata e WebP animato, abbiamo utilizzato un corpus di circa 7000 immagini GIF animate prese in modo casuale dal web. Queste immagini sono state convertite in un file WebP animato utilizzando il file "gif2webp" utilizzando lo strumento predefinite (create sulla base albero di origine libwebp al 10/08/2013). I numeri di confronto sono i valori medi di queste in formato Docker.

² I tempi di decodifica sono stati calcolati utilizzando le versioni più recenti di libwebp + ToT Blink al 10/08/2013 usando uno strumento di benchmark. "Decodifica l'ora con la ricerca" viene calcolata come "Decodifica i primi cinque frame, cancella il frame cache del buffer, decodificare i cinque frame successivi e così via".

³ WebM conserva 4 frame di riferimento YUV in memoria, con ogni frame memorizzare (larghezza+96)*(altezza+96) pixel. Per YUV 4:2:0, sono necessari 4 byte ogni 6 pixel (o 3/2 byte per pixel). Questi sistemi di riferimento utilizzano 4*3/2*(width+96)*(height+96) byte di memoria. WebP, invece, solo il frame precedente (in RGBA), ovvero 4*width*height byte di memoria.

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