Convertir GIF a TIFF

Casi todos los pliegos y normas de depósito que nombran TIFF vienen del mundo de la digitalización de documentos y fotografía, que es donde el formato se gana el sitio: dieciséis bits por canal, color CMYK y Lab, perfiles de color incrustados y una estructura de etiquetas que se lee desde 1986. Una institución que estandariza en TIFF está protegiendo escaneos de papel frente a los próximos treinta años.

Un GIF que salió de una web en 2003 no encaja en ninguno de esos supuestos y aun así tiene que cumplir la misma regla. Esta conversión produce un archivo conforme, y la expectativa sensata es que cumpla, no que mejore. Si el pliego admite PNG como alternativa para material nacido digital, esa es la respuesta mejor y varias veces más ligera.

El TIFF que sale de aquí es una línea base sin comprimir: cada píxel se guarda como cuatro valores de canal, uno detrás de otro, con un bloque de etiquetas que describe la geometría. Una imagen de 480 por 270 son 518.400 bytes de datos de píxel, muestre lo que muestre, más una cabecera pequeña.

TIFF sí define esquemas de compresión —LZW, Deflate y las codificaciones de fax— y este conversor no usa ninguno. Es una decisión deliberada a favor de la compatibilidad más amplia posible: lo único que acepta cualquier lector de TIFF construido jamás es la línea base sin comprimir, y un archivo que el validador de un repositorio no sabe leer ha fallado en lo único que tenía que hacer.

Un GIF puede declarar transparente una entrada de su paleta, y casi todas las demás conversiones de imagen de este sitio tienen que hacer algo al respecto: rellenarla con un color, preguntarte cuál, o resolverla de una manera que hay que explicar. TIFF tiene canal alfa y esta ruta lo escribe tal cual.

El aplanado sobre un color de fondo solo ocurre cuando el destino es JPG, BMP o GIF, y TIFF no es ninguno de los tres. Para un depósito la consecuencia es que el archivo conserva el gráfico como se diseñó, incluido el hecho de que estaba pensado para colocarse sobre un fondo desconocido. Si la norma exige una imagen opaca, lo que pide en realidad es componer el gráfico sobre un fondo definido, y ese es el camino de JPG o BMP con un color que eliges tú.

Entre las capacidades de TIFF están varias imágenes en un mismo archivo, las capas y un bloque de etiquetas que otras aplicaciones amplían con datos propios. El TIFF multipágina es la forma en que un informe escaneado de veinte hojas viaja como un solo objeto.

Esta conversión escribe una sola imagen. Un GIF animado se descodifica a su primer fotograma y ese fotograma es lo que contiene el archivo, así que la secuencia no se convierte en un TIFF de varias páginas. Si los fotogramas importan como conjunto, extraerlos por separado y montar las páginas en una herramienta dedicada es la ruta, y es un trabajo distinto de este.

Merece la pena nombrar con exactitud lo que se deposita. Un fotograma de GIF es un índice sobre una paleta de 256 colores como mucho, y esa paleta se eligió —normalmente por un programa, normalmente con tramado— en el momento en que se creó el GIF. Todo lo que el original tuviera más allá de esos 256 valores se descartó entonces.

El TIFF preserva el resultado de aquella decisión de forma fiel y permanente, que es exactamente lo que un archivo quiere: el objeto tal y como circuló, no una conjetura sobre lo que pudo haber sido. Lo que no puede hacer es deshacer la reducción, y no lo hará ningún formato, ajuste ni proceso posterior. Un degradado tramado sigue siendo un degradado tramado con dieciséis bits por canal exactamente igual que con ocho.

En esta conversión no aparece ningún ajuste de calidad, y no es una omisión. TIFF está en el grupo de destinos que ignoran ese parámetro por completo, junto con PNG, BMP, ICO y GIF, porque no se está negociando nada entre tamaño y fidelidad.

El tamaño sale de la aritmética de los píxeles y punto. Eso hace que esta sea una de las conversiones más previsibles del sitio: sueltas el archivo, conviertes, y el resultado es el mismo tantas veces como lo repitas. Si el peso es el problema, el problema no se resuelve con un mando en esta página sino cambiando de formato de destino.

Un flujo de imprenta piensa en tamaño físico: una figura mide 90 milímetros de ancho a 300 puntos por pulgada. Un GIF no registra nada de eso. Guarda una cuadrícula de píxeles y ninguna declaración sobre qué tamaño se supone que tiene esa cuadrícula sobre el papel.

Así que la pregunta de la resolución no la puede responder la conversión y hay que responderla en la maquetación. Un gráfico de 480 píxeles de ancho colocado a 300 puntos por pulgada mide 40 milímetros, y ampliarlo más en la página no añade detalle: amplía los píxeles. Si el pliego exige una resolución efectiva mínima, compara las dimensiones en píxeles con el tamaño físico previsto antes de convertir, no después.

Un GIF puede contener bloques de comentario con el nombre del programa que lo creó, una fecha o una nota de quien lo hizo. Nada de eso llega al TIFF, y no porque se elimine a propósito: la imagen se descodifica a píxeles y el codificador escribe la imagen, sin ningún canal por el que pudiera pasar ese texto.

Para un depósito eso importa más que para casi cualquier otro destino, porque la procedencia es exactamente lo que un archivo tiene que registrar. Si el GIF llevaba algo dentro que sirva como evidencia de origen, extráelo y anótalo antes de convertir, y conserva también el GIF original junto al TIFF: es la única copia que sigue teniéndolo.

Cuatro comprobaciones, todas en un visor de escritorio. Que las dimensiones en píxeles coinciden con las del GIF; que la transparencia, si la había, sigue ahí y no se ha vuelto negra o blanca; que el archivo pesa aproximadamente cuatro bytes por píxel, que es la señal de que se escribió sin comprimir; y que el visor lo abre sin quejarse.

Si el repositorio tiene un validador de formatos, pásale un archivo antes de preparar el lote entero. Descubrir en el archivo número uno que el perfil de depósito exige algo que este TIFF no lleva —una profundidad concreta, un espacio de color declarado— es barato; descubrirlo en el trescientos, después de haber cerrado el expediente, no lo es.

El soporte de TIFF en navegadores es parcial y conviene decirlo con precisión en lugar de exagerarlo: Safari lo muestra desde hace años, y los demás motores no. En la práctica eso significa que no puedes comprobar el resultado arrastrándolo a cualquier pestaña ni incrustarlo en una página y esperar que funcione para todo el mundo.

Para un máster de archivo eso no es un defecto, porque un máster no está pensado para ser la copia de consulta. Sí implica mantener al lado una versión visible. El montaje habitual es el TIFF en el repositorio y un PNG o un JPG como copia de acceso, generados ambos desde la misma fuente y no uno a partir del otro.

Si la norma admite cualquier formato sin pérdida y simplemente cita TIFF en primer lugar, PNG es la mejor respuesta para un GIF. Es sin pérdida exactamente en el mismo sentido, conserva el canal alfa, lo abre cualquier navegador y visor, y ocupará una fracción porque sí comprime de verdad.

El caso para seguir adelante es cuando el requisito está escrito como TIFF y no se negocia, o cuando el archivo se incorpora a una colección donde todo lo demás es TIFF y la coherencia tiene valor por sí misma. Los dos son frecuentes, y ninguno necesita que la conversión finja haber mejorado nada.

La descodificación y la escritura ocurren dentro de la pestaña, sin servidor y sin cuenta. Para material que va a un archivo eso es con frecuencia una condición dura —una regla de cadena de custodia que dice que nada puede pasar por un tercero— y aquí se cumple porque no hay tercero en el camino.

El tope es de 100 MB por archivo, que para un GIF es un tamaño extraordinario, y un lote admite hasta 100 archivos: si el depósito es de una carpeta entera, se convierte de una vez y vuelve un TIFF por cada entrada. Conviene abrir uno en un visor de escritorio antes de dar por bueno el lote completo.