Convertir GIF a AVIF

Un fotograma de GIF es una rejilla de índices sobre una paleta de 256 entradas como mucho, comprimida con LZW. No hay tono continuo dentro. La fotografía, el degradado o la sombra suave que hubiera al principio se asignó a esos 256 valores en el momento de escribir el GIF, y esa asignación no se deshace.

Conviene tenerlo presente porque la fama de AVIF se ganó con fotografías, donde le saca ventaja al JPEG por un margen amplio con la misma calidad aparente. Un GIF no es una fotografía en el sentido que importa aquí, aunque represente una, y las cifras que se citan de AVIF no se trasladan a esta fuente. Lo que se puede lograr está limitado por lo que el GIF conservó.

Para fingir los colores que no tiene, un codificador de GIF alterna píxeles de dos entradas disponibles en un patrón regular —el difuminado de Floyd-Steinberg, casi siempre— para que la vista los promedie en un tercer color. A tamaño de lectura funciona. A nivel de píxel es un campo de ruido de alta frecuencia.

Cualquier códec moderno, AVIF incluido, predice cada bloque a partir de lo anterior y guarda solo el error. Un patrón de tramado es justo lo que no se puede predecir, así que el codificador gasta bytes reales en reproducir el ruido. De ahí el resultado que desconcierta a mucha gente: un AVIF más pesado que el GIF del que salió, en una imagen con seis colores visibles.

El control de calidad vale 82 por defecto, y ese mismo 82 se aplica igual a JPEG, WebP, AVIF y JXL: no hay un valor pensado para cada formato. Es un punto de partida razonable para una cámara y conservador de más para lo que hay aquí.

Una fuente indexada tiene mucho menos que proteger, así que bajar a 60 o 65 sobre un GIF convertido suele ser indistinguible del original y se lleva por delante la mayor parte del recargo del tramado. La prueba que zanja la discusión es el recuento de bytes, no una opinión: convierte una vez con el valor por defecto, otra más abajo, y compara los dos con el GIF.

El lector típico de esta página no tiene un GIF, tiene una carpeta. Portales municipales, intranets universitarias, webs de asociaciones y tiendas montadas sobre gestores de contenido antiguos arrastran cientos de botones, separadores, diagramas, cabeceras y capturas guardadas en GIF porque en su día era lo que abría todo el mundo.

Esos archivos siguen viajando por la red cada vez que alguien abre la página desde el móvil, con frecuencia sobre una conexión que se paga por megabyte. Ahí está el argumento real para pasar por esta conversión: no es un cambio de moda de formato, es peso que se descarga miles de veces al mes y que en muchos casos se puede reducir sin que nadie note la diferencia.

El registro clasifica la compatibilidad de AVIF como moderna, no universal, y esa distinción tiene consecuencias en una web con tráfico real: los navegadores actuales lo leen y queda una cola que no. Un GIF, con todos sus defectos, lo abre absolutamente todo lo que se haya construido nunca.

Sustituirlo sin más es una regresión para esa cola, y para eso existe el elemento «picture». Se declara el AVIF como primera fuente, un PNG o un WebP como segunda, y dentro queda una etiqueta de imagen normal como caso base. El navegador se queda con lo primero que entiende. Merece la pena comprobar que el respaldo se ve de verdad, porque este fallo es invisible en el equipo donde se programó.

AVIF admite animación —el formato la contempla y existen archivos animados—, pero esta conversión no produce ninguno. El decodificador entrega una sola imagen y se codifica una sola imagen, así que un GIF animado llega convertido en el fotograma con el que empieza.

Para el trabajo del que trata esta página, que son imágenes fijas, ese comportamiento es el correcto. Si el GIF que estás optimizando sí se mueve, AVIF no es donde está el ahorro: un contenedor de vídeo con compensación de movimiento real ocupa una fracción de lo que ocupa cualquier formato de imagen por fotogramas, y el camino que compensa es el del vídeo.

AVIF guarda hasta 12 bits por canal y admite gamas de color amplias. Son las capacidades por las que resulta un buen formato de entrega y de archivo para fotografía tomada con equipo moderno.

Nada de eso aplica a un GIF. La fuente tiene color indexado de 8 bits sacado de una tabla de 256 entradas, y meterlo en un contenedor que podría haber almacenado mucho más no inventa colores nuevos: guarda ese puñado con sitio de sobra. Tampoco se pierde nada, y esa es la conclusión útil. En color la conversión es neutra y la única pregunta que queda es la de los bytes.

Aquí solo se aplana lo que va a JPG, a BMP y a GIF. AVIF no está en esa lista, así que el canal alfa se escribe y el fondo transparente de un botón o de un logotipo sobrevive a la conversión sin que haya que elegir un color de relleno.

Lo que llega es exactamente lo que había, ni más ni menos. Un GIF solo puede marcar una entrada de su paleta como transparente, de modo que sus bordes son duros por construcción; AVIF admite una transparencia gradual, pero no puede inventar la suavidad que la fuente nunca tuvo. Si el logotipo se ve dentado sobre el fondo de la página, el dentado venía de origen.

El problema declarado de AVIF en este registro es la velocidad de codificación, y no es un efecto menor. AV1 se diseñó con un espacio de búsqueda enorme y el codificador de imagen fija lo aprovecha; una imagen mediana tarda bastante más que la misma imagen como WebP o como JPEG, y ese trabajo lo hace tu procesador y no una granja de servidores.

Para una carpeta de gráficos heredados sigue siendo el intercambio correcto, porque el coste se paga una vez y el ahorro se cobra en cada visita. Pero conviene planificarlo: doscientos GIF antiguos son un café, no un clic, y lanzarlos en la misma máquina que tiene abierto el entorno de desarrollo hará que las dos cosas vayan lentas. Se pueden soltar hasta cien archivos por tanda.

AVIF no es automáticamente la respuesta buena para un GIF heredado. WebP codifica mucho más rápido, lo lee un conjunto más amplio de navegadores y, en gráficos pequeños y planos —que es lo que son casi todos los GIF supervivientes—, la diferencia de tamaño entre ambos se mide en unos pocos cientos de bytes.

La división aproximada: AVIF donde la imagen es grande y fotográfica y el ahorro se cuenta en decenas de kilobytes; WebP donde es un gráfico pequeño de interfaz y lo que se gana es compatibilidad y tiempo. Y cuando el GIF es un logotipo de bordes duros con cuatro colores, PNG le gana con frecuencia a los dos, porque comprimir color plano sin pérdida es exactamente para lo que se hizo.

Conviene saberlo antes de automatizar nada: una conversión entrega lo que el codificador haya producido, sea más pequeño o más grande que el original. La herramienta de compresión de este sitio sí compara y devuelve el archivo de partida cuando el resultado no mejora, pero esa red de seguridad vive en la compresión y no en esta ruta.

De modo que, con una carpeta de GIF tramados, es perfectamente posible acabar con doscientos AVIF que pesan más que lo que sustituyen y con una web más lenta que antes. La disciplina que lo evita es aburrida y funciona: convertir, comparar los dos tamaños archivo por archivo y quedarse con el menor de cada pareja. Una hoja de cálculo con dos columnas basta para eso.

El codificador de AV1 es un módulo de WebAssembly que se descarga la primera vez que se usa este par y luego se ejecuta en local. La imagen se descodifica y se vuelve a codificar dentro de la pestaña, sin cuenta de usuario y sin que ninguna parte del archivo llegue a un servidor. El tope por archivo es de 100 MB.

También desaparecen por el camino los datos que el GIF llevara escritos: la conversión descodifica a píxeles y el codificador solo escribe la imagen, de modo que un bloque de comentario con el nombre del programa que generó el banner en 2008 no viaja al AVIF. En una migración masiva eso es una limpieza gratuita que nadie tiene que acordarse de hacer.