Inspector de archivos WebP

Cómo usar

1. Suelta un archivo .webp en la caja. Vale cualquier cosa que cubra la extensión: una foto, una pegatina con transparencia, una animación o un archivo que sospechas roto.
2. Mira primero la forma del archivo. Simple con pérdida, simple sin pérdida y extendido son tres diseños distintos, y un decodificador que solo entienda los simples rechazará el tercero.
3. Compara el lienzo declarado con lo que decodificó este navegador. Deberían coincidir; si el navegador rechazó el archivo, la lista de hallazgos explica por qué.
4. Abre la tabla de fragmentos para ver el diseño: fourcc, desplazamiento, tamaño declarado y si sigue un byte de relleno. Esos desplazamientos son por donde empezar si depuras un codificador.
5. En una animación, revisa la tabla de fotogramas —los desplazamientos ya están devueltos al doble del campo— y las duraciones, donde Chrome reproduce un fotograma de 0 ms como 100 ms.

Preguntas frecuentes

¿Por qué un .webp empieza con un fragmento VP8 y otro con VP8L o VP8X? ¿No son el mismo formato?

Comparten contenedor y extensión, no flujo de bits. La forma simple con pérdida envuelve un fotograma clave de VP8, el mismo fotograma intra con el que arrancaría un vídeo VP8, y la forma simple sin pérdida envuelve un flujo VP8L, que es un códec completamente distinto con su propia codificación entrópica y sus transformadas de color. La forma extendida pone delante un fragmento VP8X para que el archivo pueda llevar además alfa en un fragmento ALPH aparte, un perfil ICC, Exif, XMP o una animación, y solo después los datos de imagen. Por eso un decodificador antiguo abre un WebP y rechaza el siguiente: las formas simples llegaron en 2010 y la extendida en 2011, y cada biblioteca las fue añadiendo en momentos distintos. El fourcc del primer fragmento es lo único que decide qué forma tienes.

Los desplazamientos de los fotogramas de una animación parecen la mitad de lo que deberían. ¿Por qué?

Porque es literalmente lo que está guardado. Una cabecera ANMF guarda la X y la Y del fotograma como valores de 24 bits que son el desplazamiento real dividido entre dos, que es también la razón de que un fotograma solo pueda colocarse en coordenadas pares. Un lector que imprima el campo tal cual muestra un fotograma en x=8 como x=4, y un compositor que use el campo en bruto dibuja cada fotograma a la mitad de distancia del borde del lienzo: un fallo que parece una deriva sutil y no una ruptura evidente. La misma cabecera guarda el ancho y el alto menos uno, así que un fotograma de 32 píxeles de ancho se escribe como 31. Esta herramienta duplica los desplazamientos y suma uno a los tamaños antes de mostrarlos, y por eso las cifras coinciden con lo que un decodificador pinta de verdad.

¿Qué pasa con un fotograma que declara una duración de 0 ms?

No se muestra durante cero tiempo. Chrome y los demás navegadores basados en Blink sustituyen por 100 ms la duración de un fotograma WebP que vale 0, la misma sustitución que hacen con un fotograma GIF de retardo muy pequeño, partiendo de que el cero era un descuido y no una petición de animación infinitamente rápida. Firefox y Safari no siempre han coincidido, y herramientas de línea de órdenes como ffmpeg conservan el cero y producen otra tasa de fotogramas. La consecuencia práctica es que la suma de las duraciones declaradas no es lo que dura el archivo: aquí se muestran ambos totales para que veas cuánto se separan antes de fiarte de los tiempos.

El lienzo y la imagen que contiene tienen tamaños distintos. ¿El navegador la estira o la encaja con bandas?

Ninguna de las dos cosas, si es una imagen fija. libwebp exige que el lienzo del VP8X sea igual a las dimensiones del único fotograma VP8 o VP8L que contiene, y rechaza el archivo cuando no coinciden; y como Chrome, Firefox y Safari decodifican WebP con libwebp, una imagen fija descuadrada sencillamente no se ve en ninguna parte. En una animación la regla es otra y el lienzo sí puede ser mayor: cada fotograma ANMF se compone en su propio desplazamiento y lo que sobresalga del borde se recorta. Por eso esta herramienta trata el desacuerdo entre lienzo y flujo de bits en una imagen fija como un hallazgo, e informa aparte de los fotogramas que se salen del lienzo.

¿Por qué importa el campo de tamaño RIFF si el archivo se ve igualmente?

Solo se ve igualmente si el campo es correcto. Los cuatro bytes del desplazamiento 4 deben contener el tamaño del archivo menos ocho —esos ocho son el fourcc RIFF y el propio campo de tamaño— y libwebp lo valida antes de decodificar nada. Una descarga que se cortó conserva su campo de tamaño original mientras pierde bytes por el final, así que el campo queda demasiado grande y el archivo se rechaza sin más aviso que un icono de imagen rota. El caso contrario es un codificador que se olvidó de volver atrás y corregir el campo tras añadir metadatos, lo que produce un archivo que algunas herramientas leen y los navegadores no. Aquí se imprimen ambos números para que veas cuál de los dos casos tienes, y se señalan aparte los bytes que queden tras el último fragmento.

¿Cómo se guarda la transparencia y por qué la misma imagen a veces tiene un fragmento ALPH y a veces no?

Hay tres disposiciones. Un archivo sin pérdida registra el alfa dentro del propio flujo VP8L y se limita a poner un bit de pista en su cabecera. Uno con pérdida no puede, porque VP8 no tiene canal alfa en absoluto, así que el codificador emite un archivo extendido: un VP8X con la bandera de alfa activada, un fragmento ALPH con el plano de alfa —comprimido sin pérdida y filtrado opcionalmente en horizontal, vertical o por gradiente— y después el fragmento VP8 con el color. Una animación repite eso por fotograma, así que unos fotogramas pueden llevar ALPH y otros no. Un detalle más: un codificador con pérdida suele tirar el color de los píxeles totalmente transparentes para ahorrar bytes, algo invisible hasta que algo compone o desenfoca la imagen, y la opción exact de libwebp es la que lo conserva.

Herramientas relacionadas