Optimizar GIF

Elimina la redundancia entre los fotogramas de un GIF animado sin cambiar su tamaño, su velocidad ni sus colores.

1. 1

   Añade tu GIF

   Arrastra un GIF animado al área de carga o haz clic para buscarlo. También funcionan WebP animado y APNG. El archivo se lee en tu dispositivo y nunca se sube.

2. 2

   Deja los valores por defecto para una pasada sin pérdida

   La diferencia entre fotogramas está activada y solo se eliminan los duplicados idénticos byte a byte. Con estos ajustes la imagen no cambia: el archivo simplemente deja de guardar lo que ya guardaba.

3. 3

   Usa un control deslizante solo si necesitas más

   La tolerancia de diferencia perdona píxeles casi idénticos entre fotogramas. Las rachas con pérdida unen píxeles casi idénticos dentro de un fotograma. Ambas cambian precisión por tamaño y te muestran exactamente cuánto cuesta.

4. 4

   Revisa el informe y descarga

   El panel de resultado indica los fotogramas conservados, la parte del lienzo que cubre cada fotograma guardado y la duración de entrada y de salida. Pulsa Descargar cuando los números digan lo que buscabas.

Casi todos los GIF que circulan son más grandes de lo necesario por un motivo que nada tiene que ver con la calidad. El formato permite desde 1989 que un fotograma cubra solo el rectángulo que cambió y marque el resto de sus píxeles como «lo que ya hay en pantalla sigue siendo correcto», y la mayoría de codificadores nunca usan ninguna de las dos cosas. Así, una grabación de veinte fotogramas de una página estática con un cursor en movimiento guarda esa página estática veinte veces. Optimizar elimina la repetición y no toca nada más.

Guarda solo los píxeles que cambian entre fotogramas, borra los fotogramas que se repiten y suma su tiempo al que se queda, y comparte una tabla de colores en toda la animación.

Lee GIF, WebP animado y APNG. Escribe un GIF89a estándar con las mismas dimensiones, la misma duración y —cuando la paleta cabe— los mismos colores.

Cuánto vale eso, medido

• Diferencia entre fotogramas. En nuestra animación de referencia, 196.091 bytes guardados completos pasan a 48.131 guardados como diferencias. En la versión de cien fotogramas, 4.776.638 pasan a 1.172.755. Ambos son 4,07x y ambos son exactos en color.
• Fotogramas duplicados. Una animación de doce fotogramas con cuatro imágenes distintas sale con cuatro fotogramas que llevan el tiempo de los doce. Una de seis fotogramas de una sola imagen sale con uno que retiene los 600 ms.
• Recorte de un fotograma transparente. Una pegatina cuyo contenido opaco ocupa una quinta parte del lienzo se guarda como una quinta parte del lienzo: 191 bytes desde 19.473, con la transparencia intacta.
• Nada que no hayas pedido. Sin redimensionar, sin bajar la tasa de fotogramas, sin reducir la paleta salvo que muevas un control. Si recodificar no mejora tu archivo, recuperas el tuyo y se te dice.

Un GIF no es una pila de imágenes. Es un lienzo más una lista de instrucciones, y cada instrucción puede pintar un rectángulo en cualquier parte de ese lienzo, de cualquier tamaño, con cualquiera de sus píxeles marcados como transparentes para que se vea lo que hay debajo. Un fotograma que cambia una zona de 30 píxeles puede guardarse como una zona de 30 píxeles. Si tan pocos archivos lo hacen es porque escribirlo es mucho más difícil: el codificador tiene que mantener un modelo de lo que un decodificador estaría mostrando y comparar contra eso, no contra el fotograma original anterior.

Qué le ocurre a cada fotograma

• Componer. Cada fotograma se dibuja sobre un lienzo del tamaño lógico de la animación, respetando su desplazamiento, su método de descarte y su transparencia, de modo que lo que se compara es la imagen que vería un espectador.
• Analizar una vez. Una sola pasada responde a todo lo que necesita la codificación: qué fotogramas se repiten, si hay transparencia, cuántos colores distintos hay y la muestra con la que se construye la paleta.
• Asignar a una tabla compartida. Si los colores del original caben en una tabla, esa lista exacta es la paleta. Si no, se deriva una para toda la animación y no solo para el primer fotograma, así los colores no cambian durante la reproducción.
• Diferenciar y luego comprimir rachas. Cada fotograma se compara con un modelo del lienzo decodificado, se reduce al rectángulo que cambió y los píxeles sin cambios se marcan como transparentes. Solo entonces se ejecuta la pasada con pérdida, para que nunca dañe la diferencia.

El invariante que casi todas las implementaciones rompen

Cuando se elimina un fotograma duplicado, su tiempo tiene que ir a alguna parte. Si eliminas diez de veinte fotogramas de 100 ms y olvidas fusionar los tiempos, te quedan diez fotogramas de 100 ms: una animación de dos segundos que se reproduce en uno, al doble de velocidad. La salida es un GIF válido. Nada falla. Simplemente no es la animación que entró. Aquí se comparan la duración de entrada y la de salida en cada ejecución y una discrepancia se lanza como error, no se devuelve como archivo más pequeño.

Eliminar fotogramas por contenido es distinto de descartar uno de cada dos, y esa diferencia es todo el asunto. Descartar uno de cada N es ciego: quita fotogramas que mostraban algo nuevo junto a los que no, y el resultado da tirones de inmediato. Eliminar duplicados solo borra fotogramas que un espectador no habría distinguido del anterior y fusiona su tiempo. Si lo que quieres es menos fotogramas por segundo, esa palanca está en el compresor, junto a las demás decisiones de calidad.

Dos modos y el umbral que los separa

• Solo idénticos. Repeticiones byte a byte y nada más. Es el modo por defecto porque no puede cambiar lo que nadie ve: los fotogramas eliminados ya estaban en pantalla, píxel a píxel.
• Casi idénticos. Un umbral de similitud del 80% al 100%. Al 98%, un fotograma que coincide con al menos el 98% del último conservado se trata como repetición. Útil con material con ruido leve.
• Desactivado. Se conservan todos los fotogramas. Conviene cuando el número de fotogramas importa: algunos editores y algunos flujos de sprites los indexan por número.

Por qué la comparación es contra el último fotograma conservado

Si comparas cada fotograma con el inmediatamente anterior, un fundido lento supera el umbral en cada paso y toda la animación se reduce a su primer fotograma mientras cada comparación individual parecía razonable. Comparar contra el último fotograma CONSERVADO acota el error: sea cual sea el umbral, eso es lo máximo que se le puede mostrar a un espectador que la grabación no contenía, y no se acumula. Se eliminan menos fotogramas en material con deriva y es la decisión correcta, porque el fallo que evita es silencioso.

Todos los números siguientes proceden del conjunto de pruebas de esta herramienta, sobre archivos generados por un script en lugar de guardados como binarios misteriosos. Cada salida se vuelve a leer con tres implementaciones independientes: libvips para la animación renderizada, gifsicle para la estructura de fotogramas y un lector estructural escrito para las pruebas que recorre los bloques del archivo sin descomprimirlo nunca.

Las palancas, por lo que valen

• Diferencia entre fotogramas 4,07x en la animación de referencia tanto a 20 como a 100 fotogramas, con un error medio de color medido de 0,000 sobre 255.
• Eliminación de duplicados De 12 fotogramas a 4, y de 6 a 1, en los dos archivos dedicados, con 1.200 ms de entrada y 1.200 de salida, y 600 ms de entrada y 600 de salida.
• Tolerancia de diferencia a 40 De 1.172.755 bytes a 487.196 en la referencia de cien fotogramas. Un 2,41x adicional sobre la pasada sin pérdida.
• Rachas con pérdida a 60 De 1.172.755 bytes a 478.644 en el mismo archivo. Comparable al otro control y visible de otra manera: dentro del fotograma en lugar de entre fotogramas.
• Velocidad Cien fotogramas a 480x270, decodificados, analizados, diferenciados y escritos, en 252 a 380 ms en el dispositivo de referencia.

Frente a gifsicle, el motor de casi todos los optimizadores en línea

Los rectángulos de fotograma que produce esta herramienta son idénticos a los de gifsicle -O3 en todos los archivos medidos: mismos desplazamientos, mismos tamaños, mismas tablas de color. En tamaño total igualamos o superamos a gifsicle -O3 en ocho de diez casos y perdemos en dos, por 0,03% y 3,1%, enteramente dentro de la carga comprimida y no de la estructura. Dos cosas hacemos que él no: eliminar fotogramas casi duplicados y avisar cuando recodificar agrandó el archivo.

Son dos trabajos distintos y elegir el equivocado gasta calidad que no hacía falta gastar. Optimizar elimina redundancia: el archivo se reduce y la animación no cambia, así que no hay motivo para no hacerlo. Comprimir elimina información: menos píxeles, menos colores, menos fotogramas por segundo, hasta llegar a un tamaño que tú nombras. Empieza aquí. Si el resultado sigue siendo demasiado grande, el compresor continúa donde esto termina.

Una lista corta de decisiones

• Empieza siempre por el optimizador. No cuesta nada visualmente y a menudo basta. No tiene sentido tirar colores antes de dejar de guardar píxeles dos veces.
• Usa el compresor cuando el requisito es un número. «Menos de 8 MB para Discord», «menos de 256 KB para un emoji». Busca en resolución, paleta y tasa de fotogramas hasta alcanzarlo.
• Usa el redimensionador cuando las dimensiones estén mal. Esta herramienta nunca las cambia. Si la animación tiene 1920 de ancho y la columna 700, eso es un redimensionado, y hacerlo antes abarata todo lo demás.
• Vuelve aquí después. Optimizar la salida de un redimensionado o de una compresión suele encontrar más, porque esas herramientas reconstruyen los fotogramas y esta es la que les quita la repetición.

Compresor de GIF · Redimensionar GIF

Los ajustes por defecto están elegidos para que nadie tenga que pensarlos: diferencia entre fotogramas activada, duplicados eliminados solo cuando son idénticos byte a byte, los dos controles con pérdida a cero y sin tramado. Esa combinación no puede cambiar lo que nadie ve, y por eso es la predeterminada: un optimizador que alterase la imagen en silencio sería un compresor con un nombre engañoso.

Según el material

• Grabaciones de pantalla y demos de interfaz. El mejor caso posible. El fondo es estático, las diferencias son mínimas y las pausas producen fotogramas idénticos que no cuesta nada eliminar. Deja los valores por defecto.
• Material procedente de vídeo. Nada es nunca idéntico byte a byte por el ruido de compresión, así que cambia la eliminación de duplicados a casi idénticos al 98% y sube la tolerancia de diferencia.
• Pegatinas y logotipos con fondo transparente. La diferencia entre fotogramas no está disponible, pero los fotogramas se recortan igualmente a su contenido opaco, que aquí suele valer más.
• GIF fotográficos o muy tramados. Puede que no haya nada que eliminar, y la herramienta lo dirá en lugar de devolverte un archivo mayor. Reduce el número de colores o usa el compresor.

La lista de entrada es cerrada y se aplica en el propio diálogo de archivos, no en el motor, así que un archivo que esta herramienta no puede abrir se rechaza en milisegundos con una ruta a la herramienta que sí puede, en lugar de aceptarse y fallar después detrás de un indicador de carga.

• GIF de entrada. Animado o de un solo fotograma, entrelazado o no, con paleta global o con una paleta local distinta en cada fotograma. Los fotogramas parciales se componen sobre el lienzo completo antes de comparar nada.
• WebP animado y APNG de entrada. Ambos se leen con nuestros propios demultiplexores en todos los navegadores, así que el número de fotogramas y el ritmo son idénticos en todas partes. Ambos llevan mucho más de 256 colores.
• GIF de salida, siempre. Un GIF89a estándar con una tabla de colores global, tiempos por fotograma, fotogramas parciales, métodos de descarte y extensión de bucle Netscape.
• Cualquier otra cosa se rechaza con una ruta. Un vídeo va a Vídeo a GIF; una imagen fija, al Creador de GIF.

Qué lee la herramienta

El GIF se decodifica de forma nativa donde el navegador tiene decodificador y con nuestro propio lector en el resto, así que una animación se abre igual en todas partes en lugar de llegar como su primer fotograma sin más aviso. WebP animado y APNG usan siempre nuestro lector, que es lo que mantiene idénticos el número de fotogramas y el ritmo entre motores. Lo que un archivo dice llamarse se ignora: deciden los primeros dieciséis bytes.

Límites de tamaño y de lote

• Gratis. Un archivo de hasta 50 MB y hasta 300 fotogramas. Todas las palancas estructurales están incluidas, porque son lo que la herramienta es. La tabla de colores se limita a 128 entradas.
• Pro. Hasta 50 archivos a la vez, descargados en un solo ZIP, sin límite de tamaño ni de fotogramas más allá de lo que tu dispositivo pueda sostener, y la tabla completa de 256 colores.
• Sin límite de dimensiones en ningún plan. El optimizador nunca cambia las dimensiones, así que un tope sobre ellas sería un límite sobre nada. Ambos planes devuelven la animación al tamaño exacto con el que llegó.
• El límite que comparten los dos planes. Cada fotograma se expande a color completo mientras se trabaja con él, así que un presupuesto de memoria acota el trabajo antes de empezar en lugar de dejar que la pestaña deje de responder.

No se sube nada. El archivo se decodifica fotograma a fotograma en tu equipo, se analiza una vez en busca de repeticiones, transparencia y número de colores, se asigna a una única paleta compartida, se compara con un modelo de lo que un decodificador estaría mostrando y se escribe como GIF89a estándar. Todo ocurre en un hilo en segundo plano para que la página siga respondiendo, y la asignación de paleta —la parte por píxel, la cara— se ejecuta en tu hardware gráfico cuando está disponible.

Por qué el mismo archivo se optimiza igual siempre

• Un cuantizador determinista. Corte por la mediana, no el cuantizador neuronal aleatorio que usan la mayoría de bibliotecas, y ningún cuantizador cuando los colores del original caben. La misma entrada con los mismos ajustes da siempre bytes idénticos.
• Resultados idénticos en todas las rutas. Las rutas aceleradas por hardware y por procesador deben producir los mismos bytes, no solo bytes parecidos. Una ruta que eligiera otra entrada de paleta se vería como parpadeo de color entre fotogramas.
• Comprobado con implementaciones que no comparten código. La animación renderizada la lee libvips, la estructura de fotogramas gifsicle y los bloques del archivo un lector escrito para las pruebas. Un archivo que nuestro propio código escribe y lee no prueba nada.
• Optimizar dos veces no cambia nada. Ejecutar la herramienta sobre su propia salida devuelve el mismo archivo y lo declara ya optimizado, que es la propiedad que dice que la primera pasada terminó el trabajo.

La asignación de paleta se acelera por hardware cuando tu dispositivo lo permite, y se verifica que las rutas acelerada y de reserva producen bytes idénticos. La estructura de fotogramas se comprueba con gifsicle y la animación renderizada con libvips, y ninguno comparte código con esta herramienta. Medido en el dispositivo de referencia: 100 fotogramas a 480x270 optimizados en 252 ms, 4,07x más pequeños, con un error medio de color de 0,000 sobre 255. Se ejecuta en tu dispositivo, no en nuestros servidores.

• Compresor de GIF
• Redimensionar GIF
• Creador de GIF
• Vídeo a GIF
• GIF a MP4
• Editor de GIF