ICO naar BMP omzetten

Beide komen van Microsoft en zijn samen ontworpen. Het oorspronkelijke icoonformaat omwikkelde geen aparte afbeelding: elk item bevatte een bitmapheader gevolgd door kleurdata en een één-bit masker dat aangaf welke pixels met rust te laten. Een ICO was letterlijk bitmaps in een mapje met een sjabloon erbij.

De twee groeiden daarna uit elkaar. Iconen kregen een echt acht-bit alfakanaal met Windows XP en de mogelijkheid om een PNG te dragen met Vista, wat moderne icoonbestanden voor hun grote items gebruiken. De bitmap die deze omzetter schrijft is de 24-bit basisvorm, die geen van beide kreeg.

De encoder schrijft 24 bit per pixel: acht blauw, acht groen, acht rood, en verder niets. Er bestaat een BMP-headervariant met alfakanaal, maar vrijwel niets leest die betrouwbaar — precies het betrouwbaarheidsprobleem dat BMP meestal moet voorkomen.

De transparantie moet dus ergens naartoe voordat de encoder draait, en de achtergrondinstelling bepaalt waarheen. Wit is de standaard. Kies de kleur van het oppervlak waarop de bitmap getekend wordt: een installatiebanner, de paneelkleur van een embedded scherm.

Dit is geen fout, het is de hele reden dat BMP bestaat. Elke pixel neemt drie bytes in beslag ongeacht de inhoud, dus de bestandsgrootte is rekenkunde: breedte maal drie, afgerond naar boven op een veelvoud van vier, maal hoogte, plus 54 bytes header.

Voor een vierkant van 256 pixels is dat 768 bytes per rij en 196.608 bytes pixels, in totaal 196.662. Gemeten tegen een testicoon van 8471 bytes is de bitmap meer dan drieëntwintig keer zo groot. Reken dat vooraf uit als er een groottelimiet is.

De grootste. Het decoderen gebeurt door de icoonlezer van je browser, die het grootste item in de map teruggeeft — getest met een bestand met tekeningen van 16, 32, 48 en 256 pixels in vier verschillende kleuren, in drie verschillende volgordes geschreven. De 256-pixeltekening kwam er elke keer uit.

De kleinere items worden nergens weggeschreven en er is geen instelling die ze bereikt. Wil je software een bitmap van 32 pixels en bevat het icoon zo’n item, dan exporteert een icoonbewerker zoals GIMP die laag rechtstreeks — een beter resultaat dan de 256-pixelversie verkleinen.

Twee details voor wie de bytes leest in plaats van het bestand te openen. BMP slaat zijn rijen van onder naar boven op, en elke pixel als blauw, dan groen, dan rood. Beide staan gewoon in de specificatie.

Elke rij is ook opgevuld tot een veelvoud van vier bytes, wat telt bij oneven breedtes: een bitmap van 33 pixels breed heeft 99 bytes kleur per rij en één byte opvulling. Bij 256 pixels is de rij 768 bytes en is geen opvulling nodig.

Omdat er geen decoder voor nodig is. Een microcontroller die een klein scherm aanstuurt, kan bytes uit een bestand met een lus en een headeroffset naar een framebuffer kopiëren; een PNG-decoder toevoegen betekent een decompressor, een geheugentoewijzer en een chunk-parser toevoegen aan een apparaat met misschien 32 KB ram.

Dezelfde redenering geldt voor installatiebronnen, oudere Windows-besturingselementen die bronnen via de eigen bitmapfuncties van het platform laden, en testfixtures die pixels byte voor byte willen vergelijken zonder een codec ertussen.

Beide formaten zijn lossless, en dit pad heeft geen kwaliteitsinstelling omdat er niets te verhandelen valt. Elke pixel die het platslaan overleeft, is byte voor byte wat het icoon opsloeg, dus tweemaal hetzelfde bestand omzetten geeft identieke uitvoer.

De twee dingen die echt verloren gaan, zijn het alfakanaal, vervangen door de achtergrondkleur, en de andere items in de container. Geen van beide is achteraf uit de bitmap terug te halen — bewaar daarom het originele icoonbestand.

Is de bestemming moderne software met een voorkeur in plaats van een harde eis, dan is een PNG twee ordes van grootte kleiner en behoudt hij de transparantie. Hetzelfde testicoon was 1737 bytes als PNG tegenover 196.662 als bitmap — genoeg verschil voor een mailtje of BMP echt vereist is.

Is het antwoord ja — firmware, een installatiescript, een fixture met byte-voor-byte vergelijking — dan is de bitmap correct en de grootte de prijs van leesbaarheid zonder decoder. Zeg dat in de commitboodschap, want een bestand van 200 KB voor een klein icoon lijkt een vergissing voor wie het later beoordeelt.

Sleep de hele set naar binnen. Elk bestand wordt gedecodeerd, platgeslagen op dezelfde achtergrondkleur en apart weggeschreven, met alles teruggegeven als ZIP. Eén gedeelde achtergrondkleur over de hele batch is meestal wat deze bestemmingen nodig hebben.

Controleer de afmetingen in het resultaat in plaats van ze aan te nemen. Icoonsets opgebouwd over jaren mengen items tot 256 pixels met items die bij 32 stoppen, en de bitmaps erven die spreiding — met een factor vierenzestig tussen de bestandsgroottes aan de twee uitersten.