Convertir WebM a WebP

Una imagen destinada a una página web se juzga con otro criterio que una destinada a un documento. Nadie la va a abrir en un visor: será una de veinte cosas que el navegador descarga mientras alguien decide si se queda. Su peso en kilobytes es un coste real que paga cada visita, y su formato tiene que ser uno que el gestor de contenidos, el paso de compilación y el navegador acepten sin tratamiento especial.

Ese es todo el argumento a favor de WebP frente a JPG aquí. El mismo resultado visible, alrededor de un treinta por ciento menos de bytes y soporte universal en los navegadores actuales. En una rejilla de doce miniaturas de tutoriales eso es un tercio del peso de imagen fuera, sin cambio visible y sin marcado de respaldo, que es la clase de optimización que sobrevive al contacto con un proyecto real.

WebP y WebM salen del mismo esfuerzo. Google publicó ambos alrededor de 2010 como respuestas libres de regalías a formatos gravados por patentes, y la compresión de imagen fija de WebP creció a partir de la codificación intra de VP8, el códec de vídeo alrededor del cual se construyó WebM. Sacar una imagen fija de un WebM y escribirla como WebP se parece más a un aire de familia que a una traducción.

Eso no hace que la conversión sea sin pérdida, y conviene decirlo para que nadie lo espere. El fotograma se descodifica a píxeles y se vuelve a codificar desde cero. Lo que sí compra el parecido de familia es que la clase de detalle que el códec de vídeo conservó es la clase de detalle que el codificador de imagen fija sabe conservar, y por eso las imágenes WebP sacadas de vídeo aguantan mejor de lo que sugerirían los números por sí solos.

Lo más útil que se puede hacer con esta conversión es también lo más obvio en cuanto se ve: coger un fotograma del WebM y usarlo como atributo poster de ese mismo vídeo. El navegador muestra el póster hasta que empieza la reproducción, así que lo primero que ve la gente es una imagen real del vídeo y no un rectángulo negro ni una foto de archivo sin relación.

Cógelo alrededor del segundo uno en lugar de en el cero. El primer fotograma de una grabación es a menudo un fundido, un estado en blanco o una página todavía cargando, y es además el fotograma que el vídeo va a pintar en el instante en que arranque, así que un póster tomado un poco después le da a quien mira algo que ver sin producir un salto visible al empezar. El segundo cero da el fotograma menos interesante del archivo y un póster que lo duplica.

El fotograma sale con las dimensiones propias del vídeo y sin escalar nada. Una grabación en Full HD produce un WebP de 1.920 por 1.080; una captura en 4K, uno de 3.840 por 2.160. Es deliberado: un fotograma tiene una resolución real y el trabajo de esta conversión es entregarla intacta, no adivinar a qué tamaño se va a mostrar.

El redimensionado pertenece más adelante en la cadena. Lo que genera tu srcset, la canalización de imágenes de tu gestor de contenidos o tu paso de compilación ya sabe qué anchos necesita la maqueta, y hará mejor trabajo partiendo de un original a resolución completa que de uno ya reducido. Llévate aquí la versión más grande honesta y deja que las pequeñas las haga lo que conoce la maqueta.

Esta página no ofrece control de calidad. La imagen fija se escribe con el valor por defecto del sitio, 82, que es la banda donde WebP resulta visualmente indistinguible del origen en contenido corriente y sigue comprimiendo con fuerza. El único mando que hay es qué segundo del vídeo tomar.

De ahí se sigue algo que conviene tener claro: esta salida nunca es sin pérdida. WebP tiene un modo sin pérdida propio y este camino no lo pide en ningún caso, así que si lo que necesitas es una copia exacta del fotograma descodificado —una prueba en una incidencia, una imagen que se va a comparar píxel a píxel—, la conversión de WebM a PNG es la que hace eso y esta no.

La imagen que hay dentro de un WebM se codificó para el movimiento. Un códec de vídeo gasta sus bits donde las cosas cambian y economiza donde no, dando por supuesto que nadie se va a quedar mirando un fotograma suelto. Congelar uno es hacer exactamente lo que daba por descartado.

Para una miniatura el efecto práctico es pequeño, porque una miniatura se muestra a una fracción de su tamaño nativo y reducir disimula bastante bien la blandura. Importa cuando la imagen se usa grande —una cabecera, una ilustración a todo el ancho—, donde un fotograma tomado durante una panorámica o un desplazamiento se verá visiblemente pastoso junto al resto de la página. La solución es el segundo: busca un instante en el que la imagen esté quieta y tómalo de ahí.

Los navegadores dejaron de ser el problema; la cola larga está en otra parte. Algunos programas de correo no dibujan WebP, así que la miniatura de un boletín debería ser un JPG. Bastantes aplicaciones de escritorio antiguas, flujos de imprenta y algún formulario de subida siguen rechazando el formato. Windows y macOS lo previsualizan bien desde hace tiempo, cosa que no era cierta hace unos años y de donde viene casi todo el consejo desactualizado sobre este tema.

Dentro de un navegador es seguro tratar WebP como universal, y eso es lo que lo convierte en la opción pragmática frente a AVIF. Si el destino es cualquier otra cosa —un correo, un documento, una imprenta, un formulario—, coge el JPG y deja de darle vueltas.

Una biblioteca de tutoriales necesita una miniatura por vídeo, y eso significa una conversión por archivo y no una por fotograma. Conviertes, apuntas el segundo que funcionó, pasas al siguiente. El ciclo completo son un par de segundos porque entre intentos no se sube nada y no hay cola.

Merece la pena elegir los segundos a conciencia en lugar de aceptar el cero en todos. Una rejilla de miniaturas donde todas muestran un editor vacío o un indicador de carga no le dice a nadie cuál es cuál, y eso es exactamente lo que produce coger el fotograma por defecto de cada archivo.

La imagen no lleva sonido, por definición, ni pistas de subtítulos como tales; los subtítulos incrustados aparecen porque forman parte de la imagen. Tampoco cruza nada de lo que el archivo llevara escrito: el WebP que sale de aquí no tiene fecha, ni dispositivo, ni título, porque la conversión descodifica a píxeles y el codificador escribe solo píxeles.

Para una imagen que va a publicarse eso es una ventaja discreta: no hay nada incrustado que revise alguien más adelante. Si necesitas atribuir la imagen o fechar la captura, esa información va en la página que la publica, no dentro del archivo.

Las grabaciones que necesitan un póster suelen ser justamente las que todavía no se han publicado: una demostración de producto, el recorrido por una función que no se ha anunciado, un módulo de un curso. Subir el vídeo entero a un conversor para que te devuelva una miniatura de 60 KB es mucha exposición para muy poco trabajo.

La descodificación y la codificación ocurren en la pestaña, con los códecs que el navegador ya tiene para reproducir WebM. No se envía nada que contenga el vídeo, no hace falta cuenta y no hay cupo diario, lo cual significa además que convertir treinta archivos es la misma operación treinta veces y no un motivo para contratar nada.