Tutorial | Pixel Art overtrekken

Inkscape is powered by libdepixelize with the ability to automatically vectorize these "special" Pixel Art images. You can try other types of input images too, but be warned: The result won't be equally good and it is a better idea to use the other tab in Inkscape's Trace Bitmap dialog.

Laten we met een voorbeeldafbeelding starten om je de mogelijkheden van deze tracer te tonen. Hieronder vind je links een voorbeeldrasterafbeelding (van een vrije Pixel Cup inzending) and de gectoriseerde uitvoer rechts.

Libdepixelize gebruikt het Kopf-Lischinski algorithme om afbeeldingen te vectoriseren. Dit algoritme maakt gebruik van verschillende computerwetenschappelijke technieken en wiskundeconcepten voor een goed resultaat bij pixel art afbeeldingen. Noteer dat het alfakanaal genegeerd wordt bij dit algoritme. libdepixelize bevat nog geen uitbreidingen om dit type afbeeldingen optimaal te verwerken, alhoewel alle pixel art afbeeldingen die het alfakanaal gebruiken, vergelijkbare resultaten geven in vergelijking met de hoofdgroep van afbeeldingen herkend door Kopf-Lischinski.

De bovenstaande afbeelding bevat een alfakanaal en het resultaat is in orde. Echter, indien je een pixel art afbeelding vindt met een slecht resultaat en je vermoedt dat de hoofdreden daarvoor het alfakanaal zou zijn, contacteer dan de ontwikkelaar van libdepixelize (vb. maak een bugrapport op de projectpagina aan). Hij zal met plezier het algoritme uitbreiden. Het algoritme kan immers niet uitgebreid worden indien hij niet beschikt over afbeeldingen met slechte resultaten.

The image below is a screenshot of Pixel art dialog in the English localisation. You can open this dialog using the Path⇒Trace Bitmap⇒Pixel art menu or right-clicking on an image object and then Trace Bitmap.

Deze dialoog bevat twee secties: Heuristiek en Uitvoer. Heuristiek is bedoeld voor gevorderd gebruik. De standaardwaarden zijn goed en je zou er niet naar moeten omkijken. Daarom laten we ze voor wat ze zijn en beginnen we met de uitleg over de uitvoer.

Het Kopf-Lischinski algorithme werkt (vanuit een high level gezichtspunt) zoals een compiler die de data tussen verschillende voorstellinswijzen converteert. Bij elke stap kan het algoritme de bewerkingen verkennen van deze voorstelling. Enkele tussenliggende voorstellingen geven een correcte visuele voorstelling (zoals de hertekende cel grafiek van de Voronoi uitvoer), andere niet (zoals de similariteitsgrafiek). Tijdens de ontwikkeling van libdepixelize vroegen gebruikers naar de mogelijkheid deze tussenliggende stappen te exporteren, hetgeen nu mogelijk is.

The default output should give the smoothest result and is probably what you want. You saw already the default output on the first samples of this tutorial. If you want to try it yourself, just open the Trace Bitmap dialog, select Pixel art tab and click in OK after choosing some image on Inkscape.

Hieronder zie je de Voronoi uitvoer, hetgeen een "hertekende pixelafbeelding" is waar de cellen (voorheen pixels) vervormd werden om pixels te verbinden die deel uitmaken van hetzelfde kleurvlak. Er worden geen paden gemaakt en de afbeelding bestaat nog altijd uit rechte lijnen. Het verschil wordt duidelijk wanneer je de afbeelding vergroot. Voorheen konden pixels geen rand delen met een diagonale buur, zelfs indien het deel uitmaakt van hetzelfde kleurvlak. Maar nu (dankzij de kleurensimilariteitsgrafiek en heuristiek die je kan fijnafregelen voor een beter resultaat) is het mogelijk om twee diagonale cellen een rand te laten delen (voorheen werden slechts hoekpunten gedeeld bij twee diagonale cellen).

De standaard B-splines uitvoer geeft je effen resultaten, omdat de voorgaande Voronoi-uitvoer omgezet wordt in kwadratische Bézierpaden. Echter, de omzetting is niet 1:1, omdat andere heuristieken beslissen welke paden samengevoegd worden wanneer het algoritme een T-junctie vindt bij de zichtbare kleuren. Noteer over de heuristieken van dit statium dat je ze niet kan afregelen.

De uiteindelijke uitvoer van libdepixelize (niet beschikbaar in de huidige Inscape GUI vanwege het experimentele en onvolledige stadium) zijn de "geoptimaliseerde curves". Dit stadium bevat een randdetectietechniek om te verhinderen dat sommige kenmerken uitgevlakt worden en een triangulatiemethode om de positie van knooppunten te corrigeren na de optimalisatie. Je zou deze features één per één moeten kunnen uitschakelen wanneer deze features uit het "experimenteel stadium" van libdepixelize komen (hopelijk snel).

De sectie heuristiek in de gui laat je toe de heuristieken van libdepixelize in te stellen om te laten beslissen wat er gebeurt bij het samenkomen van een 2x2 pixelblok waarbij de twee diagonalen vergelijkbare kleuren hebben. Wat libdepixelize vraagt is "Welke connectie moet ik behouden?". Het tracht alle heuristieken toe te passen bij de conflicterende diagonalen en behoudt de beste. Bij gelijke uitkomst worden beide verbindingen weggehaald.

Indien je het effect van elke heuristiek wil analyseren en spelen met de getallen, is de Voronoi-uitvoer de beste. Je kan de effecten eenvoudiger zien in de Voronoi-uitvoer. Indien je tevreden bent met de bekomen instellingen, pas je slechts het uitvoertype aan naar diegene die je wil.

De afbeelding hieronder toont de B-splines uitvoer van een afbeelding met telkens één van de heuristieken actief. Let op de purperen cirkels die de belangrijkste effecten van elke heuristiek aangeven.

Voor de eerste poging (afbeelding bovenaan) passen we alleen de heuristiek paden toe. Deze heuristiek tracht lange lijnen verbonden te houden. Je kan zien dat het resultaat vergelijkbaar is met de laatste afbeelding, waar de verspreidde pixels heuristiek is toegepast. Het verschil is dat de "kracht" beter verdeeld is. Het geeft alleen een hoog gewicht, wanneer het belangrijk is de verbinding te behouden. Het concept "beter verdeeld" is hier gebaseerd op "menselijke intuïtie" voor het gegeven pixelvlak. Een bijkomend verschil is dat deze heuristiek niet kan beslissing wat er gedaan wordt wanneer verbindingen grote blokken groepen in plaats van lange curves (zoals bij een schaakbord).

Voor de tweede poging (afbeelding midden), passen we alleen de heuristiek eilanden toe. Het enige streefdoel van deze heuristiek is een verbinding behouden die anders in verschillende geïsoleerde pixels zou resulteren (eilanden) met een constant gewicht. Deze situatie komt niet zoveel voor als de situaties van de overige heuristieken, al is deze heuristiek cool en kan deze toch betere resultaten geven.

Voor de derde poging (afbeelding onderaan), passen we alleen de heuristiek verspreidde pixels toe. Deze heuristiek tracht paden te behouden die verbonden zijn door de voorgrondkleur. Om de voorgrondkleur te bepalen, analyseert de heuristiek een venster met pixels rond de conflicterende paden. Voor deze heuristiek kan je niet alleen zijn "gewicht", maar ook het venster met geanalyseerde pixels, tunen. Noteer echter dat voor het vergroten van het venster, het maximum "gewicht" ook zal toenemen en je de (vermenigvuldigings)factor voor het gewicht kan aanpassen. De oorspronkele libdepixelize auteur vind deze heuristiek te inhalig en gebruikt "0.25" voor de factor.

Zelfs waneer de resultaten van de heuristieken curves en verspreidde pixels vergelijkbare resultaten geven, kan je beide inschakelen. Dit omdat de heuristiek curves voor een extra veiligheid kan zorgen opdat de belangrijke curves of contourpixels niet gehinderd worden en omdat andere gevallen enkel behandeld kunnen worden met de heuristiek verspreidde pixels.

Tip: je kan elke heuristiek uitschakelen door zijn gewicht/factor op nul in te stellen. Je kan elke heuristiek tegengesteld laten werken door negatieve waarden voor het gewicht/factor. Waarom zou je het gedrag dat juist bedoeld was om een betere kwaliteit te bekomen, willen veranderen in tegenovergesteld gedrag? Omdat het kan ... voor het "artistieke" resultaat ... hoe het ook zij, omdat het mogelijk is.

Dat is het! Voor deze initiële release van libdepixelize zijn dit alle beschikbare opties. Wanneer het onderzoek van de oorspronkelijke libdepixelize programmeur en zijn creatieve mentor slaagt, zullen extra opties beschikbaar komen zodat libdepixelize voor meer afbeeldingen een goed resultaat geeft. Duim voor ze!

Alle hier gebruikte voorbeelden zijn afkomstig van de Liberated Pixel Cup om copyrightproblemen te vermijden. De links zijn:

• http://opengameart.org/content/memento

• http://opengameart.org/content/rpg-enemies-bathroom-tiles