GIF

Familia de formatos de archivo de imagen de mapa de bits

Para otros usos, consulte GIF (desambiguación) .

GIF

Un GIF animado de un globo terráqueo giratorio
Extensión de nombre de archivo	.gif
Tipo de medio de Internet	image/gif
Código de tipo	GIFf
Identificador de tipo uniforme (UTI)	com.compuserve.gif
número mágico	GIF87a/GIF89a
Desarrollado por	CompuServe
Versión inicial	15 de junio de 1987 ; Hace 33 años [1] ( 15 de junio de 1987 )
Último lanzamiento	89a (1989 ; hace 32 años [2] ) ( 1989 )
Tipo de formato	formato de imagen de mapa de bits sin pérdidas
Sitio web	www .w3 .org / Graphics / GIF / spec-gif89a .txt

El formato de intercambio de gráficos ( GIF ; / ɡ ɪ f / GHIF o / dʒ ɪ f / JIF ) es un formato de imagen de mapa de bits que fue desarrollado por un equipo del proveedor de servicios en línea CompuServe dirigido por el científico informático estadounidense Steve Wilhite el 15 de junio de 1987. ^[1] Desde entonces ha tenido 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 cuadro. Estas limitaciones de paleta hacen que GIF sea menos adecuado para reproducir fotografías en color y otras imágenes con degradados de color , pero que sea 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érdida de Lempel – Ziv – Welch (LZW) para reducir el tamaño del archivo sin degradar la calidad visual. Esta técnica de compresión fue patentada en 1985. La controversia sobre el acuerdo de licencia entre el titular de la patente de software , Unisys , y CompuServe en 1994 estimuló el desarrollo del estándar Portable Network Graphics (PNG). En 2004, todas las patentes pertinentes habían expirado.

Historia

Más información: Aplicación de patentes de Unisys y LZW

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 formato de codificación de longitud de ejecución anterior , que era solo en blanco y negro. GIF se hizo popular porque usaba compresión de datos LZW . Dado que esto era más eficiente que la codificación de longitud de ejecución utilizada por PCX y MacPaint , se podían descargar imágenes bastante grandes con razonable rapidez incluso con módems lentos .

La versión original de GIF se llamó 87a . ^[1] En 1989, CompuServe lanzó una versión mejorada, llamada 89a , ^[2] que agregó soporte para retrasos de animación (múltiples imágenes en una secuencia ya eran compatibles en 87a), colores de fondo transparentes y almacenamiento de metadatos específicos de la aplicación. La especificación 89a también admite la incorporación de etiquetas de texto como texto (no incrustarlas en los datos gráficos), pero como hay poco control sobre las fuentes de visualización, esta función no se usa ampliamente. 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, lea "GIF87a" y "GIF89a", respectivamente.

CompuServe alentó la adopción de GIF al proporcionar 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 . ^[3] 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 . ^[4]

En septiembre de 1995, Netscape Navigator 2.0 agregó la capacidad de que los GIF animados se repitieran .

La función de almacenar varias imágenes en un archivo, acompañadas de datos de control, se utiliza ampliamente 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 parcialmente descargada era algo reconocible, también ayudó a la popularidad de GIF, ^[5] ya que un usuario podía abortar la descarga si no era lo que se requería.

En mayo de 2015, Facebook agregó soporte para GIF. ^{[6] [7]} En enero de 2018, Instagram también agregó pegatinas GIF al modo historia. ^[8]

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ó GIF como un verbo , que significa "crear un archivo GIF", ya que "GIF era el medio perfecto para compartir escenas de los Juegos Olímpicos de verano ". Los lexicógrafos de la prensa la votaron como su palabra del año , diciendo que los GIF se han convertido en "una herramienta con aplicaciones serias que incluyen la investigación y el periodismo". ^{[9] [10]}

Pronunciación de GIF

Ver también: g dura y blanda y descripción y prescripción

Una imagen humorística que anuncia el lanzamiento de un Tumblr de la Casa Blanca sugiere pronunciar GIF con el sonido duro de la "G".

Los creadores del formato pronunciaron la palabra como "jif" con una suave "G" / dʒ ɪ f / como en "gimnasio". Steve Wilhite dice que la pronunciación deseada se hace eco deliberadamente de la marca estadounidense de mantequilla de maní Jif , y los empleados de CompuServe solían decir "Los desarrolladores exigentes eligen GIF", falsificando los comerciales de televisión de esta marca. ^[11] La palabra ahora también se pronuncia ampliamente con una "G" dura / ɡ ɪ f / como en "regalo". ^[12] En 2017, una encuesta informal en el sitio web de programación Stack Overflowmostraron cierta preferencia numérica por la pronunciación de la "G" dura, ^[13] especialmente entre los encuestados en Europa del Este, aunque se encontró que tanto la "G" suave como cada letra individualmente eran populares en Asia y los países emergentes. ^[14]

Dictionary.com ^[15] cita ambos, indicando "jif" como la pronunciación principal, mientras que el Cambridge Dictionary of American English ^[16] ofrece sólo la pronunciación dura de "G". El Diccionario Colegiado de Merriam-Webster ^[17] y los Diccionarios de Oxford citan ambas pronunciaciones, pero coloque "gif" primero: / gɪf, dʒɪf / . ^{[18] [19] [20] [21]} El New Oxford American Dictionary dio sólo "jif" en su segunda edición ^[22] pero lo actualizó a "jif, gif" en su tercera edición. ^[23]

El desacuerdo sobre la pronunciación provocó un acalorado debate en Internet. Con motivo de recibir un premio a la trayectoria en la ceremonia del premio Webby 2013 , Wilhite rechazó la pronunciación dura de la "G", ^{[12] [24] [25]} y su discurso dio lugar a 17.000 publicaciones en Twitter y 50 artículos de noticias. ^[26] La Casa Blanca ^[12] y el programa de televisión Jeopardy! también entró en el debate durante 2013 ^[25].

En febrero de 2020, The JM Smucker Company , los propietarios de la marca de mantequilla de maní Jif, se asoció con la base de datos de imágenes animadas y el motor de búsqueda Giphy para lanzar una edición limitada "Jif vs. GIF" (con el hashtag #JIFvsGIF) de mantequilla de maní Jif. que tiene una etiqueta que declara con humor que la pronunciación suave de la "G" se refiere exclusivamente a la mantequilla de maní, y GIF que se pronuncia exclusivamente con la pronunciación dura de la "G". ^[27]

Uso

• Los GIF son adecuados para dibujos de líneas nítidas con un número limitado de colores, como logotipos. Esto aprovecha la compresión sin pérdidas del formato, que favorece áreas planas de color uniforme con bordes bien definidos. ^[28]
• Los GIF se pueden usar para almacenar datos de sprites de bajo color para juegos. ^[29]
• Los GIF se pueden utilizar para pequeñas animaciones y videoclips de baja resolución. ^[29]
• Los GIF se pueden usar como una reacción al enviar mensajes en línea, se usan para transmitir emociones y sentimientos, como alternativa al uso de palabras
• Popular 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 independientes. 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 proporciona las dimensiones en píxeles y otras 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 colores global (GCT), que sigue a continuación si está presente.

A partir de entonces, el archivo se divide en segmentos, cada uno introducido por un centinela de 1 byte:

• Una imagen (introducida por 0x2C, una coma ASCII ',')
• Un bloque de extensión (introducido por 0x21, un signo de exclamación ASCII '!')
• El final (un solo byte de valor 0x3B, un punto y coma ASCII ';'), que debería 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 colores locales (que sigue a continuación si está presente). Los datos de la imagen son los siguientes: un byte que proporciona el ancho de bits 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 de 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 enlazada 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 retardo de la animación opcional y el color de fondo transparente opcional) deben preceder inmediatamente al segmento con la imagen a la que hacen referencia.

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

Esta estructura permite analizar el archivo incluso si no se comprenden todas las partes. Un GIF marcado con 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 en extensiones que no comprende.

Todos los detalles del formato de archivo se tratan en la especificación GIF. ^[2]

Paletas

Un ejemplo de una imagen GIF guardada con una paleta segura para la Web y difuminada mediante el método Floyd-Steinberg . Debido al número reducido de colores en la imagen, existen 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 paleta. 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. Esta limitación parecía razonable cuando se desarrolló GIF porque pocas personas podían permitirse el hardware para mostrar más colores simultáneamente. Los gráficos simples, los dibujos lineales, los dibujos animados y las fotografías en escala de grises suelen necesitar 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 anterior.

Se han desarrollado muchas técnicas, denominadas colectivamente difuminado , 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 difuminado se puede utilizar en imágenes codificadas posteriormente como imágenes GIF. A menudo, esta no es una solución ideal para imágenes GIF, tanto porque la pérdida de resolución espacial normalmente hace que una imagen se vea borrosa en la pantalla, como porque los patrones de tramado a menudo interfieren con la compresibilidad de los datos de la imagen, lo que va en contra del propósito principal de GIF.

En los primeros días de los navegadores web gráficos ^{[ ¿cuándo? ]} , las tarjetas gráficas con búfer de 8 bits (que solo permiten 256 colores) eran comunes y era bastante común crear imágenes GIF utilizando la paleta segura para la web . ^{[ según quién? ]} 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 pudieron poblar 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 color de 2 ⁿ colores para cualquier n de 1 a 8. La mayoría de las aplicaciones de gráficos leerán y mostrarán imágenes GIF 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

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

Aunque GIF casi nunca se usa para imágenes en color verdadero , es posible hacerlo. ^{[30] [31]} Una imagen GIF puede incluir varios bloques de imagen, 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 color "transparente" 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 colocando bloques de imagen en capas con la parte visible de cada capa que se muestra a través de las partes transparentes de las capas superiores.

Para renderizar 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. A continuación, cada una de estas regiones se almacena como un bloque de imagen independiente con su propia paleta local y cuando los bloques de imagen se muestran juntos (ya sea por mosaico o por capas de bloques de imagen parcialmente transparentes) aparece la imagen completa a todo color. Por ejemplo, dividir una imagen en mosaicos de 16 por 16 píxeles (256 píxeles en total) asegura que ningún mosaico tenga más del límite de paleta local de 256 colores, aunque se pueden usar mosaicos más grandes y colores similares fusionados, lo que da como resultado una cierta pérdida de color. información. ^[30]

Dado que cada bloque de imágenes puede tener su propia tabla de colores local, un archivo GIF con muchos bloques de imágenes puede ser muy grande, lo que limita la utilidad de los GIF a todo color. ^[31] Además, no todos los programas de renderizado de GIF manejan correctamente las imágenes en mosaico o en capas. Muchos programas de renderizado interpretan mosaicos o capas como cuadros de animación y los muestran en secuencia como una animación sin fin ^[30] y la mayoría de los navegadores web muestran automáticamente los cuadros con un tiempo de retraso de 0,1 segundos o más. ^{[32] [33] [se necesita una mejor fuente ]}

Ejemplo de archivo GIF

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

Bytes D _h a 30C _h en el ejemplo definen una paleta de 256 colores.

Microsoft Paint guarda una pequeña imagen en blanco y negro como el siguiente archivo GIF. Paint no hace un uso óptimo de GIF; Debido a la tabla de colores innecesariamente grande (que almacena 256 colores completos en lugar de los 2 usados) y al ancho del símbolo, este archivo GIF no es una representación eficiente de la imagen de 15 píxeles (ilustrada ampliada arriba).

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 usa en la imagen. Los únicos índices de color que aparecen en los datos de la imagen son el decimal 40 y 255, que la Tabla de colores global asigna a blanco y negro, respectivamente.

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

Tabla de valores de imagen GIF de ejemplo

Byte # (hexadecimal)	Hexadecimal	Texto o valor	Significado
0	47 49 46 38 39 61	GIF89a	Encabezamiento
6	03 00	3	Ancho de pantalla lógica
8	05 00	5	Altura lógica de la pantalla
A	F7		GCT sigue para 256 colores con resolución 3  ×  8 bits / primario, los 3 bits más bajos representan la profundidad de bits menos 1, el bit verdadero más alto significa que el GCT está presente
B	00	0	Color de fondo: # 000000, negro
C	00	0	Relación de aspecto de píxeles predeterminada, 0: 0
D	00 00 00	R (rojo) G (verde) B (azul) 0 0 0	Tabla de colores global, color # 0: # 000000, negro
10	80 00 00	R (rojo) G (verde) B (azul) 128 0 0	Tabla de colores global, color n. ° 1: bit transparente, no se usa en la imagen
...	...	...	La tabla de colores global se extiende a 30A
30A	FF FF FF	R (rojo) G (verde) B (azul) 255 255 255	Tabla de colores global, color # 255: #ffffff, blanco
30D	21 F9		Extensión de control gráfico (los campos de comentarios preceden a 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 campo de bits, el bit más bajo significa transparencia
311	00 00		Retraso de la animación en centésimas de segundo; no utilizado
313	10	dieciséis	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	(0, 0)	Posición de la esquina noroeste de la imagen en la pantalla lógica
31A	03 00 05 00	(3, 5)	Ancho y alto de la imagen en píxeles
31E	00	0	Bit de tabla de colores locales, 0 significa ninguno
31F	08	8	Inicio de imagen, tamaño de código mínimo LZW
320	0B	11	Cantidad de imágenes codificadas en LZW siguientes, 11 bytes
321	00 51 FC 1B 28 70 A0 C1 83 01 01	<datos de imagen>	11 bytes de datos de imagen, ver campo 320
32C	00	0	Fin del bloque de datos de imagen
32D	3B		Terminación de archivo

Codificación de imagen

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 a 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 esquema "little-Endian": el bit menos significativo del primer código se almacena en el bit menos significativo del primer byte, bits de orden superior del código en bits de orden superior del byte, extendiéndose a 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 haya utilizado.

Este flujo de bytes se almacena en el archivo como una serie de "sub-bloques". Cada subbloque tiene una longitud máxima de 255 bytes y está precedido por 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 solo byte 0, que indica un subbloque con 0 bytes de datos).

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

Mapeo reversible

Código de 9 bits	Binario	Bytes (hexadecimal)
100	| 00000000 |	00
028	| 0101000 | 1	51
0FF	| 111111 | 00	FC
103	| 00011 | 011	1B
102	| 0010 | 1000	28
103	| 011 | 10000	70
106	| 10 | 100000	A0
107	| 1 | 1000001	C1
	| 10000011	83
101	| 00000001	01
	| 0000000 | 1	01

Es evidente una ligera compresión: los colores de los píxeles definidos inicialmente por 15 bytes están exactamente representados 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 color 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).

 Tabla  Cadena de 9 bits -> código código Acción # 0 | 000h Inicializar tabla raíz de códigos de 9 bits paleta | : colores | : # 255 | 0FFh clr | 100h fin | 101h | 100h despejadoPixel Local |cadena de paleta de colores |NEGRO # 40 28 | 028h 1er píxel siempre a la salidaBLANCO # 255 FF | Cadena encontrada en la tabla 28 FF | 102h Siempre agregue la 1ra cuerda a la mesa FF | Inicializar cadena localBLANCO # 255 FF FF | Cadena no encontrada en la tabla | 0FFh - código de salida para la cadena anterior FF FF | 103h - agregar la última cadena a la tabla FF | - inicializar cadena localBLANCO # 255 FF FF | Cadena encontrada en la tablaNEGRO # 40 FF FF 28 | Cadena no encontrada en la tabla | 103h - código de salida para la cadena anterior FF FF 28 | 104h - agregar la última cadena a la tabla 28 | - inicializar cadena localBLANCO # 255 28 FF | Cadena encontrada en la tablaBLANCO # 255 28 FF FF | Cadena no encontrada en la tabla | 102h - código de salida para la cadena anterior 28 FF FF | 105h - agregar la última cadena a la tabla FF | - inicializar cadena localBLANCO # 255 FF FF | Cadena encontrada en la tablaBLANCO # 255 FF FF FF | Cadena no encontrada en la tabla | 103h - código de salida para la cadena anterior FF FF FF | 106h - agregar la última cadena a la tabla FF | - inicializar cadena localBLANCO # 255 FF FF | Cadena encontrada en la tablaBLANCO # 255 FF FF FF | Cadena encontrada en la tablaBLANCO # 255 FF FF FF FF | Cadena no encontrada en la tabla | 106h - código de salida para la cadena anterior FF FF FF FF | 107h - agregar la última cadena a la tabla FF | - inicializar cadena localBLANCO # 255 FF FF | Cadena encontrada en la tablaBLANCO # 255 FF FF FF | Cadena encontrada en la tablaBLANCO # 255 FF FF FF FF | Cadena encontrada en la tabla No más píxeles 107h - código de salida para la última cadena 101h Fin

Para mayor claridad, la tabla se muestra arriba como construida con cuerdas de longitud creciente. Ese esquema puede funcionar, pero la mesa consume una cantidad de memoria impredecible. En la práctica, la memoria se puede guardar notando que cada nueva cadena que se va a 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 de hasta 4096 direcciones ralentizaría la codificación. En la práctica, los códigos se pueden almacenar en orden de valor numérico; esto permite que cada búsqueda se realice mediante un SAR (Registro de aproximación sucesiva, como se usa en algunos ADC ), con solo 12 comparaciones de magnitud. Para lograr esta eficiencia, se necesita una tabla adicional para convertir entre códigos y direcciones de memoria reales; la actualización adicional de la tabla es necesaria solo cuando se almacena un nuevo código, lo que ocurre a una velocidad mucho menor que la de píxeles.

Decodificación de imágenes

La decodificación comienza mapeando los bytes almacenados de nuevo a códigos de 9 bits. Estos se decodifican para recuperar los colores de los píxeles como se muestra a continuación. Una tabla idéntica a la que se usa en el codificador se construye agregando cadenas según esta regla:

¿Se encuentra el código entrante en la tabla?

sí	agregue una cadena para el código local seguido del primer byte de la cadena para el código entrante
No	agregue una cadena para el código local seguido de una copia de su propio primer byte

 cambio de 9 bits ----> Código de código de código de píxel de tabla local -> Cadena de color de paleta Acción100h 000h | # 0 Inicializar tabla raíz de códigos de 9 bits  : | paleta  : | colores 0FFh | # 255 100h | clr 101h | final028h | # 40 NEGRO Decodificación 1er píxel0FFh 028h | Código entrante encontrado en la tabla | # 255 BLANCO - cadena de salida de la tabla 102h | 28 FF - agregar a la tabla103h 0FFh | El código entrante no se encuentra en la tabla 103h | FF FF - agregar a la tabla | - cadena de salida de la tabla | # 255 BLANCO | # 255 BLANCO102h 103h | Código entrante encontrado en la tabla | - cadena de salida de la tabla | # 40 NEGRO | # 255 BLANCO 104h | FF FF 28 - añadir a la tabla103h 102h | Código entrante encontrado en la tabla | - cadena de salida de la tabla | # 255 BLANCO | # 255 BLANCO 105h | 28 FF FF - agregar a la tabla106h 103h | El código entrante no se encuentra en la tabla 106h | FF FF FF - agregar a la tabla | - cadena de salida de la tabla | # 255 BLANCO | # 255 BLANCO | # 255 BLANCO107h 106h | El código entrante no se encuentra en la tabla 107h | FF FF FF FF - agregar a la tabla | - cadena de salida de la tabla | # 255 BLANCO | # 255 BLANCO | # 255 BLANCO | # 255 BLANCO101h | Final

Longitudes de código LZW

Se pueden utilizar 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 puede tomarse como 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 el número 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 sólo se utilizan los primeros cuatro colores (valores de 0 a 3) de la paleta, los símbolos pueden tomarse como 2 bits de ancho con códigos que comienzan en 3 bits.

A la inversa, el ancho del símbolo podría establecerse en 8, incluso si solo se utilizan 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 sucede típicamente 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 contiene inicialmente códigos que son un poco 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 dar espacio para más cadenas, hasta un código máximo 4095 = FFF (hexadecimal). A medida que el decodificador construye su tabla, rastrea estos aumentos en la longitud del código y puede descomprimir los bytes entrantes en consecuencia.

GIF sin comprimir

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

El proceso de codificación 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. 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 normal 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 GIF estándar escriba cadenas en su tabla de diccionario, pero el ancho del código nunca debe aumentar, ya que eso desencadena un empaquetado diferente de bits a bytes.

Si el ancho del símbolo es n , los códigos de ancho n +1 se dividen naturalmente en dos bloques: el bloque inferior de 2 ⁿ códigos para codificar símbolos individuales y el bloque superior de 2 ⁿ códigos que utilizará el decodificador para secuencias de longitud mayor que uno. De ese bloque superior, los dos primeros códigos ya están tomados: 2 ⁿ para CLEAR y 2 ⁿ + 1 para STOP. También se debe evitar que el decodificador use el último código en el bloque superior, 2 ^{n +1} - 1 , porque cuando el decodificador llena ese espacio, aumentará el ancho del código. Así, en el bloque superior hay2 ⁿ - 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 de tabla al recibir el primer código del codificador, pero generará una para cada código sucesivo. 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 reinicie el diccionario de codificación. El estándar GIF permite insertar códigos CLEAR adicionales en los datos de la imagen en cualquier momento. El flujo de datos compuestos se divide en sub-bloques que cada uno transporta de 1 a 255 bytes.

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

100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

Una vez que los códigos anteriores se asignan a bytes, el archivo sin comprimir se diferencia del archivo comprimido por lo tanto:

Byte # (hexadecimal)	Hexadecimal	Texto o valor	Significado
320	14	20	Siguen 20 bytes de datos de imagen sin comprimir
321	00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335	00	0	Fin de los datos de la imagen

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.

Compresión de muestra de un archivo GIF

Código			Pixeles		Notas
No. N i	Valor N i + 256	Longitud (bits)	Este código N i	Acumulado N yo (N yo + 1)/2	Las relaciones que usan N i solo se aplican a píxeles del mismo color hasta que la tabla de codificación esté llena.
0	100h	9			Tabla de códigos clara
1	FFh		1	1	Color de píxel superior izquierdo elegido como el índice más alto de una paleta de 256 colores
2	102h		2	3
3 ⋮ 255	103h ⋮ 1FFh		3 ⋮ 255	6 ⋮ 32640	Último código de 9 bits
256 ⋮ 767	200h ⋮ 3FFh	10	256 ⋮ 767	32896 ⋮ 294528	Último código de 10 bits
768 ⋮ 1791	400h ⋮ 7FFh	11	768 ⋮ 1791	295296 ⋮ 1604736	Último código de 11 bits
1792 ⋮ 3839	800h ⋮ FFFh	12	1792 ⋮ 3839	1606528 ⋮ 7370880	Tabla de códigos llena
⋮	FFFh		3839	El código máximo puede repetirse para más píxeles del mismo color. La compresión general de datos se acerca asintóticamente a 3839 ×8/ 12= 2559+1/3
	101h				Fin de los datos de la imagen

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 a seguir. 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 pintar 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 superior) de cada franja.
• Paso 2: Línea 4 de cada franja.
• Paso 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 existe una ruptura entre los datos de una línea y los datos de la siguiente. El indicador de que una imagen está entrelazada es un conjunto de bits en el correspondiente bloque de descriptor de imagen.

GIF animado

El GIF se puede utilizar para mostrar animaciones, como en esta imagen de la cuna de Newton .

Una animación GIF compuesta por dos fotos, una transformándose en la otra.

Aunque GIF no fue diseñado como un medio de animación, su capacidad para almacenar múltiples 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 (fotogramas) en el archivo se pinten con retrasos de tiempo, formando un videoclip.. Cada fotograma en un GIF de animación es introducido por su propio GCE que especifica el tiempo de espera después de que se dibuja el fotograma. La información global al principio del archivo se aplica de forma predeterminada a todos los fotogramas. Los datos están orientados a la transmisión, por lo que el desplazamiento de archivo del inicio de cada GCE depende de la longitud de los datos anteriores. Dentro de cada cuadro, los datos de imagen codificados en 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 fotogramas solo una vez y se detiene cuando se muestra el último fotograma. Para permitir que una animación se repita, Netscape en la década de 1990 utilizó 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). ^[34] Este bloque, colocado inmediatamente antes de la secuencia de cuadros de animación, especifica el número de veces que se debe reproducir la secuencia de cuadros (1 a 65535 veces) o que debe repetirse continuamente (cero indica bucle para siempre). El soporte para estas animaciones repetidas apareció por primera vez en Netscape Navigator versión 2.0 y luego se extendió a otros navegadores. ^[35] 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 giratoria (grande) .gif que se muestra (como miniatura) en el cuadro de información del artículo.

Estructura de GIF

Byte # (hexadecimal)	Hexadecimal	Texto o valor	Significado
0	47 49 46 38 39 61	GIF89a	Descriptor de pantalla lógica
6	90 01	400	Ancho en píxeles
8	90 01	400	Alto en pixeles
A	F7		GCT sigue para 256 colores con resolución 3  ×  8 bits / primario
B	00	0	Color de fondo: # 000000, negro
C	00	0	Relación de aspecto de píxeles predeterminada, 0: 0
D	00		Tabla de colores global
⋮
30D	21 FF		Extensión de la aplicación
30F	0B	11	Tamaño del bloque que incluye el nombre de la aplicación y los bytes de verificación (siempre 11)
310	4E 45 54 53 43 41 50 45 32 2E 30	NETSCAPE2.0	Nombre de la aplicación de 8 bytes más 3 bytes de verificación
31B	03	3	Número de bytes en el siguiente subbloque
31C	01	1	Índice del subbloque de datos actual (siempre 1 para el bloque NETSCAPE)
31D	FF FF	65535	Número de repeticiones sin signo
31F	00		Fin de la cadena de subbloques para el bloque de extensión de la aplicación
320	21 F9		Extensión de control gráfico para el marco n. ° 1
322	04	4	Número de bytes (4) en el subbloque actual
323	04	000 ........ 001 ........ 0........ 0 (dividido en secciones para facilitar la lectura)	Reservado, 5 bits inferiores son campo de bits Método de eliminación 1: no desechar Sin entrada de usuario Color transparente, 0 significa no proporcionado
324	09 00	9	Retraso de fotograma: retardo de 0,09 segundos antes de pintar el siguiente fotograma
326	FF		Índice de color transparente (no utilizado en este marco)
327	00		Fin de la cadena de subbloques para el bloque de extensión de control gráfico
328	2C		Descriptor de imagen del fotograma n. ° 1
329	00 00 00 00	(0, 0)	Posición de la esquina noroeste de la imagen en la pantalla lógica: (0, 0)
32D	90 01 90 01	(400, 400)	Ancho y alto del marco: 400  ×  400 píxeles
331	00	0	Tabla de colores locales: 0 significa ninguno y sin entrelazado
332	08	8	Tamaño mínimo del código LZW para los datos de imagen del fotograma n. ° 1
333	FF	255	Número de bytes de datos de imagen LZW en el siguiente subbloque: 255 bytes
334	...	<datos de imagen>	Datos de imagen, 255 bytes
433	FF	255	Número de bytes de datos de imagen LZW en el siguiente subbloque, 255 bytes
434	...	<datos de imagen>	Datos de imagen, 255 bytes
⋮			Repita para los siguientes bloques
92C0	00		Fin de la cadena de sub-bloques para este marco
92C1	21 F9		Extensión de control gráfico para el marco n. ° 2
⋮			Repita para los siguientes fotogramas
EDABD	21 F9		Extensión de control gráfico para el marco # 44
⋮			Información y datos de imagen para el fotograma n. ° 44
F48F5	3B		Tráiler: último byte en el archivo, señalización EOF

El retraso de la animación para cada fotograma se especifica en el GCE en centésimas de segundo. Es posible cierta economía de datos cuando un fotograma 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 suelen mostrar solo el primer fotograma.

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 fotogramas (en lugar de una tabla de colores local completa para cada fotograma) y minimizar el número de píxeles cubiertos en fotogramas sucesivos (de modo que solo los píxeles que cambian de un fotograma al siguientes se incluyen en el último cuadro). Las técnicas más avanzadas implican la modificación de secuencias de color para que coincidan mejor con el diccionario LZW existente, una forma de compresión con pérdida . El simple hecho de empaquetar una serie de imágenes de fotogramas 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ífico de la aplicación. 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.

Todos estos métodos requieren técnicamente que los metadatos se dividan en sub-bloques para que las aplicaciones puedan navegar por el bloque de metadatos sin conocer su estructura interna.

El estándar de metadatos de la Plataforma de metadatos extensible (XMP) introdujo un bloque de extensión de aplicación "Datos XMP" no oficial pero ahora generalizado para incluir datos XMP en archivos GIF. ^[36] Dado que los datos XMP se codifican utilizando 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 sub-bloques a un byte final 0 que termina la cadena de sub-bloques.

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érdida, ahora denominados colectivamente LZ77 y LZ78 . En 1983, Terry Welch desarrolló una variante rápida de LZ78 que se llamó Lempel – Ziv – Welch (LZW). ^{[37] [38]}

Welch presentó una solicitud de patente para el método LZW en junio de 1983. La patente resultante, US 4558302  , concedida en diciembre de 1985, fue cedida a Sperry Corporation, quien posteriormente se fusionó con Burroughs Corporation en 1986 y formó Unisys . ^[37] 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, incluidas dos patentes japonesas de 1980 ( JP9343880A y JP17790880A ) de Jun Kanatsu de NEC , Patente de EE . UU. 4.021.782 (1974) de John S. Hoerning, Patente de Estados Unidos 4.366.551 (1977) de Klaus E. Holtz y una patente holandesa de 1981 ( DE19813118676 ) de Karl Eckhart Heinz. ^[39]

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. ^[40] LZW se convirtió en una técnica de compresión de datos popular y, cuando se otorgó la patente, Unisys celebró acuerdos de licencia con más de cien empresas. ^{[37] [41]}

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 conocía la patente. ^[37] Unisys se dio cuenta de que la versión de GIF utilizaba 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. ^[38] Unisys declaró que esperaban todos los principales comerciales en- empresas de servicios de información de línea que emplean la patente LZW para obtener licencias de la tecnología de Unisys a un precio razonable, pero que no requerirían licencias ni pagar tarifas para aplicaciones no comerciales y sin fines de lucro basadas en GIF, incluidas las de uso sobre los servicios en línea. ^[41]

Tras 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. ^{[37] [38] [40]} Sin embargo, obtener el apoyo de los fabricantes de navegadores web y otro software para el formato PNG resultó difícil y no fue posible reemplazar GIF, aunque PNG ha aumentado gradualmente en popularidad. ^[37] Por lo tanto, se desarrollaron variaciones GIF sin compresión LZW. Por ejemplo, la biblioteca libungif, basada en Eric S. Raymondgiflib, 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. ^[42] Un artículo de 2001 del Dr. Dobb describía otra alternativa a la compresión LZW, basada en raíces cuadradas. ^[43]

En agosto de 1999, Unisys cambió los detalles de su práctica de licencias, anunciando la opción para los propietarios de ciertos sitios web privados y no comerciales de obtener licencias mediante el pago de una tarifa de licencia única de $ 5000 o $ 7500. ^[44] 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 se les cobrarían 5000 dólares o se les demandaría por usar GIF en sus sitios web. ^[45] 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 individuos y organizaciones como laLeague for Programming Freedom que inició la campaña "Grabar todos los GIF" en 1999. ^{[46] [47]}

La patente estadounidense LZW expiró el 20 de junio de 2003. ^[48] Las patentes homólogas en el Reino Unido, Francia, Alemania e Italia expiraron el 18 de junio de 2004, las patentes japonesas expiraron el 20 de junio de 2004 y la patente canadiense expiró el 7 de julio. 2004. ^[48] En consecuencia, si bien Unisys tiene más patentes y solicitudes de patente relacionadas con mejoras en la técnica LZW, ^[48] GIF ahora se puede utilizar libremente. ^[49]

Alternativas

PNG

Portable Network Graphics (PNG) fue diseñado como un reemplazo de GIF para evitar la infracción de la patente de Unisys sobre la técnica de compresión LZW. ^[37] PNG ofrece una mejor compresión y más funciones que GIF, ^{[50] la} animación es la única excepción significativa. PNG es más adecuado que GIF en casos en los que se requieren imágenes en color verdadero y transparencia alfa .

Aunque la compatibilidad con el formato PNG llegó lentamente, los nuevos navegadores web generalmente admiten PNG. Las versiones anteriores de Internet Explorer no admiten todas las funciones de PNG. Las versiones 6 y anteriores no admiten la transparencia de canal alfa sin utilizar extensiones HTML específicas de Microsoft. ^[51] La corrección gamma de 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 tono incorrecto. ^[52]

Para datos de imagen idénticos de 8 bits (o inferiores), 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. ^[53] El soporte completo para GIF se complica principalmente por la compleja estructura de lienzo que permite, aunque esto es lo que habilita las funciones 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 y compresión de cuadros 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 el video en el estándar HTML hicieron que GIF ganara importancia con el propósito de mostrar archivos cortos similares a videos en la web.

MNG ("Gráficos de red de múltiples imágenes") se desarrolló originalmente como una solución basada en PNG para animaciones. MNG alcanzó la versión 1.0 en 2001, pero pocas aplicaciones la admiten.

En 2006, Mozilla propuso una extensión del formato PNG llamada APNG ("Gráficos de red portátiles animados") como alternativa al formato MNG . APNG es compatible con la mayoría de los navegadores a partir de 2019. ^[54] APNG proporciona la capacidad de animar archivos PNG, al tiempo que conserva la compatibilidad con versiones anteriores en decodificadores que no pueden comprender el fragmento de animación (a diferencia de MNG). Los decodificadores más antiguos simplemente renderizarán el primer fotograma de la animación. El grupo PNG rechazó oficialmente APNG como una extensión oficial el 20 de abril de 2007. ^[55] Ha habido varias propuestas posteriores para un formato de gráficos animados simple basado en PNG utilizando varios enfoques diferentes. ^[56] No obstante, gráficos de red portátiles animadosMozilla aún está en desarrollo y es compatible con Firefox 3 ^{[57] [58]} mientras que el soporte de MNG se eliminó. ^{[59] [60]} APNG es actualmente compatible con todos los principales navegadores web, incluido Chrome desde la versión 59.0 y Opera, Firefox y Edge.

En algunos sitios web se utilizan objetos de Adobe Flash incrustados y MPEG para mostrar videos simples, pero requieren el uso de un complemento de navegador adicional. WebM y WebP están en desarrollo y son compatibles con algunos navegadores web. ^[61] Otras opciones para la animación web incluyen servir fotogramas individuales usando AJAX , o animar imágenes SVG usando JavaScript o SMIL ("Lenguaje de integración multimedia sincronizado"). ^{[ cita requerida ]}

Con la introducción de un soporte generalizado de la etiqueta de video HTML5 ( <video>) en la mayoría de los navegadores web, algunos sitios web utilizan una versión en bucle de la etiqueta de video generada por las funciones de JavaScript . Esto le da la apariencia de un GIF, pero con las ventajas de tamaño y velocidad del video comprimido. Ejemplos notables son Gfycat e Imgur y su metaformato GIFV , que en realidad es una etiqueta de video que reproduce un video comprimido MP4 o WebM en bucle . ^[62]

El formato de archivo de imagen de alta eficiencia (HEIF) es un formato de archivo de imagen, finalizado en 2015, que utiliza un algoritmo de compresión con pérdida de transformación de coseno discreta (DCT) basado en el formato de video HEVC y relacionado con el formato de imagen JPEG . A diferencia de JPEG, HEIF admite animación. ^[63] Comparado 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 en una pequeña fracción del tamaño de un GIF equivalente. ^[64]

VP9 solo admite composición alfa con submuestreo de croma 4: 2: 0 ^[65] en el formato de píxel YUV A420, que puede no ser adecuado para GIF que combinan transparencia con gráficos vectoriales rasterizados con detalles de color finos.

El códec AV1 también se puede utilizar como vídeo o como 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, ^{[66] [67]} y en octubre de 2014, Imgur comenzó a convertir cualquier archivo GIF subido al sitio en video y le dio el vincular al reproductor HTML la apariencia de un archivo real con una .gifvextensión. ^{[68] [69]}

En enero de 2016, Telegram comenzó a volver a codificar todos los GIF en videos MPEG4 que "requieren hasta un 95% menos de espacio en disco para obtener la misma calidad de imagen". ^[70]

Ver también

• Cinemagraph , una fotografía parcialmente animada a menudo en GIF
• Comparación de formatos de archivos gráficos
• Comparación de motores de diseño (gráficos)
• Arte GIF , una forma de arte digital asociada con GIF
• GNU plotutils (admite pseudo-GIF, que usa codificación de longitud de ejecución en lugar de LZW)
• Microsoft GIF Animator , programa histórico para crear GIF animados sencillos
• Patente de software

Referencias

1. "Formato de intercambio de gráficos, versión 87a" . W3C . 15 de junio de 1987 . Consultado el 13 de octubre de 2012 .
2. "Formato de intercambio de gráficos, versión 89a" . W3C . 31 de julio de 1990 . Consultado el 6 de marzo de 2009 .
3. "Arte en línea" . Calcular! Es Aplicaciones de Apple . Diciembre de 1987. p. 10 . Consultado el 14 de septiembre de 2016 .
4. Holdener III, Anthony (2008). Ajax: la guía definitiva: aplicaciones interactivas para la web . O'Reilly Media. ISBN 978-0596528386.
5. Furht, Borko (2008). Enciclopedia de Multimedia . Saltador. ISBN 978-0387747248.
6. McHugh, Molly (29 de mayo de 2015). "Finalmente, de verdad, de verdad, de verdad puede publicar GIF en Facebook" . Cableado . wired.com . Consultado el 29 de mayo de 2015 .
7. Pérez, Sarah (29 de mayo de 2015). "Facebook confirma que admitirá oficialmente GIF" . techcrunch.com . Consultado el 29 de mayo de 2015 .
8. "Presentación de pegatinas GIF" . Instagram . 23 de enero de 2018 . Consultado el 19 de septiembre de 2019 .
9. "Palabra de Oxford Dictionaries USA del año 2012" . Blog de OxfordWords . Diccionarios estadounidenses de Oxford. 13 de noviembre de 2012 . Consultado el 1 de mayo de 2013 .
10. Flood, Alison (27 de abril de 2013). "¿ Gif es la palabra del año en Estados Unidos? Eso es lo que yo llamo un omnishambles" . Blog de libros. The Guardian . Londres . Consultado el 1 de mayo de 2013 .
11. Olsen, Steve. "La página de pronunciación GIF" . Consultado el 6 de marzo de 2009 .
12. "El inventor de Gif dice que ignore los diccionarios y diga 'Jif ' " . BBC News . 22 de mayo de 2013 . Consultado el 22 de mayo de 2013 .
13. "Encuesta de desarrolladores de desbordamiento de pila 2017" . 2017 . Consultado el 19 de agosto de 2018 .
14. "¿Cómo se pronuncia" GIF "?" . The Economist . Consultado el 4 de enero de 2018 .
15. "GIF" . Diccionario de abreviaturas de la herencia americana, tercera edición . Compañía Houghton Mifflin. 2005 . Consultado el 15 de abril de 2007 .
16. "GIF" . El Diccionario Cambridge de Inglés Americano . Prensa de la Universidad de Cambridge . Consultado el 19 de febrero de 2014 .
17. "Gif - Definición del diccionario Merriam-Webster" . Diccionario Merriam-Webster . Merriam-Webster, Incorporated . Consultado el 6 de junio de 2013 .
18. "GIF" . Diccionarios de Oxford en línea . Prensa de la Universidad de Oxford . Consultado el 7 de octubre de 2014 .
19. "sustantivo gif - Definición, imágenes, pronunciación y notas de uso | Diccionario de aprendizaje avanzado de Oxford" . Diccionarios de aprendizaje de Oxford . Consultado el 6 de febrero de 2021 .
20. "GIF | Definición de GIF por Oxford Dictionary" . Léxico . Consultado el 6 de febrero de 2021 .
21. Stevenson, Angus, ed. (2010). Diccionario Oxford de Inglés (3ª ed.). Prensa de la Universidad de Oxford. ISBN 9780199571123. OCLC  729551189 .
22. El nuevo diccionario americano de Oxford (2ª ed.). Prensa de la Universidad de Oxford. 2005. p. 711.
23. El nuevo diccionario americano de Oxford (3ª ed.). 2012. (parte de los diccionarios integrados de Macintosh).
24. O'Leary, Amy (21 de mayo de 2013). "Un honor para el creador del GIF" . The New York Times . Consultado el 22 de mayo de 2013 .
25. Rothberg, Daniel (4 de diciembre de 2013). " ' Jeopardy' se mete en la batalla de pronunciación de 'GIF'" . Los Angeles Times . Consultado el 4 de diciembre de 2013 .
26. O'Leary, Amy (23 de mayo de 2013). "La batalla por la pronunciación 'GIF' estalla" . The New York Times .
27. Valinsky, Jordan (25 de febrero de 2020). "Jif resuelve el gran debate con un tarro de mantequilla de maní GIF" . CNN . Consultado el 25 de febrero de 2020 .
28. Marur, DR; Bhaskar, V. (marzo de 2012). "Comparación de técnicas de distribución de documentos electrónicos independientes de la plataforma". Dispositivos, circuitos y sistemas (ICDCS) . Conferencia Internacional sobre Dispositivos, Circuitos y Sistemas (ICDCS) . Universidad de Karunya; Coimbatore, India: IEEE. págs. 297-301. doi : 10.1109 / ICDCSyst.2012.6188724 . ISBN 9781457715457.
29. S. Chin; D. Iverson; O. Campesato; P. Trani (2011). Pro Android Flash (PDF) . Nueva York: Apress. pag. 350. ISBN  9781430232315. Consultado el 11 de marzo de 2015 .
30. Andreas Kleinert (2007). "Extensiones GIF 24 Bit (truecolor)" . Archivado desde el original el 16 de marzo de 2012 . Consultado el 23 de marzo de 2012 .
31. Philip Howard. "Ejemplo de GIF de color verdadero" . Archivado desde el original el 22 de febrero de 2015 . Consultado el 23 de marzo de 2012 .
32. "Nullsleep - Jeremiah Johnson - Estudio de compatibilidad de navegador de retardo de marco mínimo de GIF animado" . Consultado el 26 de mayo de 2015 .
33. "¡Son diferentes! Cómo igualar la velocidad de animación de los archivos gif en los navegadores [ sic ]" . Blog del desarrollador . 14 de febrero de 2012. Archivado desde el original el 1 de febrero de 2017 . Consultado el 15 de junio de 2017 .
34. Royal Frazier. "Todo sobre GIF89a" . Archivado desde el original el 18 de abril de 1999 . Consultado el 7 de enero de 2013 .
35. Scott Walter (1996). Armas secretas de secuencias de comandos web . Que Publishing . ISBN 0-7897-0947-3.
36. "Parte 3 de la especificación XMP: almacenamiento en archivos" (PDF) . Adobe. 2016. págs. 11-12 . Consultado el 16 de agosto de 2018 .
37. Greg Roelofs. "Historia del formato de gráficos de red portátiles (PNG)" . Consultado el 23 de marzo de 2012 .
38. Stuart Caie. "Día triste ... Patente GIF muerta a los 20" . Consultado el 23 de marzo de 2012 .
39. Patente de Estados Unidos 4.558.302
40. "La controversia del GIF: la perspectiva de un desarrollador de software" . Consultado el 26 de mayo de 2015 .
41. "Unisys aclara la política sobre el uso de patentes en las ofertas de servicios en línea" . Archivado desde el original el 7 de febrero de 2007.- archivado por League for Programming Freedom
42. "Libungif" . Consultado el 26 de mayo de 2015 .
43. Cargill, Tom (1 de octubre de 2001). "Reemplazo de un diccionario con una raíz cuadrada" . Diario del Dr. Dobb . Consultado el 20 de enero de 2017 .
44. "Información sobre patentes y software de LZW" . Archivado desde el original el 8 de junio de 2009 . Consultado el 31 de enero de 2007 . - aclaración de 2 de septiembre de 1999
45. Unisys no demanda a (la mayoría) de los webmasters por usar GIF :investigación de Slashdot sobre la controversia
46. "Día de grabar todos los GIF" . Archivado desde el original el 13 de octubre de 1999.
47. Grabar todos los GIF : un proyecto de League for Programming Freedom (última versión)
48. "Información de licencia sobre GIF y otras tecnologías basadas en LZW" . Archivado desde el original el 2 de junio de 2009 . Consultado el 26 de abril de 2005 .
49. "Por qué no hay archivos GIF en las páginas web GNU" . Fundación de Software Libre . Consultado el 19 de mayo de 2012 .
50. "PNG versus compresión GIF" . Consultado el 8 de junio de 2009 .
51. "Filtro AlphaImageLoader" . Microsoft . Consultado el 26 de mayo de 2015 .
52. "Novedades de Internet Explorer 7" . MSDN . Consultado el 6 de marzo de 2009 .
53. "Formato de archivo de imagen PNG" . Consultado el 8 de junio de 2009 .
54. "Puedo usar ... Tablas de soporte para HTML5, CSS3, etc." . caniuse.com .
55. "VOTO FALLIDO: APNG 20070405a" . Lista de correo de SourceForge . 20 de abril de 2007.
56. "Discusión sobre un formato PNG" animado "simple" . Archivado desde el original el 26 de febrero de 2009 . Consultado el 12 de julio de 2011 .
57. "Especificación APNG" . Consultado el 26 de mayo de 2015 .
58. Mozilla Labs »Archivo del blog» Mejores animaciones en Firefox 3
59. "195280 - Eliminación de soporte MNG / JNG" . Consultado el 26 de mayo de 2015 .
60. "18574 - (mng) soporte de restauración para formato de animación MNG y formato de imagen JNG" . Consultado el 26 de mayo de 2015 .
61. "Blog de Chromium: Chrome 32 Beta: imágenes animadas de WebP y entrada táctil más rápida de Chrome para Android" . Blog.chromium.org. 21 de noviembre de 2013 . Consultado el 1 de febrero de 2014 .
62. "Presentación de GIFV - Blog de Imgur" . imgur.com. 9 de octubre de 2014 . Consultado el 14 de diciembre de 2014 .
63. Thomson, Gavin; Shah, Athar (2017). "Presentación de HEIF y HEVC" (PDF) . Apple Inc. Consultado el 5 de agosto de 2019 .
64. "Comparación HEIF - formato de archivo de imagen de alta eficiencia" . Tecnologías Nokia . Consultado el 5 de agosto de 2019 .
65. "# 3271 (Permitir el uso de formatos de píxeles adicionales con libvpx-vp9) - FFmpeg" . trac.ffmpeg.org .
66. Dewey, Caitlin. "Conoce la tecnología que podría hacer obsoletos los GIF" . The Washington Post . Consultado el 4 de febrero de 2015 .
67. "Soporte de WebM en 4chan" . Blog de 4chan . Consultado el 4 de febrero de 2015 .
68. "Presentación de GIFV" . Imgur. 9 de agosto de 2014 . Consultado el 21 de julio de 2016 .
69. Allan, Patrick. "Imgur renueva GIF para velocidades más rápidas y mayor calidad con GIFV" . Lifehacker . Consultado el 4 de febrero de 2015 .
70. "Revolución GIF" . Blog oficial de Telegram . Consultado el 4 de enero de 2016 .

Enlaces externos

Wikimedia Commons tiene medios relacionados con el formato de archivo GIF .

• El proyecto GIFLIB
• spec-gif89a.txt Especificación GIF 89a en w3.org
• Especificación GIF 89a reformateada en HTML
• Explicación de LZW y GIF
• GIF animados : un documental de seis minutos producido por Off Book (serie web)
• GifCities (El motor de búsqueda de GIF animados de GeoCities)