Convertir TIFF a GIF

Casi nadie elige GIF. Se llega aquí porque un destino concreto —un gestor documental interno, una intranet que nadie se atreve a tocar, un foro, una herramienta de incidencias, una firma de correo corporativa— enumera cuatro o cinco extensiones y GIF es la única que aún no se ha probado. El TIFF no está en esa lista y no lo va a estar.

Esa lista se redactó cuando GIF era el formato universal, y sobrevive porque cambiarla implica tocar un sistema que funciona. Así que la pregunta útil no es si GIF es un buen formato en 2026, sino qué le ocurre exactamente a tu escaneo al pasar por él. La respuesta depende de si el documento tiene tinta y papel o tiene tonos continuos, y la diferencia es abrupta.

El límite famoso del GIF son 256 colores, y buena parte del material que llega a esta página no lo nota siquiera. Un fax, un formulario rellenado, un plano de líneas, un texto negro sobre papel blanco gasta dos de esas 256 casillas, así que la paleta no descarta absolutamente nada: cada píxel llega con el valor que tenía.

Además el archivo sale pequeño, porque la compresión LZW del GIF resume muy bien las tiradas largas de píxeles idénticos, que es justamente de lo que está hecho un documento escaneado. Un escaneo en escala de grises está casi igual de bien servido: 256 grises es exactamente lo que tiene una imagen de 8 bits en gris. El problema empieza con el color y con la trama de imprenta.

Alguien tiene que decidir qué colores sobreviven, y aquí lo decide gifenc mediante agrupamiento por vecino más próximo, sobre un espacio de color reducido en lugar de los dieciséis millones completos. Eso cuesta algo de precisión y ahorra varios segundos en un escaneo grande, que para un formato que termina en 256 entradas es el orden correcto de prioridades.

El resultado sobre tono continuo no es un desastre ni es bueno. Un cielo se convierte en escalones visibles, los tonos de piel se apelmazan y un original impreso con trama recoge un muaré que no estaba en el escaneo. En las muestras de este sitio la fotografía ocupa 37.227 bytes como GIF frente a 14.700 como WebP: más grande y peor a la vez, que es la señal más clara de que lo que te ha traído aquí es una exigencia del destino y no la imagen.

El formato GIF permite marcar una entrada de la paleta como invisible, pero el codificador que se usa aquí no marca ninguna. Lo que ocurre con las zonas transparentes del TIFF es otra cosa: se rellenan con el color de fondo del panel de opciones antes de construir la paleta, y ese color empieza en blanco.

Conviene fijarlo a conciencia antes de convertir un lote. Un logotipo escaneado con el fondo recortado, o un TIFF exportado desde un programa de diseño con canal alfa, vuelve sobre un rectángulo macizo de ese color, y el borde suavizado queda mezclado con él: recortado sobre blanco y colocado luego en una página oscura, se le ve una orla pálida alrededor. Si la transparencia es parte de la imagen, TIFF a PNG y TIFF a WebP la conservan de verdad.

Aquí chocan dos hechos de contenedor y ninguno es evidente. Un TIFF puede guardar muchas imágenes en un archivo y el lector toma la primera; un GIF puede guardar muchos fotogramas y el escritor emite uno. Así que un fax escaneado de seis hojas se convierte en una imagen fija de la hoja uno, sin aviso de ninguna clase.

Eso también liquida una esperanza que trae a bastante gente a esta pareja: un TIFF de varias páginas no se convierte en un GIF animado. Nada aquí monta fotogramas a partir de páginas, y aunque lo hiciera, una animación es el contenedor equivocado para un documento. Separa las páginas antes de convertir, o usa TIFF a PDF, que es la única conversión de esta familia que las guarda todas en un archivo.

El orden de las dos operaciones no es arbitrario y se decidió midiendo. El color de fondo se pinta primero y el dibujo se coloca encima en la misma pasada, de modo que rellenar y redimensionar son un solo paso. Hacerlo al revés deja huella: rellenar y después escalar mezcla el color de relleno con los bordes, y escalar antes de aplanar deja un halo oscuro alrededor del motivo.

La consecuencia práctica es que si vas a reducir el ancho del escaneo, no hace falta que decidas nada al respecto: el color que elijas se comporta igual con o sin redimensionado. Lo que sí cambia el resultado es el color en sí, y cuando el destino es un fondo oscuro conviene ponerlo oscuro en lugar de dejar el blanco por defecto y descubrir el recuadro más tarde.

Las muestras de este sitio miden 480 por 320 píxeles y pesan 615.400 bytes como TIFF en los tres casos, porque a un archivo sin comprimir le da igual lo que haya dentro. Como GIF son 6.326 bytes la escena tipo captura de pantalla, 7.688 el gráfico plano y 37.227 la fotografía.

Lo interesante es el orden. El GIF rinde mejor en material plano y de bordes duros —que es exactamente lo que es un documento escaneado— y peor en tono continuo, justo al revés que el JPEG. Por eso un sistema antiguo que acepte GIF y JPG tratará mejor tu formulario escaneado como GIF y tu fotografía escaneada como JPG, y mandar los dos por la misma ruta es el error que conviene evitar.

GIF guarda sus dimensiones en dieciséis bits, de modo que una imagen puede llegar a 65.535 píxeles de lado. Es cuatro veces el techo de WebP, que se queda en 16.383, y muy por encima de lo que produce cualquier escáner de documentos: a diferencia de la ruta hacia WebP, esta conversión no se rompe con un escaneo grande.

Lo que sí se resiente con un escaneo grande es la memoria y la paciencia. Cuantizar una imagen de 20.000 píxeles de ancho significa examinar varios cientos de millones de píxeles dentro de la pestaña, y el GIF resultante, aunque sea mucho menor que el TIFF, seguirá siendo un archivo considerable que el sistema de destino puede rechazar por tamaño. Reducir el ancho primero, con la opción del mismo panel, suele ser lo sensato: un documento que se mira en pantalla rara vez necesita más de 2.000 píxeles.

En las conversiones hacia JPG, WebP, AVIF o JXL hay un número que decide cuánto detalle se descarta. Aquí no aparece ninguno, y no es un olvido: el único margen real de un codificador GIF es qué 256 colores conserva, y eso lo decide el cuantizador, no una casilla que rellenes tú.

Lo mismo vale para PNG, BMP, ICO y TIFF como destinos: ninguno lee un ajuste de calidad. Si el GIF sale con bandas, subir un número no lo arregla porque ese número no existe. Lo que sí cambia el resultado es el material de partida —un escaneo bitonal limpio en lugar de uno en color a 24 bits— y el ancho al que lo reduzcas.

PNG conserva cada píxel sin paleta alguna, lo lee cualquier cosa escrita desde los años noventa y en contenido plano escaneado sale con frecuencia más pequeño que el propio GIF: la muestra tipo captura ocupa 2.608 bytes como PNG frente a 6.326 como GIF. Cuando ambos están en la lista, no hay argumento a favor del GIF.

Si el destino es una página web que controlas tú, TIFF a WebP es más pequeño todavía y lo entiende cualquier navegador actual. Y si el escaneo es un documento que se va a archivar o reenviar, TIFF a PDF conserva las páginas y es el archivo que espera quien lo recibe. GIF es la respuesta correcta solo cuando una lista lo dice, y esta página parte de que la lista existe.

Todo el proceso ocurre en tu navegador: utif2 descodifica el TIFF, gifenc construye la paleta y escribe el GIF, y ninguno de los dos se descarga hasta que hace falta. Del archivo no se sube nada, que es lo que importa cuando los escaneos son expedientes, correspondencia o cualquier cosa con un nombre encima.

El límite gratuito es de 100 MB por archivo, más o menos un A4 en color escaneado a 600 ppp y guardado sin comprimir. Los lotes funcionan igual, hasta cien archivos de una tirada y un ZIP al final, y el cuantizador es el paso lento: una tanda de escaneos en color tarda bastante más que una de bitonales. Convertir dos o tres y comprobarlos en el sistema de destino antes de mandar la carpeta entera vale los dos minutos que cuesta.