Begin deze week heb ik de bug verholpen die verhinderde grotere afbeeldingen te synthetiseren. Bleek dat het een oude matrix die geïnitialiseerd werd, waardoor er een array ontstond van over 200 miljoen elementen. Dat gaf een klein foutje :p

Nu, eens die bug verholpen, kon ik onder andere dit uitbrengen:
strerry (256/32/30)* Het geeft met andere woorden, geen slechte resultaten, maar het kan beter!

Daarom heb ik vandaag de multilevel synthesis geïmplementeerd, waar men begint met kleine resolutie afbeeldingen en deze ingeeft als bron voor hun grotere varianten. Dit terwijl de neighborhood grootte ook varieert! En dit geeft verbluffende resultaten!!

• jellybeans1 (256/var/36)*
• strerry (256/var/36)*
• iq_radishes_sc (256/var/36)*
• iq_text (256/var/36)*

De tijden voor deze resultaten varieren tussen de 4 en 15 minuten voor 36 iteraties, telkens met dezelfde levels! De eerste 30 iteraties zijn telkens onder de 20 minuten en geven resultaten gelijkwaardig aan de niet variabele versies! Enkel de text-test geeft nog wat vervelende resultaten, ik denk dat dit aan de energiefunctie kan liggen! Misschien vind ik dit nog!

Allezins veelbelovende resultaten!! Ik kan nu gaan beginnen met het integreren van de tilepacking! Hopen dat dit ook lukt!

In ander nieuws: mijn proefpresentatie zal plaatsvinden op woensdag 19 april tussen 14h en 16h te 200B. Wish me luck!

*(output size / neighborhood size / #iteraties)

Hier is een eerste animateratie of hoe 10 iteraties en 23 minuten render tijd wat kunnen opleveren!

Bron                           Animateratie
Â

En nu… snelheid…

UPDATE:
anderhalve minuut voor 30 frames:
stone1, jellybeans1, graphcut1

Wat blijft er nu nog te doen?

• Slim eindigen van iteraties
• Bug verhelpen dat grotere frames dan de source frame niet toelaat

Maar dat is voor later! Slaapwel !

Vanmiddag had ik mijn tweede presentatie over mijn thesis. Ik heb hieruit enkele waardevolle dingen uitgeleerd.
Enerzijds waarom juist een tilepacking nodig is en niet een tiling met alle tiles erin. Dit komt omdat de viewer mipmapping gebruikt. Als ik een gewone tiling gebruik, krijg ik artifacts bij het vergroten en verkleinen. Zonder mipmapping zou dit probleem niet voorvallen!
Anderzijds gaf mijn begeleider de terechte opmerking dat mijn wang viewer, die ik tijdens het voorbereiden van mijn presentatie had geïmplementeerd, niet totaal random was.

Deze herhalingen was ik compleet uit het oog verloren, aangezien ik enkel gekeken had naar de correctheid van de tegeling. Op de presentatie werd mij duidelijk dat deze verre van random was. Eens thuis heb ik dit op 5 minuutjes opgelost door middel van een catmap. (10 tekens meer :p)

Tijdens het tweede semester zal ik ook via andere methodes proberen om een geldige wang tiling in de viewer te krijgen. Ik denk onder andere aan het voorstel in het paper van Dutré en Lagae om met random hoekenparen te werken. Dit zou meer op de omega tiling methode moeten lijken. En eens zien of ik de waarde als texture kan doorgeven en wat de voordelen hiervan zijn inzage snelheid. Ook zal ik onderzoeken of ik een omega tilepack kan vinden zonder brute force!

Dit weekend heb ik een hele boel klaar kunnen krijgen qua code. Eerst en vooral heb ik gentext onder handen genomen. Gentext is het programma om snel tilings te kunnen bezichtigen in HTML. Deze is serieus opgefokt geweest! Voor zowel omega- als wang-tiles kan men nu ook meteen de tilings als afbeeldingen opslaan, al dan niet als tilepacks. Ziehier een korte en voorlopige handleiding:

Usage: gentext <filename> [-v] [-h] [-s <size>] [-p] [-o <output>] [-n <basename>] [-f <format>]

* = required parameter

Hiermee heb ik de nodige tilepacks al kunnen aanmaken voor de viewer: cohen2, cohen3, jellybeans2, beans, quilting.

Ook de viewer zelf is onder handen genomen, er wordt nu onder andere met mipmaps gewerkt. Er zijn nog steeds enkele artifacts, er kunnen nog geen wang tilings worden getoond, de camera is soms wat stroef en animatie zou nog mooi zijn. Maar al bij al is het een leuk speeltje aan het worden.

En nog wat meer viewers: viewer2 en viewer3.

Hier zijn we met de picies…

• cohen2
• cohen3
• beans
• jellybeans2
• quilting

Merk op dus dat de graph cuts nu stukken beter zijn! Nog eens bedankt, Vladimir!

Een van de methodes om te knippen, maw. het pad te kiezen waarlangs men gaat beslissen welk deel van beide plaatjes we gaan nemen, is dynamic programming. Deze gaat volgens een accumulerende history de fout beoordelen.

Nu ik heb de indruk dat die soms erg de mist in gaat. Deze resultaten heb ik verkregen door het stochastisch tile algoritme uit te werken…

• wd-cohen2: Men kan hier opmerken dat sommigen bloempjes gewoon doormidden zijn gesneden.
• wd-wind: Met dit ander voorbeeld kan men nog duidelijker zien dat er bepaalde vormen worden “weggesneden”.

Nu weet ik niet of dit normaal is of dat ik ergens met een bug zit.. Ik hoop niet een bug.. :p

Het was een lange dag vandaag. Maar het heeft zijn vruchten geworpen, want ik heb zowaar mijn eerste resulaten!! Aanschouw:

Wang-tiles

Dit is een voorbeeld van de wang tiles met dynamic programming! Zoals men wel kan zien, zijn er nog fouten in het algoritme. Desalniettemin ben ik erg optimistisch, er is namelijk een prentje!!

update 14:15 De tegels zijn al aansluitend…

Hier zou ik een overzicht willen geven, van welke algoritmen ik zou willen implementeren.

Er zijn 2 grote Tile families: de wang-tiles en de nieuwe ω-tiles. Beide families zou ik willen implementeren. Om dan te snijden in afbeeldingen zijn er twee technieken: dynamic programming en grafen. Ook deze zou ik willen hebben. Ik dacht ook aan smoothing technieken te implementeren. Maar dat zal enkel gebeuren als er tijd over is.

Overzicht:

• wang-tiles – dynamic programming
• wang-tiles – graph cut
• ω-tiles – graph cut

(al dan niet met smoothing)