GIF -GIF

GIF
Terre en rotation (grande).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 ; Il y a 35 ans ( 1987-06-15 )
Dernière version
89a
1989 ; il y a 33 ans ( 1989 )
Type de format format d'image bitmap sans perte
Site Internet www .w3 .org /Graphics /GIF /spec-gif89a .txt

Le Graphics Interchange Format ( GIF ; / ɪ 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

Une image humoristique annonçant le lancement d'un compte Tumblr pour la Maison Blanche suggère de prononcer GIF avec un g dur .

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 / ɪ 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 / ɪ 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 / ɪ 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 , ɪ f / . Le New Oxford American Dictionary n'a donné que / ɪ f / dans sa deuxième édition mais l'a mis à jour en / ɪ 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

Un exemple d'image GIF enregistrée avec une palette Web sécurisée et tramée à l'aide de la méthode Floyd-Steinberg . En raison du nombre réduit de couleurs dans l'image, il y a des problèmes d'affichage.

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.

Un GIF animé illustrant une technique pour afficher plus que la limite typique de 256 couleurs

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).

Exemple d'image (agrandie), taille réelle 3 pixels de large sur 5 de haut
Les octets D h à 30C h dans l'exemple définissent une palette de 256 couleurs.

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.

Tableau d'exemples de valeurs d'image GIF
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
00 00 00
R (rouge) G (vert) B (bleu)
0 0 0
Tableau des couleurs globales, couleur #0 : #000000, noir
dix 80 00 00
R (rouge) G (vert) B (bleu)
128 0 0
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
R (rouge) G (vert) B (bleu)
255 255 255
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.

Cartographie réversible
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 :

Le code entrant se trouve-t-il dans le tableau ?
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é

Un GIF non compressé 46 × 46 avec des symboles 7 bits (128 couleurs, codes 8 bits). Cliquez sur l'image pour une explication du code.

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.

Exemple de compression d'un fichier GIF
Code pixels Remarques
Non.
N je
Évaluer
N je + 256
Longueur
(morceaux)
Ce code
N 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é

GIF peut être utilisé pour afficher une animation, comme dans cette image du berceau de Newton .
Une animation GIF composée de deux photos, l'une se transformant en l'autre

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.

Structure du GIF
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
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
(divisé en sections pour faciliter la lecture)
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 :

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.
  • WebM et
  • WebP est en cours de développement et est pris en charge par certains navigateurs Web.
  • 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.
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.
  • 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 .gifvextension.

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

Références

Liens externes