GIF -GIF
Extension de nom de fichier |
.gif
|
---|---|
Type de média Internet | image/gif
|
Tapez le code | GIFf |
Identificateur de type uniforme (UTI) | com.compuserve.gif |
nombre magique |
GIF87a /GIF89a
|
Développé par | CompuServ |
Première version | 15 juin 1987 |
Dernière version | 89a 1989 |
Type de format | format d'image bitmap sans perte |
Site Internet | www |
Le Graphics Interchange Format ( GIF ; / dʒ ɪ f / JIF ou / ɡ ɪ f / GHIF , voir la prononciation ) est un format d'image bitmap qui a été développé par une équipe du fournisseur de services en ligne CompuServe dirigé par l'informaticien américain Steve Wilhite et publié le 15 juin 1987. Il est depuis devenu largement utilisé sur le World Wide Web en raison de sa large prise en charge et de sa portabilité entre les applications et les systèmes d'exploitation.
Le format prend en charge jusqu'à 8 bits par pixel pour chaque image, permettant à une seule image de référencer sa propre palette de jusqu'à 256 couleurs différentes choisies dans l' espace colorimétrique RVB 24 bits . Il prend également en charge les animations et permet une palette distincte de jusqu'à 256 couleurs pour chaque image. Ces limitations de palette rendent le GIF moins adapté à la reproduction de photographies en couleur et d'autres images avec des dégradés de couleurs , mais bien adapté aux images plus simples telles que des graphiques ou des logos avec des zones de couleur unies.
Les images GIF sont compressées à l'aide de la technique de compression de données sans perte Lempel-Ziv-Welch (LZW) pour réduire la taille du fichier sans dégrader la qualité visuelle. Cette technique de compression a été brevetée en 1985. La controverse sur l'accord de licence entre le détenteur du brevet logiciel , Unisys , et CompuServe en 1994 a stimulé le développement de la norme Portable Network Graphics (PNG). En 2004, tous les brevets pertinents avaient expiré.
Histoire
CompuServe a introduit GIF le 15 juin 1987 pour fournir un format d'image couleur pour ses zones de téléchargement de fichiers. Cela a remplacé leur ancien format d'encodage de longueur d'exécution , qui était uniquement en noir et blanc. GIF est devenu populaire parce qu'il utilisait la compression de données Lempel-Ziv-Welch . Comme cela était plus efficace que le codage de longueur d'exécution utilisé par PCX et MacPaint , des images assez volumineuses pouvaient être téléchargées assez rapidement même avec des modems lents .
La version originale de GIF s'appelait 87a . Cette version prenait déjà en charge plusieurs images dans un flux.
En 1989, CompuServe a publié une version améliorée , appelée 89a , Cette version a ajouté :
- prise en charge des retards d'animation ,
- couleurs de fond transparentes ,
- stockage de métadonnées spécifiques à l'application et
- incorporant des étiquettes de texte en tant que texte (sans les incorporer dans les données graphiques),
mais comme il y a peu de contrôle sur les polices d'affichage, cette fonctionnalité n'est pas largement utilisée.
Les deux versions peuvent être distinguées en regardant les six premiers octets du fichier (le " nombre magique " ou signature), qui, lorsqu'ils sont interprétés comme ASCII , se lisent respectivement " GIF87a " et " GIF89a ".
CompuServe a encouragé l'adoption de GIF en fournissant des utilitaires de conversion téléchargeables pour de nombreux ordinateurs. En décembre 1987, par exemple, un utilisateur Apple IIGS pouvait voir des images créées sur un Atari ST ou un Commodore 64 . GIF était l'un des deux premiers formats d'image couramment utilisés sur les sites Web, l'autre étant le XBM en noir et blanc .
En septembre 1995 , Netscape Navigator 2.0 a ajouté la possibilité de boucler les GIF animés .
La fonctionnalité de stockage de plusieurs images dans un seul fichier, accompagnées de données de contrôle, est largement utilisée sur le Web pour produire des animations simples .
La fonction d' entrelacement facultative , qui stocke les lignes de numérisation d'image dans le désordre de telle sorte que même une image partiellement téléchargée était quelque peu reconnaissable, a également contribué à la popularité de GIF, car un utilisateur pouvait interrompre le téléchargement si ce n'était pas ce qui était requis.
En mai 2015 , Facebook a ajouté la prise en charge du GIF. En janvier 2018, Instagram a également ajouté des autocollants GIF au mode histoire.
Terminologie
En tant que nom , le mot GIF se trouve dans les nouvelles éditions de nombreux dictionnaires. En 2012, l'aile américaine de l' Oxford University Press a également reconnu GIF comme un verbe , signifiant "créer un fichier GIF", car dans "GIFing était le moyen idéal pour partager des scènes des Jeux olympiques d'été ". Les lexicographes de la presse l'ont élu leur mot de l'année , estimant que les GIF sont devenus "un outil aux applications sérieuses, notamment pour la recherche et le journalisme".
Prononciation
La prononciation de la première lettre de GIF est contestée depuis les années 1990. Les prononciations les plus courantes en anglais sont / dʒ ɪ f / ( écouter ) (avec un g doux comme dans gin ) et / ɡ ɪ f / ( écouter ) (avec un g dur comme dans gift ), différant par le phonème représenté par le lettre G. _ Les créateurs du format ont prononcé l'acronyme GIF comme / dʒ ɪ f / , avec un g doux , Wilhite déclarant qu'il avait l'intention que la prononciation fasse délibérément écho à la marque américaine de beurre de cacahuète Jif , et les employés de CompuServe plaisantaient souvent " les développeurs exigeants choisissent GIF", une parodie des publicités télévisées de Jif. Cependant, le mot est largement prononcé comme / ɡ ɪ f / , avec un g dur , et les sondages ont généralement montré que cette prononciation g dure est plus répandue.
Dictionary.com cite les deux prononciations, indiquant / dʒ ɪ f / comme prononciation principale, tandis que le Cambridge Dictionary of American English ne propose que laprononciation hard- g . Le Merriam-Webster's Collegiate Dictionary et les Oxford Dictionaries citent les deux prononciations, mais placent le g dur en premier : / ɡ ɪ f , dʒ ɪ f / . Le New Oxford American Dictionary n'a donné que / dʒ ɪ f / dans sa deuxième édition mais l'a mis à jour en / dʒ ɪ f , ɡ ɪ f / dans la troisième édition.
Le désaccord sur la prononciation a conduit à un débat houleux sur Internet. À l'occasion de la réception d'un prix pour l'ensemble de ses réalisations lors de la cérémonie des Webby Awards 2013 , Wilhite a publiquement rejeté la prononciation hard- g ; son discours a conduit à plus de 17 000 messages sur Twitter et des dizaines d'articles de presse. La Maison Blanche et l'émission télévisée Jeopardy! est également entré dans le débat en 2013. En février 2020, The JM Smucker Company , les propriétaires de la marque Jif, s'est associée à la base de données d'images animées et au moteur de recherche Giphy pour publier une édition limitée "Jif vs. GIF" ( hashtag as #JIFvsGIF ) pot de beurre de cacahuète qui avait une étiquette déclarant avec humour que la prononciation en g doux se réfère exclusivement au beurre de cacahuète, et GIF à prononcer exclusivement avec la prononciation en g dur .
Usage
Les GIF conviennent aux dessins au trait nets avec un nombre limité de couleurs, comme les logos. Cela tire parti de la compression sans perte du format, qui favorise les zones plates de couleur uniforme avec des bords bien définis. Ils peuvent également être utilisés pour stocker des données de sprite de faible couleur pour les jeux. Les GIF peuvent être utilisés pour de petites animations et des clips vidéo basse résolution, ou comme réactions dans la messagerie en ligne utilisée pour transmettre des émotions et des sentiments au lieu d'utiliser des mots. Ils sont populaires sur les plateformes de médias sociaux telles que Tumblr, Facebook et Twitter.
Format de fichier
Conceptuellement, un fichier GIF décrit une zone graphique de taille fixe ("l'écran logique") peuplée de zéro ou plusieurs "images". De nombreux fichiers GIF ont une seule image qui remplit tout l'écran logique. D'autres divisent l'écran logique en sous-images distinctes. Les images peuvent également fonctionner comme des images d'animation dans un fichier GIF animé, mais encore une fois, elles n'ont pas besoin de remplir tout l'écran logique.
Les fichiers GIF commencent par un en-tête de longueur fixe ("GIF87a" ou "GIF89a") donnant la version, suivi d'un descripteur d'écran logique de longueur fixe donnant les dimensions en pixels et d'autres caractéristiques de l'écran logique. Le descripteur d'écran peut également spécifier la présence et la taille d'une table de couleurs globale (GCT), qui suit ensuite si elle est présente.
Par la suite, le fichier est divisé en segments, chacun introduit par une sentinelle de 1 octet :
- Une image (introduite par 0x2C, une virgule ASCII
','
) - Un bloc d'extension (introduit par 0x21, un point d'exclamation ASCII
'!'
) - La fin (un seul octet de valeur 0x3B, un point-virgule ASCII
';'
), qui doit être le dernier octet du fichier.
Une image commence par un descripteur d'image de longueur fixe, qui peut spécifier la présence et la taille d'une table de couleurs locales (qui suit ensuite si elle est présente). Les données d'image suivent : un octet donnant la largeur en bits des symboles non codés (qui doit être d'au moins 2 bits de large, même pour les images bicolores), suivi d'une liste chaînée de sous-blocs contenant les données codées en LZW.
Les blocs d'extension (blocs qui "étendent" la définition 87a via un mécanisme déjà défini dans la spécification 87a) se composent de la sentinelle, d'un octet supplémentaire spécifiant le type d'extension et d'une liste liée de sous-blocs avec les données d'extension. Les blocs d'extension qui modifient une image (comme l'extension de contrôle graphique qui spécifie le temps de retard d'animation facultatif et la couleur d'arrière-plan transparente facultative) doivent immédiatement précéder le segment avec l'image à laquelle ils se réfèrent.
Les listes chaînées utilisées par les données d'image et les blocs d'extension consistent en des séries de sous-blocs, chaque sous-bloc commençant par un octet donnant le nombre d'octets de données suivants dans le sous-bloc (1 à 255). La suite de sous-blocs se termine par un sous-bloc vide (un octet 0).
Cette structure permet au fichier d'être analysé même si toutes les parties ne sont pas comprises. Un GIF marqué 87a peut contenir des blocs d'extension ; l'intention est qu'un décodeur puisse lire et afficher le fichier sans les fonctionnalités couvertes par les extensions qu'il ne comprend pas.
Le détail complet du format de fichier est couvert dans la spécification GIF.
Palettes
GIF est basé sur une palette : les couleurs utilisées dans une image (un cadre) dans le fichier ont leurs valeurs RVB définies dans une table de palette pouvant contenir jusqu'à 256 entrées, et les données de l'image se réfèrent aux couleurs par leurs indices ( 0–255) dans le tableau de la palette. Les définitions de couleurs dans la palette peuvent être tirées d'un espace colorimétrique de millions de nuances (2 24 nuances, 8 bits pour chaque primaire), mais le nombre maximum de couleurs qu'un cadre peut utiliser est de 256. Cette limitation semblait raisonnable lorsque GIF a été développé car peu de gens pouvaient se permettre le matériel pour afficher plus de couleurs simultanément. Les graphiques simples, les dessins au trait, les dessins animés et les photographies en niveaux de gris nécessitent généralement moins de 256 couleurs.
Chaque image peut désigner un index comme "couleur d'arrière-plan transparente": tout pixel affecté à cet index prend la couleur du pixel à la même position par rapport à l'arrière-plan, qui peut avoir été déterminée par une image d'animation précédente.
De nombreuses techniques, appelées collectivement tramage , ont été développées pour approximer une gamme de couleurs plus large avec une petite palette de couleurs en utilisant des pixels de deux couleurs ou plus pour approximer les couleurs intermédiaires. Ces techniques sacrifient la résolution spatiale pour se rapprocher d'une résolution de couleur plus profonde. Bien qu'il ne fasse pas partie de la spécification GIF, le tramage peut être utilisé dans des images ultérieurement codées en tant qu'images GIF. Ce n'est souvent pas une solution idéale pour les images GIF, à la fois parce que la perte de résolution spatiale rend généralement une image floue à l'écran et parce que les motifs de tramage interfèrent souvent avec la compressibilité des données d'image, ce qui va à l'encontre de l'objectif principal de GIF.
Au début des navigateurs Web graphiques, les cartes graphiques avec des tampons 8 bits (autorisant seulement 256 couleurs) étaient courantes et il était assez courant de créer des images GIF à l'aide de la palette Websafe . Cela garantissait un affichage prévisible, mais limitait considérablement le choix des couleurs. Lorsque la couleur 24 bits est devenue la norme, les palettes pouvaient à la place être remplies avec les couleurs optimales pour les images individuelles.
Une petite table de couleurs peut suffire pour les petites images, et garder la petite table de couleurs permet au fichier d'être téléchargé plus rapidement. Les spécifications 87a et 89a autorisent des tables de couleurs de 2 n couleurs pour n'importe quel n de 1 à 8. La plupart des applications graphiques liront et afficheront des images GIF avec n'importe laquelle de ces tailles de table ; mais certains ne prennent pas en charge toutes les tailles lors de la création d' images. Les tableaux de 2, 16 et 256 couleurs sont largement pris en charge.
Vraie couleur
Bien que le GIF ne soit presque jamais utilisé pour les images en vraies couleurs , il est possible de le faire. Une image GIF peut inclure plusieurs blocs d'image, chacun pouvant avoir sa propre palette de 256 couleurs, et les blocs peuvent être tuilés pour créer une image complète. Alternativement, la spécification GIF89a a introduit l'idée d'une couleur "transparente" où chaque bloc d'image peut inclure sa propre palette de 255 couleurs visibles plus une couleur transparente. Une image complète peut être créée en superposant des blocs d'image avec la partie visible de chaque couche visible à travers les parties transparentes des couches au-dessus.
Pour restituer une image en couleur au format GIF, l'image d'origine doit être décomposée en régions plus petites n'ayant pas plus de 255 ou 256 couleurs différentes. Chacune de ces régions est ensuite stockée en tant que bloc d'image séparé avec sa propre palette locale et lorsque les blocs d'image sont affichés ensemble (soit en mosaïque, soit en superposant des blocs d'image partiellement transparents), l'image complète en couleur apparaît. Par exemple, diviser une image en tuiles de 16 par 16 pixels (256 pixels au total) garantit qu'aucune tuile n'a plus que la limite de palette locale de 256 couleurs, bien que des tuiles plus grandes puissent être utilisées et des couleurs similaires fusionnées entraînant une certaine perte de couleur informations.
Étant donné que chaque bloc d'image peut avoir sa propre table de couleurs locale, un fichier GIF contenant de nombreux blocs d'image peut être très volumineux, ce qui limite l'utilité des GIF en couleur. De plus, tous les programmes de rendu GIF ne gèrent pas correctement les images en mosaïque ou en couches. De nombreux programmes de rendu interprètent les mosaïques ou les calques comme des images d'animation et les affichent en séquence comme une animation, la plupart des navigateurs Web affichant automatiquement les images avec un délai de 0,1 seconde ou plus.
Exemple de fichier GIF
Microsoft Paint enregistre une petite image en noir et blanc sous la forme du fichier GIF suivant (illustré agrandi).
Paint n'utilise pas le format GIF de manière optimale ; en raison de la table de couleurs inutilement grande (stockant 256 couleurs complètes au lieu des 2 utilisées) et de la largeur des symboles, ce fichier GIF n'est pas une représentation efficace de l'image de 15 pixels.
Bien que le bloc Graphic Control Extension déclare que l'index de couleur 16 (hexadécimal 10) est transparent, cet index n'est pas utilisé dans l'image. Les seuls index de couleur apparaissant dans les données d'image sont les nombres décimaux 40 et 255, que la table des couleurs globales mappe respectivement en noir et blanc.
Notez que les nombres hexadécimaux dans les tableaux suivants sont dans l'ordre des octets little-endian , comme le prescrit la spécification de format.
Octet # (hex) | Hexadécimal | Texte ou valeur | Sens | ||||||
---|---|---|---|---|---|---|---|---|---|
0 | 47 49 46 38 39 61 | GIF89a | Entête | ||||||
6 | 03 00 | 3 | Largeur d'écran logique | ||||||
8 | 05 00 | 5 | Hauteur d'écran logique | ||||||
UN | F7 | GCT suit pour 256 couleurs avec une résolution de 3 × 8 bits/primaire, les 3 bits les plus bas représentent la profondeur de bits moins 1, le bit vrai le plus élevé signifie que le GCT est présent | |||||||
B | 00 | 0 | Couleur de fond : indice #0 ; #000000 noir | ||||||
C | 00 | 0 | Format d'image des pixels par défaut, 0:0 | ||||||
ré | 00 00 00 |
|
Tableau des couleurs globales, couleur #0 : #000000, noir | ||||||
dix | 80 00 00 |
|
Table des couleurs globales, couleur #1 : bit transparent, non utilisé dans l'image | ||||||
... | ... | ... | La table des couleurs globales s'étend jusqu'à 30 A | ||||||
30A | FF FF FF |
|
Tableau des couleurs globales, couleur #255 : #ffffff, blanc | ||||||
30D | 21 F9 | Graphic Control Extension (les champs de commentaires précèdent cela dans la plupart des fichiers) | |||||||
30F | 04 | 4 | Quantité de données GCE, 4 octets | ||||||
310 | 01 | Couleur de fond transparente ; c'est un champ de bits, le bit le plus bas signifie la transparence | |||||||
311 | 00 00 | Délai d'animation en centièmes de seconde ; non utilisé | |||||||
313 | dix | 16 | Numéro de couleur du pixel transparent dans GCT | ||||||
314 | 00 | Fin du bloc GCE | |||||||
315 | 2C | Descripteur d'image | |||||||
316 | 00 00 00 00 | (0, 0) | Position du coin nord-ouest de l'image dans l'écran logique | ||||||
31A | 03 00 05 00 | (3, 5) | Largeur et hauteur de l'image en pixels | ||||||
31E | 00 | 0 | Bit de la table des couleurs locales, 0 signifie aucun | ||||||
31F | 08 | 8 | Début de l'image, taille de code minimale LZW | ||||||
320 | 0B | 11 | Quantité de suivi d'image encodée LZW, 11 octets | ||||||
321 | 00 51 CF 1B 28 70 A0 C1 83 01 01 | <données d'image> | 11 octets de données d'image, voir champ 320 | ||||||
32C | 00 | 0 | Fin du bloc de données d'image | ||||||
32D | 3B | Résiliation du fichier |
Codage des images
Les données de pixel d'image, numérisées horizontalement à partir du haut à gauche, sont converties par le codage LZW en codes qui sont ensuite mappés en octets pour être stockés dans le fichier. Les codes de pixel ne correspondent généralement pas à la taille de 8 bits des octets, de sorte que les codes sont regroupés en octets selon un schéma "little-Endian" : le bit le moins significatif du premier code est stocké dans le bit le moins significatif du premier octet, les bits de poids fort du code en bits de poids fort de l'octet, débordant dans les bits de poids faible de l'octet suivant si nécessaire. Chaque code suivant est stocké en commençant par le bit le moins significatif non déjà utilisé.
Ce flux d'octets est stocké dans le fichier sous la forme d'une série de "sous-blocs". Chaque sous-bloc a une longueur maximale de 255 octets et est précédé d'un octet indiquant le nombre d'octets de données dans le sous-bloc. La série de sous-blocs se termine par un sous-bloc vide (un seul octet 0, indiquant un sous-bloc avec 0 octet de données).
Pour l'exemple d'image ci-dessus, le mappage réversible entre les codes 9 bits et les octets est illustré ci-dessous.
Code 9 bits | Octet | ||
---|---|---|---|
Hexadécimal | Binaire | Binaire | Hexadécimal |
100 | 1 00000000 | 00000000 | 00 |
028 | 00 0101000 | 0101000 1 | 51 |
0FF | 011 111111 | 111111 00 | CF |
103 | 1000 00011 | 00011 011 | 1B |
102 | 10000 0010 | 0010 1000 | 28 |
103 | 100000 011 | 011 10000 | 70 |
106 | 1000001 10 | 10 100000 | A0 |
107 | 10000011 1 | 1 1000001 | C1 |
10000011 | 83 | ||
101 | 1 00000001 | 00000001 | 01 |
0000000 1 | 01 |
Une légère compression est évidente : les couleurs des pixels définies initialement par 15 octets sont représentées exactement par 12 octets de code incluant les codes de contrôle. Le processus de codage qui produit les codes 9 bits est illustré ci-dessous. Une chaîne locale accumule les numéros de couleur des pixels de la palette, sans action de sortie tant que la chaîne locale peut être trouvée dans une table de codes. Il existe un traitement spécial des deux premiers pixels qui arrivent avant que la table ne grandisse à partir de sa taille initiale par des ajouts de chaînes. Après chaque code de sortie, la chaîne locale est initialisée avec la dernière couleur de pixel (qui n'a pas pu être incluse dans le code de sortie).
Table 9-bit string --> code code Action #0 | 000h Initialize root table of 9-bit codes palette | : colors | : #255 | 0FFh clr | 100h end | 101h | 100h Clear Pixel Local | color Palette string | BLACK #40 28 | 028h 1st pixel always to output WHITE #255 FF | String found in table 28 FF | 102h Always add 1st string to table FF | Initialize local string WHITE #255 FF FF | String not found in table | 0FFh - output code for previous string FF FF | 103h - add latest string to table FF | - initialize local string WHITE #255 FF FF | String found in table BLACK #40 FF FF 28 | String not found in table | 103h - output code for previous string FF FF 28 | 104h - add latest string to table 28 | - initialize local string WHITE #255 28 FF | String found in table WHITE #255 28 FF FF | String not found in table | 102h - output code for previous string 28 FF FF | 105h - add latest string to table FF | - initialize local string WHITE #255 FF FF | String found in table WHITE #255 FF FF FF | String not found in table | 103h - output code for previous string FF FF FF | 106h - add latest string to table FF | - initialize local string WHITE #255 FF FF | String found in table WHITE #255 FF FF FF | String found in table WHITE #255 FF FF FF FF | String not found in table | 106h - output code for previous string FF FF FF FF| 107h - add latest string to table FF | - initialize local string WHITE #255 FF FF | String found in table WHITE #255 FF FF FF | String found in table WHITE #255 FF FF FF FF | String found in table No more pixels 107h - output code for last string 101h End
Pour plus de clarté, la table est présentée ci-dessus comme étant constituée de chaînes de longueur croissante. Ce schéma peut fonctionner mais la table consomme une quantité imprévisible de mémoire. La mémoire peut être économisée en pratique en notant que chaque nouvelle chaîne à stocker consiste en une chaîne précédemment stockée augmentée d'un caractère. Il est économique de ne stocker à chaque adresse que deux mots : une adresse existante et un caractère.
L'algorithme LZW nécessite une recherche de la table pour chaque pixel. Une recherche linéaire jusqu'à 4096 adresses ralentirait le codage. En pratique, les codes peuvent être stockés par ordre de valeur numérique ; cela permet à chaque recherche d'être effectuée par un SAR (registre d'approximations successives, tel qu'utilisé dans certains ADC ), avec seulement 12 comparaisons de magnitude. Pour cette efficacité, une table supplémentaire est nécessaire pour effectuer la conversion entre les codes et les adresses mémoire réelles ; la maintenance supplémentaire de la table n'est nécessaire que lorsqu'un nouveau code est stocké, ce qui se produit à un taux bien inférieur à celui des pixels.
Décodage d'images
Le décodage commence par mapper les octets stockés sur des codes 9 bits. Ceux-ci sont décodés pour récupérer les couleurs des pixels comme indiqué ci-dessous. Une table identique à celle utilisée dans l'encodeur est construite en ajoutant des chaînes selon cette règle :
Oui | ajouter une chaîne pour le code local suivi du premier octet de la chaîne pour le code entrant |
Non | ajouter une chaîne pour le code local suivi d'une copie de son propre premier octet |
shift 9-bit ----> Local Table Pixel code code code --> string Palette color Action 100h 000h | #0 Initialize root table of 9-bit codes : | palette : | colors 0FFh | #255 100h | clr 101h | end 028h | #40 BLACK Decode 1st pixel 0FFh 028h | Incoming code found in table | #255 WHITE - output string from table 102h | 28 FF - add to table 103h 0FFh | Incoming code not found in table 103h | FF FF - add to table | - output string from table | #255 WHITE | #255 WHITE 102h 103h | Incoming code found in table | - output string from table | #40 BLACK | #255 WHITE 104h | FF FF 28 - add to table 103h 102h | Incoming code found in table | - output string from table | #255 WHITE | #255 WHITE 105h | 28 FF FF - add to table 106h 103h | Incoming code not found in table 106h | FF FF FF - add to table | - output string from table | #255 WHITE | #255 WHITE | #255 WHITE 107h 106h | Incoming code not found in table 107h | FF FF FF FF - add to table | - output string from table | #255 WHITE | #255 WHITE | #255 WHITE | #255 WHITE 101h | End
Longueurs de code LZW
Des longueurs de code plus courtes peuvent être utilisées pour des palettes plus petites que les 256 couleurs de l'exemple. Si la palette ne contient que 64 couleurs (les index de couleurs ont donc une largeur de 6 bits), les symboles peuvent aller de 0 à 63, et la largeur du symbole peut être considérée comme étant de 6 bits, avec des codes commençant à 7 bits. En fait, la largeur du symbole n'a pas besoin de correspondre à la taille de la palette : tant que les valeurs décodées sont toujours inférieures au nombre de couleurs dans la palette, les symboles peuvent avoir n'importe quelle largeur de 2 à 8, et la taille de la palette n'importe quelle puissance de 2 de 2 à 256. Par exemple, si seules les quatre premières couleurs (valeurs 0 à 3) de la palette sont utilisées, les symboles peuvent être considérés comme ayant une largeur de 2 bits avec des codes commençant à 3 bits.
Inversement, la largeur du symbole pourrait être fixée à 8, même si seules les valeurs 0 et 1 sont utilisées ; ces données ne nécessiteraient qu'un tableau à deux couleurs. Bien qu'il soit inutile d'encoder le fichier de cette façon, quelque chose de similaire se produit généralement pour les images bicolores : la largeur minimale du symbole est de 2, même si seules les valeurs 0 et 1 sont utilisées.
La table de codes contient initialement des codes qui sont un peu plus longs que la taille du symbole afin de prendre en charge les deux codes spéciaux clr et end et les codes pour les chaînes qui sont ajoutés au cours du processus. Lorsque la table est pleine, la longueur du code augmente pour laisser de la place pour plus de chaînes, jusqu'à un code maximum 4095 = FFF(hex). Au fur et à mesure que le décodeur construit sa table, il suit ces augmentations de longueur de code et il est capable de décompacter les octets entrants en conséquence.
GIF non compressé
Le processus d'encodage GIF peut être modifié pour créer un fichier sans compression LZW qui est toujours visible en tant qu'image GIF. Cette technique a été introduite à l'origine comme un moyen d'éviter la contrefaçon de brevet. Le GIF non compressé peut également être un format intermédiaire utile pour un programmeur graphique car les pixels individuels sont accessibles pour la lecture ou la peinture. Un fichier GIF non compressé peut être converti en un fichier GIF ordinaire simplement en le faisant passer par un éditeur d'images.
La méthode de codage modifiée ignore la construction de la table LZW et n'émet que les codes de la palette racine et les codes pour CLEAR et STOP. Cela donne un encodage plus simple (une correspondance 1 à 1 entre les valeurs de code et les codes de palette) mais sacrifie toute la compression : chaque pixel de l'image génère un code de sortie indiquant son indice de couleur. Lors du traitement d'un GIF non compressé, un décodeur GIF standard ne sera pas empêché d'écrire des chaînes dans sa table de dictionnaire, mais la largeur du code ne doit jamais augmenter car cela déclenche un conditionnement différent de bits en octets.
Si la largeur de symbole est n , les codes de largeur n +1 se répartissent naturellement en deux blocs : le bloc inférieur de 2 n codes pour coder des symboles simples, et le bloc supérieur de 2 n codes qui seront utilisés par le décodeur pour des séquences de longueur supérieure à un. De ce bloc supérieur, les deux premiers codes sont déjà pris : 2 n pour CLEAR et 2 n + 1 pour STOP. Le décodeur doit également être empêché d'utiliser le dernier code du bloc supérieur, 2 n +1 - 1 , car lorsque le décodeur remplit ce créneau, il augmentera la largeur du code. Ainsi, dans le bloc supérieur, il y a 2 n - 3 codes disponibles pour le décodeur qui ne déclencheront pas d'augmentation de la largeur de code. Étant donné que le décodeur est toujours en retard dans la maintenance de la table, il ne génère pas d'entrée de table lors de la réception du premier code de l'encodeur, mais en génère une pour chaque code suivant. Ainsi le codeur peut générer 2 n - 2 codes sans déclencher d'augmentation de largeur de code. Par conséquent, le codeur doit émettre des codes CLEAR supplémentaires à des intervalles de 2 n - 2 codes ou moins pour que le décodeur réinitialise le dictionnaire de codage. La norme GIF permet d'insérer à tout moment de tels codes CLEAR supplémentaires dans les données d'image. Le flux de données composite est partitionné en sous-blocs qui portent chacun de 1 à 255 octets.
Pour l'exemple d'image 3 × 5 ci-dessus, les codes à 9 bits suivants représentent "clear" (100) suivi de pixels d'image dans l'ordre de balayage et "stop" (101).
100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101
Une fois les codes ci-dessus mappés en octets, le fichier non compressé diffère ainsi du fichier compressé :
Octet # (hex) | Hexadécimal | Texte ou valeur | Sens |
---|---|---|---|
320 | 14 | 20 | 20 octets de données d'image non compressées suivent |
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 des données d'image |
Exemple de compression
L'exemple trivial d'une grande image de couleur unie illustre la compression LZW de longueur variable utilisée dans les fichiers GIF.
Code | pixels | Remarques | |||
---|---|---|---|---|---|
Non.N je | ÉvaluerN je + 256 | Longueur(morceaux) | Ce codeN je | Accumulé N je (N je + 1)/2 | Les relations utilisant N i ne s'appliquent qu'aux pixels de même couleur jusqu'à ce que la table de codage soit pleine. |
0 | 100h | 9 | Effacer le tableau des codes | ||
1 | FFh | 1 | 1 | Couleur du pixel supérieur gauche choisie comme indice le plus élevé d'une palette de 256 couleurs | |
2 | 102h | 2 | 3 | ||
3⋮255 | 103h⋮1FFh | 3⋮255 | 6⋮32640 | Dernier code 9 bits | |
256⋮767 | 200h⋮3FFh | dix | 256⋮767 | 32896⋮294528 | Dernier code 10 bits |
768⋮1791 | 400h⋮7FFh | 11 | 768⋮1791 | 295296⋮1604736 | Dernier code 11 bits |
1792⋮3839 | 800h⋮FFFh | 12 | 1792⋮3839 | 1606528⋮7370880 | Table de codes pleine |
⋮ | FFFh | 3839 | Le code maximum peut se répéter pour plusieurs pixels de même couleur.La compression globale des données approche asymptotiquement 3839 ×8/12= 2559+1/3 | ||
101h | Fin des données d'image |
Les valeurs de code affichées sont compressées en octets qui sont ensuite compressés en blocs de 255 octets maximum. Un bloc de données d'image commence par un octet qui déclare le nombre d'octets à suivre. Le dernier bloc de données d'une image est marqué par un octet de longueur de bloc nulle.
Entrelacement
La spécification GIF permet à chaque image dans l'écran logique d'un fichier GIF de spécifier qu'elle est entrelacée ; c'est-à-dire que l'ordre des lignes raster dans son bloc de données n'est pas séquentiel. Cela permet un affichage partiel de l'image qui peut être reconnue avant que l'image complète ne soit peinte.
Une image entrelacée est divisée de haut en bas en bandes de 8 pixels de haut, et les rangées de l'image sont présentées dans l'ordre suivant :
- Passe 1 : Ligne 0 (la ligne la plus haute) de chaque bande.
- Passe 2 : Ligne 4 de chaque bande.
- Pass 3 : Lignes 2 et 6 de chaque bande.
- Passe 4 : Lignes 1, 3, 5 et 7 de chaque bande.
Les pixels à l'intérieur de chaque ligne ne sont pas entrelacés, mais présentés consécutivement de gauche à droite. Comme pour les images non entrelacées, il n'y a pas de rupture entre les données d'une ligne et les données de la suivante. L'indicateur qu'une image est entrelacée est un bit défini dans le bloc de description d'image correspondant.
GIF animé
Bien que GIF n'ait pas été conçu comme un support d'animation, sa capacité à stocker plusieurs images dans un seul fichier suggérait naturellement d'utiliser le format pour stocker les images d'une séquence d'animation. Pour faciliter l' affichage des animations, la spécification GIF89a a ajouté l'extension de contrôle graphique (GCE), qui permet aux images (frames) du fichier d'être peintes avec des retards, formant un clip vidéo . Chaque image d'un GIF d'animation est introduite par son propre GCE spécifiant le délai d'attente après le dessin de l'image. Les informations globales au début du fichier s'appliquent par défaut à toutes les trames. Les données sont orientées flux, de sorte que le décalage de fichier du début de chaque GCE dépend de la longueur des données précédentes. Dans chaque trame, les données d'image codées en LZW sont agencées en sous-blocs allant jusqu'à 255 octets ; la taille de chaque sous-bloc est déclarée par l'octet qui le précède.
Par défaut, une animation affiche la séquence d'images une seule fois, s'arrêtant lorsque la dernière image est affichée. Pour permettre à une animation de boucler, Netscape dans les années 1990 a utilisé le bloc d'extension d'application (destiné à permettre aux fournisseurs d'ajouter des informations spécifiques à l'application au fichier GIF) pour implémenter le bloc d'application Netscape (NAB). Ce bloc, placé immédiatement avant la séquence d'images d'animation, spécifie le nombre de fois que la séquence d'images doit être jouée (1 à 65535 fois) ou qu'elle doit se répéter en continu (zéro indique une boucle éternelle). La prise en charge de ces animations répétitives est apparue pour la première fois dans la version 2.0 de Netscape Navigator , puis s'est étendue à d'autres navigateurs. La plupart des navigateurs reconnaissent et prennent désormais en charge NAB, bien qu'il ne fasse pas strictement partie de la spécification GIF89a.
L'exemple suivant montre la structure du fichier d'animation Terre tournante (large).gif affiché (sous forme de vignette) dans l'infobox de l'article.
Octet # (hex) | Hexadécimal | Texte ou valeur | Sens |
---|---|---|---|
0 | 47 49 46 38 39 61 | GIF89a | Descripteur d'écran logique |
6 | 90 01 | 400 | Largeur en pixels |
8 | 90 01 | 400 | Hauteur en pixels |
UN | F7 | GCT suit pour 256 couleurs avec une résolution de 3 × 8 bits/primaire | |
B | 00 | 0 | Couleur de fond : #000000, noir |
C | 00 | 0 | Format d'image des pixels par défaut, 0:0 |
ré | 00 | Tableau des couleurs globales | |
⋮ | |||
30D | 21 FF | Extension d'application | |
30F | 0B | 11 | Taille du bloc, y compris le nom de l'application et les octets de vérification (toujours 11) |
310 | 4E 45 54 53 43 41 50 45 32 2E 30 | NETSCAPE2.0 | Nom d'application de 8 octets plus 3 octets de vérification |
31B | 03 | 3 | Nombre d'octets dans le sous-bloc suivant |
31C | 01 | 1 | Index du sous-bloc de données courant (toujours 1 pour le bloc NETSCAPE) |
31D | FF FF | 65535 | Nombre de répétitions non signé |
31F | 00 | Fin de la chaîne de sous-blocs pour le bloc Application Extension | |
320 | 21 F9 | Extension de contrôle graphique pour le cadre #1 | |
322 | 04 | 4 | Nombre d'octets (4) dans le sous-bloc courant |
323 | 04 |
000.....
...001..
......0.
.......0
|
Réservé, les 5 bits inférieurs sont un champ de bits Méthode d'élimination 1 : ne pas éliminer Aucune entrée utilisateur Couleur transparente, 0 signifie non donné |
324 | 09 00 | 9 | Délai d'image : délai de 0,09 seconde avant de peindre l'image suivante |
326 | FF | Indice de couleur transparent (inutilisé dans ce cadre) | |
327 | 00 | Fin de la chaîne de sous-blocs pour le bloc Graphic Control Extension | |
328 | 2C | Descripteur d'image du cadre #1 | |
329 | 00 00 00 00 | (0, 0) | Position du coin nord-ouest de l'image dans l'écran logique : (0, 0) |
32D | 90 01 90 01 | (400, 400) | Largeur et hauteur du cadre : 400 × 400 pixels |
331 | 00 | 0 | Table des couleurs locales : 0 signifie aucun et aucun entrelacement |
332 | 08 | 8 | Taille minimale du code LZW pour les données d'image de la trame 1 |
333 | FF | 255 | Nombre d'octets de données d'image LZW dans le sous-bloc suivant : 255 octets |
334 | ... | <données d'image> | Données d'image, 255 octets |
433 | FF | 255 | Nombre d'octets de données d'image LZW dans le sous-bloc suivant, 255 octets |
434 | ... | <données d'image> | Données d'image, 255 octets |
⋮ | Répéter pour les blocs suivants | ||
92C0 | 00 | Fin de chaîne de sous-blocs pour cette trame | |
92C1 | 21 F9 | Extension de contrôle graphique pour le cadre #2 | |
⋮ | Répéter pour les images suivantes | ||
EDABD | 21 F9 | Extension de contrôle graphique pour le cadre #44 | |
⋮ | Informations et données d'image pour le cadre #44 | ||
F48F5 | 3B | Bande-annonce : dernier octet du fichier, signalant EOF |
Le délai d'animation pour chaque image est spécifié dans le GCE en centièmes de seconde. Une certaine économie de données est possible lorsqu'un cadre n'a besoin de réécrire qu'une partie des pixels de l'affichage, car le descripteur d'image peut définir un rectangle plus petit à rescanner au lieu de l'image entière. Les navigateurs ou autres écrans qui ne prennent pas en charge les GIF animés n'affichent généralement que la première image.
La taille et la qualité des couleurs des fichiers GIF animés peuvent varier considérablement en fonction de l'application utilisée pour les créer. Les stratégies de minimisation de la taille du fichier comprennent l'utilisation d'une table de couleurs globale commune pour toutes les images (plutôt qu'une table de couleurs locale complète pour chaque image) et la minimisation du nombre de pixels couverts dans les images successives (de sorte que seuls les pixels qui changent d'une image à l'autre suivant sont inclus dans ce dernier cadre). Des techniques plus avancées impliquent la modification des séquences de couleurs pour mieux correspondre au dictionnaire LZW existant, une forme de compression avec perte . Le simple fait de regrouper une série d'images d'images indépendantes dans une animation composite a tendance à produire des fichiers de grande taille. Des outils sont disponibles pour minimiser la taille du fichier en fonction d'un GIF existant.
Métadonnées
Les métadonnées peuvent être stockées dans des fichiers GIF sous la forme d'un bloc de commentaires, d'un bloc de texte brut ou d'un bloc d'extension d'application spécifique à l'application. Plusieurs éditeurs graphiques utilisent des blocs d'extension d'application non officiels pour inclure les données utilisées pour générer l'image, afin qu'elle puisse être récupérée pour une édition ultérieure.
Toutes ces méthodes nécessitent techniquement que les métadonnées soient divisées en sous-blocs afin que les applications puissent naviguer dans le bloc de métadonnées sans connaître sa structure interne.
La norme de métadonnées Extensible Metadata Platform (XMP) a introduit un bloc d'extension d'application "XMP Data" non officiel mais désormais répandu pour inclure des données XMP dans des fichiers GIF. Étant donné que les données XMP sont codées en UTF-8 sans caractères NUL, il n'y a pas d'octets 0 dans les données. Plutôt que de diviser les données en sous-blocs formels, le bloc d'extension se termine par une "remorque magique" qui achemine toute application traitant les données comme des sous-blocs vers un octet 0 final qui termine la chaîne de sous-blocs.
Application des brevets Unisys et LZW
En 1977 et 1978, Jacob Ziv et Abraham Lempel ont publié une paire d'articles sur une nouvelle classe d'algorithmes de compression de données sans perte, désormais appelés collectivement LZ77 et LZ78 . En 1983, Terry Welch a développé une variante rapide de LZ78 qui a été nommée Lempel – Ziv – Welch (LZW).
Welch a déposé une demande de brevet pour la méthode LZW en juin 1983. Le brevet résultant, US4558302, accordé en décembre 1985, a été attribué à Sperry Corporation qui a ensuite fusionné avec Burroughs Corporation en 1986 et a formé Unisys . D'autres brevets ont été obtenus au Royaume-Uni, en France, en Allemagne, en Italie, au Japon et au Canada.
En plus des brevets ci-dessus, le brevet de 1983 de Welch comprend également des citations de plusieurs autres brevets qui l'ont influencé, notamment :
- deux brevets japonais de 1980 de Jun Kanatsu de NEC ,
- Brevet américain 4 021 782 (1974) de John S. Hoerning,
- Brevet américain 4 366 551 (1977) de Klaus E. Holtz, et
- un brevet allemand de 1981 de Karl Eckhart Heinz.
En juin 1984, un article de Welch a été publié dans le magazine IEEE qui décrit publiquement la technique LZW pour la première fois. LZW est devenu une technique de compression de données populaire et, lorsque le brevet a été accordé, Unisys a conclu des accords de licence avec plus d'une centaine d'entreprises.
La popularité de LZW a conduit CompuServe à le choisir comme technique de compression pour leur version de GIF, développée en 1987. À l'époque, CompuServe n'était pas au courant du brevet. Unisys a appris que la version de GIF utilisait la technique de compression LZW et a entamé des négociations de licence avec CompuServe en janvier 1993. L'accord ultérieur a été annoncé le 24 décembre 1994. Unisys a déclaré qu'elle s'attendait à ce que toutes les principales sociétés commerciales de services d'information en ligne employant le Brevet LZW pour licencier la technologie d'Unisys à un taux raisonnable, mais qu'ils n'exigeraient pas de licence, ni de frais à payer, pour les applications basées sur GIF non commerciales et à but non lucratif, y compris celles à utiliser sur les services en ligne .
Suite à cette annonce, CompuServe et Unisys ont été largement condamnés, et de nombreux développeurs de logiciels ont menacé de cesser d'utiliser GIF. Le format PNG (voir ci-dessous) a été développé en 1995 en remplacement prévu. Cependant, obtenir le soutien des fabricants de navigateurs Web et d'autres logiciels pour le format PNG s'est avéré difficile et il n'a pas été possible de remplacer le GIF, bien que le PNG ait progressivement gagné en popularité. Par conséquent, des variantes GIF sans compression LZW ont été développées. Par exemple, la bibliothèque libungif, basée sur le giflib d' Eric S. Raymond , permet la création de GIF qui suivent le format de données mais évitent les fonctions de compression, évitant ainsi l'utilisation du brevet Unisys LZW. Un article du Dr Dobb de 2001 décrivait une autre alternative à la compression LZW, basée sur les racines carrées.
En août 1999, Unisys a modifié les détails de sa pratique en matière de licences, annonçant la possibilité pour les propriétaires de certains sites Web non commerciaux et privés d'obtenir des licences moyennant le paiement d'un droit de licence unique de 5 000 $ ou 7 500 $. De telles licences n'étaient pas requises pour les propriétaires de sites Web ou d'autres utilisateurs de GIF qui avaient utilisé un logiciel sous licence pour générer des GIF. Néanmoins, Unisys a été victime de milliers d'attaques en ligne et d'e-mails abusifs d'utilisateurs pensant qu'ils allaient être facturés 5 000 $ ou poursuivis pour avoir utilisé des GIF sur leurs sites Web. Malgré l'octroi de licences gratuites à des centaines d'organisations à but non lucratif, d'écoles et de gouvernements, Unisys a été totalement incapable de générer une bonne publicité et a continué à être condamné par des individus et des organisations telles que la League for Programming Freedom qui a lancé la campagne "Burn All GIFs". en 1999.
Le brevet américain LZW a expiré le 20 juin 2003. Les brevets homologues au Royaume-Uni, en France, en Allemagne et en Italie ont expiré le 18 juin 2004, les brevets japonais ont expiré le 20 juin 2004 et le brevet canadien a expiré le 7 juillet 2004. Par conséquent , alors qu'Unisys détient d'autres brevets et demandes de brevets relatifs à des améliorations de la technique LZW, LZW lui-même (et par conséquent GIF) est libre d'utilisation depuis juillet 2004.
Alternatives
PNG
Portable Network Graphics (PNG) a été conçu pour remplacer GIF afin d'éviter la violation du brevet d'Unisys sur la technique de compression LZW. PNG offre une meilleure compression et plus de fonctionnalités que GIF, l'animation étant la seule exception significative. PNG est plus approprié que GIF dans les cas où une imagerie en couleurs vraies et une transparence alpha sont requises.
Bien que la prise en charge du format PNG soit lente, les nouveaux navigateurs Web prennent en charge le format PNG. Les anciennes versions d' Internet Explorer ne prennent pas en charge toutes les fonctionnalités de PNG. Les versions 6 et antérieures ne prennent pas en charge la transparence du canal alpha sans utiliser les extensions HTML spécifiques à Microsoft. La correction gamma des images PNG n'était pas prise en charge avant la version 8, et l'affichage de ces images dans les versions antérieures peut avoir la mauvaise teinte.
Pour des données d'image 8 bits (ou inférieures) identiques, les fichiers PNG sont généralement plus petits que les GIF équivalents, en raison des techniques de compression plus efficaces utilisées dans l'encodage PNG. La prise en charge complète de GIF est compliquée principalement par la structure de canevas complexe qu'elle permet, bien que ce soit ce qui active les fonctionnalités d'animation compactes.
Formats d'animations
Les vidéos résolvent de nombreux problèmes que les GIF présentent lors d'une utilisation courante sur le Web. Ils incluent des tailles de fichiers considérablement plus petites , la possibilité de dépasser la restriction de couleur 8 bits et une meilleure gestion et compression des images grâce aux codecs . La prise en charge pratiquement universelle du format GIF dans les navigateurs Web et l'absence de prise en charge officielle de la vidéo dans la norme HTML ont permis à GIF de prendre de l'importance dans le but d'afficher de courts fichiers de type vidéo sur le Web.
- MNG ("Multiple-image Network Graphics") a été développé à l'origine comme une solution basée sur PNG pour les animations. MNG a atteint la version 1.0 en 2001, mais peu d'applications la supportent.
- APNG ("Animated Portable Network Graphics") a été proposé par Mozilla en 2006. APNG est une extension du format PNG comme alternative au format MNG. APNG est pris en charge par la plupart des navigateurs à partir de 2019. APNG offre la possibilité d'animer des fichiers PNG, tout en conservant la rétrocompatibilité dans les décodeurs qui ne peuvent pas comprendre le bloc d'animation (contrairement à MNG). Les décodeurs plus anciens rendront simplement la première image de l'animation.
- Le groupe PNG a officiellement rejeté APNG en tant qu'extension officielle le 20 avril 2007.
- Il y a eu plusieurs propositions ultérieures pour un format graphique animé simple basé sur PNG utilisant plusieurs approches différentes. Néanmoins, APNG est toujours en cours de développement par Mozilla et est pris en charge dans Firefox 3.0 tandis que le support MNG a été abandonné. APNG est actuellement pris en charge par tous les principaux navigateurs Web, y compris Chrome (depuis la version 59.0), Opera, Firefox et Edge.
- Objets Adobe Flash intégrés et
- Les fichiers MPEG étaient utilisés sur certains sites Web pour afficher une vidéo simple, mais nécessitaient l'utilisation d'un plug-in de navigateur supplémentaire.
- D'autres options pour l'animation Web incluent la diffusion d'images individuelles à l'aide d' AJAX , ou
- animation d'images SVG ("Scalable vector graphics") à l'aide de JavaScript ou SMIL ("Synchronized Multimedia Integration Language").
- Avec l'introduction de la prise en charge généralisée de la balise vidéo HTML5 (
<video>
) dans la plupart des navigateurs Web, certains sites Web utilisent une version en boucle de la balise vidéo générée par les fonctions JavaScript . Cela donne l'apparence d'un GIF, mais avec les avantages de taille et de vitesse de la vidéo compressée.
- Des exemples notables sont Gfycat et Imgur et leur métaformat GIFV, qui est en réalité une balise vidéo lisant une vidéo compressée MP4 ou WebM en boucle.
- HEIF ("High Efficiency Image File Format") est un format de fichier image, finalisé en 2015, qui utilise un algorithme de compression avec perte par transformée en cosinus discrète (DCT) basé sur le format vidéo HEVC , et lié au format d'image JPEG . Contrairement au JPEG, HEIF prend en charge l'animation.
- Comparé au format GIF, qui manque de compression DCT, HEIF permet une compression nettement plus efficace. HEIF stocke plus d'informations et produit des images animées de meilleure qualité à une petite fraction de la taille d'un GIF équivalent.
- VP9 ne prend en charge que la composition alpha avec un sous-échantillonnage de chrominance 4:2:0 au format pixel YUV A420, ce qui peut ne pas convenir aux GIF qui combinent la transparence avec des graphiques vectoriels pixellisés avec des détails de couleur fins.
- Le codec AV1 peut également être utilisé soit comme une vidéo soit comme une image séquencée.
Les usages
En avril 2014, 4chan a ajouté la prise en charge des vidéos WebM silencieuses d'une taille inférieure à 3 Mo et d'une durée de 2 minutes, et en octobre 2014, Imgur a commencé à convertir tous les fichiers GIF téléchargés sur le site en vidéo et à donner le lien vers le lecteur HTML le apparence d'un fichier réel avec une .gifv
extension.
En janvier 2016, Telegram a commencé à réencoder tous les GIF en vidéos MPEG-4 qui "nécessitent jusqu'à 95 % d'espace disque en moins pour la même qualité d'image".
Voir également
- AVIF
- Cinemagraph , une photographie partiellement animée souvent en GIF
- Comparaison des formats de fichiers graphiques
- Comparaison des moteurs de mise en page (graphiques)
- GIF art , une forme d' art numérique associée au GIF
- GIFBuilder , premier programme de création de GIF animés
- GNU plotutils (prend en charge le pseudo-GIF, qui utilise le codage de longueur d'exécution plutôt que LZW)
- Microsoft GIF Animator , programme historique pour créer des GIF animés simples
- Brevet logiciel
Références
Liens externes
- Le projet GIFLIB
- spec-gif89a.txt Spécification GIF 89a sur w3.org
- Spécification GIF 89a reformatée en HTML
- LZW et GIF expliqués
- GIFs animés : un documentaire de six minutes produit par Off Book (web série)
- GifCities (le moteur de recherche de GIF animés GeoCities)