GIF analyseren — frames, vertragingen, palet en bestandsgrootte

Q: Wat is het verschil tussen de twee frameweergaven?

Het canvas na elk frame is wat een viewer op dat moment laat zien: dit frame getekend bovenop wat de frames ervoor achterlieten. Alleen wat elk frame opslaat is de rechthoek die het bestand werkelijk voor dat frame bevat, op zichzelf, met niets eronder. De tweede is de interessante. Een GIF mag van een frame alleen het veranderde deel opslaan, en daarom kan een schermopname van een vrijwel stilstaand venster klein zijn. Is elk frame in jouw bestand het volledige canvas, dan heeft niemand dat werk gedaan, en aan de animatie zie je dat niet: alleen aan wat er opgeslagen is.

Hoe je de privacybelofte controleert

Je GIF kan nergens heen. In de Content-Security-Policy staat elk adres dat deze pagina mag benaderen, en geen daarvan is van ons. Er is hier geen eindpunt waar je bestand verzameld zou kunnen worden, en er staat ook niets in de code dat het daarheen zou sturen als dat er wel was. Hier stond ooit connect-src 'none', en dat was absoluut. Advertenties hebben dat gekost, en dat erbij zeggen hoort bij de afspraak.

De lezer bestaat uit vier bestanden in deze repository. Niets hier gebruikt de eigen GIF-decoder van de browser om uit te zoeken wat er in het bestand zit, want die decoder vertelt niet waar een byte heen ging. Dus wordt het formaat met de hand gelezen: src/gif.js loopt de blokken langs, src/lzw.js pakt de pixels uit, src/frames.js stapelt ze en src/budget.js telt de onderdelen weer op en controleert of ze samen de grootte van het bestand zijn.

Opmerkingen en metadata krijg jij te zien, en verder niemand. Een GIF kan een opmerkingenblok bevatten, een XMP-pakket dat een bewerking beschrijft, of een kleurprofiel, en deze pagina drukt ze allemaal af. Ze komen op het scherm voor je neus te staan en gaan verder nergens heen: er is in deze repository geen enkel analytics-event dat er iets van meedraagt, en de pagina zou het niet kunnen versturen als dat er wel was.

Wat Google laadt, en wat het niet te zien krijgt. De advertentie- en meetscripts komen van Google. Geen van beide krijgt iets over je bestand mee: niet het bestand, geen miniatuur, geen naam, geen grootte, geen aantal frames en geen opmerking. Elke regel die een GIF leest, uitpakt of tekent, wordt vanaf deze herkomst geserveerd en staat in de repository.

Wat de doneerknop laadt, en wat die niet te zien krijgt. De knop “Buy me a coffee” in de kop wordt getekend door een script van cdnjs.buymeacoffee.com en haalt zijn letters bij Google Fonts. Het is niet meer dan een link: hij meldt geen bezoek en krijgt niets over jou of je bestanden mee. Er gebeurt niets zolang je er niet op klikt, en waar je dan op zou klikken is de site van iemand anders.

Het werkt offline. Verbreek de verbinding en alles op deze pagina blijft werken. Eenvoudiger bewijs bestaat er niet: een tool die je GIF wegstuurde om hem te laten analyseren zou stoppen op het moment dat je de stekker eruit trok.

Controleer het zelf. Je hoeft niets van het bovenstaande op ons woord aan te nemen. Een buildscript maakt deze pagina uit de sjablonen en de configuratie in de repository, en dat script kun je lezen en zelf draaien. Het resultaat staat vastgelegd op de branch dist, dus je kunt wat er geserveerd wordt vergelijken met wat een build van de bronnen oplevert:

github.com/A-Box-of-Tools/website

De bestanden die je als eerste wilt lezen zijn config/site.toml voor de Content-Security-Policy, src/gif.js voor de bloklezer die het bestand doorloopt, src/lzw.js voor het uitpakken en src/budget.js voor de byteboekhouding. In geen daarvan staat een regel die het netwerk zou kunnen bereiken.

Als de beveiligingssoftware van je werkgever voor een upload waarschuwt. Die let op het moment dat er in een browser een bestand wordt gekozen, en kan niet weten of de pagina het wil versturen — dus waarschuwt hij bij het kiezen. Hier wordt niets verstuurd: open de ontwikkelaarstools, ga naar Netwerk en kies een bestand. Er is geen verzoek dat het meeneemt, en helemaal geen verzoek behalve de lokale voorbeeldweergave van de pagina. Diezelfde controle doet je IT-afdeling in een halve minuut.

Kies een GIF

Sleep hier een GIF naartoe of klik om te bladeren — geanimeerd of stil, elk formaat

Waar de bytes heen gingen

Elke byte van het bestand staat in precies één rij, en de rijen zijn samen het bestand. Klopte dat niet, dan zou de laatste rij dat zeggen in plaats van dat de balk stilletjes uitrekt tot het past.

Waar de bytes van dit bestand heen gingen
Onderdeel	Bytes	Aandeel
Het hele bestand	—	100%

{name} wordt gelezen… {name} is geen GIF: {why}. Dit gereedschap leest het GIF-formaat zelf, dus het heeft niets te zeggen over andere bestanden. {name} kon niet gelezen worden: {why} het bestand eindigt bij {available} bytes en er waren er bij {at} nog {wanted} nodig dit bestand begint met {what}, niet met „GIF” een JPEG een PNG een RIFF-bestand — een WebP of een WAV een PDF een zipbestand de bytes {bytes} de codegrootte is {size}, en het formaat staat 2 tot 8 toe {n} beeld {n} beelden {n} kleur {n} kleuren {n} ingang {n} ingangen {n} tabel per beeld {n} tabellen per beeld {n} keer {n} keer {n} bytes {minutes} min {seconds} s {n} s {time} ({fps} fps) {n} beelden vragen minder dan 0,02 s, en elke browser houdt ze in plaats daarvan 0,10 s vast. één keer — geen herhaalblok eindeloos {n} keer Probleem Goed om te weten Opmerking {frames}. {drawn} ervan zijn hier getekend; de rest is te groot om in één keer in het geheugen te houden en wordt alleen uit de koppen beschreven. {frames}, waarvan er geen enkele het hele doek bedekt. {frames}, die allemaal het hele doek bedekken. {frames}, waarvan er {n} het hele doek bedekken. Toon de andere {frames} Wat beeld {n} op zichzelf bevat Het doek na beeld {n} Beeld {n} niet getekend Vertraging {delay} → 0,10 s Rechthoek ⁦{width} × {height}⁩ op ⁦{left}, {top}⁩ Palet {n} van zichzelf het globale helemaal geen Transparant index {n} nee Grootte {size} — {share} Interlaced ja Gecomprimeerd {ratio}× Probleem de gegevens houden te vroeg op De tabellen in dit bestand verklaren samen {declared}, de pixels verwijzen naar {referenced} daarvan, en {different} daarvan verschillen van elkaar. {entries}, {size}, gedeeld door {frames}. Vervaagde ingangen zijn er waar geen enkele pixel ooit naar verwijst. {tables} ({size} in totaal) Beeld {n} — {colours} De eerste 24 van {n} worden getoond. De rest staat in het downloadbare rapport. Een opmerking. Geen enkele weergever toont hem, en elke kopie van het bestand draagt hem mee. Het herhaalblok, dat zegt eindeloos af te spelen. Het hoort niet bij de GIF-specificatie: Netscape verzon het in 1995 en alles heeft het toch geïmplementeerd. Het herhaalblok, dat zegt {times} af te spelen. Een XMP-pakket: de XML die een beeldbewerker schrijft om vast te leggen wat hij gedaan heeft. Niets tekent het. Een ICC-kleurprofiel, dat zegt wat de getallen van het palet als kleuren betekenen. Vrijwel niets leest er een uit een GIF. Een blok platte tekst, dat de weergever vraagt tekst over het plaatje te tekenen. Het stond in de specificatie van 1989 en is nooit door iets geïmplementeerd. Een toepassingsblok. Weergevers slaan de blokken over die ze niet herkennen. Duurt {time} zoals geschreven Speelt werkelijk {time} - {n} beeld(en) onder 0,02 s worden door elke browser op 0,10 s gezet Snelheid {fps} beelden per seconde Herhalingen geen herhaalblok - speelt een keer Globaal palet {n} kleuren geen Getekende kleuren Achtergrondindex Gekopieerd. Het is platte tekst, en het is alleen naar je klembord gegaan. Deze browser liet de pagina niet naar het klembord schrijven. Gebruik „Downloaden” in plaats daarvan. Kop en schermbeschrijving De handtekening, het canvasformaat en de vlaggen. Dertien bytes, in elke GIF die ooit gemaakt is. Globale kleurtabel {colours} kleuren van drie bytes elk, gedeeld door elk frame dat er geen eigen meebrengt. Dit bestand heeft er geen: elk frame draagt zijn eigen palet. Kleurtabellen per frame Een eigen palet voor een frame dat andere kleuren nodig had. Drie bytes per kleur, elke keer. Timingblokken Acht bytes per frame: de vertraging, de opruimmethode en welke kleur doorzichtig is. Framebeschrijvingen Elf bytes per frame: waar de rechthoek ligt, hoe groot hij is, en met welke codegrootte de compressor begint. Gecomprimeerde pixels De afbeelding zelf, LZW-gecomprimeerd. In een gezonde GIF is dat bijna het hele bestand. Blokomlijsting Eén lengtebyte per 255 bytes aan data, plus een nul om elke reeks af te sluiten. Onvermijdelijk, en de moeite van het zien waard. Opmerkingen en metadata Herhaalblokken, opmerkingen, kleurprofielen en alle XMP die een programma heeft achtergelaten. Afsluiter Eén byte die zegt dat het bestand voorbij is. Bytes na het einde Data die achter de afsluiter ligt. Geen enkele decoder leest het, en het is puur gewicht. Niet verantwoord Bytes in blokken waar deze lezer is blijven staan. Een bestand dat middenin een blok eindigt laat er wat achter. Dubbel geteld De blokken overlappen, wat betekent dat dit bestand het met zichzelf oneens is over waar ze beginnen. Niet opgegeven Laten staan Terug naar de achtergrond Herstellen wat eronder zat Gereserveerd ({n}) Opruimen GIF-analyse — {name} Volledig in een browser gelezen door abox.tools/gif-analyzer/. Het bestand is niet geüpload. Het bestand Versie Canvas ⁦{width} x {height}⁩ pixels Grootte {rounded} ({exact}) Frames Waar de bytes heen gingen Totaal Wat opvalt De frames Tekst die in het bestand meereist Het globale palet {colours} eigen globaal heel canvas nr. op formaat duur opruimen palet bytes Het bestand eindigt zonder afsluitbyte en is dus onvolledig — een download die te vroeg stopte, of een afgekapt bestand. Byte {at} is 0x{marker}, en dat begint geen enkel blok dat dit formaat kent. Alles erna is genegeerd. Twee grafische controleblokken achter elkaar, op {first} en {second}. Het eerste beschrijft geen beeld en doet niets. Het bestand eindigt midden in een blok dat op {at} begint. {detail}. Code {code} kwam als eerste, voordat het woordenboek iets bevatte. Een weergever tekent wat hij kan en laat de rest van de rechthoek leeg. Code {code} verwijst naar woordenboekingang {code}, en er zijn er maar {entries}. Een weergever tekent wat hij kan en laat de rest van de rechthoek leeg. Er zitten geen frames in dit bestand. De kop liet zich lezen, maar er volgde geen beeldblok. Wat dit ook is, geen enkele weergever tekent er iets uit. Het bestand eindigt niet netjes. {bytes} staan achter het einde van het bestand. Elke decoder stopt bij de afsluitbyte, dus deze worden nooit gelezen en nooit getekend. Meestal is het een tweede bestand dat achter het eerste is geplakt, of een programma dat voorbij zichzelf schreef. Het bestand bij de afsluitbyte afkappen verliest niets. Eén frame vraagt om korter dan 0,02 seconde te blijven staan, en geen enkele browser doet dat. {count} frames vragen om korter dan 0,02 seconde te blijven staan, en geen enkele browser doet dat. Elke browser sinds Netscape rondt een vertraging onder twee honderdsten van een seconde af naar tien — een regel uit 1996, geschreven voor de draaiende wereldbollen van toen en nooit verwijderd. Deze animatie zegt dus {nominal} te duren en duurt in werkelijkheid {real}, ongeveer {factor} keer zo traag. 0,02 schrijven in plaats van 0,01 geeft haar de snelheid waar ze om vraagt. Elk frame heeft vertraging nul. Het bestand geeft helemaal geen tijden op, dus hoe snel dit loopt hangt volledig van de weergever af — meestal tien frames per seconde, maar niets garandeert het. Twee browsers kunnen dit op twee snelheden afspelen en allebei gelijk hebben. De frames lopen niet gelijkmatig: {delays} verschillende vertragingen, van {shortest} tot {longest}. Een laatste frame dat blijft staan is bedoeld en gewoon. Vertragingen die door het midden heen verspreid liggen komen meestal van een omzetter die frames uit een video liet vallen en de buren oprekte om het gat te dekken. Er is geen herhaalblok, dus dit speelt één keer en houdt op. Herhalen hoort niet bij de GIF-specificatie. Het is een blok dat Netscape in 1995 verzon en dat iedereen toch inbouwde; een bestand zonder dat blok is een bestand dat elke browser precies één keer laat zien. Als dit moest herhalen, heeft wat het schreef het blok weggelaten. Dit speelt één keer en houdt dan op. Dit speelt {count} keer en houdt dan op. Het herhaalblok noemt een aantal in plaats van de gebruikelijke nul, die voor altijd betekent. Sommige oudere weergevers negeren het aantal en herhalen toch. Elk frame tekent het hele canvas opnieuw. Een GIF mag van een frame alleen de rechthoek bewaren die sinds het vorige veranderde — daarom kan een opname van een vrijwel stil venster klein zijn. Hier doet geen enkel frame dat: elk frame is het hele canvas, ⁦{width}×{height}⁩. Voor beelden die niets met elkaar te maken hebben klopt dat, en voor alles wat gefilmd of opgenomen is, waar het grootste deel van het beeld niet beweegt, is het weggegooide ruimte. Eén frame van {total} tekent het hele canvas opnieuw; de rest bewaart alleen het veranderde deel. {count} frames van {total} tekenen het hele canvas opnieuw; de rest bewaart alleen het veranderde deel. Zo ziet een geoptimaliseerde GIF eruit. De volledige zijn meestal het eerste frame en elk punt waar het beeld helemaal veranderde. Geen enkel frame tekent het hele canvas opnieuw. Elk frame na het eerste bewaart alleen de rechthoek die veranderde. Zo hoort het formaat gebruikt te worden, en daarom is dit bestand zo klein als het is. Eén frame steekt buiten het canvas uit. {count} frames steken buiten het canvas uit. Het canvas is ⁦{width}×{height}⁩ en een frame claimt een rechthoek die over de rand loopt. Decoders zijn het oneens over wat er met dat overhangende deel moet gebeuren: de een knipt het weg, de ander weigert het bestand. Het canvas is ⁦{width}×{height}⁩ en sommige frames claimen een rechthoek die over de rand loopt. Decoders zijn het oneens over wat er met dat overhangende deel moet gebeuren: de een knipt het weg, de ander weigert het bestand. Eén frame draagt een eigen kleurtabel mee, die {bytes} kost — {share} van het bestand. {count} frames dragen een eigen kleurtabel mee, die {bytes} kost — {share} van het bestand. Een eigen palet laat een frame kleuren gebruiken die de gedeelde tabel niet heeft, en kost drie bytes per ingang telkens als het geschreven wordt. Waar de frames dezelfde scène tonen is één tabel voor allemaal zowel kleiner als rustiger om naar te kijken: een palet dat tussen frames heen en weer schiet is precies wat GIF-flikkering is. Er is geen globale kleurtabel. Daar is niets mis mee — elk frame brengt hier zijn eigen mee — maar het betekent wel dat een weergever niets heeft om het canvas mee te vullen voordat het eerste frame binnenkomt. {entries} ingangen van de kleurtabellen worden nooit gebruikt, en dat is {bytes}. De tabellen in dit bestand noemen {declared} kleuren en de pixels verwijzen naar {referenced} daarvan. Een kleurtabel is altijd een macht van twee lang, wat er ook in staat, dus een frame met negen kleuren krijgt er toch zestien; enig afronden is onvermijdelijk. Veel meer dan dat betekent dat de paletten voor een ander beeld zijn gebouwd dan het beeld dat er uiteindelijk in kwam. De hele animatie tekent met één kleur. De hele animatie tekent met {count} kleuren. Dat is vlak tekenwerk, en daar is GIF voor gemaakt. Zo’n bestand comprimeert goed en dithert slecht, dus als het spikkelig oogt is het ditheren wat je moet uitzetten. Een foto, of iets dat daaruit voortkomt. GIF geeft een frame hoogstens 256 kleuren, dus alles met een verloop erin wordt benaderd — en daar komen het ditheren en de ruis vandaan die een bestand groot maken. Er zit een commentaarblok van {bytes} in dit bestand. Commentaar wordt door geen enkele weergever getoond en gaat met elke kopie van het bestand mee. Meestal is het de naam van wat het schreef, en af en toe iets dat de maker niet gepubliceerd zou willen hebben. Een XMP-metadatapakket neemt {bytes} in beslag — {share} van het bestand. XMP is het XML-blok dat een fotobewerker schrijft om vast te leggen wat hij deed, en het kan de bewerkingsgeschiedenis, de software en soms de maker bevatten. Geen enkele weergever tekent er iets van. Het weghalen kost het beeld niets. Een ICC-kleurprofiel neemt {bytes} in beslag. Het profiel zegt wat de getallen in het palet als kleuren betekenen. Bijna niets leest er een uit een GIF, dus meestal is het gewicht voor niets — maar het weglaten kan de kleuren verschuiven in de weergevers die het wel lezen. Er zit een platte-tekstuitbreiding in dit bestand. Een blok dat de weergever vraagt tekst over het beeld te tekenen, in een raster van cellen. Het stond in de specificatie van 1989, het is nooit door iets ingebouwd, en elke decoder slaat het over. Wat er ook in staat, het verschijnt niet. Er is een toepassingsblok met de naam „{name}”, van {bytes}. Toepassingsblokken zijn de manier waarop alles buiten de specificatie in een GIF terechtkomt. Weergevers slaan de blokken over die ze niet kennen, dus dit is gewicht tenzij iets specifieks het leest. Eén frame is interlaced opgeslagen. {count} frames zijn interlaced opgeslagen. De rijen staan in vier doorgangen, zodat een beeld dat over een trage lijn binnenkwam vroeg een grove versie van zichzelf liet zien. In 1993 sloeg dat ergens op, het comprimeert iets slechter dan rijen op volgorde, en geen enkele weergever heeft er nu nog baat bij. Dit bestand zegt GIF{version} te zijn in plaats van GIF89a. GIF87a kwam eerst en heeft geen tijdblokken, geen transparantie en geen herhaalblok. Een bestand dat 87a claimt en toch een van die dingen meedraagt is gewoon — decoders controleren het niet — maar het is een teken dat de kop gekopieerd is in plaats van geschreven. De achtergrondkleur is index {index}, en de globale tabel heeft maar {entries} ingangen. Er crasht niets — weergevers nemen dan transparant — maar het betekent dat het veld nooit is ingevuld, of is ingevuld voor een palet dat niet meer het palet in het bestand is. De pixelverhouding staat op {ratio}. Een veld voor schermen die geen vierkante pixels hadden. Elke moderne weergever negeert het en tekent het frame op de opgeslagen maat, dus een bestand dat erop leunt oogt uitgerekt voor wie het maakte en normaal voor alle anderen. De compressor zette zijn woordenboek {count} keer terug. LZW bouwt gaandeweg een woordenboek op en er passen 4.096 ingangen in; als het vol is, begint de encoder opnieuw. Eén keer per frame is normaal — zo begint een frame. Meer dan dat betekent dat het beeld gevarieerd genoeg was om het woordenboek halverwege uit te putten, en dat is wat een foto of stevig ditheren doet — daarom zijn die bestanden groot. Eén frame is identiek aan het frame ervoor. {count} frames zijn identiek aan het frame ervoor. Ze kosten hun volle gecomprimeerde grootte en veranderen niets op het scherm. Hun vertraging bij het vorige frame optellen zou er precies hetzelfde uitzien en kleiner zijn. Eén frame decodeert niet volledig. {count} frames decoderen niet volledig. De gecomprimeerde gegevens houden op voordat het frame vol is. Een weergever tekent wat hij kan en laat de rest van de rechthoek leeg. Je GIF is nergens heen gegaan. {total} bestanden geladen. {platform} Iets heeft {hosts} benaderd, en dat doet dit gereedschap nooit. {platform} De eigen scripts van de site voor advertenties, meting en de donatieknop kwamen van {hosts} host; geen daarvan heeft een bestand gekregen. De eigen scripts van de site voor advertenties, meting en de donatieknop kwamen van {hosts} hosts; geen daarvan heeft een bestand gekregen.

# GIF analyseren — wat er echt in een GIF zit Frames, vertragingen, paletten, en waar elke byte heen ging. > Haal een GIF uit elkaar in je browser: elk frame met zijn vertraging en opruimregel, de kleurtabellen, het aantal herhalingen en een byte-voor-byte overzicht van waar de bestandsgrootte heen ging. Er wordt niets geüpload. Deze pagina is een interactief hulpmiddel dat volledig in je browser draait, op https://abox.tools/nl/gif-analyseren/ — niets van wat je het geeft wordt geüpload. Hieronder staat alles wat de pagina er in woorden over zegt; om het te gebruiken, open je het adres. ## Je GIF's worden **nooit geüpload**. Er is geen server. Het bestand wordt door je eigen browser geopend en uit elkaar gehaald: de blokstructuur, het uitpakken van de LZW-compressie en elk frame dat op deze pagina getekend wordt, gebeuren op dit apparaat. Aan de andere kant van deze pagina zit geen server waar een bestand naartoe zou kunnen, ook al zou iets hier dat willen. - ✗ Geen upload - ✗ Geen account - ✓ Werkt offline - ✓ Open source - ✓ Bestanden blijven op je apparaat ## Zo analyseer je een GIF 1. **Kies een GIF.** Sleep hem op de kiezer of zoek hem met de hand op. De browser leest hem rechtstreeks van je schijf, en er gaat ondertussen niets ergens heen. 2. **Lees eerst de samenvatting.** De canvasgrootte, het aantal frames, hoe lang de animatie zegt te duren en hoe lang hij werkelijk speelt. Die laatste twee lopen vaker uiteen dan mensen verwachten, en de reden staat in de volgende sectie. 3. **Kijk naar wat eruit springt.** Elke regel daar is aan jouw bestand gemeten: vertragingen die geen enkele browser aanhoudt, een ontbrekend herhalingsblok, kleurtabellen waar niets naar verwijst, metadata die groter is dan sommige frames. Niets ervan is een gok naar wat je bedoeld had. 4. **Zie waar de bytes heen gingen.** Elke byte van het bestand staat in precies één rij, en de rijen zijn samen het bestand. Zit het meeste niet in “gecomprimeerde pixels”, dan zegt de rest van de tabel waar het wel zit. 5. **Loop de frames langs.** Elk frame toont zijn vertraging, zijn rechthoek, zijn opruimregel en zijn grootte. Wissel tussen “het canvas na elk frame” en “alleen wat elk frame opslaat”. Met het tweede zie je of het bestand geoptimaliseerd is, want een goed gemaakte GIF slaat minuscule rechthoekjes op en een slecht gemaakte elke keer het hele plaatje. 6. **Neem het rapport mee als je het nodig hebt.** De hele analyse als platte tekst, om in een bericht te plakken of naast het bestand te bewaren. Het wordt in de pagina opgebouwd uit wat al op je scherm staat. ## De uitgebreide versie [Wat er werkelijk in een GIF zit](https://abox.tools/nl/gidsen/wat-zit-er-in-een-gif/): Frames, vertragingen, opruimmethoden en kleurtabellen uitgelegd, waarom browsers de snelste vertragingen weigeren, en hoe je uitzoekt waar de bestandsgrootte van een GIF echt heen is. ## Ook in de gereedschapskist - [Afbeeldingen naar video](https://abox.tools/nl/afbeeldingen-naar-video/): Maak van een map vol afbeeldingen een video. - [Videoknipper](https://abox.tools/nl/video-knippen/): Markeer tijdens het afspelen wat het bewaren waard is. Krijg het terug als één video. - [Videobijsnijder](https://abox.tools/nl/video-bijsnijden/): Snijd een filmpje terug tot het stuk waar het om gaat. - [Video-omkeerder](https://abox.tools/nl/video-achteruit-afspelen/): Laatste frame eerst, geluid en al. ## Vragen ### Wordt mijn GIF ergens naartoe geüpload? Nee. Het bestand wordt gelezen, uitgepakt en getekend door je eigen browser op je eigen hardware. Deze tool heeft geen serverkant, en de `Content-Security-Policy` van de pagina noemt elk adres dat ze mag benaderen: geen daarvan is van ons. Trek de stekker eruit en hij analyseert nog steeds GIF's. ### Waarom speelt mijn GIF trager af dan de vertragingen zeggen? Omdat elke browser weigert een vertraging onder twee honderdsten van een seconde aan te houden en het frame in plaats daarvan een tiende laat staan. De regel is in 1996 in Netscape geschreven, voor de draaiende wereldbollen en bordjes met “in aanbouw” van toen, en is sindsdien in elke browser overgenomen; niemand heeft hem ooit weggehaald. \ \ Een GIF waarvan alle frames 0,01 s zeggen, speelt dus niet op 100 frames per seconde. Hij speelt op 10, vijf tot tien keer trager dan wat de maker ervan bedoelde. Deze pagina laat beide getallen zien, wat het bestand zegt en wat het echt gaat doen, en markeert de frames die het treft. De oplossing zit in het programma dat het bestand maakte: schrijf 0,02 in plaats van 0,01. ### Wat betekent “opruimen”? Wat er op het scherm blijft staan als de tijd van een frame om is, en het is het veld dat bepaalt of een animatie er goed uitziet of uitsmeert. \ \ **Laten staan** betekent dat het volgende frame eroverheen schildert, en dat wil je als frames dekkend zijn en elkaar bedekken. **Terug naar de achtergrond** veegt eerst de rechthoek van het frame schoon, en dat heeft transparantie nodig: zonder dat laten de doorzichtige stukken van het volgende frame het vorige eronder zien. **Herstellen wat eronder zat** zet terug wat er stond voordat dit frame tekende, en zo wordt een klein bewegend voorwerp op een stilstaande achtergrond opgeslagen. En **niet opgegeven** betekent dat het bestand niets zei, en elke viewer behandelt dat als “laten staan”. ### Waarom is mijn GIF zo groot? De tabel “Waar de bytes heen gingen” beantwoordt dat voor jouw bestand in plaats van in het algemeen, en er zijn maar een paar mogelijke antwoorden. \ \ Zit bijna alles in **gecomprimeerde pixels**, dan is het bestand eenvoudigweg veel plaatje: een GIF slaat elk frame op als hele pixels, zonder bewegingscompensatie en zonder kwaliteitsknop, dus de grootte is ruwweg de oppervlakte maal het aantal frames. Minder frames, een kleiner formaat of minder kleuren zijn de enige knoppen. \ \ Zit een grote plak in **kleurtabellen**, dan schrijft het bestand een palet per frame van 768 bytes per stuk. Zit een grote plak in **metadata**, dan heeft een bewerkingsprogramma een XMP-pakket achtergelaten, en dat kan eruit zonder het plaatje aan te raken. En als alle frames het hele canvas beslaan, heeft de encoder nooit uitgezocht welk deel er echt veranderde, en bij alles wat gefilmd of opgenomen is, is dat het grootste deel van het bestand. ### Wat is het verschil tussen de twee frameweergaven? **Het canvas na elk frame** is wat een viewer op dat moment laat zien: dit frame getekend bovenop wat de frames ervoor achterlieten. **Alleen wat elk frame opslaat** is de rechthoek die het bestand werkelijk voor dat frame bevat, op zichzelf, met niets eronder. \ \ De tweede is de interessante. Een GIF mag van een frame alleen het veranderde deel opslaan, en daarom kan een schermopname van een vrijwel stilstaand venster klein zijn. Is elk frame in jouw bestand het volledige canvas, dan heeft niemand dat werk gedaan, en aan de animatie zie je dat niet: alleen aan wat er opgeslagen is. ### Er staat dat mijn bestand een opmerking of XMP bevat. Wat is dat? Tekst die met het plaatje meereist en die geen enkele viewer tekent. Een opmerkingenblok is meestal de naam van het programma dat het bestand schreef. Een XMP-pakket is de XML die een fotobewerker schrijft om vast te leggen wat hij deed, en dat kan de bewerkingsgeschiedenis, de programmaversie en soms de naam van de maker bevatten. \ \ Deze pagina drukt beide volledig af, want de interessante vraag bij metadata is wat erin staat, niet dat het er is. Jij krijgt het te zien en verder niemand: niets in deze repository leest er iets van aan wie dan ook voor. ### Kan hij een kapotte GIF openen? Hij probeert het, en vertelt waar hij het opgaf. Een bestand dat midden in een blok ophoudt, dat een byte heeft waar een blokmarkering hoort, of dat een frame draagt waarvan de gecomprimeerde data te vroeg opraakt, laat nog steeds alles zien wat tot dat punt leesbaar was, met het probleem bovenaan benoemd. Dat is precies het geval waarvoor je een analyse het hardst wilt, dus het hele bestand weggooien om één slechte byte zou verkeerd zijn. ### Verandert hij mijn bestand? Nee. Deze tool leest alleen. Er is geen uitvoerbestand, geen hercodering en geen knop hier die een GIF schrijft: het enige wat je kunt downloaden is een kopie van de analyse als platte tekst. Je origineel ligt onaangeroerd op je schijf, wat meteen het eerlijke antwoord is op de vraag wat er gebeurt als je het tabblad sluit. ### Is het gratis, en heb ik een account nodig? Het is gratis, en er komt geen account, geen inlog en geen proefperiode aan te pas. Er zit geen limiet op de bestandsgrootte behalve het geheugen van je eigen apparaat. De site draait op advertenties, en die betalen hem; die advertenties krijgen niets over je bestand mee. ### Werkt het offline? Ja. Laad de pagina één keer, verbreek daarna je internetverbinding en hij werkt gewoon door. Dat is meteen de eenvoudigste manier om te bewijzen dat er niets geüpload wordt, want een tool die je GIF wegstuurde om hem te laten analyseren zou ermee ophouden zodra je de stekker eruit trok. ## Hoe je de privacybelofte controleert - **Je GIF kan nergens heen.** In de Content-Security-Policy staat elk adres dat deze pagina mag benaderen, en geen daarvan is van ons. Er is hier geen eindpunt waar je bestand verzameld zou kunnen worden, en er staat ook niets in de code dat het daarheen zou sturen als dat er wel was. Hier stond ooit `connect-src 'none'`, en dat was absoluut. Advertenties hebben dat gekost, en dat erbij zeggen hoort bij de afspraak. - **De lezer bestaat uit vier bestanden in deze repository.** Niets hier gebruikt de eigen GIF-decoder van de browser om uit te zoeken wat er in het bestand zit, want die decoder vertelt niet waar een byte heen ging. Dus wordt het formaat met de hand gelezen: `src/gif.js` loopt de blokken langs, `src/lzw.js` pakt de pixels uit, `src/frames.js` stapelt ze en `src/budget.js` telt de onderdelen weer op en controleert of ze samen de grootte van het bestand zijn. - **Opmerkingen en metadata krijg jij te zien, en verder niemand.** Een GIF kan een opmerkingenblok bevatten, een XMP-pakket dat een bewerking beschrijft, of een kleurprofiel, en deze pagina drukt ze allemaal af. Ze komen op het scherm voor je neus te staan en gaan verder nergens heen: er is in deze repository geen enkel analytics-event dat er iets van meedraagt, en de pagina zou het niet kunnen versturen als dat er wel was. - **Wat Google laadt, en wat het niet te zien krijgt.** De advertentie- en meetscripts komen van Google. Geen van beide krijgt iets over je bestand mee: niet het bestand, geen miniatuur, geen naam, geen grootte, geen aantal frames en geen opmerking. Elke regel die een GIF leest, uitpakt of tekent, wordt vanaf deze herkomst geserveerd en staat in de repository. - **Wat de doneerknop laadt, en wat die niet te zien krijgt.** De knop “Buy me a coffee” in de kop wordt getekend door een script van cdnjs.buymeacoffee.com en haalt zijn letters bij Google Fonts. Het is niet meer dan een link: hij meldt geen bezoek en krijgt niets over jou of je bestanden mee. Er gebeurt niets zolang je er niet op klikt, en waar je dan op zou klikken is de site van iemand anders. - **Het werkt offline.** Verbreek de verbinding en alles op deze pagina blijft werken. Eenvoudiger bewijs bestaat er niet: een tool die je GIF wegstuurde om hem te laten analyseren zou stoppen op het moment dat je de stekker eruit trok. **Controleer het zelf.** Je hoeft niets van het bovenstaande op ons woord aan te nemen. Een buildscript maakt deze pagina uit de sjablonen en de configuratie in de repository, en dat script kun je lezen en zelf draaien. Het resultaat staat vastgelegd op de branch `dist`, dus je kunt wat er geserveerd wordt vergelijken met wat een build van de bronnen oplevert: https://github.com/A-Box-of-Tools/website De bestanden die je als eerste wilt lezen zijn `config/site.toml` voor de Content-Security-Policy, `src/gif.js` voor de bloklezer die het bestand doorloopt, `src/lzw.js` voor het uitpakken en `src/budget.js` voor de byteboekhouding. In geen daarvan staat een regel die het netwerk zou kunnen bereiken.

Vragen

Wordt mijn GIF ergens naartoe geüpload?

Nee. Het bestand wordt gelezen, uitgepakt en getekend door je eigen browser op je eigen hardware. Deze tool heeft geen serverkant, en de Content-Security-Policy van de pagina noemt elk adres dat ze mag benaderen: geen daarvan is van ons. Trek de stekker eruit en hij analyseert nog steeds GIF's.

Waarom speelt mijn GIF trager af dan de vertragingen zeggen?

Omdat elke browser weigert een vertraging onder twee honderdsten van een seconde aan te houden en het frame in plaats daarvan een tiende laat staan. De regel is in 1996 in Netscape geschreven, voor de draaiende wereldbollen en bordjes met “in aanbouw” van toen, en is sindsdien in elke browser overgenomen; niemand heeft hem ooit weggehaald.

Een GIF waarvan alle frames 0,01 s zeggen, speelt dus niet op 100 frames per seconde. Hij speelt op 10, vijf tot tien keer trager dan wat de maker ervan bedoelde. Deze pagina laat beide getallen zien, wat het bestand zegt en wat het echt gaat doen, en markeert de frames die het treft. De oplossing zit in het programma dat het bestand maakte: schrijf 0,02 in plaats van 0,01.

Wat betekent “opruimen”?

Wat er op het scherm blijft staan als de tijd van een frame om is, en het is het veld dat bepaalt of een animatie er goed uitziet of uitsmeert.

Laten staan betekent dat het volgende frame eroverheen schildert, en dat wil je als frames dekkend zijn en elkaar bedekken. Terug naar de achtergrond veegt eerst de rechthoek van het frame schoon, en dat heeft transparantie nodig: zonder dat laten de doorzichtige stukken van het volgende frame het vorige eronder zien. Herstellen wat eronder zat zet terug wat er stond voordat dit frame tekende, en zo wordt een klein bewegend voorwerp op een stilstaande achtergrond opgeslagen. En niet opgegeven betekent dat het bestand niets zei, en elke viewer behandelt dat als “laten staan”.

Waarom is mijn GIF zo groot?

De tabel “Waar de bytes heen gingen” beantwoordt dat voor jouw bestand in plaats van in het algemeen, en er zijn maar een paar mogelijke antwoorden.

Zit bijna alles in gecomprimeerde pixels, dan is het bestand eenvoudigweg veel plaatje: een GIF slaat elk frame op als hele pixels, zonder bewegingscompensatie en zonder kwaliteitsknop, dus de grootte is ruwweg de oppervlakte maal het aantal frames. Minder frames, een kleiner formaat of minder kleuren zijn de enige knoppen.

Zit een grote plak in kleurtabellen, dan schrijft het bestand een palet per frame van 768 bytes per stuk. Zit een grote plak in metadata, dan heeft een bewerkingsprogramma een XMP-pakket achtergelaten, en dat kan eruit zonder het plaatje aan te raken. En als alle frames het hele canvas beslaan, heeft de encoder nooit uitgezocht welk deel er echt veranderde, en bij alles wat gefilmd of opgenomen is, is dat het grootste deel van het bestand.

Wat is het verschil tussen de twee frameweergaven?

Het canvas na elk frame is wat een viewer op dat moment laat zien: dit frame getekend bovenop wat de frames ervoor achterlieten. Alleen wat elk frame opslaat is de rechthoek die het bestand werkelijk voor dat frame bevat, op zichzelf, met niets eronder.

De tweede is de interessante. Een GIF mag van een frame alleen het veranderde deel opslaan, en daarom kan een schermopname van een vrijwel stilstaand venster klein zijn. Is elk frame in jouw bestand het volledige canvas, dan heeft niemand dat werk gedaan, en aan de animatie zie je dat niet: alleen aan wat er opgeslagen is.

Er staat dat mijn bestand een opmerking of XMP bevat. Wat is dat?

Tekst die met het plaatje meereist en die geen enkele viewer tekent. Een opmerkingenblok is meestal de naam van het programma dat het bestand schreef. Een XMP-pakket is de XML die een fotobewerker schrijft om vast te leggen wat hij deed, en dat kan de bewerkingsgeschiedenis, de programmaversie en soms de naam van de maker bevatten.

Deze pagina drukt beide volledig af, want de interessante vraag bij metadata is wat erin staat, niet dat het er is. Jij krijgt het te zien en verder niemand: niets in deze repository leest er iets van aan wie dan ook voor.

Kan hij een kapotte GIF openen?

Hij probeert het, en vertelt waar hij het opgaf. Een bestand dat midden in een blok ophoudt, dat een byte heeft waar een blokmarkering hoort, of dat een frame draagt waarvan de gecomprimeerde data te vroeg opraakt, laat nog steeds alles zien wat tot dat punt leesbaar was, met het probleem bovenaan benoemd. Dat is precies het geval waarvoor je een analyse het hardst wilt, dus het hele bestand weggooien om één slechte byte zou verkeerd zijn.

Verandert hij mijn bestand?

Nee. Deze tool leest alleen. Er is geen uitvoerbestand, geen hercodering en geen knop hier die een GIF schrijft: het enige wat je kunt downloaden is een kopie van de analyse als platte tekst. Je origineel ligt onaangeroerd op je schijf, wat meteen het eerlijke antwoord is op de vraag wat er gebeurt als je het tabblad sluit.

Is het gratis, en heb ik een account nodig?

Het is gratis, en er komt geen account, geen inlog en geen proefperiode aan te pas. Er zit geen limiet op de bestandsgrootte behalve het geheugen van je eigen apparaat. De site draait op advertenties, en die betalen hem; die advertenties krijgen niets over je bestand mee.

Werkt het offline?

Ja. Laad de pagina één keer, verbreek daarna je internetverbinding en hij werkt gewoon door. Dat is meteen de eenvoudigste manier om te bewijzen dat er niets geüpload wordt, want een tool die je GIF wegstuurde om hem te laten analyseren zou ermee ophouden zodra je de stekker eruit trok.

GIF analyseren — wat er echt in een GIF zit

Hoe je de privacybelofte controleert

Kies een GIF

Wat eruit springt

Waar de bytes heen gingen

De kleuren

De globale tabel

Wat er verder in zit

Zo analyseer je een GIF

De uitgebreide versie

Vragen

Hoe je de privacybelofte controleert

Kies een GIF

—

Wat eruit springt

Waar de bytes heen gingen

Frame voor frame

De kleuren

De globale tabel

Wat er verder in zit

Zo analyseer je een GIF

De uitgebreide versie

Ook in de gereedschapskist

Vragen