El formato de intercambio de gráficos ( GIF; /ɡɪf/ GHIF o / dʒɪf / JIF , véase § Pronunciación ) es un 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 y lanzado el 15 de junio de 1987. [1]
El formato puede contener hasta 8 bits por píxel , 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 puede representar varias imágenes en un archivo, que se puede utilizar para 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 adecuado para imágenes más simples, como gráficos o logotipos con áreas sólidas de color.
Las imágenes GIF se comprimen utilizando la técnica de compresión de datos sin pérdida Lempel–Ziv–Welch (LZW) para reducir el tamaño del archivo sin degradar la calidad visual.
Si bien en su momento se utilizó ampliamente en la World Wide Web debido a su amplia implementación y portabilidad entre aplicaciones y sistemas operativos, el uso del formato ha disminuido por razones de espacio y calidad, y a menudo se lo reemplaza con formatos de video como el formato de archivo MP4 . Estos reemplazos, a su vez, a veces se denominan "GIF", a pesar de no tener relación con el formato de archivo original. [3]
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ó a 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 . Como 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 bastante rapidez incluso con módems lentos .
La versión original de GIF se llamó 87a. [1] Esta versión ya admitía varias imágenes en una transmisión.
En 1989, CompuServe lanzó una versión mejorada, llamada 89a, [2] Esta versión agregó:
Las dos versiones se pueden distinguir observando los primeros seis bytes del archivo (el " número mágico " o firma), que, al interpretarse como ASCII , se leen "GIF87a" o "GIF89a", respectivamente.
CompuServe fomentó la adopción de GIF al proporcionar utilidades de conversión descargables para muchos ordenadores. En diciembre de 1987, por ejemplo, un usuario de Apple IIGS podía ver imágenes creadas en un Atari ST o un Commodore 64. [ 4] GIF fue uno de los dos primeros formatos de imagen utilizados comúnmente en los sitios web, el otro era el XBM en blanco y negro . [5]
En septiembre de 1995, Netscape Navigator 2.0 agregó la capacidad de reproducir GIF animados en bucle.
Aunque el formato GIF fue desarrollado por CompuServe , utilizaba 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 del estándar Portable Network Graphics (PNG). En 2004, expiraron todas las patentes relacionadas con la compresión patentada utilizada para GIF.
La función de almacenar múltiples 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 imágenes fuera de orden de tal manera que incluso una imagen parcialmente descargada era algo reconocible, también ayudó a la popularidad de GIF, [6] 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. [7] [8] En enero de 2018, Instagram también agregó stickers GIF al modo historia. [9]
Como sustantivo , la palabra GIF se encuentra en las ediciones más recientes de muchos diccionarios. En 2012, la sección estadounidense de la Oxford University Press reconoció GIF también como verbo , que significa "crear un archivo GIF", como en "GIFing fue 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 han evolucionado hasta convertirse en "una herramienta con aplicaciones serias que incluyen la investigación y el periodismo". [10] [11]
La pronunciación de la primera letra de GIF ha sido objeto de controversia desde la década de 1990. Las pronunciaciones más comunes en inglés son / dʒɪf / (con unagsuavecomo engin) y/ ɡ ɪ f / (con unagduracomo enregalo), que difiere en elfonemarepresentado por la letraG.Los creadores del formato pronunciaron el acrónimoGIFcomo/ dʒ ɪ f /, con unagsuave, y Wilhite afirmó que pretendía que la pronunciación hiciera eco deliberadamente de lamarcade mantequilla de maníJif, y los empleados de CompuServe solían bromear "los desarrolladores selectivos eligen GIF", una parodia de los comerciales de televisión de Jif.[12]Sin embargo, la palabra se pronuncia ampliamente como/ ɡ ɪ f /, con unagdura,[13]y las encuestas generalmente han demostrado que estages más frecuente.[14][15]
Dictionary.com [16] cita ambas pronunciaciones, indicando / dʒ ɪ f / como la pronunciación principal, mientras que Cambridge Dictionary of American English [17] ofrece solo la pronunciación con g dura . Merriam-Webster's Collegiate Dictionary [18] y Oxford Dictionaries citan ambas pronunciaciones, pero colocan la g dura primero: / ɡ ɪ f , dʒ ɪ f / . [19] [20] [21] [22] El New Oxford American Dictionary solo dio / dʒ ɪ f / en su segunda edición [23] pero lo actualizó a / dʒ ɪ f , ɡ ɪ f / en la tercera edición. [24]
El desacuerdo sobre la pronunciación ha dado lugar a 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 la g dura ; [13] [25] [26] su discurso dio lugar a más de 17.000 publicaciones en Twitter y decenas de artículos de prensa. [27] La Casa Blanca [13] y el programa de televisión Jeopardy! también entraron en el debate en 2013. [26] En febrero de 2020, The JM 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 lanzar un tarro de mantequilla de maní de edición limitada "Jif vs. GIF" ( con el hashtag #JIFvsGIF) que tenía una etiqueta que declaraba humorísticamente que la pronunciación de la g suave se refería exclusivamente a la mantequilla de maní, y que GIF se pronunciaba exclusivamente con la pronunciación de la g dura . [28]
Los GIF son adecuados para dibujos lineales de bordes nítidos con un número limitado de colores, como logotipos. Esto aprovecha la compresión sin pérdida del formato, que favorece las áreas planas de color uniforme con bordes bien definidos. [29] También se pueden utilizar para almacenar datos de sprites de bajo color para juegos. [30] Los GIF se pueden utilizar para pequeñas animaciones y videoclips de baja resolución, o como reacciones en mensajes en línea utilizados para transmitir emociones y sentimientos en lugar de usar palabras. Son populares en plataformas de redes sociales como Tumblr , [31] Facebook y Twitter . [32]
En teoría, 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 llena 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 nuevamente 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 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 aparece a continuación si está presente.
A continuación, el archivo se divide en segmentos de los siguientes tipos, cada uno introducido por un centinela de 1 byte:
',')'!')';'), 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 colores local (que sigue a continuación si está presente). A continuación, se muestran los datos de la imagen: un byte que indica el ancho en bits de los símbolos no codificados (que debe tener al menos 2 bits de ancho, incluso para imágenes bicolores), seguido de una serie de subbloques que contienen los datos codificados con 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 serie de subbloques 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 animación opcional y el color de fondo transparente opcional) deben preceder inmediatamente al segmento con la imagen a la que hacen referencia.
Cada subbloque comienza con un byte que indica el número de bytes de datos subsiguientes en el subbloque (de 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 sus 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 extensiones que no comprende.
Los detalles completos del formato de archivo están cubiertos en la especificación GIF. [2]
GIF se basa en paletas: los colores utilizados en una imagen (un fotograma) en el archivo tienen sus valores RGB definidos en una tabla de paleta que puede albergar hasta 256 entradas, y los datos de la imagen hacen referencia 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 24 tonos, 8 bits para cada primario), pero el número máximo de colores que un fotograma puede utilizar es 256. Esta limitación era razonable cuando se desarrolló GIF porque el hardware que podía mostrar más de 256 colores simultáneamente era poco común. 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 adquiere 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, llamadas colectivamente dithering , para aproximarse a 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 aproximarse a 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 dithering se puede utilizar en imágenes codificadas posteriormente como imágenes GIF. A menudo, esta no es una solución ideal para las imágenes GIF, tanto porque la pérdida de resolución espacial generalmente hace que una imagen se vea borrosa en la pantalla como porque los patrones de dithering 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 buffers de 8 bits (que permitían solo 256 colores) eran comunes y era bastante común crear imágenes GIF utilizando la paleta websafe . [ ¿según quién? ] Esto garantizaba una visualización predecible, pero limitaba severamente la elección de colores. Cuando el color de 24 bits se convirtió en la norma, las paletas se podían completar 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. Tanto la especificación 87a como la 89a permiten tablas de colores de 2 n colores para cualquier n de 1 a 8. La mayoría de las aplicaciones gráficas leerán y mostrarán imágenes GIF con cualquiera de estos tamaños de tabla; pero algunas no admiten todos los tamaños al crear imágenes. Las tablas de 2, 16 y 256 colores son ampliamente compatibles.
Aunque GIF casi nunca se utiliza para imágenes en color verdadero , es posible hacerlo. [33] [34] Una imagen GIF puede incluir múltiples 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 en capas bloques de imagen con la parte visible de cada capa mostrándose a través de las partes transparentes de las capas superiores.
Para reproducir 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. Cada una de estas regiones se almacena luego como un bloque de imagen separado con su propia paleta local y cuando los bloques de imagen se muestran juntos (ya sea mediante mosaicos o mediante la superposición 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) garantiza que ningún mosaico tenga más que el límite de la paleta local de 256 colores, aunque se pueden usar mosaicos más grandes y combinar colores similares, lo que da como resultado cierta pérdida de información de color. [33]
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. [34] 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 los mosaicos o las capas como cuadros de animación y los muestran en secuencia como una animación [33] 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. [35] [36] [ se necesita una mejor fuente ]
Los números hexadecimales en las siguientes tablas están en orden de bytes little-endian , como lo prescribe la especificación del formato.
Los datos de píxeles de la imagen, escaneados horizontalmente desde la parte superior izquierda, se convierten mediante la 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, los bits de orden superior del código en los bits de orden superior del byte, y se desbordan hacia los bits de orden inferior del siguiente byte según sea necesario. Cada código posterior se almacena comenzando por el bit menos significativo que no se haya 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 está precedido por un byte que indica la cantidad 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 se muestra a continuación el mapeo reversible entre códigos de 9 bits y bytes.
Se evidencia una ligera compresión: los colores de los píxeles definidos inicialmente por 15 bytes se representan exactamente con 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 ninguna acción de salida mientras 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 a partir de 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 de cadena de 9 bits --> código código Acción #0 | 000h Inicializar la tabla raíz de códigos de 9 bits paleta | : colores | : #255 | 0FFh 100 horas fin | 101h | 100h ClaroPíxel local |Paleta de colores cadena |NEGRO #40 28 | 028h 1er píxel siempre a la salidaBLANCO #255 FF | Cadena encontrada en la tabla 28 FF | 102h Siempre agregue la primera cadena a la tabla 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 | - inicializa 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 - añadir 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 | - inicializa 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 | - inicializa 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 | - inicializa 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 que se muestra arriba está formada por cadenas de longitud creciente. Este esquema puede funcionar, pero la tabla consume una cantidad impredecible de memoria. En la práctica, se puede ahorrar memoria teniendo en cuenta que cada nueva cadena que se almacene consta de una cadena almacenada previamente aumentada con un carácter. Resulta económico almacenar en cada dirección sólo dos palabras: una dirección existente y un carácter.
El algoritmo LZW requiere una búsqueda en 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 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; el mantenimiento de la tabla adicional solo se necesita cuando se almacena un nuevo código, lo que ocurre a una velocidad mucho menor que la de los píxeles.
La decodificación comienza asignando 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:
desplazamiento de 9 bits ----> Código de píxel de tabla local Código de código --> cadena Paleta de colores Acción100h 000h | #0 Inicializar la tabla raíz de códigos de 9 bits : | paleta : | colores 0FFh | #255 100 h | claro 101h | fin028h | #40 NEGRO Descodificar 1er píxel0FFh 028h | Código entrante encontrado en la tabla | #255 BLANCO - cadena de salida de la tabla 102h | 28 FF - añadir a la tabla103h 0FFh | Código entrante no encontrado en la tabla 103h | FF FF - añadir 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 - añadir a la tabla106h 103h | Código entrante no encontrado en la tabla 106h | FF FF FF - añadir a la tabla | - cadena de salida de la tabla | #255 BLANCO | #255 BLANCO | #255 BLANCO107h 106h | Código entrante no encontrado en la tabla 107h | FF FF FF FF - añadir a la tabla | - cadena de salida de la tabla | #255 BLANCO | #255 BLANCO | #255 BLANCO | #255 BLANCO101h | Fin
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 6 bits de ancho), 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 solo se utilizan los primeros cuatro colores (valores de 0 a 3) de la paleta, los símbolos pueden tomarse como 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 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 suele ocurrir con las imágenes bicolores: el ancho mínimo del símbolo es 2, incluso si solo se utilizan los valores 0 y 1.
La tabla de códigos contiene inicialmente 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 los códigos para cadenas que se agregan durante el proceso. Cuando la tabla está llena, la longitud del código aumenta para dar espacio a más cadenas, hasta un código máximo de 4095 = FFF(hex). 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.
El proceso de codificación GIF se puede modificar para crear un archivo sin compresión LZW que aún se pueda 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 normal simplemente pasándolo por un editor de imágenes.
El método de codificación modificado ignora la creación de la tabla LZW y emite únicamente 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 de código y los códigos de 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 activa un empaquetamiento 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 2n códigos para codificar símbolos individuales y el bloque superior de 2n 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: 2n para CLEAR y 2n +1 para STOP. También se debe evitar que el decodificador utilice el último código del bloque superior, 2n + 1-1 , porque cuando el decodificador llena esa ranura, aumentará el ancho del código. Por lo tanto, en el bloque superior hay 2n -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 por detrás en el mantenimiento de la tabla, no genera una entrada de tabla al recibir el primer código del codificador, sino que generará una para cada código sucesivo. De esta manera, el codificador puede generar 2 n − 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 n − 2 códigos o menos para hacer que el decodificador restablezca el diccionario de codificación. El estándar GIF permite que dichos códigos CLEAR adicionales se inserten en los datos de la imagen en cualquier momento. El flujo de datos compuesto se divide en subbloques que contienen cada uno de 1 a 255 bytes.
Para la imagen de muestra 3×5 anterior, los siguientes códigos de 9 bits representan "borrar" (100) seguido de los píxeles de la 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 de la siguiente manera:
El ejemplo trivial de una imagen grande de color sólido demuestra la compresión LZW de longitud variable utilizada en archivos GIF.
Los valores de código que se muestran se empaquetan en bytes que, a su vez, se empaquetan en bloques de hasta 255 bytes. Un bloque de datos de imagen comienza con un byte que declara la cantidad de bytes que le seguirán. El último bloque de datos de una imagen está marcado por un byte de longitud de bloque cero.
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:
Los píxeles de cada línea no están entrelazados, sino que se presentan de forma consecutiva de izquierda a derecha. Al igual que con las imágenes no entrelazadas, no hay interrupción entre los datos de una línea y los de la siguiente. El indicador de que una imagen está entrelazada es un bit establecido en el bloque Descriptor de imagen correspondiente.
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 el uso del 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 dibujen con retrasos de tiempo, formando un videoclip . Cada fotograma en un GIF de animación se introduce por su propia GCE que especifica el retraso de tiempo que se debe esperar después de que se dibuje el fotograma. La información global al comienzo 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 del archivo del inicio de cada GCE depende de la longitud de los datos anteriores. Dentro de cada fotograma, los datos de imagen codificados con LZW se organizan en subbloques de hasta 255 bytes; el tamaño de cada subbloque se declara 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 en bucle, Netscape utilizó en la década de 1990 el bloque de extensión de aplicación (destinado a permitir que los proveedores agregaran información específica de la aplicación al archivo GIF) para implementar el bloque de aplicación Netscape (NAB). [37] 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 (de 1 a 65535 veces) o que se debe repetir de forma continua (cero indica que se repetirá en bucle para siempre). El soporte para estas animaciones repetidas apareció por primera vez en la versión 2.0 de Netscape Navigator y luego se extendió a otros navegadores. [38] 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.
El retardo de animación de cada fotograma se especifica en el GCE en centésimas de segundo. Es posible ahorrar datos cuando un fotograma solo necesita reescribir una parte de los píxeles de la pantalla, ya que el descriptor de imagen puede definir un rectángulo más pequeño para volver a escanearlo 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 que se utilice para crearlos. Las estrategias para minimizar el tamaño de los archivos 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 la minimización del número de píxeles cubiertos en fotogramas sucesivos (de modo que solo los píxeles que cambian de un fotograma al siguiente se incluyan en el último fotograma). Las técnicas más avanzadas implican la modificación de las 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 fotogramas independientes en una animación compuesta tiende a producir archivos de gran tamaño. Hay herramientas disponibles para minimizar el tamaño de archivo dado un GIF existente.
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 aplicación no oficiales para incluir los datos utilizados para generar la imagen, de modo que se puedan recuperar para su posterior edición.
Todos estos métodos requieren técnicamente 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 Extensible Metadata Platform (XMP) introdujo un bloque de extensión de aplicación no oficial, pero ahora muy extendido, "XMP Data", para incluir datos XMP en archivos GIF. [39] Dado que los datos XMP se codifican utilizando UTF-8 sin caracteres NUL, no hay bytes 0 en los datos. En lugar de dividir los datos en subbloques formales, el bloque de extensión termina con un "truco mágico" que enruta cualquier aplicación que trate los datos como subbloques a un byte 0 final que termina la cadena de subbloques.
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 denominó Lempel–Ziv–Welch (LZW). [40] [41]
Welch presentó una solicitud de patente para el método LZW en junio de 1983. La patente resultante, US4558302, [42] concedida en diciembre de 1985, fue asignada a Sperry Corporation, que posteriormente se fusionó con Burroughs Corporation en 1986 y formó Unisys . [40] Se obtuvieron otras patentes en el Reino Unido, Francia, Alemania, Italia, Japón y Canadá.
Además de las patentes mencionadas anteriormente, la patente de Welch de 1983 también incluye citas de varias otras patentes que la influyeron, entre ellas:
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. [47] LZW se convirtió en una técnica de compresión de datos popular y, cuando se concedió la patente, Unisys firmó acuerdos de licencia con más de cien empresas. [40] [48]
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. [40] Unisys se enteró de que la versión de GIF utilizaba la técnica de compresión LZW y entabló negociaciones de licencia con CompuServe en enero de 1993. El acuerdo posterior se anunció el 24 de diciembre de 1994. [41] Unisys declaró que esperaba que todas las principales empresas de servicios de información en línea comerciales que emplearan la patente LZW obtuvieran la licencia de la tecnología de Unisys a una tasa razonable, pero que no exigirían licencias ni el pago de tasas para aplicaciones basadas en GIF no comerciales y sin fines de lucro, incluidas las que se utilizarían en los servicios en línea. [48]
Tras este anuncio, hubo una condena generalizada de CompuServe y Unisys, y muchos desarrolladores de software amenazaron con dejar de utilizar GIF. El formato PNG (ver más abajo) se desarrolló en 1995 como un reemplazo previsto. [40] [41] [47] 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 a GIF, aunque PNG ha aumentado gradualmente en popularidad. [40] Por lo tanto, se desarrollaron variaciones de GIF sin compresión LZW. Por ejemplo, la biblioteca libungif, basada en giflib de Eric S. Raymond , permite la creación de GIF que seguían el formato de datos pero evitaban las funciones de compresión, evitando así el uso de la patente LZW de Unisys. [49] Un artículo del Dr. Dobb de 2001 describió una forma de lograr una codificación compatible con LZW sin infringir sus patentes. [50]
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 no comerciales y privados de obtener licencias mediante el pago de una tarifa única de licencia de $5000 o $7500. [51] 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 iba a cobrar $5000 o demandar por usar GIF en sus sitios web. [52] A pesar de otorgar licencias gratuitas a cientos de organizaciones sin fines de lucro, escuelas y gobiernos, Unisys fue completamente incapaz de generar ninguna buena publicidad y continuó siendo condenada por individuos y organizaciones como la Liga para la Libertad de Programación que inició la campaña "Burn All GIFs" en 1999. [53] [54]
La patente estadounidense de LZW expiró el 20 de junio de 2003. [55] Las patentes equivalentes 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 de 2004. [55] En consecuencia, si bien Unisys tiene más patentes y solicitudes de patentes relacionadas con mejoras a la técnica LZW, [55] la propia LZW (y en consecuencia GIF) han sido libres de usar desde julio de 2004. [56]
Portable Network Graphics (PNG) fue diseñado como reemplazo de GIF para evitar la infracción de la patente de Unisys sobre la técnica de compresión LZW. [40] PNG ofrece una mejor compresión y más funciones que GIF, [57] siendo la animación la única excepción significativa. PNG es más adecuado que GIF en casos en los que se requieren imágenes con colores verdaderos y transparencia alfa .
Aunque el soporte para el formato PNG llegó lentamente, los nuevos navegadores web admiten PNG. Las versiones anteriores de Internet Explorer no admiten todas las características de PNG. Las versiones 6 y anteriores no admiten la transparencia del canal alfa sin utilizar extensiones HTML específicas de Microsoft. [58] La corrección gamma de las imágenes PNG no era compatible antes de la versión 8, y la visualización de estas imágenes en versiones anteriores puede tener un tono incorrecto. [59]
Para datos de imágenes 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 utilizadas en la codificación PNG. [60] 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 compactas.
Los videos resuelven muchos de los problemas que presentan los GIF a través de su uso común en la web. Entre ellos, se 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 fotogramas mediante la codificación entre fotogramas . 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 el GIF cobrara importancia con el propósito de mostrar archivos cortos similares a videos en la web.
<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 funciones de JavaScript . Esto da la apariencia de un GIF, pero con las ventajas de tamaño y velocidad del video comprimido.En abril de 2014, 4chan agregó soporte para videos WebM silenciosos de menos de 3 MB de tamaño y 2 minutos de duración, [74] [75] y en octubre de 2014, Imgur comenzó a convertir cualquier archivo GIF cargado al sitio a video H.264 y a darle al enlace al reproductor HTML la apariencia de un archivo real con una .gifvextensión. [76] [77]
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 la misma calidad de imagen". [78]
.gif/File:Rotating_earth_(large).gif){kind=link}