GIF

El formato de intercambio de gráficos (GIF; GHIF o JIF ver pronunciación) es un formato de imagen de mapa de bits desarrollado por un equipo del proveedor de servicios en línea CompuServe dirigido por American científico informático Steve Wilhite y lanzado el 15 de junio de 1987. Tiene un uso generalizado en la World Wide Web debido a su amplio soporte y portabilidad entre aplicaciones y sistemas operativos.

El formato admite hasta 8 bits por píxel para cada imagen, lo que permite que una sola imagen haga referencia a su propia paleta de hasta 256 colores diferentes elegidos del espacio de color RGB de 24 bits. También admite animaciones y permite una paleta separada de hasta 256 colores para cada fotograma. Estas limitaciones de la paleta hacen que GIF sea menos adecuado para reproducir fotografías en color y otras imágenes con degradados de color, pero es adecuado para imágenes más simples como gráficos o logotipos con áreas sólidas de color.

Las imágenes GIF se comprimen mediante la técnica de compresión de datos sin pérdidas Lempel-Ziv-Welch (LZW) para reducir el tamaño del archivo sin degradar la calidad visual.

Historia

CompuServe introdujo GIF el 15 de junio de 1987 para proporcionar un formato de imagen en color para sus áreas de descarga de archivos. Esto reemplazó su anterior formato de codificación de longitud de ejecución, que era solo en blanco y negro. GIF se hizo popular porque usaba la compresión de datos Lempel-Ziv-Welch. Dado que esto era más eficiente que la codificación de longitud de ejecución utilizada por PCX y MacPaint, las imágenes bastante grandes se podían descargar razonablemente rápido incluso con módems lentos.

La versión original de GIF se llamaba 87a. Esta versión ya admitía varias imágenes en una secuencia.

En 1989, CompuServe lanzó una versión mejorada, llamada 89a. Esta versión agregó:

• soporte para retrasos de animación
• transparentes colores de fondo
• almacenamiento de metadatos específicos para aplicaciones
• permitiendo etiquetas de texto como texto (no incrustarlas en los datos gráficos). Como hay poco control sobre las fuentes de visualización, sin embargo, esta característica raramente se utiliza.

Las dos versiones se pueden distinguir mirando los primeros seis bytes del archivo (el "número mágico" o firma), que, cuando se interpreta como ASCII, lee "GIF87a" o "GIF89a", respectivamente.

CompuServe fomentó la adopción de GIF proporcionando utilidades de conversión descargables para muchas computadoras. En diciembre de 1987, por ejemplo, un usuario de Apple IIGS podía ver imágenes creadas en un Atari ST o Commodore 64. El GIF fue uno de los dos primeros formatos de imagen comúnmente utilizados en los sitios web, siendo el otro el XBM en blanco y negro.

En septiembre de 1995, Netscape Navigator 2.0 agregó la posibilidad de reproducir en bucle los GIF animados.

Si bien GIF fue desarrollado por CompuServe, utilizó el algoritmo de compresión de datos sin pérdida Lempel–Ziv–Welch (LZW) patentado por Unisys en 1985. La controversia sobre el acuerdo de licencia entre Unisys y CompuServe en 1994 impulsó el desarrollo de Portable Network Graphics (PNG) estándar. En 2004, expiraron todas las patentes relacionadas con la compresión patentada utilizada para GIF.

La función de almacenar varias imágenes en un archivo, acompañadas de datos de control, se usa mucho en la web para producir animaciones simples.

La función de entrelazado opcional, que almacena las líneas de escaneo de la imagen desordenadas de tal manera que incluso una imagen descargada parcialmente era algo reconocible, también ayudó a la popularidad de GIF, ya que un usuario podía cancelar la descarga si no se descargaba. lo que se requería.

En mayo de 2015, Facebook agregó soporte para GIF. En enero de 2018, Instagram también agregó pegatinas GIF al modo historia.

Terminología

Como sustantivo, la palabra GIF se encuentra en las ediciones más recientes de muchos diccionarios. En 2012, el ala estadounidense de Oxford University Press también reconoció a GIF como un verbo, que significa "crear un archivo GIF", como en "GIFing was the perfect medio para compartir escenas de los Juegos Olímpicos de verano". Los lexicógrafos de la prensa la votaron como su palabra del año y dijeron que los GIF se han convertido en "una herramienta con aplicaciones serias que incluyen la investigación y el periodismo".

Pronunciación

Una imagen humorística anunciando el lanzamiento de una cuenta Tumblr para la Casa Blanca sugiere pronunciar GIF con un duro g.

La pronunciación de la primera letra de GIF ha sido cuestionada desde la década de 1990. Las pronunciaciones más comunes en inglés son (con g suave como en gin) y (con g fuerte como en gift), diferenciándose en el fonema representado por la letra G. Los creadores del formato pronunciaron el acrónimo GIF como con una g suave, y Wilhite afirmó que pretendía que la pronunciación hiciera eco deliberadamente de la marca estadounidense de mantequilla de maní Jif, y los empleados de CompuServe solían bromear &#34 Los desarrolladores selectivos eligen GIF, una parodia de los comerciales de televisión de Jif. Sin embargo, la palabra se pronuncia ampliamente como con una g fuerte, y las encuestas generalmente han demostrado que esta pronunciación fuerte g es más frecuente.

Dictionary.com cita ambas pronunciaciones, indicando que es la pronunciación principal, mientras que Cambridge Dictionary of American English ofrece solo la pronunciación hard-g. Merriam-Webster's Collegiate Dictionary y Oxford Dictionaries citan ambas pronunciaciones, pero coloque la g dura primero:. El New Oxford American Dictionary dio solo en su segunda edición pero lo actualizó en la tercera edición.

El desacuerdo sobre la pronunciación ha provocado un acalorado debate en Internet. Con motivo de recibir un premio a la trayectoria en la ceremonia de los Premios Webby de 2013, Wilhite rechazó públicamente la pronunciación de g dura; su discurso generó más de 17.000 publicaciones en Twitter y decenas de artículos periodísticos. La Casa Blanca y el programa de televisión Jeopardy! también entraron en el debate en 2013. En febrero de 2020, The J.M. Smucker Company, los propietarios de la marca Jif, se asociaron con la base de datos de imágenes animadas y el motor de búsqueda Giphy para lanza una edición limitada de "Jif vs. GIF" (etiquetado como #JIFvsGIF) tarro de mantequilla de maní que tenía una etiqueta que declaraba con humor que la pronunciación g suave se refería exclusivamente a la mantequilla de maní, y GIF para pronunciarse exclusivamente con la pronunciación dura-g.

Uso

Los GIF son adecuados para líneas de arte con bordes nítidos con una cantidad limitada de colores, como logotipos. Esto aprovecha la compresión sin pérdidas del formato, que favorece las áreas planas de color uniforme con bordes bien definidos. También se pueden usar para almacenar datos de sprites de color bajo para juegos. Los GIF se pueden usar para animaciones pequeñas y videoclips de baja resolución, o como reacciones en mensajes en línea que se usan para transmitir emociones y sentimientos en lugar de usar palabras. Son populares en plataformas de redes sociales como Tumblr, Facebook y Twitter.

Formato de archivo

Conceptualmente, un archivo GIF describe un área gráfica de tamaño fijo (la "pantalla lógica") poblada con cero o más "imágenes". Muchos archivos GIF tienen una sola imagen que ocupa toda la pantalla lógica. Otros dividen la pantalla lógica en subimágenes separadas. Las imágenes también pueden funcionar como cuadros de animación en un archivo GIF animado, pero, de nuevo, no es necesario que llenen toda la pantalla lógica.

Los archivos GIF comienzan con un encabezado de longitud fija ("GIF87a" o "GIF89a") que indica la versión, seguido de un descriptor de pantalla lógica de longitud fija que indica las dimensiones en píxeles y otros características de la pantalla lógica. El descriptor de pantalla también puede especificar la presencia y el tamaño de una tabla de color global (GCT), que sigue a continuación, si está presente.

Después, el archivo se divide en segmentos, cada uno introducido por un centinela de 1 byte:

• Una imagen (introducida por 0x2C, un coma ASCII) ',')
• Un bloque de extensión (introducido por 0x21, un punto de exclamación ASCII '!')
• El tráiler (un solo byte de valor 0x3B, un semicolon ASCII ';'), que debe ser el último byte del archivo.

Una imagen comienza con un descriptor de imagen de longitud fija, que puede especificar la presencia y el tamaño de una tabla de color local (que sigue a continuación, si está presente). Los datos de la imagen son los siguientes: un byte que indica el ancho de bit de los símbolos no codificados (que debe tener al menos 2 bits de ancho, incluso para imágenes bicolores), seguido de una lista enlazada de subbloques que contienen los datos codificados en LZW.

Los bloques de extensión (bloques que "extienden" la definición 87a a través de un mecanismo ya definido en la especificación 87a) consisten en el centinela, un byte adicional que especifica el tipo de extensión y una lista vinculada de sub- bloques con los datos de extensión. Los bloques de extensión que modifican una imagen (como la extensión de control gráfico que especifica el tiempo de demora de animación opcional y el color de fondo transparente opcional) deben preceder inmediatamente al segmento con la imagen a la que se refieren.

Las listas enlazadas utilizadas por los datos de imagen y los bloques de extensión constan de una serie de subbloques, cada subbloque que comienza con un byte que indica el número de bytes de datos subsiguientes en el subbloque (1 a 255). La serie de subbloques termina con un subbloque vacío (un byte 0).

Esta estructura permite analizar el archivo incluso si no se comprenden todas las partes. Un GIF marcado como 87a puede contener bloques de extensión; la intención es que un decodificador pueda leer y mostrar el archivo sin las características cubiertas por las extensiones que no comprende.

Los detalles completos del formato de archivo están cubiertos en la especificación GIF.

Paletas

Un ejemplo de una imagen GIF guardada con una paleta web segura y separada usando el método Floyd-Steinberg. Debido al número reducido de colores en la imagen, hay problemas de visualización.

GIF se basa en una paleta: los colores utilizados en una imagen (un marco) en el archivo tienen sus valores RGB definidos en una tabla de paleta que puede contener hasta 256 entradas, y los datos de la imagen se refieren a los colores por sus índices (0–255) en la tabla de paletas. Las definiciones de color en la paleta se pueden extraer de un espacio de color de millones de tonos (2²⁴ tonos, 8 bits para cada primario), pero el número máximo de colores que puede usar un marco es 256. Este La limitación parecía razonable cuando se desarrolló GIF porque pocas personas podían pagar el hardware para mostrar más colores simultáneamente. Los gráficos simples, los dibujos lineales, las caricaturas y las fotografías en escala de grises normalmente necesitan menos de 256 colores.

Cada cuadro puede designar un índice como "color de fondo transparente": cualquier píxel asignado a este índice toma el color del píxel en la misma posición del fondo, que puede haber sido determinado por un cuadro de animación.

Se han desarrollado muchas técnicas, denominadas colectivamente tramado, para aproximar una gama más amplia de colores con una paleta de colores pequeña mediante el uso de píxeles de dos o más colores para aproximar los colores intermedios. Estas técnicas sacrifican la resolución espacial para aproximarse a una resolución de color más profunda. Si bien no forma parte de la especificación GIF, el tramado se puede usar en imágenes codificadas posteriormente como imágenes GIF. A menudo, esta no es una solución ideal para las imágenes GIF, porque la pérdida de resolución espacial suele hacer que una imagen se vea borrosa en la pantalla y porque los patrones de difuminado a menudo interfieren con la compresibilidad de los datos de la imagen, lo que va en contra de los GIF. propósito principal.

En los primeros días de los navegadores web gráficos, las tarjetas gráficas con búfer de 8 bits (que permitían solo 256 colores) eran comunes y era bastante común crear imágenes GIF usando la paleta web segura. Esto aseguró una visualización predecible, pero limitó severamente la elección de colores. Cuando el color de 24 bits se convirtió en la norma, las paletas se podían llenar con los colores óptimos para imágenes individuales.

Una tabla de colores pequeña puede ser suficiente para imágenes pequeñas, y mantener la tabla de colores pequeña permite que el archivo se descargue más rápido. Las especificaciones 87a y 89a permiten tablas de colores de 2ⁿ colores para cualquier n del 1 al 8. La mayoría de las aplicaciones gráficas leerán y mostrarán GIF imágenes con cualquiera de estos tamaños de tabla; pero algunos no admiten todos los tamaños al crear imágenes. Las tablas de 2, 16 y 256 colores son ampliamente compatibles.

Color verdadero

Aunque el GIF casi nunca se usa para imágenes en color verdadero, es posible hacerlo. Una imagen GIF puede incluir varios bloques de imágenes, cada uno de los cuales puede tener su propia paleta de 256 colores, y los bloques se pueden colocar en mosaico para crear una imagen completa. Alternativamente, la especificación GIF89a introdujo la idea de un elemento "transparente" color donde cada bloque de imagen puede incluir su propia paleta de 255 colores visibles más un color transparente. Se puede crear una imagen completa superponiendo bloques de imagen con la parte visible de cada capa a través de las partes transparentes de las capas superiores.

Un GIF animado ilustrando una técnica para mostrar más que el límite típico de 256 colores

Para representar una imagen a todo color como GIF, la imagen original debe dividirse en regiones más pequeñas que no tengan más de 255 o 256 colores diferentes. Luego, cada una de estas regiones se almacena como un bloque de imagen separado con su propia paleta local y cuando los bloques de imagen se muestran juntos (ya sea en mosaico o superponiendo bloques de imagen parcialmente transparentes), aparece la imagen completa a todo color. Por ejemplo, dividir una imagen en mosaicos de 16 x 16 píxeles (256 píxeles en total) garantiza que ningún mosaico tenga más del límite de la paleta local de 256 colores, aunque se pueden usar mosaicos más grandes y combinar colores similares, lo que resulta en cierta pérdida de color. información.

Dado que cada bloque de imagen puede tener su propia tabla de colores local, un archivo GIF que tenga muchos bloques de imagen puede ser muy grande, lo que limita la utilidad de los GIF a todo color. Además, no todos los programas de procesamiento de GIF manejan correctamente las imágenes en mosaico o en capas. Muchos programas de representación interpretan mosaicos o capas como fotogramas de animación y los muestran en secuencia como una animación; la mayoría de los navegadores web muestran automáticamente los fotogramas con un tiempo de retraso de 0,1 segundos o más.

Archivo GIF de ejemplo

Microsoft Paint guarda una pequeña imagen en blanco y negro como el siguiente archivo GIF (extratado ampliado). La pintura no hace un uso óptimo de GIF; debido a la tabla de colores innecesariamente grande (tormentando un total de 256 colores en lugar de la anchura utilizada 2) y el símbolo, este archivo GIF no es una representación eficiente de la imagen de 15 píxeles. Aunque el bloque de extensión de control gráfico declara que el índice de color 16 (hexadecimal 10) es transparente, ese índice no se utiliza en la imagen. Los únicos índices de color que aparecen en los datos de imagen son decimal 40 y 255, que el Global Color Table mapea a blanco y negro, respectivamente.

Imagen de muestra (agrandada), tamaño real 3 píxeles de ancho por 5 alto

Tenga en cuenta que los números hexadecimales en las siguientes tablas están en orden de bytes little-endian, como lo prescribe la especificación de formato.

Tabla de valores de imagen GIF

Byte # (hex)	Hexadecimal	Texto o valor	Significado
0	47 49 46 38 39 61	GIF89a	Header
6	03 00	3	Ancho de pantalla lógico
8	05 00	5	Altura de la pantalla lógica
A	F7		GCT sigue por 256 colores con resolución 3×8 bits/primario, los 3 bits más bajos representan la profundidad del bit menos 1, la parte más alta verdadera significa que el GCT está presente
B	00	0	Color de fondo: índice #0; #000 negro
C	00	0	ratio de aspecto de píxel predeterminado, 0:0
D	00 00 00 00	R (red) G (verde) B (azul) 0 0 0	Mesa de Color Global, color #0: #000000, negro	Bytes Dh a 30Ch en el ejemplo define una paleta de 256 colores.
10	80 00 00	R (red) G (verde) B (azul) 128 0 0	Mesa de Color Global, color #1: bit transparente, no utilizado en la imagen
...	...	...	Mesa de color global se extiende a 30A
30A	FF FF FF	R (red) G (verde) B (azul) 255 255 255	Mesa de Color Global, color #255: #ffffff, white
30D	21 F9		Ampliación de control gráfico (los campos de compromiso preceden esto en la mayoría de los archivos)
30F	04	4	Cantidad de datos GCE, 4 bytes
310	01		Color de fondo transparente; este es un poco de campo, el bit más bajo significa transparencia
311	00		Retraso para animación en cientos de segundos; no utilizado
313	10	16	Número de color de píxel transparente en GCT
314	00		Fin del bloque GCE
315	2C		Descriptor de imagen
316	00 00 00 00 00 00	(0, 0)	Posición esquina noroeste de la imagen en la pantalla lógica
31A	03 00 05 00	(3, 5)	Ancho de imagen y altura en píxeles
31E	00	0	Boda de mesa de color local, 0 significa ninguno
31F	08	8	Inicio de la imagen, tamaño mínimo de código LZW
320	0B	11	Cantidad de imagen codificada LZW sigue, 11 bytes
321	00 51 FC 1B 28 70 A0 C1 83 01	* datos obtenidos	11 bytes de datos de imagen, ver campo 320
32C	00	0	Fin del bloque de datos de imagen
32D	3B		Terminación del archivo

Codificación de imágenes

Los datos de píxeles de la imagen, escaneados horizontalmente desde la parte superior izquierda, se convierten mediante codificación LZW en códigos que luego se asignan en bytes para almacenarlos en el archivo. Los códigos de píxeles normalmente no coinciden con el tamaño de 8 bits de los bytes, por lo que los códigos se empaquetan en bytes mediante un "little-Endian" esquema: el bit menos significativo del primer código se almacena en el bit menos significativo del primer byte, los bits de orden superior del código en bits de orden superior del byte, desbordándose en los bits de orden inferior del siguiente byte según sea necesario. Cada código subsiguiente se almacena comenzando por el bit menos significativo que aún no se ha utilizado.

Este flujo de bytes se almacena en el archivo como una serie de "subbloques". Cada subbloque tiene una longitud máxima de 255 bytes y tiene como prefijo un byte que indica el número de bytes de datos en el subbloque. La serie de subbloques termina con un subbloque vacío (un único byte 0, que indica un subbloque con 0 bytes de datos).

Para la imagen de muestra anterior, la asignación reversible entre códigos de 9 bits y bytes se muestra a continuación.

Es evidente una ligera compresión: los colores de píxeles definidos inicialmente por 15 bytes se representan exactamente por 12 bytes de código, incluidos los códigos de control. El proceso de codificación que produce los códigos de 9 bits se muestra a continuación. Una cadena local acumula números de colores de píxeles de la paleta, sin acción de salida, siempre que la cadena local se pueda encontrar en una tabla de códigos. Hay un tratamiento especial de los dos primeros píxeles que llegan antes de que la tabla crezca desde su tamaño inicial mediante la adición de cadenas. Después de cada código de salida, la cadena local se inicializa con el último color de píxel (que no se pudo incluir en el código de salida).

 Cuadro 9-bit cadena -- código de acceso Acción#0 Silencio 000h Inicializar la tabla raíz de códigos de 9 bits
paleta Silencio:
colores Silencio:
#255 Silencio 0FFh
clérigo Silencio 100h
end tención 101h
tención 100h Clear
Pixel Local Silencio
Color de la cuerda de la paleta
BLACK #40 28 Silencio 028h 1st pixel siempre a la salida
WHITE #255 FF Silencio String encontrado en la mesa
28 FF Silencio 102h Siempre añadir 1a cuerda a la tabla
FF ← Inicia la cadena local
WHITE #255 FF FF ANTE String no se encuentra en la mesa
tención 0FFh - código de salida para cadena anterior
FF FF Silencio 103h - añadir la última cadena a la tabla
FF Silencio - inicializar cadena local
WHITE #255 FF FF ANTE String encontrado en la tabla
BLACK #40 FF FF 28 Silencio String not found in table
tención 103h - código de salida para cadena anterior
FF FF 28 Silencio 104h - añadir la última cadena a la tabla
28 TEN - inicializar cadena local
WHITE #255 28 FF ANTE String encontrado en la tabla
BLANCO #255 28 FF FF Silencio No se encuentra en la mesa
tención 102h - código de salida para cadena anterior
28 FF FF Silencio 105h - añadir la última cadena a la tabla
FF Silencio - inicializar cadena local
WHITE #255 FF FF ANTE String encontrado en la tabla
BLANTO #255 FF FF FF Silencio No se encuentra en la mesa
tención 103h - código de salida para cadena anterior
FF FF FF Silencio 106h - añadir la última cadena a la tabla
FF Silencio - inicializar cadena local
WHITE #255 FF FF ANTE String encontrado en la tabla
WHITE #255 FF FF FF Silencio String encontrado en la tabla
BLANCO #255 FF FF FF FF Silencio No se encuentra en la mesa
tención 106h - código de salida para cadena anterior
FF FF FF FF WordPress 107h - añadir la última cadena a la tabla
FF Silencio - inicializar cadena local
WHITE #255 FF FF ANTE String encontrado en la tabla
WHITE #255 FF FF FF Silencio String encontrado en la tabla
BLANCA #255 FF FF FF FF Silencio String encontrado en la tabla
No más pixeles
107h - código de salida para última cadena
101h End

Para mayor claridad, la tabla se muestra arriba como si estuviera construida con cadenas de longitud creciente. Ese esquema puede funcionar, pero la tabla consume una cantidad impredecible de memoria. La memoria se puede ahorrar en la práctica al observar que cada nueva cadena que se almacenará consiste en una cadena previamente almacenada aumentada por un carácter. Es económico almacenar en cada dirección solo dos palabras: una dirección existente y un carácter.

El algoritmo LZW requiere una búsqueda de la tabla para cada píxel. Una búsqueda lineal a través de hasta 4096 direcciones haría que la codificación fuera lenta. En la práctica, los códigos se pueden almacenar en orden de valor numérico; esto permite que cada búsqueda sea realizada por un SAR (Registro de aproximación sucesiva, como se usa en algunos ADC), con solo 12 comparaciones de magnitud. Para esta eficiencia se necesita una tabla adicional para convertir entre códigos y direcciones de memoria reales; el mantenimiento adicional de la tabla solo se necesita cuando se almacena un nuevo código, lo que ocurre a una velocidad mucho menor que la de los píxeles.

Descodificación de imágenes

La decodificación comienza con la asignación de los bytes almacenados a códigos de 9 bits. Estos se decodifican para recuperar los colores de los píxeles como se muestra a continuación. Se crea una tabla idéntica a la utilizada en el codificador agregando cadenas según esta regla:

 cambio9-bit... Pixel de mesa localcódigo de código -- collar de cuerdas Palette color Acción100h 000h Silencio #0 Inicializar la tabla raíz de códigos de 9 bits
: Paleta
: Colores rígidos
# 255 #
100h Silencioso cler
101h tención final
028h Silencio #40 BLACK Decode 1st pixel
0FFh 028h Silencio Código entrante encontrado en la tabla
Silencio #255 BLANCO - cadena de salida de la tabla
102h tención 28 FF - añadir a la tabla
103h 0FFh Silencio código entrante no se encuentra en la tabla
103h ← FF FF FF - añadir a la tabla
TEN - cadena de salida de la tabla
Silencio #255 BLANCOSilencio #255 BLANCO102h 103h ← Código entrante encontrado en la tabla
TEN - cadena de salida de la tabla
Silencio BLACKSilencio #255 BLANCO104h Silencio FF FF 28 - añadir a la tabla
103h 102h Silencio Código entrante encontrado en la tabla
TEN - cadena de salida de la tabla
Silencio #255 BLANCOSilencio #255 BLANCO105h tención 28 FF FF - añadir a la tabla
106h 103h ← Código entrante no encontrado en la tabla
106h ← FF FF FF FF - añadir a la tabla
TEN - cadena de salida de la tabla
Silencio #255 BLANCOSilencio #255 BLANCOSilencio #255 BLANCO107h 106h ← Código entrante no encontrado en la tabla
107h ← FF FF FF FF FF - añadir a la tabla
TEN - cadena de salida de la tabla
Silencio #255 BLANCOSilencio #255 BLANCOSilencio #255 BLANCOSilencio #255 BLANCO101h ← Final

Longitud de código LZW

Se pueden usar longitudes de código más cortas para paletas más pequeñas que los 256 colores del ejemplo. Si la paleta tiene solo 64 colores (por lo que los índices de color tienen un ancho de 6 bits), los símbolos pueden variar de 0 a 63, y el ancho del símbolo se puede considerar de 6 bits, con códigos que comienzan en 7 bits. De hecho, el ancho del símbolo no necesita coincidir con el tamaño de la paleta: siempre que los valores decodificados sean siempre menores que la cantidad de colores en la paleta, los símbolos pueden tener cualquier ancho de 2 a 8, y el tamaño de la paleta cualquier potencia de 2 de 2 a 256. Por ejemplo, si solo se utilizan los primeros cuatro colores (valores de 0 a 3) de la paleta, los símbolos se pueden considerar de 2 bits de ancho con códigos que comienzan en 3 bits.

Por el contrario, el ancho del símbolo podría establecerse en 8, incluso si solo se usan los valores 0 y 1; estos datos solo requerirían una tabla de dos colores. Aunque no tendría sentido codificar el archivo de esa manera, algo similar suele ocurrir con las imágenes bicolores: el ancho mínimo del símbolo es 2, incluso si solo se usan los valores 0 y 1.

La tabla de códigos inicialmente contiene códigos que son un bit más largos que el tamaño del símbolo para acomodar los dos códigos especiales clr y end y códigos para cadenas que se agregan durante el proceso. Cuando la tabla está llena, la longitud del código aumenta para dejar espacio para más cadenas, hasta un código máximo de 4095 = FFF (hexadecimal). A medida que el decodificador crea su tabla, realiza un seguimiento de estos aumentos en la longitud del código y puede desempaquetar los bytes entrantes en consecuencia.

GIF sin comprimir

A 46×46 GIF sin comprimir con símbolos de 7 bits (128 colores, códigos de 8 bits). Haga clic en la imagen para una explicación del código.

El proceso de codificación de GIF se puede modificar para crear un archivo sin compresión LZW que aún se puede ver como una imagen GIF. Esta técnica se introdujo originalmente como una forma de evitar la infracción de patentes. El GIF sin comprimir también puede ser un formato intermedio útil para un programador de gráficos porque los píxeles individuales son accesibles para leer o pintar. Un archivo GIF sin comprimir se puede convertir en un archivo GIF ordinario simplemente pasándolo por un editor de imágenes.

El método de codificación modificado ignora la construcción de la tabla LZW y emite solo los códigos de la paleta raíz y los códigos para CLEAR y STOP. Esto produce una codificación más simple (una correspondencia 1 a 1 entre los valores del código y los códigos de la paleta) pero sacrifica toda la compresión: cada píxel de la imagen genera un código de salida que indica su índice de color. Al procesar un GIF sin comprimir, no se impedirá que un decodificador de GIF estándar escriba cadenas en su tabla de diccionario, pero el ancho del código nunca debe aumentar, ya que eso desencadena un empaque diferente de bits a bytes.

Si el ancho del símbolo es n, los códigos de ancho n+1 se divide naturalmente en dos bloques: el bloque inferior de 2ⁿ códigos para codificar símbolos únicos y el bloque superior de 2ⁿ códigos que utilizará el decodificador para secuencias de longitud superior a una. De ese bloque superior ya están tomados los dos primeros códigos: 2ⁿ para CLEAR y 2ⁿ + 1 para DETENER. También se debe evitar que el decodificador use el último código en el bloque superior, 2ⁿ⁺¹ − 1, porque cuando el decodificador llene esa ranura, aumentará el ancho del código. Por lo tanto, en el bloque superior hay 2ⁿ − 3 códigos disponibles para el decodificador que no activarán un aumento en el ancho del código. Debido a que el decodificador siempre está un paso atrás en el mantenimiento de la tabla, no genera una entrada en la tabla al recibir el primer código del codificador, pero generará una para cada código subsiguiente. Por lo tanto, el codificador puede generar 2ⁿ − 2 códigos sin provocar un aumento en el ancho del código. Por lo tanto, el codificador debe emitir códigos CLEAR adicionales a intervalos de 2ⁿ − 2 códigos o menos para que el decodificador se reinicie. el diccionario de codificación. El estándar GIF permite insertar dichos códigos CLEAR adicionales en los datos de la imagen en cualquier momento. El flujo de datos compuesto se divide en subbloques, cada uno de los cuales contiene de 1 a 255 bytes.

Para la imagen de muestra de 3×5 anterior, los siguientes códigos de 9 bits representan "claro" (100) seguido de píxeles de imagen en orden de escaneo y "detener" (101).

0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF

Después de que los códigos anteriores se asignan a bytes, el archivo sin comprimir difiere del archivo comprimido de la siguiente manera:

Ejemplo de compresión

El ejemplo trivial de una imagen grande de color sólido demuestra la compresión LZW de longitud variable que se usa en los archivos GIF.

Los valores de código que se muestran se empaquetan en bytes que luego se empaquetan en bloques de hasta 255 bytes. Un bloque de datos de imagen comienza con un byte que declara el número de bytes que le siguen. El último bloque de datos de una imagen se marca con un byte de longitud de bloque cero.

Entrelazado

La especificación GIF permite que cada imagen dentro de la pantalla lógica de un archivo GIF especifique que está entrelazada; es decir, que el orden de las líneas de trama en su bloque de datos no es secuencial. Esto permite una visualización parcial de la imagen que se puede reconocer antes de que se pinte la imagen completa.

Una imagen entrelazada se divide de arriba a abajo en tiras de 8 píxeles de alto y las filas de la imagen se presentan en el siguiente orden:

• Pase 1: Línea 0 (la línea más alta) de cada tira.
• Pase 2: Línea 4 de cada tira.
• Pase 3: Líneas 2 y 6 de cada tira.
• Pase 4: Líneas 1, 3, 5 y 7 de cada tira.

Los píxeles dentro de cada línea no están entrelazados, sino que se presentan consecutivamente de izquierda a derecha. Al igual que con las imágenes no entrelazadas, no hay ruptura entre los datos de una línea y los datos de la siguiente. El indicador de que una imagen está entrelazada se establece en un bit en el bloque Image Descriptor correspondiente.

GIF animado

GIF se puede utilizar para mostrar animación, como en esta imagen de la cuna de Newton.

Una animación GIF hecha de dos fotos, una morder en la otra

Aunque GIF no se diseñó como un medio de animación, su capacidad para almacenar varias imágenes en un archivo sugirió naturalmente usar el formato para almacenar los fotogramas de una secuencia de animación. Para facilitar la visualización de animaciones, la especificación GIF89a agregó la Extensión de control gráfico (GCE), que permite que las imágenes (cuadros) en el archivo se pinten con demoras de tiempo, formando un videoclip. Cada cuadro en un GIF de animación es introducido por su propio GCE que especifica el tiempo de espera después de dibujar el cuadro. La información global al comienzo del archivo se aplica de forma predeterminada a todos los fotogramas. Los datos están orientados a la secuencia, por lo que el desplazamiento del archivo del inicio de cada GCE depende de la longitud de los datos anteriores. Dentro de cada cuadro, los datos de imagen codificados con LZW se organizan en subbloques de hasta 255 bytes; el tamaño de cada subbloque es declarado por el byte que lo precede.

De forma predeterminada, una animación muestra la secuencia de cuadros solo una vez y se detiene cuando se muestra el último cuadro. Para permitir que una animación se reproduzca en bucle, Netscape en la década de 1990 usó el bloque de extensión de aplicación (destinado a permitir que los proveedores agreguen información específica de la aplicación al archivo GIF) para implementar el bloque de aplicación de Netscape (NAB). Este bloque, colocado inmediatamente antes de la secuencia de fotogramas de la animación, especifica el número de veces que se debe reproducir la secuencia de fotogramas (1 a 65535 veces) o que se debe repetir de forma continua (cero indica un ciclo indefinido). La compatibilidad con estas animaciones repetitivas apareció por primera vez en Netscape Navigator versión 2.0 y luego se extendió a otros navegadores. La mayoría de los navegadores ahora reconocen y admiten NAB, aunque no es estrictamente parte de la especificación GIF89a.

El siguiente ejemplo muestra la estructura del archivo de animación Tierra en rotación (grande).gif que se muestra (como miniatura) en el cuadro de información del artículo.

000...
...001..
...0.
...

El retraso de la animación para cada cuadro se especifica en el GCE en centésimas de segundo. Cierta economía de datos es posible cuando un cuadro solo necesita reescribir una parte de los píxeles de la pantalla, porque el descriptor de imagen puede definir un rectángulo más pequeño para volver a escanear en lugar de la imagen completa. Los navegadores u otras pantallas que no admiten GIF animados generalmente muestran solo el primer cuadro.

El tamaño y la calidad del color de los archivos GIF animados pueden variar significativamente según la aplicación utilizada para crearlos. Las estrategias para minimizar el tamaño del archivo incluyen el uso de una tabla de colores global común para todos los cuadros (en lugar de una tabla de colores local completa para cada cuadro) y minimizar la cantidad de píxeles cubiertos en cuadros sucesivos (para que solo los píxeles que cambian de un cuadro al otro). siguientes se incluyen en este último marco). Las técnicas más avanzadas implican la modificación de secuencias de colores para que coincidan mejor con el diccionario LZW existente, una forma de compresión con pérdida. Simplemente empaquetar una serie de imágenes de cuadros independientes en una animación compuesta tiende a producir archivos de gran tamaño. Hay herramientas disponibles para minimizar el tamaño del archivo dado un GIF existente.

Metadatos

Los metadatos se pueden almacenar en archivos GIF como un bloque de comentarios, un bloque de texto sin formato o un bloque de extensión de aplicación específica. Varios editores de gráficos utilizan bloques de extensión de aplicaciones no oficiales para incluir los datos utilizados para generar la imagen, de modo que pueda recuperarse para su posterior edición.

Técnicamente, todos estos métodos requieren que los metadatos se dividan en subbloques para que las aplicaciones puedan navegar por el bloque de metadatos sin conocer su estructura interna.

El estándar de metadatos de la plataforma extensible de metadatos (XMP) introdujo un "XMP Data" no oficial pero ahora muy extendido; Bloque de extensión de aplicación para incluir datos XMP en archivos GIF. Dado que los datos XMP se codifican con UTF-8 sin caracteres NUL, no hay 0 bytes en los datos. En lugar de dividir los datos en subbloques formales, el bloque de extensión termina con un "tráiler mágico" que enruta cualquier aplicación que trate los datos como subbloques a un byte 0 final que finaliza la cadena de subbloques.

Aplicación de patentes de Unisys y LZW

En 1977 y 1978, Jacob Ziv y Abraham Lempel publicaron un par de artículos sobre una nueva clase de algoritmos de compresión de datos sin pérdidas, ahora denominados colectivamente LZ77 y LZ78. En 1983, Terry Welch desarrolló una variante rápida de LZ78 que se denominó Lempel-Ziv-Welch (LZW).

Welch presentó una solicitud de patente para el método LZW en junio de 1983. La patente resultante, US4558302, otorgada en diciembre de 1985, se asignó a Sperry Corporation, quien posteriormente se fusionó con Burroughs Corporation en 1986 y formó Unisys. Se obtuvieron más patentes en el Reino Unido, Francia, Alemania, Italia, Japón y Canadá.

Además de las patentes anteriores, la patente de Welch de 1983 también incluye citas de varias otras patentes que influyeron en ella, entre ellas:

• dos patentes japonesas de Jun Kanatsu, de 1980
• U.S. Patent 4,021,782 (1974) de John S. Hoerning,
• U.S. Patent 4,366,551 (1977) de Klaus E. Holtz, y
• a 1981 patente alemana de Karl Eckhart Heinz.

En junio de 1984, se publicó un artículo de Welch en la revista IEEE que describía públicamente la técnica LZW por primera vez. LZW se convirtió en una técnica popular de compresión de datos y, cuando se concedió la patente, Unisys celebró acuerdos de licencia con más de cien empresas.

La popularidad de LZW llevó a CompuServe a elegirla como técnica de compresión para su versión de GIF, desarrollada en 1987. En ese momento, CompuServe no estaba al tanto de la patente. Unisys se dio cuenta de que la versión de GIF usaba la técnica de compresión LZW y entró en negociaciones de licencia con CompuServe en enero de 1993. El acuerdo posterior se anunció el 24 de diciembre de 1994. Unisys declaró que esperaban que todas las principales empresas comerciales de servicios de información en línea que emplean la Patente de LZW para licenciar la tecnología de Unisys a un precio razonable, pero que no requerirá licencia ni pago de tarifas para aplicaciones basadas en GIF no comerciales y sin fines de lucro, incluidas aquellas para uso en los servicios en línea..

Después de este anuncio, hubo una condena generalizada de CompuServe y Unisys, y muchos desarrolladores de software amenazaron con dejar de usar GIF. El formato PNG (ver más abajo) se desarrolló en 1995 como un reemplazo previsto. Sin embargo, resultó difícil obtener soporte de los fabricantes de navegadores web y otro software para el formato PNG y no fue posible reemplazar GIF, aunque PNG ha aumentado gradualmente en popularidad. Por lo tanto, se desarrollaron variaciones GIF sin compresión LZW. Por ejemplo, la biblioteca libungif, basada en giflib de Eric S. Raymond, permite la creación de GIF que siguieron el formato de datos pero evitaron las funciones de compresión, evitando así el uso de la patente Unisys LZW. Un 2001 Dr. El artículo de Dobb describía una forma de lograr una codificación compatible con LZW sin infringir sus patentes.

En agosto de 1999, Unisys cambió los detalles de su práctica de otorgamiento de licencias y anunció la opción de que los propietarios de ciertos sitios web privados y no comerciales obtengan licencias mediante el pago de una tarifa de licencia única de $5000 o $7500. Dichas licencias no eran necesarias para los propietarios de sitios web u otros usuarios de GIF que habían utilizado software con licencia para generar GIF. Sin embargo, Unisys fue objeto de miles de ataques en línea y correos electrónicos abusivos de usuarios que creían que les iban a cobrar $5000 o demandarlos por usar GIF en sus sitios web. A pesar de otorgar licencias gratuitas a cientos de organizaciones sin fines de lucro, escuelas y gobiernos, Unisys fue completamente incapaz de generar una buena publicidad y continuó siendo condenada por personas y organizaciones como la Liga para la Libertad de Programación, que inició la campaña "Burn All GIF" campaña en 1999.

La patente LZW de Estados Unidos expiró el 20 de junio de 2003. Las patentes equivalentes en el Reino Unido, Francia, Alemania e Italia vencieron el 18 de junio de 2004, las patentes japonesas vencieron el 20 de junio de 2004 y la patente canadiense venció el 7 de julio 2004. En consecuencia, aunque Unisys tiene más patentes y solicitudes de patentes relacionadas con las mejoras de la técnica LZW, LZW en sí (y, en consecuencia, GIF) ha sido de uso gratuito desde julio de 2004.

Alternativas

PNG

Portable Network Graphics (PNG) se diseñó como un reemplazo de GIF para evitar la infracción de Unisys' Patente de la técnica de compresión LZW. PNG ofrece una mejor compresión y más funciones que GIF, siendo la animación la única excepción significativa. PNG es más adecuado que GIF en los casos en que se requieren imágenes en color verdadero y transparencia alfa.

Aunque la compatibilidad con el formato PNG llegó lentamente, los nuevos navegadores web admiten PNG. Las versiones anteriores de Internet Explorer no admiten todas las funciones de PNG. Las versiones 6 y anteriores no admiten la transparencia del canal alfa sin usar extensiones HTML específicas de Microsoft. La corrección gamma de las imágenes PNG no se admitía antes de la versión 8, y la visualización de estas imágenes en versiones anteriores puede tener un tinte incorrecto.

Para datos de imagen idénticos de 8 bits (o menos), los archivos PNG suelen ser más pequeños que los GIF equivalentes, debido a las técnicas de compresión más eficientes que se utilizan en la codificación PNG. El soporte completo para GIF se complica principalmente por la compleja estructura de lienzo que permite, aunque esto es lo que habilita las características de animación compacta.

Formatos de animación

Los videos resuelven muchos problemas que presentan los GIF a través del uso común en la web. Incluyen tamaños de archivo drásticamente más pequeños, la capacidad de superar la restricción de color de 8 bits y un mejor manejo de cuadros y compresión a través de códecs. El soporte prácticamente universal para el formato GIF en los navegadores web y la falta de soporte oficial para video en el estándar HTML hicieron que GIF cobrara importancia con el fin de mostrar archivos cortos similares a videos en la web.

• MNG ("Multiple-image Network Graphics") fue desarrollado originalmente como una solución basada en PNG para animaciones. MNG alcanzó la versión 1.0 en 2001, pero pocas aplicaciones lo apoyan.

• APNG ("Animated Portable Network Graphics") fue propuesto por Mozilla en 2006. APNG es una extensión al formato PNG como alternativa al formato MNG. APNG es compatible con la mayoría de los navegadores a partir de 2019. APNG proporciona la capacidad de animar archivos PNG, manteniendo la compatibilidad atrasada en decodificadores que no pueden entender el trozo de animación (a diferencia de MNG). Decodificadores más antiguos simplemente renderizar el primer marco de la animación.

The PNG group officially rejected APNG as an official extension on 20 April 2007.

Ha habido varias propuestas posteriores para un formato gráfico simple animado basado en PNG utilizando varios enfoques diferentes. Sin embargo, APNG todavía está en desarrollo por Mozilla y es compatible con Firefox 3.0 mientras que el soporte MNG fue retirado. APNG es actualmente compatible con todos los principales navegadores web incluyendo Chrome (desde la versión 59.0), Opera, Firefox y Edge.

• Embedded Adobe Flash objetos y
• Los archivos MPEG se utilizaron en algunos sitios web para mostrar vídeo simple, pero requería el uso de un plugin adicional del navegador.

• WebM y
• WebP están en desarrollo y son compatibles con algunos navegadores web.

• Otras opciones para la animación web incluyen servir marcos individuales usando AJAX, o
• animando imágenes SVG ("Scalable vector graphics") usando JavaScript o SMIL ("Synchronized Multimedia Integration Language").

• Con la introducción del soporte generalizado del vídeo HTML5 () etiqueta en la mayoría de los navegadores web, algunos sitios web utilizan una versión de la etiqueta de vídeo generada por funciones JavaScript. Esto da la apariencia de un GIF, pero con las ventajas de tamaño y velocidad del vídeo comprimido.

Ejemplos notables son Gfycat e Imgur y su metaformato GIFV, que es realmente una etiqueta de vídeo que reproduce un vídeo comprimido MP4 o WebM.

• HEIF ("High Efficiency Image File Format") es un formato de archivo de imagen, finalizado en 2015, que utiliza un algoritmo discreto de compresión cosine transform (DCT) basado en el formato de vídeo HEVC, y relacionado con el formato de imagen JPEG. En contraste con JPEG, HEIF admite animación.

En comparación con el formato GIF, que carece de compresión DCT, HEIF permite una compresión significativamente más eficiente. HEIF almacena más información y produce imágenes animadas de mayor calidad a una pequeña fracción del tamaño equivalente de GIF.

• VP9 solo admite compositing alpha con subsampling 4:2:0 de croma en el formato YUVA420 pixel, que puede ser inadecuado para GIFs que combinan transparencia con gráficos vectoriales rasterizados con detalles de color fino.

• El codec AV1 también se puede utilizar como un vídeo o una imagen secuenciada.

Usos

En abril de 2014, 4chan agregó soporte para videos WebM silenciosos que tienen menos de 3 MB de tamaño y 2 minutos de duración, y en octubre de 2014, Imgur comenzó a convertir cualquier archivo GIF cargado en el sitio a video y proporcionó el enlace al Reproductor HTML la apariencia de un archivo real con una extensión .gifv.

En enero de 2016, Telegram comenzó a recodificar todos los GIF a videos MPEG-4 que "requieren hasta un 95 % menos de espacio en disco para obtener la misma calidad de imagen".