Sunday, December 16, 2007

MEL, Maya en PBRT

Hola, alweer een eeuwigheid geleden sinds ik hier nog vooruitgang heb gepost! En er is wel degelijk vooruitgang:

  • Ik heb MEL geleerd
  • Ik heb een scriptje dat toelaat om, nadat in Maya twee splines zijn gedefinieerd met de namen "Pos" en "View", de gegevens van deze twee splines op te vragen, en deze gegevens om te zetten naar het formaat dat nodig is om hen te gebruiken als invoer voor mijn PBRT camera
  • Ik heb een basis voor de uitgebreide Maya/PBRT plugin, al is deze nog niet getest.
Daarenboven heb ik natuurlijk ook aan mijn presentatie voor donderdag gewerkt, en zal ik deze week een meeting kunnen hebben met Maarten Van Volsem, op wiens doctoraat deze thesis is gebaseerd.
Meer info volgt zodra ik mijn presentatie heb, dan kan ik hier ook eens een mooie samenvatting zetten van mijn werk dit semester.

Ben

Thursday, November 29, 2007

Invoerformaat en Planning (3)

Tussen alle andere werkjes door nog eens goed nieuws: het invoerformaat is eindelijk deftig aangepast, ik kan splines inlezen! Toch een klein beetje euforie, afgezien van het feit dat dat twee weken te laat is... De volgende stap is dan om splines vanuit Maya om te zetten naar het formaat dat PBRT nu kan lezen.
Ik heb daarnet in mijn meeting met Toon dan ook mijn planning voor de komende drie weken (de laatste drie van dit semester) opgesteld:

  • 29/11-7/12: Maya/MEL bestuderen en een spline gedefinieerd in Maya uitschrijven naar PBRT (initieel gewoon vanuit MEL proberen uit te schrijven, daarna de Maya-PBRT plugin uitbreiden zodat dit automatisch gebeurt.
  • 8/12-20/12: Proberen een spline te definiëren door gewoon rond te lopen in Maya, en punten van het gevolgde pad te pollen. Ook de presentatie en demo van 20/12 voorbereiden.
B

Wednesday, November 21, 2007

Splines (2)


Als ik dacht dat het frustrerend was een heel weekend zonder resultaat te zoeken naar een manier om met splines te werken in c++, verbleekte dat maandag bij het antwoord van Toon, die na even googlen een library had gevonden waar ik meteen mee aan de slag kon.
Meteen dient hier geïnterpreteerd te worden als 7 uur later, gezien ik les had tot 22u. Daarna ben ik als een gek beginnen programmeren, en heb ik ook nog een stuk in de ochtend doorgewerkt, om op een hoop compilatieproblemen te stuiten. Ik heb de meeting met Toon verzet naar woensdag om al die fouten er nog uit te krijgen en de kans te hebben om ook nog wat te testen. Na de compilatieproblemen opgelost te hebben (gisteravond, door omstandigheden overdag niet veel kunnen doen), bleken er ook nog problemen in mijn applicatie van de library te zetten (en compatibiliteitsproblemen tussen de c++ code van pbrt en de c-code van de library), zodat ik nu na weer een ganse nacht en ochtend programmeren kan zeggen: de splines werken! Ik kan effectief een aantal punten ingeven die op het pad van de camera moeten liggen, en de camera zal dan door deze punten bewegen.
Dat is mooi, maar de euforie is eerder beperkt... Niet alleen sta ik door die splines zwaar achter op schema, mijn aanpassing van het invoerformaat om camerapaden (lees: een reeks punten) te kunnen inlezen blijkt ook niet te kloppen. Deze had ik nog niet getest omdat ik er eerst splines mee wou kunnen maken. Op dit moment zijn alle punten dus nog gehardcoded in de cameraklasse, iets wat hopelijk zo snel mogelijk verholpen zal zijn. Toch nog een piccie om het te illustreren: hierin is enkel de positie van de camera veranderlijk, de kijkrichting niet. De implementatie om de kijkrichting volledig te laten verlopen via een spline is functioneel, maar ik heb nog geen goeie waarden gevonden en moet stilaan vertrekken naar een groepswerkje.

B-Een klein klein beetje opgewekter dan vorige post

Sunday, November 18, 2007

Splines

Ik word er stilaan horendul van: na een kleine twee weken te zoeken achter een deftig pakket voor splines te modelleren in C++ heb ik er nog steeds geen gevonden dat minimaal aansluit bij wat ik nodig heb (een simpele manier om een spline-curve te modelleren op basis van een set van punten), en dat duidelijk gedocumenteerd is.
De libraries die ik heb onderzocht zijn:

  • Geometrictools (www.geometrictools.com: erg onduidelijk gedocumenteerd, en, volgens wat ik er kan uit opmaken na bestuderen van de curve-klasse en de voorbeelden (die zowat alles exhaustief illustreren buiten het gebruik van de curve-klasse) geen mogelijkheid om enkel op basis van punten een curve te modelleren. Je moet er namelijk afgeleide(n) en normaal in het punt meegeven, wat geen gegevens zijn waarover ik beschik als ik bijvoorbeeld het gevolgde pad van iemand die interactief door een virtuele scene loopt wil samplen.
  • De (aangepaste ?) versie van Geometrictools zoals beschreven staat in het boek 3D Game Engine Design, en dat op de bijgeleverde CD te vinden is. Volgens de website van Geometric Tools zou dit boek de documentatie bij hun library zijn, maar de referenties op de site kloppen totaal niet, en het boek levert in het hoofdstuk Curves niet meer dan een wiskundige uitleg over splines, en totaal geen uitleg bij de code of het gebruik ervan.
  • NURBS++ (http://sourceforge.net/projects/libnurbs/), een library die zoals de naam al doet vermoeden NURBS-curven en -oppervlakken modelleert in C++. Ook hier was de documentatie zeer ondermaats. Op de site van het project is wel een paper te vinden die verscheidene eigenschappen van splines beschrijft en de generatie van curves illustreert, maar de documentatie is onvolledig (zegt de auteur zelf), en is sinds 2002 in onvolledige staat gebleven. Dit pakket laat wel toe op basis van punten een curve te genereren, maar vraagt ook nog een aantal andere parameters waarvan ik ook na het lezen van de 'documentatie' geen idee heb wat ze zijn.
  • Diverse andere pakketten die beweren dat ze dienen om curves te modelleren maar eigenlijk enkel functies (en in de meeste gevallen dan ook nog enkel 2D-functies) blijken aan te kunnen, als je wat dieper in de documentatie graaft.
Er zijn nu drie mogelijkheden om mijn splineprobleem op te lossen. Ofwel blijf ik voortzoeken naar het ideale pakket tot ik het vind en mijn problemen op magische wijze verdwijnen (iets wat elke dag en met elke google-beurt onwaarschijnlijker wordt), ofwel blijf ik doorgraven in de documentatie van NURBS++ totdat ik uitvis wat de ontbrekende parameters zijn of erachter kom dat ook deze library totaal niet geschikt is, ofwel schrijf ik mijn eigen spline-klasse.
Mijn persoonlijke voorkeur gaat momenteel uit naar die laatste course of action. Op die manier kan ik de klasse perfect integreren in de PBRT-manier van werken (voorstellingen van punten etc.) zodat ik achteraf geen bridge tussen PBRT en het andere pakket moet gaan schrijven, ben ik er zeker van dat de klasse precies de opties gaat bieden die ik nodig heb, en weet ik zeker dat ik de intenties van de auteur bij het schrijven van de code ga begrijpen.
Nadelen hiervan zijn dan weer dat ik er extra tijd moet insteken, terwijl de tijd toch stilaan begint te dringen, dat er altijd het risico bestaat dat ik fouten maak met betrekking tot die splines, en dat het computationeel lang niet zo efficiënt (of erger: nauwkeurig) is als professionele pakketten zouden zijn. Anderzijds, betreffende dat laatste nadeel: ik heb ook niet de indruk dat NURBS++ zo ongelooflijk professioneel is, dus ook daar reken ik op een zeker risico qua efficiëntie en nauwkeurigheid.
Ik ga mij alvast voor de rest van vandaag (althans tot ik advies heb ingewonnen van Toon) opnieuw verdiepen in mijn cursus Numerieke Modellering en Benadering. Als ik zelf een spline-klasse ga schrijven zal ik het nodig hebben, zoniet kan het geen kwaad nog eens precies op te frissen hoe het ook weer allemaal werkte (de beschrijvingen waarop ik ben gestoten bij het researchen van de verschillende libraries waren nooit echt uitgebreid of diep wiskundig, de uitleg in het boek was wel wiskundig, maar gaf vooral een overview van verschillende soorten curven zonder echt diep op algoritmische details in te gaan). Nog verder zoeken naar splines op het web zie ik momenteel niet zitten.
Wat ik ook nog plan te doen vandaag is nog eens wat prentjes maken (dat is altijd goed om de moraal op te krikken), en een beetje research te doen naar de Maya-PBRT plugin en de mogelijkheden daarvan.

B


Tuesday, November 13, 2007

Planning (2)

Vorige week had ik met Toon mijn planning besproken tot het einde van dit semester. Die staat nog niet online, dus bij deze:

6/11 - 13/11: mogelijkheid uitwerken om een spline in te lezen in het invoerformaat van PBRT (eentje om het pad voor te stellen, eentje om de kijkrichting voor te stellen)
14/11-27/11: Maya, MEL en de Maya -> PBRT plugin bestuderen en aanpassen: een spline gedefinieerd in Maya uitschrijven naar PBRT, en proberen om bij het interactief lopen door een scene of het bewegen van de camera een spline te halen die naar PBRT kan worden uitgeschreven
28/11-11/12: Uittesten van de mogelijkheden die de viewer in Maya biedt, en of er dan interactief een multiperspectief beeld kan worden opgebouwd. Zoniet kijken wat mogelijk is met een OpenGL viewer.

Ondertussen kan ik ook melden dat ik nog geen spline kan inlezen, omdat ik nog geen goede C++ library hiervoor heb gevonden (ik probeer nu de fijnere puntjes van GeometricTools uit te zoeken), maar ik heb wel het invoerformaat van PBRT uitgebreid om vectoren van punten in te lezen, die dus kunnen dienen als basis voor de spline. Door verschillende deadlines (4 in totaal) heb ik dat vorige week dus niet kunnen afwerken.

B

Tweetuit


Nog snel een mooi prentje posten dat ik van het weekend heb gerenderd, voor ik naar Toon vertrek: dezelfde theepot als vorige keer, maar een camera die rechts vertrekt en daar naar links kijkt, en vervolgens naar links beweegt en naar rechts gaat kijken.

Monday, November 5, 2007

Prentjes!






Ik denk er zopas aan dat ik dit nog niet gepost heb: daarstraks ben ik er in het graphicslabo wél in geslaagd mijn eerste pbrt prentjes te renderen.
Even uitleg bij wat u ziet: het camerapad in elk prentje is een parametrische functie (drie coördinaten in functie van 1 parameter t, die 0 is helemaal links in het beeld en 1 helemaal rechts). Van boven naar onder zijn 1 en 4 stilstaande, gewone camera's, 2 heeft als pad (t, 10t^2, 0), en 3 en 5 hebben als pad (-5t^2, 30*(t-0.5)^2, 0). Ik had zeer graag nog wat doorgeëxperimenteerd, maar helaas moest ik naar de les, en werkt pbrt op mijn machine nog steeds niet. Als u zich zou afvragen wat die randen boven- en onderaan sommige van de prentjes zijn: mijn tooltje om afbeeldingen van het formaat dat pbrt uitspuwt te converteren naar een formaat dat blogger aankan werkt òòk niet.

Bon, bedtijd.
B


Problemen

Hoog tijd om hier nog eens een update aan te brengen.
Het thesissen lukt helaas minder vlot dan verhoopt, de laatste twee weken een stapeltje problemen gehad. Na de euforie van een degelijke presentatie ben ik begonnen aan 'het echte werk': het schrijven van een plugin voor PBRT (een academisch renderprogramma, voor de niet-graphicsmensen die ook dit blog volgen), die automatisch multiperspectief beelden genereert door middel van een nieuwe camera-implementatie.
Hiervoor moeten we natuurlijk eerst deftig weten hoe PBRT in mekaar zit. Dat is gelukkig goed beschreven in een boek, maar dat was uiteraard op dat moment uitgeleend in de campusbibliotheek. Ik heb het dan meteen gereserveerd, blijkbaar perfect gelijktijdig met een ander groepje thesissende studenten, zodat ik met hen maar ben overeen gekomen dat ik het boek enkele dagen zou houden, en het dan aan hen zou uitlenen.
Die paar dagen (die ook nog gevuld waren met andere werkjes) waren echter niet genoeg om een volledige systeemoverview te krijgen, dus heb ik het boek ook maar besteld. Gelukkig kon Toon ook nog een tussentijdse oplossing voorzien, zodat ik ondertussen verder kon.
Dan moest die PBRT natuurlijk ook nog geïnstalleerd geraken, wat ook niet zo straightforward bleek (de bij het boek bijgeleverde binary werkte niet naar behoren, dus was het compilen van de source geblazen, en daar horen wel wat dependencies bij. Maargoed, dat was dan uiteindelijk gefikst en de eerste renderings van de bijgeleverde voorbeeldscènes liepen heel vlotjes.
Ondertussen was de nieuwe versie van Mac OS X, Leopard uitgekomen. Apple-fan als ik ben heb ik dat meteen gekocht, maar de installatie op zich leverde al heel wat extra problemen op, waar ik hier niet dieper op zal ingaan. Wat wel belangrijk is: toen die waren opgelost (en na nog eens extra installatie van alweer een nieuwe versie van XCode) kon ik opnieuw aan de slag aan mijn PBRT-plugin. Tweede grote mijlpaal, na de eerste prentjes: de eerste lijntjes code. Altijd tof, programmeren, niets zo verfrissend als avonden voor de boeg gevuld met klassen, code en cola. Plugin geschreven, PBRT mét plugin hercompileren, ... problemen. Onleesbare errorboodschappen zelfs. En gezien ik op dat moment op de trein zat, en uw opties zonder internet sowieso eerder beperkt zijn, sloeg de frustratie meteen toe. Eenmaal thuisgekomen had ik dan het briljante plan opgevat PBRT eens opnieuw te downloaden, en de source eens clean te compilen. Wonderwel, het werkte!
Dan nog maar eens compilen mét mijn plugin: leesbare errors. Een hele vooruitgang op onleesbare errors, daar kan een mens tenminste wat mee. De fouten oplossen namelijk. En dat ging nog vrij gemakkelijk, in een mum van tijd had ik geen errors meer. Tot ik effectief probeerde een scène te renderen dan toch. PBRT geeft ondertussen segmentation faults. Voor de niet-technische mensen die dit blog volgen: dat wil zeggen dat er geschreven/gelezen wordt naar/van een stukje geheugen dat niet toegankelijk is (tenminste als ik mij niet vergis, de technische mensen die dit blog lezen mogen altijd corrigeren). En dat wil zeggen: oh-oh. Zeker voor iets dat voor die installatie van Leopard wél nog werkte. Ook daar heb ik weer lang op zitten zoeken en prullen, maar daar is tot op dit eigenste moment nog geen oplossing voor gevonden.
Wat nu? Zo dadelijk ga ik maar eens proberen op de pc's van het graphicslabo, kijken of het daar wel werkt. En als het werkt, kijken of ik dan gekke prentjes krijg. Zoja zal ik ze meteen posten hier. Verwezenlijkingen zijn altijd leuker om te posten (en zullen dus sneller gebeuren) dan tegenslagen...

En zo hebben we ook weer geleerd dat thesissen een proces is van vallen en opstaan.

B

Monday, October 22, 2007

Extra prentjes






Vorige week stond zo een beetje in het teken van het renderen van extra prentjes, en het maken van mijn presentatie voor morgen. Het werd stilaan tijd om die prentjes ook met u te delen. Ze zijn (in volgorde van boven naar beneden):

  1. Een langgerekte (Van Volsem-style) versie van mijn eerste prentje van vorige post
  2. Een versie waar de camera altijd dezelfde hoogte en dezelfde kijkrichting behoudt, maar wel meetransleert met het wagentje
  3. Een versie waar per animatieframe 3 pixelkolommen worden genomen in plaats van 1
  4. Zelfde als 1., maar dan met een hoogte van 480 pixels ipv 120
  5. Een versie waar de camera niet mee 'bankt' met het wagentje, maar wel mee draait
In sommige van de foto's zijn zwarte stukken te zien. Deze worden vermoedelijk veroorzaakt doordat het wagentje op dat punt begint te 'banken' en zo de camera in het model van het wagentje belandt.

Monday, October 15, 2007

Prentjes!



Het is zover! De opwinding! De euforie! Het bloed, het zweet en de tranen! Allemaal zo terecht, want na lang prutsen met bash-scriptjes en povray is het gelukt: het eerste prentje is klaar. En omdat het eerste prentje op niet veel sloeg wegens veel te weinig frames genomen, is meteen ook het tweede prentje klaar.
Even uitleggen wat u hier ziet: een vliegtuig-achtig wagentje rijdt samen met een hoop andere identieke wagentjes over een achtbaan-achtig parcours. Dit was oorspronkelijk een filmpje van 640 frames (opgenomen vanuit zo één wagentje), waarvan steeds de middelste pixelkolom is genomen, en deze kolommen zijn aan mekaar geplakt. Zo bekomen we dus een afbeelding waarin 640 verschillende oogpunten van deze scène aan bod komen. Zo heeft u rechts een beeld op een aantal andere vliegtuigjes op dezelfde baan, en in het midden een cilindervormig object in de buurt van de baan.
Eigenlijk was dit gisterenavond al klaar, maar toen wou blogger de prentjes niet uploaden. Gelukkig had ik vanmorgen meer geluk.

B

Tijdsbesteding

Zoals u kan zien is nu ook mijn tijdsbesteding toegevoegd. Dit is altijd een schatting, en beschrijft een beetje hoog-niveau wat ik aan het doen ben (geweest).

Toch nog even een korte update: het renderen is ondertussen gelukt, ik heb nu een stapel prentjes bestaande uit één rij pixels. Volgende stap: deze aan mekaar stitchen (daar heeft Toon ondertussen al een zeer goede tip voor gegeven, dus dat moet wel lukken).

B

Sunday, October 14, 2007

Statusupdate

Tijd voor nog eens een update. Momenteel is mijn literatuurstudie nog volop bezig, maar ben ik ook al aan het uitpluizen hoe ik op een -relatief- simpele manier al een aantal prentjes kan gaan maken om een preview te hebben van wat mijn eigenlijke werk zal zijn. Dit gaat gebeuren in PovRay. De bedoeling is om een effectieve animatie te renderen, daar uit elk frame eenzelfde kolom pixels te gaan slicen, en die kolommen dan naast mekaar te plakken in een nieuw prentje. De moeilijkheden daar liggen in: het werkende krijgen van PovRay (de command-line opties die zo gemakkelijk zijn in linux werken blijkbaar niet, of op een andere manier onder OSX), ontdekken hoe je 1 kolom kan renderen in PovRay, en een manier vinden om die 1kolomsprentjes aan mekaar te plakken tot een foto (liefst een andere manier dan via de gimp die kolommen manueel selecteren en aan mekaar copypasten ;))
Zo, dat is een beetje waar ik nu mijn tijd aan spendeer (voor zover dat kan, gezien er voor twee vakken al deadlines liggen volgende week). Zoals u kan zien is ook mijn literatuurlijst eindelijk toegevoegd (de meeste papers heb ik al gelezen, de twee laatste staan op mijn verlanglijstje).

Bon, ik ga nog eens wat verder lezen, tot de volgende!
B

Monday, October 1, 2007

Planning

Zo, ondertussen is het academiejaar terug bezig, tijd om hier ietwat meer te beginnen schrijven (temeer omdat de vorige post alweer van 6 juli geleden was).
Er is mij gezegd dat ik een planning moet maken over hoe ik deze thesis moet aanpakken, dus hieronder mijn eerste idee.

  • Oktober:
    • Verdere papers lezen, specifiek: meer over verschillende cameramodellen, gebruik van die cameramodellen (artistiek, in medische beeldvorming, ...), en beeld(collages) waar verschillende perspectieven aan bod komen. Ook doctoraat van Maarten Van Volsem doornemen.
    • Verder C++ onder de knie proberen te krijgen, door bijvoorbeeld eens een ray-tracer te proberen te schrijven in C++
    • Mogelijkheden van PBRT en Blender uitdiepen, specifiek uitbreidingsmogelijkheden.
  • November-December: uitwerken van cameramodel voor multiperspectief rendering (volgens systeem van Dr. Van Volsem)
  • Januari: waarschijnlijk weinig thesisactiviteit wegens examens
  • Februari-Maart: experimenteren met mogelijkheden van cameramodel, eventuele uitbreidingen doorvoeren
  • April: velerlei mooie prentjes genereren en een begin schrijven van de definitieve tekst
  • Mei: tekst schrijven en afwerken.
Over het realisme van deze planning hoop ik dat Toon (mijn begeleider) morgen wat meer info zal hebben.
Een dezer dagen ga ik ook proberen hier een lijstje aan te leggen van gelezen en nog te lezen papers.
Wat me dit weekend wel is opgevallen, nu ik een beetje meer over multiperspectief shots weet, begin ik die overal te zien en te herkennen. Zo zag ik dit weekend in Ugly Betty (een Amerikaanse sitcom over een 'lelijk' meisje dat bij een modeblad aan de slag gaat) een shot waarin twee dames aan het telefoneren waren, met het scherm opgedeeld in drie stukken: gezicht van de ene dame, gezicht van de andere dame, en een closeup van het ongelooflijk belangrijke stuk papier in de hand van de ene dame, vanuit een ander camerastandpunt. Ik heb de boel onmiddelijk gepauzeerd en dat opgeschreven.
Erger was het toen ik zaterdag ook in de bioscoop naar Ben X ging kijken, en een scène zag waar verschillende shots van het hoofdpersonage vanuit licht verschillende standpunten over mekaar gelegd worden om een gevoel van ongemak te creëren. Gezien ik die film moeilijk op pauze kon zetten was ik blij dat ik nog stiftjes in mijn jaszak had zitten, en kwam ik dus de bioscoop uit met 'BenX badkamer II' slordig op mijn hand geschreven.
Als daar nog veel scènes bijkomen plan ik ook daarvan een lijstje aan te leggen: scènes in populaire cultuur waar multiperspective shots in voorkomen.

Bon, tot dusver deze update, een volgende komt eraan!

B

Friday, July 6, 2007

De eerste stapjes in het onbekende

Het is zover, het startschot voor mijn thesis is officieel gegeven. Woensdag direct na de proclamatie meteen meeting gehad met de thesisbegeleider, en een klein pakketje literatuur meegekregen om te doorworstelen.

Misschien even kort voor de geïnteresseerde lezers die mij niet begeleiden in deze thesis, kort even mijn onderwerp voorstellen. In 2007 werd het doctoraat van Maarten Vanvolsem voorgesteld, een kunstwetenschapper aan de KULeuven. In dit doctoraat beschrijft (ondertussen dus dr.) Vanvolsem hoe we kunnen afstappen van het traditionele puntcameramodel dat een stilstaand beeld, een snapshot als het ware, oplevert. Hij gebruikte in zijn doctoraat een zogeten 'slit camera', die in plaats van een volledig beeld slechts een lijn oplevert per tijdseenheid. Door die camera gedurende meerdere tijdseenheiden te laten filmen en de film voort te draaien, kunnen dan meerdere tijdstippen tegelijk in beeld gebracht worden. Dit principe wordt ook gebruikt in fotofinish camera's. Dr. Vanvolsem ging echter nog een stap verder, en bewoog ook nog met zijn camera tijdens het filmen. Dit leverde dus niet alleen temporele, maar ook ruimtelijke diversiteit op in zijn beelden (anders gezegd, meerdere plaatsen én tijdstippen in één beeld). Dit levert mooie beelden op, zoals u kan zien op http://associatie.kuleuven.be/ivok/docindekunsten.htm#vanvolsem
Het doel van mijn thesis is nu om dit concept te gaan toepassen op een virtuele scène via Computer Graphics. Ik zal dus een slitcameramodel moeten implementeren, die bovendien nog kan bewegen ook.

Maar terug nu naar mijn eerste meeting, waar ik dus een literatuurpakketje meekreeg. Het bestond uit drie papers, en een bundeltje met oude artikels over fotografie in de late 19de en vroege 20ste eeuw, waarin onder andere het puntcameramodel en het slitcameramodel beschreven worden. Dat leek mij wel een fijn beginpunt om aan mijn literatuurstudie te beginnen.
Het eerste van de drie artikels, getiteld 'A One Dollar Photographic Outfit' (Scientific American, 4 juli 1891) gaat over een primitieve, lensloze puntcamera, een beetje zoals de schoendooscamera die we als avontuurlijke jonge jongetjes (en meisjes waarschijnlijk ook) wel eens gemaakt hebben. Klein gaatje in de voorkant van de schoendoos, en al het licht dat er doorkomt wordt gebundeld en vormt (ondersteboven) een beeld op de achterkant. Het enige verschil met mijn schoendoos was dat dit model ook nog een fotografische plaat aan de achterkant heeft om het beeld blijvend te maken.
Interessant is dat dit basisprincipe hetgene is dat momenteel ook het basis-uitgangspunt is van Ray Tracing-algoritmes in Computer Graphics. Geavanceerde raytracers maken wel gebruik van een soort fictieve lens om depth-of-field te genereren, maar het basisprincipe is nog altijd het puntcameramodel: we schieten stralen vanuit één punt door elke pixel, en gaan na welk object de straal raakt. Dan geven we die pixel de kleur van het object dat de straal heeft geraakt (na toepassing van shaders uiteraard).
Het tweede artikel, 'Lensless Photography' (Scientific American, 16 juli 1904) geeft een vergelijking tussen de puntcamera en de lenscamera. Een probleem van vroege puntcamera's was een mooi rond gaatje krijgen (dat meestal gefabriceerd werd door met een naald door een stukje zilverpapier te prikken). Dit leverde erg onscherpe beelden op. Dat probleem was ondertussen opgelost door een 'radioscoop' (een stuk koperplaat met een perfect rond geboord gaatje) te gebruiken. Dit levert nog steeds een minder scherp beeld op dan een lenscamera, maar een veel zachter kleurverloop (in die tijd natuurlijk nog grijswaarden). Een ander zeer belangrijk verschil is dat met een puntcamera alle delen van de foto in focus zijn, terwijl een lens uiteraard enkel objecten op een bepaalde afstand perfect in focus heeft. Het artikel beschrijft ook een aantal nuttige aanwendingen voor de puntcamera: het kan goed gebruikt worden voor portretten, maar ook zaken die scherp moeten zijn zoals kopieën. Hiervoor werkt volgens Scientific American de lenscamera minder goed, omdat een lens vaak scherper focust dan het oog, wat een onnatuurlijk effect in de kopie veroorzaakt. Een ander nadeel van de puntcamera is echter wel dat de exposure-tijd langer is dan met een lenscamera, omdat het licht trager binnenkomt in de camera.
Het derde artikel tenslotte, getiteld 'The Slit Camera' (Scientific American, 15 februari 1916) beschrijft het slitcameramodel, ontwikkeld door Wolfgang Otto. Het primaire nut voor dit cameramodel was toen het ontwikkelen van vervormde beelden (iets dat nu meteen kan door een transformatiematrix toe te passen op een digitaal beeld). Het basissysteem van de camera is min of meer hetzelfde als dat van de puntcamera, alleen is het vlak met de puntopening vervangen door twee vlakken met een spleet erin. Hierin is veel variatie mogelijk: de spleten kunnen recht of gekromd zijn, de breedte kan variëren, en de afstand van de partities tot het beeld kan ook vrij gevarieerd worden. Ook de partities zelf mogen gekromd zijn, of een hoek vormen met het beeld. Er kunnen ook meerdere spleten in één partitie worden gemaakt. Dit levert duidelijk een hoop parameters op voor het cameramodel dat ik zal implementeren.
In de basiscamera die verder wordt besproken, wordt gewerkt met twee parallelle partities met in de ene een verticale spleet, en in de andere een horizontale. Dit levert een gescaleerd beeld op, waarin de schaling van de horizontale en verticale as zich verhouden als de afstanden van de twee spleten tot het beeldvlak. Het artikel merkt tenslotte nog op dat deze camera niet alleen een wetenschappelijke follie is, maar dat hij ook kan gebruikt worden om transformaties toe te passen op verscheidene beelden, een nut dat uiteraard in onze moderne tijden overgelaten wordt aan Photoshop, of zelfs het kleinste kind dat met MS Paint of Tuxpaint overweg kan.

Zo, dat was dan de eerste (kleine) literatuurstudie voor mijn thesis, en de officiële kick-off. Wat staat er mij nu nog te doen? Wel, duidelijk eerst de andere papers lezen en dezelfde uitvoerige behandeling geven als ik nu net gedaan heb met de artikels uit Scientific American. Die papers staan natuurlijk ook tsjokvol met (al dan niet) nuttige en interessante referenties, die ik ook ten volle moet uitpluizen. Na die literatuurstudie kan ik ook nog eens een studie maken van de verscheidene bestaande graphics frameworks die voorhanden zijn, om na te gaan in welk framework ik mijn nieuw systeem best kan inbouwen. En tegen dat dat afgerond is... jah, kan ik gaan implementeren, wat waarschijnlijk het grootste deel van het werk aan deze thesis wel zal zijn.
Natuurlijk kan u de vooruitgang hier volgen.

Tot de volgende,
Ben