El formato de intercambio de gráficos ( GIF ; / ɡ ɪ f / GHIF o / dʒ ɪ f / JIF , ) es un formato de imagen de mapa de bits desarrollado por un equipo del proveedor de servicios en línea CompuServe dirigido por el 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 puede usarse para 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 más 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érdidas Lempel-Ziv-Welch (LZW) para reducir el tamaño del archivo sin degradar la calidad visual.
Si bien alguna vez tuvo un uso generalizado 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 ha sido reemplazado por formatos de video como el formato de archivo MP4 . Estos reemplazos, a su vez, suelen denominarse "GIF" a pesar de no tener ninguna 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ó su formato de codificación de tirada anterior , que era solo en blanco y negro. GIF se hizo popular porque utilizaba la compresión de datos Lempel-Ziv-Welch . Dado que esto era más eficiente que la codificación de longitud de ejecución utilizada por PCX y MacPaint , se podían descargar imágenes bastante grandes con razonable rapidez incluso con módems lentos .
La versión original del GIF se llamaba 87a. [1] Esta versión ya admitía varias imágenes en una secuencia.
En 1989, CompuServe lanzó una versión mejorada, llamada 89a, [2] Esta versión agregó:
Las dos versiones se pueden distinguir mirando los primeros seis bytes del archivo (el " número mágico " o firma), que, cuando se interpretan como ASCII , dicen "GIF87a" o "GIF89a", respectivamente.
CompuServe fomentó la adopción de GIF proporcionando utilidades de conversión descargables para muchas computadoras. En diciembre de 1987, por ejemplo, un usuario de Apple IIGS podía ver imágenes creadas en un Atari ST o Commodore 64 . [4] GIF fue uno de los dos primeros formatos de imagen comúnmente utilizados en sitios web, siendo el otro el XBM en blanco y negro . [5]
En septiembre de 1995, Netscape Navigator 2.0 añadió la posibilidad de reproducir en bucle los GIF animados.
Si bien GIF fue desarrollado por CompuServe , utilizó el algoritmo de compresión de datos sin pérdidas Lempel-Ziv-Welch (LZW) patentado por Unisys en 1985. La controversia sobre el acuerdo de licencia entre Unisys y CompuServe en 1994 impulsó el desarrollo de Portable Network Graphics (PNG). estándar. En 2004, todas las patentes relacionadas con la compresión patentada utilizada para GIF expiraron.
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 líneas de escaneo de imágenes desordenadas de tal manera que incluso una imagen parcialmente descargada era algo reconocible, también ayudó a la popularidad del GIF, [6] ya que un usuario podía cancelar la descarga si no era lo que necesitaba.
En mayo de 2015, Facebook agregó soporte para GIF. [7] [8] En enero de 2018, Instagram también agregó pegatinas GIF al modo historia. [9]
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 reconoció GIF también como un verbo , que significa "crear un archivo GIF", como en "GIFing era el medio perfecto para compartir escenas de los Juegos Olímpicos de verano ". Los lexicógrafos de la prensa la votaron como palabra del año y afirmaron que los GIF se han convertido en "una herramienta con aplicaciones serias, incluida la investigación y el periodismo". [10] [11]
La pronunciación de la primera letra del 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 enginebra) y / ɡ ɪ f / ⓘ (congduracomo enregalo), diferenciándose en elfonemarepresentado por laletraG. 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 a menudo bromeaban "los desarrolladores exigentes 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 estade ges más frecuente. [14][15]
Dictionary.com [16] cita ambas pronunciaciones, indicando / dʒ ɪ f / como la pronunciación principal, mientras que el Diccionario Cambridge de inglés americano [17] ofrece sólo la pronunciación con g fuerte . El Diccionario colegiado de Merriam-Webster [18] y los diccionarios de Oxford citan ambas pronunciaciones, pero colocan la g dura primero: / ɡ ɪ f , dʒ ɪ f / . [19] [20] [21] [22] El New Oxford American Dictionary dio solo / 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 en g fuerte; [13] [25] [26] su discurso generó más de 17.000 publicaciones en Twitter y docenas de artículos de noticias. [27] La Casa Blanca [13] y el programa de televisión Jeopardy! también entró 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 una edición limitada "Jif vs. GIF" ( con el hashtag como #JIFvsGIF) frasco de mantequilla de maní que tenía una etiqueta que declaraba con humor que la pronunciación de g suave se refería exclusivamente a la mantequilla de maní, y un GIF que se pronunciaba exclusivamente con la pronunciación de g fuerte . [28]
Los GIF son adecuados para arte lineal con bordes nítidos y 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. [29] También se pueden utilizar para almacenar datos de sprites de bajo color para juegos. [30] Los GIF se pueden usar para pequeñas animaciones y videoclips de baja resolución, o como reacciones en mensajes en línea que se usan para transmitir emociones y sentimientos en lugar de usar palabras. Son populares en plataformas de redes sociales como Tumblr , [31] Facebook y Twitter . [32]
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 única imagen que ocupa toda la pantalla lógica. Otros dividen la pantalla lógica en subimágenes separadas. Las imágenes también pueden funcionar como cuadros de animación en un archivo GIF animado, pero 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 globales (GCT), que sigue a continuación si está presente.
A partir de entonces, el archivo se divide en segmentos de los siguientes tipos, cada uno introducido por un centinela de 1 byte:
',')'!')';'), 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 local (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 deben tener al menos 2 bits de ancho, incluso para imágenes bicolores), seguido de una serie de subbloques que contienen los datos codificados en LZW.
Los bloques de extensión (bloques que "extienden" la definición 87a mediante un mecanismo ya definido en la especificación 87a) constan del centinela, un byte adicional que especifica el tipo de extensión y una serie de subbloques con los datos de la extensión. Los bloques de extensión que modifican una imagen (como la Extensión de control gráfico que especifica el tiempo de retraso 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.
Cada subbloque comienza con un byte que indica el número de bytes de datos posteriores en el subbloque (1 a 255). La serie de subbloques termina con un subbloque vacío (un byte 0).
Esta estructura permite analizar el archivo incluso si no se comprenden todas las partes. Un GIF marcado 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 por extensiones que no comprende.
Los detalles completos del formato de archivo se tratan en la especificación GIF. [2]
GIF se basa en una paleta: los colores utilizados en una imagen (un marco) en el archivo tienen sus valores RGB definidos en una tabla de paleta que puede contener hasta 256 entradas, y los datos de la imagen se refieren a los colores por sus índices ( 0–255) en la tabla de paletas. Las definiciones de color en la paleta se pueden extraer de un espacio de color de millones de tonos (2 de 24 tonos, 8 bits para cada primario), pero la cantidad máxima de colores que puede usar un marco 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, los dibujos animados 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 al que se le asigne 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, denominadas colectivamente tramado , para aproximar una gama más amplia de colores con una paleta de colores pequeña mediante el uso de píxeles de dos o más colores para aproximar los colores intermedios. Estas técnicas sacrifican la resolución espacial para aproximarse a una resolución de color más profunda. Si bien no forma parte de la especificación GIF, el tramado se puede utilizar en imágenes codificadas posteriormente como imágenes GIF. A menudo, esta no es una solución ideal para imágenes GIF, porque la pérdida de resolución espacial generalmente hace que una imagen se vea borrosa en la pantalla y 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 buffers de 8 bits (que permitían solo 256 colores) eran comunes y era bastante común crear imágenes GIF usando la paleta web segura . [¿ 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 pudieron completarse con los colores óptimos para imágenes individuales.
Una pequeña tabla de colores puede ser suficiente para imágenes pequeñas, y mantenerla pequeña permite que el archivo se descargue más rápido. Tanto la especificaciones 87a como la 89a permiten tablas de colores de 2 n colores para cualquier n del 1 al 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 algunos no admiten todos los tamaños al crear imágenes. Se admiten ampliamente tablas de 2, 16 y 256 colores.
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 imágenes, cada uno de los cuales puede tener su propia paleta de 256 colores, y los bloques se pueden colocar en mosaico para crear una imagen completa. Alternativamente, la especificación GIF89a introdujo la idea de un 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 superponiendo bloques de imágenes en capas con la parte visible de cada capa mostrándose a través de las partes transparentes de las capas superiores.
Para representar una imagen a todo color como GIF, la imagen original debe dividirse en regiones más pequeñas que no tengan más de 255 o 256 colores diferentes. Luego, cada una de estas regiones se almacena como un bloque de imagen separado con su propia paleta local y cuando los bloques de imagen se muestran juntos (ya sea mediante mosaicos o superponiendo bloques de imágenes 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 fusionar colores similares, lo que resulta en cierta pérdida de color. información. [33]
Dado que cada bloque de imágenes puede tener su propia tabla de colores local, un archivo GIF que tenga muchos bloques de imágenes puede ser muy grande, lo que limita la utilidad de los GIF a todo color. [34] Además, no todos los programas de renderizado GIF manejan correctamente 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 [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 de las siguientes tablas están en orden de bytes little-endian , como lo prescribe la especificación de formato.
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 ha utilizado.
Este flujo de bytes se almacena en el archivo como una serie de "subbloques". Cada subbloque tiene una longitud máxima de 255 bytes y tiene como prefijo un byte que indica el número de bytes de datos en el subbloque. La serie de subbloques termina con un subbloque vacío (un único byte 0, que indica un subbloque con 0 bytes de datos).
Para la imagen de muestra de arriba, a continuación se muestra la asignación reversible entre códigos de 9 bits y bytes.
Se aprecia una ligera compresión: los colores de los píxeles definidos inicialmente por 15 bytes se representan exactamente por 12 bytes de código, incluidos los códigos de control. El proceso de codificación que produce los códigos de 9 bits se muestra a continuación. Una cadena local acumula números de color de píxeles de la paleta, sin ninguna 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 Inicializa la tabla raíz de códigos de 9 bits paleta | : colores | : #255 | 0FFh clr | 100h fin | 101h | 100h claroPíxeles locales |cadena de paleta de colores |NEGRO #40 28 | 028h 1er píxel siempre a la salidaBLANCO #255 FF | Cadena encontrada en la tabla 28 y siguientes | 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: agrega 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: agrega la última cadena a la tabla 28 | - inicializar cadena localBLANCO #255 28FF | 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: agrega 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: agrega 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: agrega 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 que se muestra arriba está construida con cuerdas de longitud creciente. Ese 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 almacenará consta de una cadena previamente almacenada aumentada en 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 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 Aproximaciones Sucesivas, 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 adicional de la tabla solo es necesario cuando se almacena un nuevo código, lo que ocurre a una velocidad de píxeles mucho menor.
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 construye una tabla idéntica a la utilizada en el codificador agregando cadenas según esta regla:
desplazamiento de 9 bits ----> Código de código de píxel de tabla local Código de código --> cadena Color de paleta Acción100h 000h | #0 Inicializar la tabla raíz de códigos de 9 bits : | paleta : | colores 0FFh | #255 100h | clr 101h | fin028h | #40 NEGRO Decodifica el primer 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 se puede considerar de 6 bits, con códigos que comienzan en 7 bits. De hecho, el ancho del símbolo no necesita coincidir con el tamaño de la paleta: siempre que los valores decodificados sean siempre menores que el número de colores en la paleta, los símbolos pueden tener cualquier ancho entre 2 y 8, y el tamaño de la paleta puede ser 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, se puede considerar que los símbolos tienen 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 sólo se utilizan los valores 0 y 1; estos datos sólo 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 bicolor: el ancho mínimo del símbolo es 2, incluso si solo se utilizan los valores 0 y 1.
Inicialmente, la tabla de códigos contiene códigos que son un bit más largos que el tamaño del símbolo para dar cabida a 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.
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. GIF sin comprimir también puede ser un formato intermedio útil para un programador de gráficos porque se puede acceder a píxeles individuales 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 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 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 de GIF estándar escriba cadenas en su tabla de diccionario, pero el ancho del código nunca debe aumentar, ya que eso desencadena un 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 n códigos para codificar símbolos individuales y el bloque superior de 2 n códigos que utilizará el decodificador para secuencias de longitud mayor que uno. De ese bloque superior ya están tomados los dos primeros códigos: 2 n para CLEAR y 2 n + 1 para STOP. También se debe evitar que el decodificador utilice el último código del bloque superior, 2 n +1 − 1 , porque cuando el decodificador llene esa ranura, aumentará el ancho del código. Por lo tanto, en el bloque superior hay 2 n − 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 en la tabla al recibir el primer código del codificador, pero generará una para cada código siguiente. Por tanto, 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 CLAROS adicionales a intervalos de 2 n − 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 compuesto se divide en subbloques, cada uno de los cuales 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 los píxeles de la imagen en el orden de escaneo y "detener" (101).
100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101
Después de que los códigos anteriores se asignan a bytes, el archivo sin comprimir difiere 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 mostrados se empaquetan en bytes que luego se empaquetan en bloques de hasta 255 bytes. Un bloque de datos de imagen comienza con un byte que declara el número de bytes que 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 ráster 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 franjas de 8 píxeles de alto y las filas de la imagen se presentan en el siguiente orden:
Los píxeles dentro de cada línea no están entrelazados, sino que se presentan consecutivamente de izquierda a derecha. Al igual que con las imágenes no entrelazadas, no hay interrupción entre los datos de una línea y los datos 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 naturalmente sugirió 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 pintar las imágenes (cuadros) en el archivo con retrasos de tiempo, formando un clip de video . Cada fotograma de una animación GIF es introducido por su propio GCE, que especifica el tiempo de espera después de dibujar el fotograma. La información global al inicio del archivo se aplica de forma predeterminada a todos los fotogramas. Los datos están orientados a la secuencia, por lo que el desplazamiento del archivo del inicio de cada GCE depende de la longitud de los datos anteriores. Dentro de cada cuadro, los datos de imagen codificados en LZW se organizan en subbloques de hasta 255 bytes; el tamaño de cada subbloque se declara mediante 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 a los proveedores agregar información específica de la aplicación al archivo GIF) para implementar el bloque de aplicación de Netscape (NAB). [37] Este bloque, colocado inmediatamente antes de la secuencia de cuadros de animación, especifica el número de veces que la secuencia de cuadros debe reproducirse (1 a 65535 veces) o que debe repetirse continuamente (cero indica bucle para siempre). La compatibilidad con estas animaciones repetidas apareció por primera vez en Netscape Navigator versión 2.0 y luego se extendió a otros navegadores. [38] La mayoría de los navegadores ahora reconocen y soportan 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 retraso de la animación para cada cuadro se especifica en el GCE en centésimas de segundo. Es posible realizar cierta economía de datos cuando un cuadro solo necesita reescribir una parte de los píxeles de la pantalla, porque el descriptor de imagen puede definir un rectángulo más pequeño para volver a escanear en lugar de toda la imagen. Los navegadores u otras pantallas que no admiten GIF animados normalmente muestran 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 la minimización del número de píxeles cubiertos en fotogramas sucesivos (de modo que sólo los píxeles que cambian de un fotograma al otro). Los siguientes se incluyen en este último cuadro). Las técnicas más avanzadas implican modificar 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 generar archivos de gran tamaño. Hay herramientas disponibles para minimizar el tamaño del 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ífica de la aplicación. Varios editores gráficos utilizan bloques de extensión de aplicaciones no oficiales para incluir los datos utilizados para generar la imagen, de modo que puedan recuperarse para su posterior edición.
Todos estos métodos requieren técnicamente que los metadatos se divida 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 "Datos XMP" no oficial pero ahora generalizado para incluir datos XMP en archivos GIF. [39] Dado que los datos XMP están codificados 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 "avance mágico" que dirige 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érdidas, ahora denominados colectivamente LZ77 y LZ78 . En 1983, Terry Welch desarrolló una variante rápida del LZ78 que recibió el nombre de 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 más patentes en el Reino Unido, Francia, Alemania, Italia, Japón y Canadá.
Además de las patentes anteriores, la patente de Welch de 1983 también incluye citas de varias otras patentes que influyeron en ella, entre ellas:
En junio de 1984 se publicó un artículo de Welch en la revista IEEE en el que describía públicamente por primera vez la técnica LZW. [47] LZW se convirtió en una técnica popular de compresión de datos y, cuando se concedió la patente, Unisys celebró acuerdos de licencia con más de cien empresas. [40] [48]
La popularidad de LZW llevó a CompuServe a elegirlo como técnica de compresión para su versión de GIF, desarrollada en 1987. En ese momento, CompuServe no tenía conocimiento de la patente. [40] Unisys se dio cuenta 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 esperaban todos los principales lanzamientos comerciales. compañías de servicios de información de línea que emplean la patente LZW para licenciar la tecnología de Unisys a un precio razonable, pero que no requerirían licencias ni el pago de tarifas para aplicaciones no comerciales y sin fines de lucro basadas en GIF, incluidas aquellas para su uso. 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 usar GIF. El formato PNG (ver más abajo) se desarrolló en 1995 como un reemplazo previsto. [40] [41] [47] Sin embargo, obtener soporte 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 su popularidad. [40] Por lo tanto, se desarrollaron variaciones GIF sin compresión LZW. Por ejemplo, la biblioteca libungif, basada en giflib de Eric S. Raymond , permite la creación de GIF que siguen el formato de datos pero evitan las funciones de compresión, evitando así el uso de la patente Unisys LZW. [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 concesión 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 única de licencia de 5.000 o 7.500 dólares. [51] Estas licencias no eran necesarias para los propietarios de sitios web ni para otros usuarios de GIF que hubieran utilizado software con licencia para generar GIF. Sin embargo, Unisys fue objeto de miles de ataques en línea y correos electrónicos abusivos de usuarios que creían que les iban a cobrar 5000 dólares o los demandarían 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 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". Campaña "GIFs" en 1999. [53] [54]
La patente LZW de los Estados Unidos expiró el 20 de junio de 2003. [55] 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. [55] En consecuencia, si bien Unisys tiene más patentes y solicitudes de patente relacionadas con mejoras de la técnica LZW, [55] el propio LZW (y, en consecuencia, GIF) han sido de uso gratuito 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 en color verdadero y transparencia alfa .
Aunque la compatibilidad con el formato PNG llegó lentamente, los nuevos navegadores web admiten PNG. Las versiones anteriores de Internet Explorer no son compatibles con todas las funciones 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 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 imagen idénticos de 8 bits (o menos), los archivos PNG suelen ser más pequeños que los GIF equivalentes, debido a las técnicas de compresión más eficientes 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 permite las funciones de animación compacta.
Los vídeos resuelven muchos problemas que presentan los GIF debido al uso común en la web. Incluyen tamaños de archivos 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 codificación entre cuadros . El soporte prácticamente universal para el formato GIF en los navegadores web y la falta de soporte oficial para vídeo en el estándar HTML hicieron que GIF adquiriera prominencia 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 vídeo generada por funciones de JavaScript . Esto da la apariencia de un GIF, pero con las ventajas de tamaño y velocidad del vídeo 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, [73] [74] y en octubre de 2014, Imgur comenzó a convertir cualquier archivo GIF cargado en el sitio a video H.264 . y darle al enlace al reproductor HTML la apariencia de un archivo real con una .gifvextensión. [75] [76]
En enero de 2016, Telegram comenzó a recodificar todos los GIF en videos MPEG-4 que "requieren hasta un 95% menos de espacio en disco para obtener la misma calidad de imagen". [77]
.gif/File:Rotating_earth_(large).gif){kind=link}