GIF naar BMP omzetten

Deze twee formaten zijn bijna even oud — 1987 en 1990 — en lossen hetzelfde probleem tegengesteld op. Een GIF slaat een index op in een palet van hoogstens 256 kleuren, één byte per pixel voor LZW-compressie het verder verkleint. De bitmap die hier geschreven wordt, slaat voor elke pixel een volledige blauw-, groen- en roodwaarde op, ongecomprimeerd.

De groei is dus geen enkele factor maar twee die vermenigvuldigd worden: drie bytes waar de GIF er één gebruikte, en geen van de LZW-besparing die de GIF klein maakte. Een GIF van 40 KB wordt routinematig een bitmap tien keer zo groot, en bij vlakke tekeningen met lange reeksen identieke kleur — precies waar GIF het best in comprimeert — is de verhouding nog slechter.

De rekensom is kort en er valt niets te schatten. Vermenigvuldig de breedte met drie voor de bytes in één rij, rond dat af naar boven tot een veelvoud van vier, vermenigvuldig met de hoogte en tel er 54 bytes header bij op. Een GIF van 480 bij 270 geeft 1440 bytes per rij, geen afronding nodig, 388.800 bytes aan pixels en 388.854 in totaal.

Niets aan de bron verandert dat getal. Dezelfde bitmap van 480 bij 270 komt uit een zwaar geditherde foto en uit een egaal rood vlak, omdat het formaat elke pixel letterlijk opslaat in beide gevallen. Die voorspelbaarheid is precies waarom hardware om bitmaps vraagt.

Twee conventies in deze bitmap lijken fouten en zijn dat niet. De rijen staan van onder naar boven opgeslagen, en de kanalen binnen elke pixel zijn geordend als blauw, groen, rood in plaats van andersom. Beide staan in de oorspronkelijke specificatie.

De derde is de opvulling: elke rij wordt opgevuld tot een veelvoud van vier bytes, dus een afbeelding van 101 pixels breed schrijft 303 bytes aan pixels gevolgd door één byte niets, 304 bytes per rij. Code die aanneemt dat elke rij precies breedte maal drie bytes is, produceert een beeld dat diagonaal afschuift.

BMP kent één afbeelding. Het heeft geen begrip van een reeks, een vertraging of een lus, dus een geanimeerde GIF wordt hier het frame waarmee hij opent, en de rest vervalt.

Voor de bestemmingen die om bitmaps vragen is dat zelden een probleem, want een apparaat dat een BMP wil, wil per definitie een statisch beeld. Controleer wel of het eerste frame het gewenste is: veel GIF’s openen op een leeg beeld of een titelkaart voordat de inhoud begint.

Het lijkt logisch dat een afbeelding met maar 256 verschillende kleuren een klein bestand oplevert, en voor een formaat met palet zou dat kloppen. De bitmapspecificatie staat dat zelfs toe — een 8-bit BMP met kleurentabel, wat vrijwel perfect op een GIF zou aansluiten.

Deze omzetter schrijft dat niet. Elke bitmap die hij produceert is 24-bit, dus een GIF met zes kleuren kost evenveel bytes als een foto van dezelfde afmetingen. Vraagt jouw apparaat specifiek om een 8-bit bitmap met palet, dan voldoet dit bestand niet.

Een GIF kan één palet-item als transparant aanwijzen. De bitmap hier heeft helemaal geen alfakanaal — 24 bit, drie kanalen, niets over — dus die pixels moeten voor het coderen een waarde krijgen.

De achtergrondkleuroptie bepaalt die waarde en staat standaard op wit. Bewust kiezen is belangrijk bij hardware: een icoon voor een scherm met een zwarte interface hoort op zwart geplat te worden, niet op wit om het later om te draaien.

Er is geen kwaliteitsschuif bij deze omzetting en die kan er ook niet zijn: ongecomprimeerd is ongecomprimeerd, er valt niets te verhandelen. De enige hendel is de maximale breedte, die het beeld verkleint voordat de pixels geschreven worden en dus de bestandsgrootte kwadratisch verandert.

De breedte halveren deelt de bitmap door vier. Dat is meestal de juiste zet als het doel toch een klein scherm is — een paneel van 128 pixels breed wint niets bij een bron van 640 pixels.

Elke raster-omzetting hier verwijdert metadata onderweg, onvoorwaardelijk, en bij dit paar heeft die regel weinig te doen. Een GIF heeft geen EXIF-blok, geen cameramodel, geen gps-coördinaten; hoogstens een commentaar- of applicatie-extensie van wat het bestand maakte.

Het bitmapformaat heeft er sowieso geen plek voor. De header beschrijft afmetingen, bitdiepte en verder weinig, dus wat eruit komt zijn pixels en geometrie.

De GIF wordt gedecodeerd door de eigen afbeeldingsondersteuning van de browser, en de bitmapheader en pixelrijen worden in JavaScript in hetzelfde tabblad geschreven. Er is geen server in het pad, geen upload en geen account, en het bestand is weg zodra het tabblad sluit.

Dat telt hier extra, want wat mensen naar BMP omzetten is vaak intern: een bedieningspaneelgrafiek, een productlabel, een opstartscherm van een instrument. Niets daarvan hoeft langs andermans infrastructuur.