PaperAnalysis / OldPaperAnalysis

Paper Analysis

Currently in the state of early sketches the project (which is a master thesis project at center for image analysis, uppsala university / SLU. The aim of the project is to visualise a volume of paperfibre for presentation. In the volume segmentation between upper, center and lower surfaces should be visualized (and possible to remove during runtime). Currently the aim is to implement the Paper Analys volume rendering libraries as an extension to TempEngine.

Index

Diary

Plan

Explenations
DONE NOT DONE POSTPONED

Work to be done 'Week 31
  • Tuesday
    • Multiple callbacks for keyboard events.
    • Window class (container for widgets).
    • Widget class (a base for anything in the interface).
    • Button class.
    • Checked button.
  • Wednesday
    • Slidable menu (contains widgets).
    • Text field (simple for simple text).
  • Thursday
    • Interface containing:
      • a slidable menu on the left.
      • One button for each layer.
      • Zoom buttons
      • rotation buttons.
      • Cutting mode.
  • Friday
    • cut line.

  • Software
    • Improve normal calculations.
    • Improve buffer drawing.
    • Phong Shading Model.
    • Multiple Light Sources (might not be possible given time taken to calculate direction to a light source).
    • Optimise hit-point calculations.
    • User interaction.
    • Framework that can handle full screen.
  • Documentation
    • Most of it.
Week 20
  • Wednesday
    • Implement line drawing in 3d.
    • Adapt linedrawing to work with non square pixels.
  • Thursday
    • Create an image of a volume, not necessarily the required one.
    • Perform normal calculations.
    • Final documentation sweep.

Week 19
  • Wednesday
    • Test VTK and learn basics.
  • Thursday
    • Install VTK on office machine.
  • Friday
    • Transfer paper data to office machine and try to convert it to a format usable by VTK.

Week 18
  • Monday
    • Finish hitcalculations on the cube.
  • Tuesday
    • Read about line drawing schemes to create a line in the discrete space of the volume.
  • Wednesday
    • Adapt linedrawing to work with non square pixels. See week 20
    • Normal calculation of hitpoint (pre calculated?). See week 20
    • Create an image of a volume, not necessarily the required one. See week 20
    • Final documentation sweep. See week 20

Week 17
  • Monday:
    • Finish camera (a get ray in pixel x,y is needed).
    • Finish lights (analyze what properties and atributes are needed in a raytracer.
    • Create a more advanced material. (should basically have the same properties as light),
    • Create an image buffer.
  • Tuesday (early morning lecture, *sigh*):
    • Create a "volume" class. This class should be flexible and handle volumes of any size. Also it is necessary to create a file format that I want my volumes to exist in.
  • Wednesday (lab in image analysis all day).
  • Thursday:
    • Implement basics of a raytracer in the application.
    • Design a "Scene" class which will be rendered.
    • Implement hit calculations on a triangle to see that it works.
  • Friday, Saturday, Sunday
    • Read about hitcalculations on a cube.

API

A version of the API can always be found here. This API is updated irregulary (but usually before and after a big push).

Visualisation Options

Currently there are several popular ways of implementing volume rendering. I aim to produce realtime images which means that I need ways to handle the generally large sets of data which the program should handle. I will need to check up on memory compression models to reduce the size of memory. Using a traditional rendering method I could represent data as bit-vectors which would reduce size considerably. Interesting options for visualization include:
  • Shear Warp, I have not seen any implementation of this method but this (Lacroute, Levoy) paper from 1994 speaks highly of it, being able to render an image in 1s. Considering that this was 94 computer computing capacity has increased a great deal (so has requirements on graphical resultion).
  • Splatting, mentioned in the above paper seems to be the second fastest algorithm around (at the time). Which basically involves shooting voxels on the buffer rather than rendering them piecewise. Need to get more information.
  • Marching Cubes, which involves creating surfaces out of the voxels and then rendering the surfaces using traditional means i.e. OpenGL. This could be used but the amount of data generated would probably indicate that scaling of the data is needed before rendering. Also this method is probably more interesting when you have data that contains larger volumes (I suspect these volumes will be very stringy).
To produce a user interface for the program I'm inspecting several alternatives.
  • GTK, completely open source which makes it free to use on all platforms. It's availeble for both windows and linux. The drawback of a GPL:ed tool is that if publicly availeble my application can't be commercial. (I don't know if this is a problem with my instructor.
  • QT, was completely free but the development kit for windows is currently not free which means that it won't run under windows.
  • MFC, Microsoft Foundation Classes has the drawback that development under Linux is completely impossible and thus not really interesting (since I do most of my development under Linux).

Webmaster - Edit Page - Page Revisions - WikiHelp - SearchWiki - RecentChanges
Page last modified on October 21, 2004, at 02:06 PM