Come funziona la gif

GIF

L'accessibilità di questo articolo è in questione . Una discussione pertinente può essere trovata nella pagina di discussione. (dicembre 2024)

Famiglia di formati di file immagine bitmap

Per altri usi, vedere GIF (disambigua).

Il formato di interscambio grafico ( GIF ; GHIF o JIF (vedi § Pronuncia) è un formato bitmapimage sviluppato da un team del fornitore di servizi online CompuServe guidato dallo scienziato informatico americano Steve Wilhite e rilasciato il 15 giugno 1987. [1]

Il formato può contenere fino a 8 bit per pixel, consentendo a una singola immagine di fare riferimento alla propria tavolozza di un massimo di 256 colori diversi scelti dallo spazio colore RGB a 24 bit. Può anche rappresentare più immagini in un file, che può essere utilizzato per le animazioni, e consente Una tavolozza separata di un massimo di 256 colori per ogni cornice. Queste limitazioni della tavolozza rendono le GIF meno adatte per la riproduzione di fotografie a colori e altre immagini con sfumature di colore, ma adatte per immagini più semplici come grafica o loghi con aree di colore a tinta unita.

Le immagini GIF vengono compresse utilizzando la tecnica di compressione dei dati senza perdita di dati Lempel-Ziv-Welch (LZW) per ridurre le dimensioni del file senza degradare la qualità visiva.

Mentre un tempo era ampiamente utilizzato sul World Wide Web a causa della sua ampia implementazione e portabilità tra applicazioni e sistemi operativi, l'uso del formato è diminuito per motivi di spazio e qualità. spesso sostituiti con formati video come il formato di file MP4. Queste sostituzioni, a loro volta, sono talvolta denominate "GIF" nonostante non abbiano alcuna relazione con il formato di file originale. [3]

Storia

Ulteriori informazioni: § Applicazione dei brevetti Unisys e LZW

CompuServe introdusse GIF il 15 giugno 1987 per fornire un formato di immagine a colori per le loro aree di download dei file. Questo ha sostituito il precedente formato di codifica run-length, che era solo in bianco e nero. GIF è diventato popolare perché utilizzava la compressione Lempel-Ziv-Welchdata. Poiché questo era più efficiente della codifica run-length utilizzata da PCX e MacPaint, le immagini abbastanza grandi potevano essere scaricate ragionevolmente rapidamente anche con modem lenti.

La versione originale di GIF si chiamava 87a. [1] Questa versione supportava già più immagini in un flusso.

Nel 1989, CompuServe rilasciò una versione migliorata, chiamata 89a, [2] Questa versione aggiunse:

  • il supporto per l'animazione ritarda la
  • memorizzazione dei
  • colori di sfondo trasparenti
  • dei metadati specifici dell'applicazione
  • consentendo le etichette di testo come testo (non incorporandole nella grafica dati). Poiché il controllo sui caratteri di visualizzazione è limitato, tuttavia, questa funzione viene utilizzata raramente.

Le due versioni possono essere distinte guardando i primi sei byte del file (il "numero magico" o firma), che, se interpretati come ASCII, leggono rispettivamente "GIF87a" o "GIF89a".

CompuServe ha incoraggiato l'adozione di GIF fornendo utilità di conversione scaricabili per molti computer. Entro il dicembre 1987, ad esempio, un utente Apple IIGS poteva visualizzare le immagini create su un Atari ST o un Commodore 64. [4] GIF è stato uno dei primi due formati di immagine comunemente usati sui siti Web, l'altro è l'XBM in bianco e nero. [5]

Nel settembre 1995 Netscape Navigator 2.0 ha aggiunto la possibilità di riprodurre in loop le GIF animate.

Sebbene GIF sia stato sviluppato da CompuServe, utilizzava l'algoritmo di compressione dei dati senza perdita di dati Lempel-Ziv-Welch (LZW) brevettato da Unisys nel 1985. Controversia su l'accordo di licenza tra Unisys e CompuServe nel 1994 ha stimolato lo sviluppo dello standard Portable Network Graphics (PNG). Nel 2004 sono scaduti tutti i brevetti relativi alla compressione proprietaria utilizzata per le GIF.

La funzione di memorizzazione di più immagini in un unico file, accompagnate da dati di controllo, è ampiamente utilizzata sul Web per produrre semplici animazioni.

La funzione opzionale di interlacciamento, che memorizza le linee di scansione delle immagini in modo tale che anche un'immagine parzialmente scaricata fosse in qualche modo riconoscibile, ha anche aiutato la popolarità delle GIF, [6] in quanto un utente poteva interrompere il download se non era ciò che era richiesto.

Nel maggio 2015 Facebook ha aggiunto il supporto per GIF. [7] [8] Nel gennaio 2018 Instagram ha anche aggiunto adesivi GIF alla modalità storia. [9]

Nel 2016 l'Internet Archive ha rilasciato una libreria ricercabile di GIF dal loro Archivio Geocities. [10] [11]

Terminologia

Come sostantivo, la parola GIF si trova nelle edizioni più recenti di molti dizionari. Nel 2012, l'ala americana della Oxford University Press ha riconosciuto anche GIF come verbo, che significa "creare un file GIF", come in "GIFing era il mezzo perfetto per condividere scene delle Olimpiadi estive". I lessicografi della stampa l'hanno votata come parola dell'anno, affermando che le GIF si sono evolute in "uno strumento con applicazioni serie, tra cui la ricerca e il giornalismo". [12] [13]

Pronuncia Articolo

principale: Pronuncia di GIF

La pronuncia della prima lettera di GIF è stata contestata dagli anni '90. Le pronunce più comuni in inglese sono (con una g morbida come in gin ) e (con una g dura come in dono ), che differisce nel fonema rappresentato dalla lettera G . I creatori del formato hanno pronunciato l'acronimo GIF come , con una g morbida , con Wilhite che affermava che intendeva che la pronuncia riecheggiasse deliberatamente il marchio americano di burro di arachidi Jif, e i dipendenti di CompuServe spesso scherzavano "gli sviluppatori esigenti scelgono GIF", una parodia degli spot televisivi di Jif. [14] Tuttavia, la parola è ampiamente pronunciata come , con una g dura , [15] e i sondaggi hanno generalmente dimostrato che questa pronuncia con la g dura è più diffusa. [16] [17]

Dictionary.com [18] cita entrambe le pronunce, indicandole come la pronuncia primaria, mentre il Cambridge Dictionary of American English [19] offre solo la pronuncia hard-g. Merriam-Webster's Il Collegiate Dictionary [20] e l'Oxford Dictionaries citano entrambe le pronunce, ma mettono prima la g dura: . [21] [22] [23] [24] Il New Oxford American Dictionary lo ha riportato solo nella sua seconda edizione [25], ma lo ha aggiornato nella terza edizione. [26]

Il disaccordo sulla pronuncia ha portato a un acceso dibattito su Internet. In occasione di ricevere un premio alla carriera alla cerimonia dei Webby Awards 2013, Wilhite ha pubblicamente rifiutato la pronuncia hard-g; [15] [27] [28] il suo discorso ha portato a più di 17.000 post su Twitter e dozzine di articoli di notizie. [29] Anche la Casa Bianca [15] e il programma televisivo Jeopardy! sono entrati nel dibattito nel 2013. [28] Nel febbraio 2020, The J.M. Smucker Company, proprietaria del marchio Jif, ha collaborato con il database di immagini animate e il motore di ricerca Giphy per rilasciare un barattolo di burro di arachidi "Jif vs. GIF" (con l'hashtag #JIFvsGIF) in edizione limitata che aveva un'etichetta che dichiarava umoristicamente che la pronuncia della g morbida si riferiva esclusivamente al burro di arachidi, e GIF da pronunciare esclusivamente con la pronuncia hard-g. [30]

Le

GIF sono adatte per line art con spigoli vivi con un numero limitato di colori, come i loghi. In questo modo si sfrutta la compressione senza perdita di dati del formato, che favorisce aree piatte di colore uniforme con bordi ben definiti. [31] Possono anche essere utilizzati per memorizzare dati sprite a basso colore per i giochi. [32] Le GIF possono essere utilizzate per piccole animazioni e clip video a bassa risoluzione o come reazioni nella messaggistica online usato per trasmettere emozioni e sentimenti invece di usare le parole. Sono popolari su piattaforme di social media come Tumblr, Facebook e Twitter. [34]

Formato file

Concettualmente, un file GIF descrive un'area grafica di dimensioni fisse (la "schermata logica") popolata con zero o più "immagini". Molti file GIF hanno una singola immagine che riempie l'intero schermo logico. Altri dividono lo schermo logico in sottoimmagini separate. Le immagini possono anche funzionare come fotogrammi di animazione in un file GIF animato, ma anche in questo caso non è necessario che riempiano l'intero schermo logico.

I file GIF iniziano con un'intestazione a lunghezza fissa ("GIF87a" o "GIF89a") che fornisce la versione, seguita da un descrittore logico dello schermo a lunghezza fissa che fornisce le dimensioni dei pixel e altre caratteristiche dello schermo logico. Il descrittore dello schermo può anche specificare la presenza e la dimensione di una tavola cromatica globale (GCT), che segue successivo, se presente.

Successivamente, il file viene diviso in segmenti dei seguenti tipi, ciascuno introdotto da un sentinella a 1 byte:

  • Un'immagine (introdotta da 0x2C, una virgola ASCII )
  • Un blocco di estensione (introdotto da 0x21, un punto esclamativo ASCII )
  • Il trailer (un singolo byte di valore 0x3B, un punto e virgola ASCII ), che dovrebbe essere l'ultimo byte del file.

Un'immagine inizia con un descrittore di immagine a lunghezza fissa, che può specificare la presenza e le dimensioni di una tabella colori locale (che segue, se presente). Seguono i dati dell'immagine: un byte che fornisce la larghezza in bit dei simboli non codificati (che deve essere larga almeno 2 bit, anche per le immagini bicolore), seguito da una serie di sottoblocchi contenenti i dati codificati in LZW.

I blocchi di estensione (blocchi che "estendono" la definizione 87a tramite un meccanismo già definito nella specifica 87a) sono costituiti dal sentinel, un byte aggiuntivo che specifica il tipo di estensione e una serie di sottoblocchi con i dati di estensione. I blocchi di estensione che modificano un'immagine (come l'estensione del controllo grafico che specifica il tempo di ritardo dell'animazione opzionale e il colore di sfondo trasparente opzionale) devono precedere immediatamente il segmento con l'immagine a cui si riferiscono.

Ogni sottoblocco inizia con un byte che fornisce il numero di byte di dati successivi nel sottoblocco (da 1 a 255). La serie di sottoblocchi è terminata da un sottoblocco vuoto (a 0 byte).

Questa struttura consente di analizzare il file anche se non tutte le parti sono comprese. Una GIF contrassegnata con 87a può contenere blocchi di estensione; L'intento è che un decoder possa leggere e visualizzare il file senza le caratteristiche coperte dalle estensioni che non comprende.

I dettagli completi del formato del file sono trattati nella specifica GIF. [2]

Tavolozze

GIF è basato su tavolozze: i colori utilizzati in un'immagine (un fotogramma) nel file i valori RGB sono definiti in una tabella della tavolozza che può contenere fino a 256 voci e i dati per l'immagine si riferiscono ai colori in base ai loro indici (0-255) nella tabella della tavolozza. Le definizioni dei colori nella tavolozza possono essere ricavate da uno spazio colore di milioni di sfumature (2 24 tonalità, 8 bit per ogni primario), ma il numero massimo di colori che un fotogramma può utilizzare è 256. Questa limitazione era ragionevole quando è stato sviluppato GIF, perché l'hardware in grado di visualizzare più di 256 colori contemporaneamente era raro. Grafica semplice, disegni al tratto, cartoni animati e fotografie in scala di grigi richiedono in genere meno di 256 colori.

Ogni fotogramma può designare un indice come un "colore di sfondo trasparente": ogni pixel assegnato a questo indice assume il colore del pixel nella stessa posizione rispetto allo sfondo, che potrebbe essere stato determinato da un precedente fotogramma di animazione.

Molte tecniche, chiamate collettivamente dithering, sono stati sviluppati per approssimare una gamma più ampia di colori con una piccola tavolozza di colori utilizzando pixel di due o più colori per approssimare i colori intermedi. Queste tecniche sacrificano la risoluzione spaziale per approssimare una risoluzione del colore più profonda. Sebbene non faccia parte della specifica GIF, il dithering può essere utilizzato nelle immagini successivamente codificate come immagini GIF. Questa spesso non è una soluzione ideale per le immagini GIF, sia perché la perdita di risoluzione spaziale in genere rende un'immagine sfocata sullo schermo, sia perché i modelli di dithering spesso interferiscono con la comprimibilità dei dati dell'immagine, andando contro lo scopo principale della GIF.

Agli albori dei browser web grafici [ quando? ] , le schede grafiche con buffer a 8 bit (che consentivano solo 256 colori) erano comuni ed era abbastanza comune creare immagini GIF utilizzando la tavolozza websafe. [ secondo chi? ] Questo garantiva Display prevedibile, ma fortemente limitata la scelta dei colori. Quando il colore a 24 bit è diventato la norma, le tavolozze potevano invece essere popolate con i colori ottimali per le singole immagini.

Una tavola dei colori piccola può essere sufficiente per le immagini di piccole dimensioni e mantenere la tabella dei colori piccola consente di scaricare il file più velocemente. Entrambe le specifiche 87a e 89a consentono tavole di colori di 2 n colori per qualsiasi n da 1 a 8. La maggior parte delle applicazioni grafiche leggerà e visualizzerà immagini GIF con una qualsiasi di queste dimensioni di tabella; Ma alcuni non supportano tutte le dimensioni durante la creazione di immagini. Le tabelle da 2, 16 e 256 colori sono ampiamente supportate.

Sebbene

la

GIF non venga quasi mai utilizzata per le immagini a colori reali, è possibile farlo. [35] [36] Un'immagine GIF può includere più blocchi di immagini, ognuno dei quali può avere la propria tavolozza di 256 colori, e i blocchi possono essere affiancati per creare un'immagine completa. In alternativa, la specifica GIF89a ha introdotto l'idea di un colore "trasparente" in cui ogni blocco di immagini può includere la propria tavolozza di 255 colori visibili più un colore trasparente. È possibile creare un'immagine completa sovrapponendo blocchi immagine con la parte visibile di ciascun livello che viene visualizzata attraverso le parti trasparenti dei livelli superiori.

Per eseguire il rendering di un'immagine a colori come GIF, l'immagine originale deve essere suddivisa in regioni più piccole con non più di 255 o 256 colori diversi. Ciascuna di queste regioni viene quindi memorizzata come un blocco immagine separato con la propria tavolozza locale e quando i blocchi immagine vengono visualizzati insieme (mediante affiancamento o stratificazione di blocchi immagine parzialmente trasparenti), viene visualizzata l'immagine completa a colori. Ad esempio, suddividendo un'immagine in riquadri di 16 x 16 pixel (256 pixel in totale) si garantisce che nessun riquadro abbia più del limite della tavolozza locale di 256 colori, anche se possono essere utilizzate tessere più grandi e colori simili fusi con conseguente perdita di informazioni sul colore. [35]

Poiché ogni blocco immagine può avere la propria tavola dei colori locale, un file GIF con molti blocchi immagine può essere molto grande, limitando l'utilità delle GIF a colori. [36] Inoltre, non tutti i programmi di rendering GIF gestiscono correttamente le immagini affiancate o stratificate. Molti programmi di rendering interpretano le tessere o i livelli come fotogrammi di animazione e li visualizzano in sequenza come un'animazione [35] con la maggior parte dei browser web che visualizzano automaticamente i fotogrammi con un tempo di ritardo di 0,1 secondi o più. [37] [38] [ fonte migliore necessaria ]

Esempio di file GIF

Microsoft Paint salva una piccola immagine in bianco e nero come il seguente file GIF (illustrato ingrandito).
Paint non fa un uso ottimale delle GIF; a causa della tavola dei colori inutilmente grande (che memorizza ben 256 colori invece dei 2 utilizzati) e della larghezza del simbolo, questo file GIF non è una rappresentazione efficiente dell'immagine da 15 pixel.
Sebbene il blocco Estensione controllo grafico dichiari che l'indice di colore 16 (esadecimale 10) è trasparente, tale indice non viene utilizzato nell'immagine. Gli unici indici di colore che appaiono nei dati dell'immagine sono i decimali 40 e 255, che la Tavola colori globale mappa rispettivamente in bianco e nero.

Immagine di esempio (ingrandita), dimensioni reali 3 pixel di larghezza per 5 di altezza

I numeri esadecimali nelle tabelle seguenti sono in ordine di byte little-endian, come prescritto dalla specifica del formato.

Significato logico dello schermo logica dello schermo di controllo grafico GCE immagine logica <td colspan="2"> Inizio del primo sottoblocco di dati, specificando 11 byte di dati codificati da seguire 321 00 51 FC 1B 28 70 A0 C1 83 01 01 <dati dell'immagine> <td colspan="2"> 11 byte di dati dell'immagine, vedere il campo 320 32C 00 0 <td colspan="2"> Sottoblocco dati finale, specificando no seguenti byte di dati (e la fine dell'immagine)
Byte # (esadecimale) Testo esadecimale o valore
0 47 49 46 38 39 61 GIF89a Intestazione
Descrittore
6 03 00 3 Larghezza
8 05 00 5 Altezza logica dello schermo
A F7 Segue GCT per 256 colori con risoluzione 3 × 8 bit/primario, i 3 bit più bassi rappresentano la profondità di bit meno 1, il bit vero più alto significa che il GCT è presente
B 00 0 Colore di sfondo: indice #0; #000000 nero
C 00 0 Rapporto d'aspetto pixel predefinito, 0:0
Tabella dei colori globale
D 00 00 00
R (rosso) G (verde) B (blu)
0 0 0
Tabella dei colori globale, colore #0: #000000, nero
10 80 00
00 R (rosso) G (verde) B (blu)
128 0 0 Tabella
dei colori globale, colore #1: bit trasparente, non utilizzato nell'immagine
... ... ... La tabella dei colori globale si estende a 30A
30A FF FF
FF R (rosso) G (verde) B (blu)
255 255 255
Tabella dei colori globale, colore #255: #ffffff, bianco
Estensione del controllo grafico
30D 21 Un blocco di estensione (introdotto da un punto esclamativo ASCII )
30E F9 Un'estensione
30F 04 4 Quantità di dati GCE, 4 byte
310 01 Colore di sfondo trasparente; questo è un campo di bit, il bit più basso indica la trasparenza
311 00 00 Ritardo per l'animazione in centesimi di secondo; non utilizzato
313 10 16 Numero di colore dei pixel trasparenti in GCT
314 00 Fine del blocco
Descrittore
315 2C Un descrittore immagine (introdotto da 0x2C, una virgola ASCII)
316 00 00 00 00 (0, 0) Posizione dell'angolo nord-ovest dell'immagine nella schermata
31A 03 00 05 00 (3, 5) Larghezza e altezza dell'immagine in pixel
31E 00 0 Bit della tabella dei colori locali, 0 significa nessuno
Dati immagine
31F 08 8 Inizio dell'immagine, dimensione minima del codice LZW
320 0B 11
Trailer
32D 3B Indicatore di blocco di terminazione del file (un punto e virgola ASCII)

Codifica dell'immagine

I dati dei pixel dell'immagine, scansionati orizzontalmente dall'alto a sinistra, vengono convertiti dalla codifica LZW in codici che vengono poi mappati in byte per la memorizzazione nel file. I codici pixel in genere non corrispondono alla dimensione di 8 bit dei byte, quindi i codici sono impacchettati in byte da uno schema "little-Endian": il bit meno significativo del primo codice è memorizzato nel bit meno significativo del primo byte, i bit di ordine superiore del codice in bit di ordine superiore del byte, riversarsi nei bit di ordine inferiore del byte successivo, se necessario. Ogni codice successivo viene memorizzato a partire dal bit meno significativo non già utilizzato.

Questo flusso di byte viene memorizzato nel file come una serie di "sottoblocchi". Ogni sottoblocco ha una lunghezza massima di 255 byte ed è preceduto da un byte che indica il numero di byte di dati nel sottoblocco. La serie di sottoblocchi è terminata da un sottoblocco vuoto (un singolo byte 0, che indica un sottoblocco con 0 byte di dati).

Per l'immagine di esempio sopra, la mappatura reversibile tra codici a 9 bit e byte è mostrata di seguito.

codice a 9 bit Byte
Binario Esadecimale Binario Esadecimale
100 1 00000000 00000000 00
028 00 0101000 01010001 51
0FF 011 111111 11111100 FC
103 1000 00011 00011011 1B
102 10000 0010 00101000 28
103 100000 011 01110000 70
106 1000001 10 10100000 A0
107 10000011 1 11000001 C1
10000011 83
101 1 00000001 00000001 01
00000001 01

È evidente una leggera compressione: i colori dei pixel definiti inizialmente da 15 byte sono esattamente rappresentati da 12 byte di codice inclusi i codici di controllo. Di seguito è illustrato il processo di codifica che produce i codici a 9 bit. Una stringa locale accumula i numeri di colore dei pixel dalla tavolozza, senza alcuna azione di output, purché la stringa locale possa essere trovata in una tabella di codice. C'è un trattamento speciale dei primi due pixel che arrivano prima che la tabella cresca dalla sua dimensione iniziale con l'aggiunta di stringhe. Dopo Ogni codice di output, la stringa locale viene inizializzata al colore pixel più recente (che non può essere incluso nel codice di output).

Tabella Stringa a 9 bit --> codice codice Azione

Per chiarezza, la tabella è mostrata sopra come costruita con stringhe di lunghezza crescente. Questo schema può funzionare, ma la tabella consuma una quantità imprevedibile di memoria. La memoria può essere risparmiata in pratica notando che ogni nuova stringa da memorizzare è costituita da una stringa precedentemente memorizzata aumentata di un carattere. È economico memorizzare in ogni indirizzo solo due parole: un indirizzo esistente e un carattere.

L'algoritmo LZW richiede una ricerca nella tabella per ogni pixel. Una ricerca lineare attraverso un massimo di 4096 indirizzi renderebbe la codifica lenta. In pratica i codici possono essere memorizzati in ordine di valore numerico; ciò consente di effettuare ogni ricerca da un SAR (Subsequent Approximation Register, come utilizzato in alcuni ADC), con solo magnitudo 12 Confronti. Per questa efficienza è necessaria una tabella aggiuntiva per convertire tra i codici e gli indirizzi di memoria effettivi; La manutenzione aggiuntiva della tabella è necessaria solo quando viene memorizzato un nuovo codice, che avviene a una velocità molto inferiore a quella dei pixel.

Decodifica delle immagini La

decodifica inizia con il mapping dei byte memorizzati a codici a 9 bit. Questi vengono decodificati per recuperare i colori dei pixel come mostrato di seguito. Una tabella identica a quella utilizzata nel codificatore viene creata aggiungendo stringhe in base a questa regola:

aggiungi stringa per il codice locale seguito dal primo byte di stringa per il codice in ingresso
No aggiungi stringa per il codice locale seguito dalla copia del proprio primo spostamento di byte
a 9 bit ----> Tabella locale Codice pixel codice --> stringa Colore tavolozza Azione 100h 000h | #0 Inizializza la tabella radice dei codici a 9 bit: | tavolozza : | Colori 0FFh | #255 100h | CLR 101H | fine 028h | #40 NERO Decodifica 1° pixel 0FFh 028h | Codice in entrata trovato nella tabella | #255 BIANCO - stringa di uscita da tavolo 102h | 28 FF - aggiungi al tavolo 103h 0FFh | Codice in entrata non trovato nella tabella 103h | FF FF - aggiungi al tavolo | - stringa di output dalla tabella | #255 BIANCO | #255 BIANCO 102h 103h | Codice in entrata trovato nella tabella | - stringa di output dalla tabella | #40 NERO | #255 BIANCO 104h | FF FF 28 - aggiungi al tavolo 103h 102h | Codice in entrata trovato nella tabella | - stringa di output dalla tabella | #255 BIANCO | #255 BIANCO 105h | 28 FF FF - aggiungi al tavolo 106h 103h | Codice in entrata non trovato nella tabella 106h | FF FF FF - Aggiungi al tavolo | - stringa di output dalla tabella | #255 BIANCO | #255 BIANCO | #255 BIANCO 107h 106h | Codice in entrata non trovato nella tabella 107h | FF FF FF FF - Aggiungi al tavolo | - stringa di output dalla tabella | #255 BIANCO | #255 BIANCO | #255 BIANCO | #255 BIANCO 101h |

Lunghezze di codice LZW

finali

È possibile utilizzare lunghezze di codice più brevi per tavolozze più piccole dei 256 colori dell'esempio. Se la tavolozza è di soli 64 colori (quindi gli indici di colore sono larghi 6 bit), i simboli possono variare da 0 a 63 e la larghezza del simbolo può essere presa come 6 bit, con codici a partire da 7 bit. Infatti, la larghezza del simbolo non deve necessariamente corrispondere alla dimensione della tavolozza: finché i valori decodificati sono sempre inferiori al numero di colori nella tavolozza, i simboli possono avere una larghezza compresa tra 2 e 8 e la dimensione della tavolozza con una potenza di 2 da 2 a 256. Ad esempio, se vengono utilizzati solo i primi quattro colori (valori da 0 a 3) della tavolozza, i simboli possono essere considerati larghi 2 bit con codici a partire da 3 bit.

Al contrario, la larghezza del simbolo potrebbe essere impostata su 8, anche se vengono utilizzati solo i valori 0 e 1; questi dati richiederebbero solo una tabella a due colori. Anche se non avrebbe senso codificare il file in questo modo, qualcosa di simile accade tipicamente per le immagini bicolore: la larghezza minima del simbolo è 2, anche se solo i valori Vengono utilizzati 0 e 1.

La tabella dei codici contiene inizialmente codici che sono un bit più lunghi della dimensione del simbolo per contenere i due codici speciali clr e end e i codici per le stringhe che vengono aggiunte durante il processo. Quando la tabella è piena, la lunghezza del codice aumenta per dare spazio a più stringhe, fino a un massimo di codice 4095 = FFF(hex). Man mano che il decodificatore crea la sua tabella, tiene traccia di questi aumenti della lunghezza del codice ed è in grado di decomprimere i byte in entrata di conseguenza.

GIF

non compressa

GIF non compressa 46×46 con simboli a 7 bit (128 colori, codici a 8 bit).
Clicca sull'immagine per una spiegazione del codice.

Il processo di codifica GIF può essere modificato per creare un file senza compressione LZW che sia ancora visualizzabile come immagine GIF. Questa tecnica è stata introdotta originariamente come un modo per evitare la violazione di brevetto. La GIF non compressa può anche essere un utile formato intermedio per un programmatore di grafica perché i singoli pixel sono accessibili per la lettura o la pittura. Un file GIF non compresso può essere convertito in un normale file GIF semplicemente passandolo attraverso un editor di immagini.

Il metodo di codifica modificato ignora la creazione della tabella LZW e genera solo i codici della tavolozza radice e i codici per CLEAR e STOP. Ciò produce una codifica più semplice (una corrispondenza 1 a 1 tra i valori del codice e i codici della tavolozza) ma sacrifica tutta la compressione: ogni pixel nell'immagine genera un codice di output che indica il suo indice di colore. Durante l'elaborazione di una GIF non compressa, a un decodificatore GIF standard non verrà impedito di scrivere stringhe nella sua tabella del dizionario, ma la larghezza del codice non deve mai aumentare poiché ciò innesca un diverso impacchettamento di bit in byte.

Se la larghezza del simbolo è n, i codici di larghezza n +1 cadono naturalmente in due blocchi: il più basso blocco di 2 n codici per la codifica di singoli simboli, e il blocco superiore di 2 n codici che verrà utilizzato dal decodificatore per sequenze di lunghezza maggiore di uno. Di quel blocco superiore, i primi due codici sono già stati presi: 2 n per CLEAR e 2 n + 1 per STOP. Al decoder deve anche essere impedito di utilizzare l'ultimo codice nel blocco superiore, 2 n +1 − 1, perché quando il decoder riempie quello slot, aumenterà la larghezza del codice. Quindi nel blocco superiore ci sono 2 n − 3 codici disponibili per il decoder che non attiveranno un aumento della larghezza del codice. Poiché il decodificatore è sempre un passo indietro nella gestione della tabella, non genera una voce di tabella alla ricezione del primo codice dal codificatore, ma ne genererà una per ogni codice successivo. In questo modo l'encoder può generare 2 n − 2 codici senza trigger un aumento della larghezza del codice. Pertanto, l'encoder deve emettere codici CLEAR extra a intervalli di 2 n − 2 codici o meno per far sì che il decoder ripristini il dizionario di codifica. Lo standard GIF consente di inserire tali codici CLEAR extra nei dati dell'immagine in qualsiasi momento. Il flusso di dati composito è partizionato in sottoblocchi che trasportano ciascuno da 1 a 255 byte.

Per l'immagine di esempio 3×5 precedente, i seguenti codici a 9 bit rappresentano "clear" (100) seguito dai pixel dell'immagine in ordine di scansione e da "stop" (101).

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

Dopo che i codici di cui sopra sono stati mappati in byte, il file non compresso differisce dal file compresso in questo modo:

Byte # (esadecimale) Testo esadecimale o valore Significato
320 14 20 20 byte dati immagine non compressi seguono
321 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335 00 0 Fine dei dati dell'immagine Esempio di

compressione

Il banale esempio di un'immagine di grandi dimensioni a tinta unita dimostra la compressione LZW a lunghezza variabile utilizzata nei file GIF.

Codice Pixel Note
No.N i ValueN i + 256 Lunghezza (bit) Questo codice N i AccumulatedN i (N i + 1)/2 Le relazioni che utilizzano N i si applicano solo ai pixel dello stesso colore fino a quando la tabella di codifica non è piena.
0 100h 9 Cancella tabella codici
1 FFh 1 1 Colore pixel in alto a sinistra scelto come indice più alto di una tavolozza di 256 colori
2 102h 2 3
3⋮255 103h⋮1FFh 3⋮255 6⋮32640 Ultimo codice a 9 bit
256⋮767 200h⋮3FFh 10 256⋮767 32896⋮294528 Ultimo codice a 10 bit
768⋮1791 400h⋮7FFh 11 768⋮1791 295296⋮1604736 Ultimo codice a 11 bit
1792⋮3839 800h⋮FFFh 12 1792⋮3839 1606528⋮7370880 Tabella codici full
FFFh 3839 Il codice massimo potrebbe ripetersi per più pixel dello stesso colore. La compressione complessiva dei dati si avvicina asintoticamente a 3839 × 8/12 = 2559+1/3
101h Fine dei dati dell'immagine

I valori di codice mostrati sono compressi in byte che vengono poi compressi in blocchi fino a 255 byte. Un blocco di dati immagine inizia con un byte che dichiara il numero di byte da seguire. L'ultimo blocco di dati per un'immagine è contrassegnato da un byte di lunghezza del blocco pari a zero.

Interlacciamento

La specifica GIF consente a ciascuna immagine all'interno della schermata logica di un file GIF di specificare che è interlacciata, ovvero che l'ordine delle linee raster nel suo blocco di dati non è sequenziale. Ciò consente una visualizzazione parziale dell'immagine che può essere riconosciuta prima che l'immagine completa venga dipinta.

Un'immagine interlacciata viene divisa dall'alto verso il basso in strisce alte 8 pixel e le righe dell'immagine vengono presentate nel seguente ordine:

  • Passaggio 1: Riga 0 (la linea più in alto) di ogni striscia.
  • Passaggio 2: Riga 4 di ogni striscia.
  • Passaggio 3: Linee 2 e 6 di ogni striscia.
  • Passaggio 4: linee 1, 3, 5 e 7 di ogni striscia.

I pixel all'interno di ogni riga non sono interlacciati, ma presentati consecutivamente da sinistra a destra. Come per le immagini non interlacciate, non vi è alcuna interruzione tra i dati di una riga e i dati della successiva. L'indicatore che un'immagine è interlacciata è un bit impostato nel blocco Descrittore immagine corrispondente.

Sebbene

la

GIF non sia stata progettata come mezzo di animazione, la sua capacità di memorizzare più immagini in un unico file suggeriva naturalmente l'utilizzo del formato per memorizzare i fotogrammi di una sequenza di animazione. Per facilitare la visualizzazione delle animazioni, la specifica GIF89a ha aggiunto la Graphic Control Extension (GCE), che consente di dipingere le immagini (fotogrammi) nel file con ritardi, formando un clip video. Ogni fotogramma in una GIF di animazione viene introdotto dal proprio GCE che specifica il ritardo di attesa dopo che il fotogramma è stato disegnato. Per impostazione predefinita, le informazioni globali all'inizio del file si applicano a tutti i fotogrammi. I dati sono orientati al flusso, quindi l'offset del file dell'inizio di ogni GCE dipende dalla lunghezza dei dati precedenti. All'interno di ogni fotogramma i dati dell'immagine codificati LZW sono disposti in sottoblocchi fino a 255 byte; La dimensione di ogni sottoblocco è dichiarata dal byte che lo precede.

Per impostazione predefinita, un'animazione visualizza la sequenza di fotogrammi una sola volta, interrompendosi quando viene visualizzato l'ultimo fotogramma. Per abilitare il ciclo di un'animazione, Netscape negli anni '90 ha utilizzato il blocco Application Extension (destinato a consentire ai fornitori di aggiungere informazioni specifiche dell'applicazione al file GIF) per implementare il Netscape Application Block (NAB). [39] Questo blocco, posizionato immediatamente prima della sequenza di fotogrammi dell'animazione, specifica il numero di volte in cui la sequenza di fotogrammi deve essere riprodotta (da 1 a 65535 volte) o che deve essere ripetuta continuamente (zero indica il ciclo per sempre). Il supporto per queste animazioni ripetute è apparso per la prima volta in Netscape Navigator versione 2.0 e poi si è diffuso ad altri browser. [40] La maggior parte dei browser ora riconosce e supporta NAB, sebbene non faccia strettamente parte della specifica GIF89a.

L'esempio seguente mostra la struttura del file di animazione Terra rotante (grande).gif mostrato (come miniatura) nell'infobox dell'articolo.

Byte # (esadecimale) Esadecimale Testo o valore Significato
0 47 49 46 38 39 61 GIF89a Descrittore logico dello schermo
6 90 01 400 Larghezza in pixel
8 90 01 400 Altezza in pixel
A F7 Segue GCT per 256 colori con risoluzione 3 × 8 bit/primario
B 00 0 Colore di sfondo: #000000, nero
C 00 0 Rapporto d'aspetto pixel predefinito, 0:0
D 00 Tabella colori globale
30D 21 Un blocco di estensione (introdotto da un punto esclamativo ASCII)
30E FF Estensione dell'applicazione
30F 0B 11 Dimensione del blocco, incluso il nome dell'applicazione e i byte di verifica (sempre 11)
310 4E 45 54 53 43 41 50 45 32 2E 30 NETSCAPE2.0 8 byte nome dell'applicazione più 3 byte di verifica
31B 03 3 Numero di byte nel seguente sottoblocco
31C 01 1 Indice del sottoblocco dati corrente (sempre 1 per il blocco NETSCAPE)
31D FF FF 65535 Numero di ripetizioni senza segno
31F 00 Fine della catena di sottoblocchi per il blocco Application Extension
320 21 Un blocco di estensione (introdotto da un punto esclamativo ASCII)
321 F9 Estensione di controllo grafico per il fotogramma #1
322 04 4 Numero di byte (4) nel sottoblocco attuale
323 04
000..... ... 001.. ...... 0. ....... 0
(suddiviso in sezioni per una lettura più semplice)
Riservato, 5 bit inferiori sono un campo
di bit Metodo di smaltimento 1: non smaltire
Nessun input dell'utente
Colore trasparente, 0 significa non dato
324 09 00 9 Ritardo fotogrammi: ritardo di 0,09 secondi prima di dipingere il fotogramma successivo
326 FF Indice di colore trasparente (non utilizzato in questo fotogramma)
327 00 Fine della catena di sottoblocchi per il blocco di estensione del controllo grafico
328 2C Un descrittore di immagine (introdotto da 0x2C, una virgola ASCII )
329 00 00 00 00 00 (0, 0) Posizione dell'angolo nord-ovest dell'immagine nella schermata logica: (0, 0)
32D 90 01 90 01 (400, 400) Larghezza e altezza del fotogramma: 400 × 400 pixel
331 00 0 Tabella dei colori locali: 0 significa nessuno e nessun interlacciamento
332 08 8 Dimensione minima del codice LZW per i dati immagine del fotogramma #1
333 FF 255 Numero di byte di dati immagine LZW in il seguente sottoblocco: 255 byte
334 ... <dati immagine> Dati immagine, 255 byte
433 FF 255 Numero di byte di dati immagine LZW nel sottoblocco successivo, 255 byte
434 ... <dati immagine> Dati immagine, 255 byte
Ripetere per i blocchi successivi
92C0 00 Fine della catena di sottoblocchi per questo fotogramma
92C1 21 Un blocco di estensione (introdotto da un punto esclamativo ASCII)
92C2 F9 Estensione del controllo grafico per il fotogramma #2
Ripeti per i fotogrammi successivi
EDABD 21 Un blocco di estensione (introdotto da un punto esclamativo ASCII)
EDABE F9 Estensione del controllo grafico per il fotogramma #44
Informazioni sull'immagine e dati per il fotogramma #44
F48F5 3B Trailer: Ultimo byte nel file, che segnala EOF

Il ritardo dell'animazione per ogni fotogramma è specificato nel GCE in centesimi di secondo. È possibile una certa economia di dati in cui un fotogramma deve riscrivere solo una parte dei pixel del display, perché il Descrittore immagine può definire un rettangolo più piccolo da riscansionare invece dell'intera immagine. I browser o altri display che non supportano le GIF animate in genere mostrano solo il primo fotogramma.

Le dimensioni e la qualità del colore dei file GIF animati possono variare in modo significativo a seconda dell'applicazione utilizzata per crearli. Le strategie per ridurre al minimo le dimensioni del file includono l'utilizzo di una tabella di colori globale comune per tutti i fotogrammi (anziché una tabella di colori locale completa per ogni fotogramma) e la riduzione al minimo il numero di pixel coperti nei fotogrammi successivi (in modo che solo i pixel che cambiano da un fotogramma all'altro siano inclusi in quest'ultimo fotogramma). Tecniche più avanzate comportano la modifica delle sequenze di colori in modo che corrispondano meglio al dizionario LZW esistente, una forma di compressione con perdita. Il semplice inserimento di una serie di immagini di fotogrammi indipendenti in un'animazione composita tende a produrre file di grandi dimensioni. Sono disponibili strumenti per ridurre al minimo le dimensioni del file in base a una GIF esistente.

Metadati

I metadati possono essere memorizzati in file GIF come blocco di commenti, blocco di testo normale o blocco di estensione dell'applicazione specifico dell'applicazione. Diversi editor grafici utilizzano blocchi di estensione dell'applicazione non ufficiali per includere i dati utilizzati per generare l'immagine, in modo che possa essere recuperata per ulteriori modifiche.

Tutti questi metodi richiedono tecnicamente che i metadati siano suddivisi in sottoblocchi in modo che le applicazioni possano navigare nel blocco di metadati senza conoscerne la struttura interna.

Lo standard di metadati XMP (Extensible Metadata Platform) ha introdotto un blocco di estensione dell'applicazione "XMP Data" non ufficiale ma ora diffuso per includere i dati XMP nei file GIF. [41] Poiché i dati XMP sono codificati utilizzando UTF-8 senza caratteri NUL, non ci sono byte 0 nei dati. Piuttosto che suddividere i dati in sottoblocchi formali, il blocco di estensione termina con un "magic trailer" che indirizza qualsiasi applicazione che tratta i dati come sottoblocchi a un byte 0 finale che termina la catena di sottoblocchi.

Nel

1977 e nel 1978, Jacob Ziv e Abraham Lempel pubblicarono un paio di articoli su una nuova classe di algoritmi di compressione dei dati senza perdita di dati, ora denominati collettivamente LZ77 e LZ78. Nel 1983, Terry Welch sviluppò una variante veloce dell'LZ78 che fu chiamata Lempel-Ziv-Welch (LZW). [42] [43]

Welch ha depositato una domanda di brevetto per il metodo LZW nel giugno 1983. Il brevetto risultante, US4558302, [44] concesso nel dicembre 1985, fu assegnato alla Sperry Corporation che successivamente si fuse con la Burroughs Corporation nel 1986 e formò Unisys. [42] Altri brevetti sono stati ottenuti nel Regno Unito, in Francia, in Germania, in Italia, in Giappone e in Canada.

Oltre ai brevetti di cui sopra, il brevetto di Welch del 1983 include anche citazioni a diversi altri brevetti che lo hanno influenzato, tra cui:

Nel giugno 1984, un articolo di Welch è stato pubblicato sulla rivista IEEE che descriveva pubblicamente la tecnica LZW per la prima volta. [49] LZW è diventata una tecnica di compressione dei dati popolare e, quando il brevetto è stato concesso, Unisys ha stipulato accordi di licenza con oltre un centinaio di aziende. [42] [50]

La popolarità di LZW ha portato CompuServe per sceglierlo come tecnica di compressione per la loro versione di GIF, sviluppata nel 1987. All'epoca, CompuServe non era a conoscenza del brevetto. [42] Unisys venne a conoscenza del fatto che la versione di GIF utilizzava la tecnica di compressione LZW e iniziò le trattative di licenza con CompuServe nel gennaio 1993. L'accordo successivo è stato annunciato il 24 dicembre 1994. [43] Unisys ha dichiarato di aspettarsi che tutte le principali società di servizi di informazione online commerciali che utilizzano il brevetto LZW concedano in licenza la tecnologia da Unisys a un prezzo ragionevole, ma che non richiederanno licenze, o tasse da pagare, per applicazioni non commerciali e senza scopo di lucro basate su GIF, comprese quelle per l'uso sui servizi on-line. [50]

A seguito di questo annuncio, c'è stata una diffusa condanna di CompuServe e Unisys e molti sviluppatori di software hanno minacciato di smettere di usare GIF. La Papua Nuova Guinea (vedi sotto) è stato sviluppato nel 1995 come sostituto previsto. [42] [43] [49] Tuttavia, ottenere il supporto dai produttori di browser Web e altri software per il formato PNG si è rivelato difficile e non è stato possibile sostituire GIF, sebbene PNG sia gradualmente aumentato in popolarità. [42] Pertanto, sono state sviluppate variazioni GIF senza compressione LZW. Ad esempio la libreria libungif, basata su giflib di Eric S. Raymond, consente la creazione di GIF che seguono il formato dei dati ma evitano le funzionalità di compressione, evitando così l'uso del brevetto Unisys LZW. [51] Un articolo del Dr. Dobb del 2001 descriveva un modo per ottenere una codifica compatibile con LZW senza violare i suoi brevetti. [52]

Nell'agosto 1999, Unisys ha cambiato i dettagli della sua pratica di licenza, annunciando l'opzione per i proprietari di alcuni siti web non commerciali e privati per ottenere licenze dietro pagamento di un canone di licenza una tantum di $ 5000 o $ 7500. [53] Tali licenze non erano richieste per i proprietari di siti Web o altri utenti GIF che avevano utilizzato software con licenza per generare GIF. Tuttavia, Unisys è stata sottoposta a migliaia di attacchi online ed e-mail abusive da parte di utenti che credevano di essere addebitati $ 5000 o citati in giudizio per l'utilizzo di GIF sui loro siti Web. [54] Nonostante abbia concesso licenze gratuite a centinaia di organizzazioni senza scopo di lucro, scuole e governi, Unisys non è stata in grado di generare alcuna buona pubblicità e ha continuato ad essere condannata da individui e organizzazioni come la League for Programming Freedom che ha avviato la campagna "Burn All GIFs" nel 1999. [55] [56]

Il brevetto LZW degli Stati Uniti è scaduto il 20 giugno 2003. [57] I brevetti omologhi nel Il Regno Unito, la Francia, la Germania e l'Italia sono scaduti il 18 giugno 2004, i brevetti giapponesi sono scaduti il 20 giugno 2004 e il brevetto canadese è scaduto il 7 luglio 2004. [57] Di conseguenza, mentre Unisys ha ulteriori brevetti e domande di brevetto relativi a miglioramenti della tecnica LZW, [57] LZW stesso (e di conseguenza GIF) sono stati liberi di essere utilizzati dal luglio 2004. [58]

Alternative PNG

Portable Network Graphics (PNG) è stato progettato come sostituto di GIF al fine di evitare la violazione del brevetto di Unisys sulla tecnica di compressione LZW. [42] PNG offre una compressione migliore e più funzionalità rispetto a GIF, [59] l'animazione è l'unica eccezione significativa. PNG è più adatto di GIF nei casi in cui sono richieste immagini a colori reali e trasparenza alfa.

Sebbene il supporto per il formato PNG è arrivato lentamente, i nuovi browser web supportano PNG. Le versioni precedenti di Internet Explorer non supportano tutte le funzionalità di PNG. Le versioni 6 e precedenti non supportano la trasparenza del canale alfa senza l'utilizzo di estensioni HTML specifiche di Microsoft. [60] La correzione gamma delle immagini PNG non era supportata prima della versione 8 e la visualizzazione di queste immagini nelle versioni precedenti potrebbe avere la tinta sbagliata. [61]

Per i dati immagine identici a 8 bit (o inferiori), i file PNG sono in genere più piccoli delle GIF equivalenti, a causa delle tecniche di compressione più efficienti utilizzate nella codifica PNG. [62] Il supporto completo per GIF è complicato principalmente dalla complessa struttura della tela che consente, sebbene questo sia ciò che consente le funzionalità di animazione compatta.

Formati di animazione

I video risolvono molti problemi che le GIF presentano attraverso l'uso comune sul web. Includono file di dimensioni drasticamente ridotte, La capacità di superare la limitazione del colore a 8 bit e una migliore gestione dei fotogrammi e compressione attraverso la codifica tra fotogrammi. Il supporto praticamente universale per il formato GIF nei browser Web e la mancanza di supporto ufficiale per i video nello standard HTML hanno causato l'ascesa alla ribalta di GIF allo scopo di visualizzare brevi file simili a video sul Web.

  • MNG ("Multiple-image Network Graphics") è stato originariamente sviluppato come soluzione basata su PNG per le animazioni. MNG ha raggiunto la versione 1.0 nel 2001, ma poche applicazioni la supportano.
  • APNG ("Animated Portable Network Graphics") è stato proposto da Mozilla nel 2006. APNG è un'estensione del formato PNG come alternativa al formato MNG. APNG è supportato dalla maggior parte dei browser a partire dal 2019. [63] APNG offre la possibilità di animare i file PNG, mantenendo la compatibilità con le versioni precedenti nei decodificatori che non sono in grado di comprendere il blocco di animazione (a differenza di MNG). I decoder più vecchi saranno semplicemente Eseguire il rendering del primo fotogramma dell'animazione.
Il gruppo PNG ha ufficialmente respinto APNG come estensione ufficiale il 20 aprile 2007. [64]
Ci sono state diverse proposte successive per un semplice formato grafico animato basato su PNG utilizzando diversi approcci. [65] Tuttavia, APNG è ancora in fase di sviluppo da Mozilla ed è supportato in Firefox 3.0 [66] [67] mentre il supporto MNG è stato abbandonato. [68] [69] APNG è attualmente supportato da tutti i principali browser web, tra cui Chrome (dalla versione 59.0), Opera, Firefox ed Edge.
  • Gli oggetti Adobe Flash incorporati e i file MPEG sono stati utilizzati su alcuni siti Web per visualizzare semplici video, ma hanno richiesto l'uso di un plug-in del browser aggiuntivo.
  • WebM e WebP sono in fase di sviluppo e sono supportati da alcuni browser Web. [70]
  • Altre opzioni per l'animazione web includono la pubblicazione di singoli fotogrammi utilizzando AJAX o l'animazione di immagini SVG ("Scalable vector graphics") utilizzando o SMIL ("Synchronized Multimedia Integration Language"). [71]
  • Con l'introduzione del supporto diffuso del tag video HTML () nella maggior parte dei browser Web, alcuni siti Web utilizzano una versione in loop del tag video generato dalle funzioni. Questo dà l'aspetto di una GIF, ma con i vantaggi delle dimensioni e della velocità del video compresso.
Esempi notevoli sono Gfycat e Imgur e il loro metaformato GIFV, che è in realtà un tag video che riproduce un video compresso MP4 o WebM in loop. [72]
Rispetto al formato GIF, che manca della compressione DCT, HEIF consente una compressione significativamente più efficiente. HEIF memorizza più informazioni e produce immagini animate di qualità superiore a una piccola frazione di un dimensioni equivalenti della GIF. [74]

Nell'aprile

2014, 4chan ha aggiunto il supporto per i video WebM silenziosi di dimensioni inferiori a 3 MB e 2 minuti di lunghezza, [76] [77] e nell'ottobre 2014, Imgur ha iniziato a convertire tutti i file GIF caricati sul sito in video H.264 e a dare al link al lettore HTML l'aspetto di un file reale con un'estensione. [78] [79]

Nel gennaio 2016, Telegram ha iniziato a ricodificare tutte le GIF in video MPEG-4 che "richiedono fino al 95% in meno di spazio su disco per la stessa qualità dell'immagine". [80]

Vedi anche

Riferimenti

  1. ^ a b c "Formato di interscambio grafico, versione 87a". W3C. 15 giugno 1987. Archiviato dall'originale il 22 Dicembre 2018. URL consultato il 13 ottobre 2012.
  2. ^ a b c "Formato di interscambio grafico, versione 89a". W3C. 31 luglio 1990. Archiviato dall'originale il 22 dicembre 2018. URL consultato il 6 marzo 2009.
  3. ^ Tiffany, Kaitlyn (7 ottobre 2022). "La GIF è sul letto di morte". L'Atlantico. URL consultato il 21 ottobre 2023.
  4. ^ "Arte online". Calcola!' s Applicazioni Apple . Dicembre 1987. p. 10. URL consultato il 14 settembre 2016.
  5. ^ Holdener III, Anthony (2008). Ajax: La Guida Definitiva: Applicazioni Interattive per il Web . O'Reilly Media. CODICE ISBN.
  6. ^ Furht, Borko (2008). Enciclopedia della multimedialità . Springer. CODICE ISBN.
  7. ^ McHugh, Molly (29 maggio 2015). "Puoi finalmente, davvero, davvero pubblicare GIF su Facebook". Cablato . Archiviato dall'originale il 30 maggio 2015. URL consultato il 29 maggio 2015.
  8. ^ Perez, Sarah (29 maggio 2015). "Facebook conferma che supporterà ufficialmente le GIF". Scricchiolio tecnico. Archiviato dall'originale il 30 maggio 2015. URL consultato il 29 maggio 2015.
  9. ^ "Introduzione agli adesivi GIF" . Instagram . 23 gennaio 2018. Archiviato dall'originale il 12 dicembre 2019. URL consultato il 19 settembre 2019.
  10. ^ Ghoshal, Abhimanyu (28 ottobre 2016). "Goditi 1,6 milioni di GIF gloriosamente old-school dell'era GeoCities". TNW | Condivisibili . URL consultato il 4 novembre 2024.
  11. ^ "GifCities". gifcities.org . URL consultato il 4 novembre 2024.
  12. ^ "Oxford Dictionaries USA Parola dell'anno 2012" . Blog di OxfordWords . Oxford Dizionari americani. 13 novembre 2012. Archiviato dall'originale il 3 agosto 2014. URL consultato il 1º maggio 2013.
  13. ^ Flood, Alison (27 aprile 2013). "Gif è la parola americana dell'anno? Questo è quello che io chiamo un caos onnicomprensivo". Blog di libri. Il Guardiano . Londra. Archiviato dall'originale il 1º dicembre 2016. URL consultato il 1º maggio 2013.
  14. ^ Olsen, Steve. "La pagina di pronuncia GIF". Archiviato dall'originale il 25 febbraio 2009. URL consultato il 6 marzo 2009.
  15. ^ a b c "L'inventore di Gif dice di ignorare i dizionari e di dire 'Jif'". Notizie della BBC . 22 maggio 2013. Archiviato dall'originale il 27 giugno 2018. URL consultato il 22 maggio 2013.
  16. ^ Buck, Stephanie (21 ottobre 2014). "Il 70% delle persone in tutto il mondo pronuncia GIF con un g ". Schiacciabile . Archiviato dall'originale il 23 dicembre 2021. URL consultato il 24 dicembre 2021.
  17. ^ van der Meulen, Marten (22 maggio 2019). "Obama, SCUBA o regalo?: Autorità e argomentazione nella discussione online sulla pronuncia di GIF ". Inglese oggi . 36 (1): 45–50. Archiviato dall'originale il 24 maggio 2022. URL consultato il 22 maggio 2022.
  18. ^ "GIF". Il dizionario delle abbreviazioni del patrimonio americano, terza edizione . Compagnia Houghton Mifflin. 2005. Archiviato dall'originale il 3 settembre 2011. URL consultato il 15 aprile 2007.
  19. ^ "GIF". Il dizionario Cambridge dell'inglese americano . Cambridge University Press. Archiviato dall'originale il 27 febbraio 2014. URL consultato il 19 febbraio 2014.