Se usó la API de Cloud Translation para traducir esta página.

Preguntas frecuentes

¿Qué es WebP? ¿Por qué debería utilizarlo?

WebP es un método de compresión con y sin pérdida que se puede usar en pantallas grandes variedad de imágenes fotográficas, traslúcidas y gráficas que se encuentran en la Web. El grado de compresión con pérdida es ajustable para que un usuario pueda elegir la el tamaño del archivo y la calidad de la imagen. WebP suele lograr una un promedio de 30% más de compresión que JPEG y JPEG 2000, sin perder la imagen calidad (consulta Estudio comparativo).

El formato WebP esencialmente tiene como objetivo crear imágenes más pequeñas y de mejor aspecto. que pueden ayudar a que la Web sea más rápida.

¿Qué navegadores web tienen compatibilidad nativa con WebP?

Los webmasters interesados en mejorar el rendimiento del sitio pueden crear alternativas WebP optimizadas para sus imágenes actuales y publicarlas en un orientadas a navegadores que admiten WebP.

Compatibilidad con WebP con pérdida
- Google Chrome (computadoras de escritorio) 17 y versiones posteriores
- Google Chrome para Android versión 25 o posterior
- Microsoft Edge 18 y versiones posteriores
- Firefox 65 y versiones posteriores
- Opera 11.10 y versiones posteriores
- Navegador web nativo, Android 4.0+ (ICS)
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur+)
WebP con pérdida, sin pérdida y compatibilidad con versiones alfa
- Google Chrome (computadoras de escritorio) 23 y versiones posteriores
- Google Chrome para Android versión 25 o posterior
- Microsoft Edge 18 y versiones posteriores
- Firefox 65 y versiones posteriores
- Opera 12.10 y versiones posteriores
- Navegador web nativo, Android 4.2 y versiones posteriores (JB-MR1)
- Luna pálida, más de 26 años
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur+)
Compatibilidad con animación WebP
- Google Chrome (computadoras de escritorio y Android) 32 y versiones posteriores
- Microsoft Edge 18 y versiones posteriores
- Firefox 65 y versiones posteriores
- Opera 19 y versiones posteriores
- Safari 14 y versiones posteriores (iOS 14 y versiones posteriores, macOS Big Sur+)

Consulta lo siguiente:

¿Cómo puedo detectar la compatibilidad de los navegadores con WebP?

Te convendrá entregar imágenes WebP solo a clientes que puedan mostrarlas correctamente y recurrir a formatos heredados para los clientes que no pueden. Por suerte Existen varias técnicas para detectar la compatibilidad con WebP, ambas en la del cliente y del servidor. Algunos proveedores de CDN ofrecen detección de compatibilidad con WebP como parte de su servicio.

Negociación de contenido del servidor mediante encabezados Accept

Es habitual que los clientes web envíen una solicitud de aceptación. de la solicitud, que indica qué formatos de contenido están dispuestos a aceptar en respuesta. Si un navegador indica anticipadamente que "aceptará" el formato image/webp el servidor web sabe que puede enviar imágenes WebP de forma segura, lo que simplifica enormemente la negociación de contenido. Consulta los siguientes vínculos para obtener más información.

Modernizr

Modernizr es una biblioteca de JavaScript que detecta de manera conveniente elementos de HTML5 y Compatibilidad con la función CSS3 en navegadores web Busca las propiedades Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha y Modernizr.webp.animation.

Elemento HTML5 `<picture>`

HTML5 admite un elemento <picture>, que te permite enumerar varias objetivos de imagen alternativos en orden de prioridad, de modo que un cliente solicite la primera imagen candidata que puede mostrar correctamente. Consulta este debate sobre HTML5 Rocks. El elemento <picture> es compatible con más navegadores todo el tiempo.

En tu propio JavaScript

Otro método de detección consiste en intentar decodificar una imagen WebP muy pequeña que usa una función en particular y comprueba si es exitosa. Ejemplo:

// 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];
}

Ten en cuenta que la carga de imágenes no implica bloqueos y es asíncrona. Esto significa que cualquier el código que depende de la compatibilidad con WebP se debe colocar preferentemente en la devolución de llamada .

¿Por qué Google lanzó WebP como código abierto?

Creemos firmemente en la importancia del modelo de código abierto. Con WebP en de código abierto, cualquier persona puede trabajar con el formato y sugerir mejoras. Con tus comentarios y sugerencias, creemos que WebP será aún más útil como formato gráfico a lo largo del tiempo.

¿Cómo puedo convertir mis archivos de imagen personales a WebP?

Puedes usar la utilidad de línea de comandos WebP para convertir tus archivos de imagen personales al formato WebP. Para obtener más información, consulta Cómo usar WebP.

Si tienes que convertir muchas imágenes, puedes usar la shell de tu plataforma simplificar la operación. Por ejemplo, para convertir todos los archivos jpeg en una carpeta, prueba lo siguiente:

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

¿Cómo puedo evaluar por mí la calidad de la imagen WebP?

Actualmente, puedes ver archivos WebP convirtiéndolos a un formato común que usa compresión sin pérdida, como PNG, y luego ve los archivos PNG en desde cualquier navegador o visor de imágenes. Para tener una idea rápida de la calidad WebP, consulta la Galería de este sitio para mostrar una foto en paralelo de datos.

¿Cómo obtengo el código fuente?

El código del conversor está disponible en la sección de descargas del proyecto de código abierto WebP . El código del decodificador básico y la especificación de VP8 están en el sitio de WebM. Consulta la Página Contenedor RIFF del contenedor especificación.

¿Cuál es el tamaño máximo que puede tener una imagen WebP?

WebP es compatible con el flujo de bits de VP8 y usa 14 bits para el ancho y la altura. Las dimensiones máximas de píxeles de una imagen WebP son de 16,383 x 16,383.

¿Qué espacios de color admite el formato WebP?

De acuerdo con el flujo de bits de VP8, el WebP con pérdida funciona exclusivamente con un Formato de imagen Y'CbCr 4:2:0 de 8 bits (a menudo llamado YUV420). Consulta la sección 2, "Descripción general del formato" de RFC 6386, Guía de decodificación y formato de datos de VP8 para obtener más detalles.

WebP sin pérdida funciona exclusivamente con el formato RGBA. Consulta la Especificación del flujo de bits sin pérdida de WebP.

¿Una imagen WebP puede crecer más que su imagen de origen?

Sí, generalmente cuando se convierte de un formato con pérdida a WebP sin pérdida o vice versa. Esto se debe principalmente a la diferencia del espacio de color (YUV420 frente a ARGB). y la conversión entre ellas.

Hay tres situaciones típicas:

Si la imagen de origen está en formato ARGB sin pérdida, la reducción de muestreo espacial YUV420 introducirá colores nuevos que son más difíciles de comprimir que a los originales. Esta situación suele ocurrir cuando la fuente está en formato PNG con pocos colores: convierte a WebP con pérdida (o, de manera similar, a un archivo JPEG con pérdida) potencialmente darán como resultado un tamaño de archivo más grande.
Si la fuente está en formato con pérdida, mediante compresión WebP sin pérdida para capturar la naturaleza con pérdidas de la fuente, por lo general, uno más grande. Esto no es particular de WebP y puede ocurrir cuando convertir una fuente JPEG en formatos WebP o PNG sin pérdida, por ejemplo.
Si la fuente está en formato con pérdida y tratas de comprimirla como un WebP con pérdida, con una configuración de calidad más alta. Por ejemplo, tratar de convierte un archivo JPEG guardado en calidad 80 en un archivo WebP con calidad 95 suele generar un archivo más grande, incluso con pérdidas en ambos formatos. Evaluar la calidad de la fuente suele ser imposible, por lo que se recomienda disminuirá la calidad de WebP objetivo si el tamaño del archivo es constantemente más grande. Otra posibilidad es evitar usar la configuración de calidad y, en cambio, Orienta el contenido a un tamaño de archivo determinado con la opción -size en la herramienta cwebp. o la API equivalente. Por ejemplo, orientar el anuncio al 80% del archivo original podría ser más sólido.

Ten en cuenta que puedes convertir una fuente JPEG en WebP con pérdida o una fuente PNG en formato sin pérdida. WebP no son propensos a estas sorpresas de tamaño de archivo.

¿WebP admite pantallas progresivas o entrelazadas?

WebP no ofrece una actualización de decodificación progresiva o entrelazada en el archivo JPEG o PNG. Es probable que esto presione demasiado la CPU y la memoria de la cliente de decodificación, ya que cada evento de actualización implica un pase completo a través del de descompresión.

En promedio, decodificar una imagen JPEG progresiva equivale a decodificar la modelo de referencia 3 veces.

Como alternativa, WebP ofrece decodificación incremental, en la que todas las solicitudes entrantes bytes del flujo de bits se usan para intentar producir una fila de muestra que se pueda mostrar como lo antes posible. Esto ahorra memoria, CPU y esfuerzo de volver a pintar en el cliente y, al mismo tiempo, proporciona indicaciones visuales sobre el estado de descarga. El aumento la función de decodificación está disponible a través del API de decodificación avanzada.

¿Cómo uso las vinculaciones de Java de libwebp en mi proyecto de Android?

WebP incluye compatibilidad con vinculaciones de JNI con el codificador y el decodificador simples. interfaces del directorio swig/.

Compila la biblioteca en Eclipse:

Asegúrate de tener las Complemento ADT junto con las herramientas del NDK y la ruta del NDK esté configurada correctamente. (Preferencias > Android > NDK).
Crea un proyecto nuevo: File > Nuevo > Proyecto > En Android Proyecto de aplicación
Clonar o Desempaqueta libwebp en una carpeta llamada jni en el proyecto nuevo.
Agrega swig/libwebp_java_wrap.c a la lista LOCAL_SRC_FILES.
Haz clic con el botón derecho en el proyecto nuevo y selecciona Android Tools > Agregar Native Support ... para incluir la biblioteca en tu compilación.
Abre las propiedades del proyecto y ve a Compilación de C/C++ > Comportamiento. Agrega ENABLE_SHARED=1 a la sección Build (Incremental build) para compilar libwebp como una biblioteca compartida.

Nota: En general, la configuración de NDK_TOOLCHAIN_VERSION=4.8 mejorará Rendimiento de compilación de 32 bits.
Agrega swig/libwebp.jar a la carpeta del proyecto libs/.
Compila tu proyecto. Esto creará libs/<target-arch>/libwebp.so.
Usa System.loadLibrary("webp") para cargar la biblioteca durante el tiempo de ejecución.

Ten en cuenta que la biblioteca se puede compilar manualmente con ndk-build y los Android.mk En ese caso, se pueden volver a usar algunos de los pasos descritos anteriormente.

¿Cómo uso libwebp con C#?

WebP se puede compilar como una DLL que exporta la API de libwebp. Estas funciones pueden y, luego, se importará en C#.

Compila libwebp.dll. Esto configurará WEBP_EXTERN correctamente para exportar la API. funciones.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Agrega libwebp.dll a tu proyecto y, luego, importa las funciones que desees. Ten en cuenta que, si utilizas API simple debes llamar a WebPFree() para liberar cualquier búfer que se muestre.

[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);
}

¿Por qué debería usar WebP animado?

Ventajas de los archivos WebP animados en comparación con los GIF animados

WebP admite color RGB de 24 bits con un canal alfa de 8 bits, en comparación con GIF de 8 bits y alfa de 1 bit.
WebP admite la compresión con y sin pérdida. de hecho, un solo puede combinar fotogramas con y sin pérdida. Solo se admiten GIF compresión sin pérdida. Las técnicas de compresión con pérdida de WebP son adecuadas hasta imágenes animadas creadas a partir de videos del mundo real, una popular fuente de imágenes animadas.
WebP requiere menos bytes que GIF¹. Los GIF animados convertidos en WebP con pérdida son un 64% más pequeños, mientras que los formatos sin pérdida Los WebP son un 19% más pequeños. Esto es especialmente importante en las redes móviles.
WebP tarda menos tiempo en decodificarse en presencia de búsquedas. En Si parpadea, se puede desplazar o cambiar de pestaña. ocultar y mostrar imágenes, lo que provoca que las animaciones se detengan y, luego, salté a un punto diferente. El uso excesivo de la CPU puede provocar que, Las animaciones que dejan de lado los fotogramas también pueden requerir que el decodificador busque hacia delante en la animación. En estas situaciones, WebP animado tarda 0.57 veces más en total el tiempo de decodificación² como GIF, lo que genera menos bloqueos durante el desplazamiento y una recuperación más rápida ante aumentos repentinos del uso de CPU. Este es debido a las siguientes dos ventajas de WebP sobre GIF:
- Las imágenes WebP almacenan metadatos sobre si cada fotograma contiene alfa o lo que elimina la necesidad de decodificar la trama para realizar esta determinación. Esto conduce a una inferencia más precisa de qué fotogramas anteriores se dan a un determinado de la que depende, lo que reduce la decodificación innecesaria de o los fotogramas.
- Al igual que un codificador de video moderno, el codificador WebP agrega de forma heurística fotogramas clave a intervalos regulares (algo que la mayoría de los codificadores de GIF no hace). Esto mejora drásticamente los saltos en animaciones largas. Para facilitar insertar esos fotogramas sin aumentar significativamente el tamaño de la imagen, WebP agrega un "método de combinación" marca para cada fotograma, además del método de eliminación de fotogramas que usa el GIF. Esto permite que un fotograma clave se dibuje como si se hubiera borrado toda la imagen. al color de fondo sin forzar al fotograma anterior tamaño completo.

Desventajas de WebP animado en comparación con GIF animado

Ante la ausencia de búsqueda, la decodificación en línea recta de WebP es más más CPU que los GIF. La calidad de WebP con pérdida tarda 2.2 veces más tiempo de decodificación GIF, mientras que el formato WebP sin pérdida tarda 1.5 veces más.
La compatibilidad con WebP no es tan generalizada como la compatibilidad con GIF, que es efectivamente universal.
Agregar compatibilidad con WebP a los navegadores aumenta la huella del código y superficie de ataque. En Blink son aproximadamente 1500 líneas adicionales de código (incluida la biblioteca demux de WebP y la imagen WebP de Blink) decodificador). Ten en cuenta que este problema podría reducirse en el futuro si WebP y WebM comparten código de decodificación más común, o si WebP y capacidades se incluyen en los WebM.

¿Por qué no se admite simplemente WebM en <img>?

A largo plazo, podría ser conveniente admitir formatos de video en <img>. etiqueta. Sin embargo, al hacerlo ahora, con el intent que WebM en <img> puede completar el rol propuesto para WebP animado es problemático:

Al decodificar un fotograma que se basa en fotogramas anteriores, WebM requiere Un 50% más de memoria que WebP animado para contener la cantidad mínima de fotogramas anteriores³.
La compatibilidad con códecs de video y contenedores varía ampliamente entre navegadores y dispositivos. Para facilitar la transcodificación automática de contenido (p.ej., para con proxies que ahorran ancho de banda), los navegadores tendrían que agregar encabezados de aceptación que indican los formatos compatibles con sus etiquetas de imagen. Incluso este podría ser insuficiente, ya que los tipos de MIME como "video/webm" o "video/mpeg" quieto No indiques la compatibilidad con el códec (p. ej., VP8 frente a VP9). Del otro el formato WebP se congela, y si los proveedores que envían acepta enviar WebP animados, el comportamiento de WebP en todos los UA. debe ser coherente; y como la columna "image/webp" El encabezado Aceptar es ya se utiliza para indicar la compatibilidad con WebP, no hay nuevos cambios de encabezado de aceptación son necesarias.
La pila de videos de Chromium está optimizada para una reproducción fluida y presupone que solo se están reproduciendo uno o dos videos al mismo tiempo tiempo. Como resultado, la implementación es agresiva en el consumo de sistemas recursos (subprocesos, memoria, etc.) para maximizar la calidad de reproducción. Así no se adapta bien a muchos videos simultáneos y se deben rediseñar para que puedan usarse en páginas web con muchas imágenes.
Actualmente, WebM no incorpora todas las técnicas de compresión desde WebP. Como resultado, esta imagen se comprime significativamente mejor con WebP que las alternativas:

¹ En todas las comparaciones entre GIF animados y WebP animados, utilizó un corpus de alrededor de 7,000 imágenes GIF animadas tomadas aleatoriamente de la Web. Estas imágenes se convirtieron a WebP animados con el archivo "gif2webp". con configuración predeterminada (creada a partir de la última Árbol de fuentes de libwebp a partir del 8 de octubre de 2013). Los números comparativos son los valores promedio entre estos imágenes de contenedores.

² Los tiempos de decodificación se calcularon con los últimos libwebp + ToT. Blink hasta el 8/10/2013 usando una herramienta de comparativas. Tiempo de decodificación con la búsqueda" se procesa como "Decodifica los primeros cinco fotogramas, borra el fotograma almacenar en caché, decodificar las siguientes cinco tramas, y así sucesivamente".

³ WebM mantiene 4 marcos de referencia YUV en la memoria, con cada fotograma. Almacenando (ancho + 96)*(alto + 96) píxeles. Para YUV 4:2:0, necesitamos 4 bytes por 6. píxeles (o 3/2 bytes por píxel). Entonces, estos marcos de referencia usan 4*3/2*(width+96)*(height+96) bytes de memoria. WebP, por otro lado, solo necesitas que el fotograma anterior (en RGBA) esté disponible, lo que 4*width*height bytes de memoria.

⁴ El procesamiento WebP animado requiere la versión 32 o una posterior de Google Chrome.