SVG naar GIF omzetten

Dit is het ding om te regelen voordat je iets omzet, en vrijwel niets dat deze omzetting aanbiedt vermeldt het. GIF heeft wel transparantie, maar in maar één vorm: één item in de kleurentabel kan onzichtbaar gemarkeerd worden. De encoder die hier gebruikt wordt markeert er nooit een. Hij bouwt een palet, schrijft het als lijst rood-groen-blauw-drietallen, en tegen de tijd dat het bestand is samengesteld is er nergens plek voor de alfa-informatie.

Een tekening gerenderd uit een SVG heeft transparante pixels waar niets getekend werd, dus moet elk daarvan iets ondoorzichtigs worden voordat het palet gebouwd wordt. Ze worden gevuld met de achtergrondkleur die op deze pagina staat, die begint op wit. Een logo getekend op niets komt dus aan als een logo op een witte kaart — onzichtbaar tegen een witte pagina en prima zichtbaar tegen een donkere, wat de moeite waard is om te checken voordat je het ergens naartoe stuurt.

De achtergrondkleurkiezer op deze pagina bepaalt wat de lege gebieden worden, en die wordt gelezen voordat er iets anders gebeurt: de vulling wordt eerst op het canvas geschilderd en de gerenderde tekening wordt er in één stap overheen gecomponeerd. Die volgorde is waarom de randen schoon uitkomen. Later vullen, of een transparante render verkleinen en dan vullen, laat een rand halfdoorschijnende pixels achter langs elke kromme die de vulling vervolgens verduistert.

Match de waarde met waar de GIF op komt te staan. Is de bestemming een witte pagina, laat het dan zo. Is het een gekleurd paneel en ken je de hexwaarde, typ die dan in en de naad verdwijnt. Kan de bestemming veranderen — een sjabloon die dit jaar wit is en volgend jaar donker — zet dan een rechthoek die het hele viewBox dekt in de tekening zelf, zodat het bestand zijn eigen ondergrond draagt en niet afhangt van een instelling die eenmalig gemaakt is.

Een SVG heeft geen grootte, dus kiest de omzetting er een: standaard 1.024 pixels breed, met de hoogte volgens de verhoudingen van de tekening. Die standaard past goed bij PNG en WebP, waar een groot vlak beeld weinig kost. Bij GIF past het slecht, want de plekken die nog om een GIF vragen — handtekeningblokken, avatars, forumiconen — werken vrijwel altijd op 100 tot 300 pixels.

Gebruik de schaalinstelling. Op 0,2 rendert dezelfde tekening 205 pixels breed, dichter bij wat deze bestemmingen tonen, en het bestand krimpt ongeveer met de oppervlakte mee. Een GIF van 1.024 pixels sturen waar 150 gevraagd werd, betekent dat andermans software het verkleint, meestal slecht en altijd zonder te vragen.

De reductie is minder rigoureus dan het getal 256 doet vermoeden, in elk geval bij het soort beeldmateriaal dat als SVG aankomt. Vlakke vullingen gebruiken elk één kleur, lijnen nog één, en anti-aliasing voegt een spreiding van tussentinten toe langs elke rand — wat bij een tweekleurige tekening een paar dozijn waarden in totaal is.

Op het testbestand leverde de kwantisering een palet op klein genoeg dat de encoder een kleurentabel van zestien items schreef, de kleinste macht van twee die het kon dragen, en de hele GIF van 1024 bij 1024 kwam uit op 7.844 bytes vanuit een SVG van 140 bytes. Vlakke kunst comprimeert uitstekend in dit formaat; GIF slaat reeksen identieke indexen op, en een tekening is grotendeels reeksen.

Verlopen zijn het geval. Een lineaire of radiale vulling over een groot gebied genereert honderden aparte waarden, en het palet kan ze niet dragen, dus kiest de kwantiseerder vertegenwoordigers en het resultaat stapt in plaats van vloeit. Op een render van 1.024 pixels zijn die stappen goed zichtbaar.

Zachte slagschaduwen, vervaagde randen en halfdoorzichtige overlays doen hetzelfde, want elk produceert een bereik van gemengde waarden. Heeft de tekening zoiets en kan de bestemming niet van GIF worden afgepraat, render dan kleiner — minder pixels betekent minder aparte mengsels en minder zichtbare banding.

SVG kan animeren. Het heeft SMIL-elementen, reageert op CSS-animatie, en een bestand kan script dragen. GIF kan ook animeren, wat verleidt tot aannemen dat de twee bij elkaar aansluiten. Dat doen ze niet: de renderer produceert één statisch beeld op de beginstand van de tekening, en de encoder schrijft precies één beeld in het bestand.

Een geanimeerd logo komt dus uit als zijn eerste houding, en geen instelling verandert dat. Een bewegende GIF maken van een bewegende SVG is een heel andere klus — het vereist dat de animatie wordt afgespeeld en beeld voor beeld vastgelegd, wat niet is wat een stilstaande-beeldrenderer doet.

GIF is sinds 1987 door alles te lezen, en dat is de enige eigenschap die telt voor wie de eis schreef. E-mailclients, forumsoftware, intranetportalen en bedrijfssoftware van vóór het midden van de jaren 2000 lezen het allemaal, en degene die het formaat specificeerde wilde een antwoord dat nergens op zou falen.

Lees de rest van die specificatie terwijl je toch bezig bent. Een eis oud genoeg om GIF te noemen legt meestal ook een maximale pixelgrootte en een maximaal aantal bytes vast, en het formaat was zelden de enige beperking. Alles in één keer goed doen is sneller dan drie rondes afwijzing.

Het is een poging waard voordat je het compromis accepteert. Heel veel systemen die GIF zeggen in hun hulptekst accepteren PNG in hun validatiecode, want de tekst werd eerder geschreven dan de code en de code dekt wat de onderliggende bibliotheek ook leest. Lukt dat, dan blijft de transparantie exact behouden en gebeurt de kleurreductie nooit.

Is GIF echt vereist, neem het dan aan en kies de vulkleur bewust in plaats van de standaard klakkeloos te accepteren. Het resultaat is dan een vlakke afbeelding die beslist is in plaats van gebeurd, en die ziet er voor elke ontvanger hetzelfde uit — wat de eis in de eerste plaats probeerde te bereiken.

Sleep de map naar binnen. Elke SVG wordt op dezelfde schaal gerenderd en apart gecodeerd, met alles teruggegeven als ZIP. Het palet wordt per beeld gebouwd in plaats van over de hele set, dus kan dezelfde merkkleur in twee bestanden op een net iets andere index landen — onzichtbaar in gebruik, en een reden om niet te verwachten dat de bestanden byte-identiek zijn.

Elk bestand houdt ook zijn eigen instellingen aan, dus wordt de achtergrondkleur per rij gekozen en niet eenmaal voor de hele drop. Voor een set die naar één sjabloon gaat betekent dat dezelfde waarde op elk ervan instellen, wat de moeite waard is om vooraf te doen in plaats van er bij elke handtekening achter te komen; de compensatie is dat een map met kunst voor twee verschillende achtergronden niet gesplitst hoeft te worden in twee rondes.