Archive pour 26 juillet 2008

open source and scientific 3D and utilities cmake

VTK The Visualization ToolKit (VTK) is an open source, freely available software system for 3D computer graphics, image processing, and visualization used by thousands of researchers and developers around the world.
ITK The Insight Segmentation and Registration Toolkit (ITK) is an open-source software system to support the VisibleHuman Project. Currently under active development, ITK employs leading-edge segmentation and registration algorithms in two, three, and more dimensions.
CMake CMake, a cross-platform, open-source make system is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice.
CDash CDash, an open source, web-based software testing server. CDash aggregates, analyzes and displays the results of software testing processes submitted from clients located around the world.
ParaView ParaView is an open-source, multi-platform, parallel scientific visualization application. Although it can be run on a single processor, ParaView is specifically designed to run on distributed parallel computers.


The Visualization ToolKit (VTK) is an open source, freely available software system

VTK has been installed and tested on nearly every Unix-based platform, PCs (Windows 98/ME/NT/2000/XP), and Mac OSX Jaguar or later.


technical paper:

Technical Overview: Software

  • Over 700 C++ classes
  • 350,000+ lines of C++ code (110,000 executable lines)
  • Designed using the approach of Rumbaugh et al. ( Object-Oriented Modelling and Design from Prentice-Hall)
  • 215,000+ lines of automatically generated Tcl wrapper code (similar counts for Python and Java)
  • In-line documentation (both in-code and man pages)
  • Easy to understand C++ code (honest!)
  • Designed to be extensible
  • Lots of examples, applications, test cases, and data
  • Supports portable multithreading and distributed memory for parallel algorithms (download J. Ahrens’s (Los Alamos Nat’l Lab) VTK Parallel Paper).

Technical Overview: 3D Graphics

  • Surface Rendering
  • Volume Rendering
    • A flexible software ray casting implementation
    • Supports texture-based volume rendering
    • Support for VolumePRO volume rendering hardware
    • Supports mixing opaque surface geometry and volume rendering
  • Rendering Primitives
    • points
    • lines
    • polygons
    • triangle strips
    • volumes
  • Interactive Viewer/Renderer « 3D Widgets » for interacting with data
  • Properties
    • ambient, ambient color
    • diffuse, diffuse color
    • specular, specular color
    • color (lights & object)
    • transparency
    • texture mapping
    • shading (flat/Gouraud)
    • backlighting on/off
  • Lights
    • infinite
    • spot
  • Cameras
    • parallel and perspective projection
    • nice methods like elevation, azimuth, zoom, reset
    • automatic camera/light creation

  • Device Independent C++ code and/or Tcl, Java, Python scripts are independent of renderer type. Renderer type set at run-time with environment variable.

  • Graphics Model
    • Lights illuminate the scene
    • Cameras define viewpoint
    • Actors specify geometry/properties
    • LOD actors support manual and automatic generation of level-of-detail to support interactive rendering for even the largest models.
    • Assemblies group actors into arbitrary hierarchies
    • Mappers define geometry/link into visualization pipeline
    • Renderers coordinate lights, cameras, actors to create image
    • Volumes are a type of actor with their own special properties

  • Special Features
    • Multiple windows/viewports
    • Red/blue stereo
    • Crystal eyes stereo
    • Motion and focal blur
    • Backface/frontface culling of polygons
    • Save images to various file formats including png, jpeg, tiff, bmp and ppm.

Technical Overview: Visualization

  • Data Types:
    • polygonal data (points, lines, polygons, triangle strips)
    • images and volumes (i.e., structured point datasets)
    • structured grids (e.g., finite difference grids)
    • unstructured grids (e.g, finite element meshes)
    • unstructured points
    • rectilinear grids

  • Cell Types:
    • vertex, poly-vertex
    • line, poly-line
    • triangle
    • triangle strip
    • pixel
    • quadrilateral
    • polygon
    • tetrahedron
    • voxel
    • hexahedron
    • wedge
    • pyramid

  • Attribute Types:
    • scalars (single valued plus grayscale, grayscale-alpha, rgb, and rgb-alpha).
    • vectors
    • 3×3 tensors
    • normals
    • texture coordinates (1-3D)
    • field data

  • Scalar algorithms
    • color mapping
    • carpet plots
    • iso-contouring: marching cubes
    • iso-contouring: dividing cubes
    • thresholding
    • scalar generation from other data (elevation, velocity, etc.)

  • Vector algorithms
    • hedgehogs
    • streamlines
    • dashed streamlines
    • stream points
    • stream surfaces
    • streampolygon
    • displacement plots/warping

  • Tensor algorithms
    • tensor ellipsoids
    • tensor glyphs
    • hyper-streamlines

  • Information Visualization
    • parallel coordinates
    • programmable glyphs
    • splatting
    • dimension reduction

  • Modelling algorithms
    • spheres, cones, cylinders, cubes, lines, planes, etc.
    • axes, cursors, text, outlines
    • implicit modelling
    • decimation
    • texture thresholding
    • boolean textures
    • glyphs
    • cutting
    • clipping (2D and 3D)
    • probing
    • normal generation
    • connectivity
    • triangle strip generation
    • linear and rotational extrusion
    • splatting
    • swept surfaces/volumes
    • multi-variate visualization
    • scattered/unstructured point visualization
    • appending, merging, cleaning data
    • 2D & 3D Delaunay triangulation (including alpha shapes)
    • Laplacian & Windowed sinc mesh smoothing
    • Surface reconstruction

  • Data Interface (Readers/Writers treat a single dataset; Importers/Exporters treat a scene.) variety of polygonal formats including stereo-lithography, MOVIE.BYU, Cyberware, etc.

    • our own VTK formats (including a parallel XML format) for all data types
    • Inventor Writer, IV Exporters
    • 3D Studio Importer
    • PLOT3D
    • PNM
    • RIB (RenderMan) Exporter
    • SLC (Volume) Reader
    • TIFF Writer
    • VRML Exporter
    • Wavefront .OBJ Exporter, .OBJ Reader
    • BMP reader and writer
    • Raw image formats

  • Visualization Pipeline Demand-driven data-flow with automatic network updates

    • Reference counting to reduce memory requirements
    • Uses sources, filters, mappers to start, process, and terminate network
    • Network looping and feedback supported
    • Strongly type-checked to enforce filter connectivity
    • Supports multiple input / multiple output filters

  • Annotation
    • 2D and 3D text
    • Scalar bar (scalar to color index)
    • x-y plots
    • Flying axes
    • Overlay plane drawing
    • Attach overlay annotation to 3D positions

Technical Overview: Imaging

  • Features
    • Uses cached, streaming pipeline so that you can operate on gigantic datasets (i.e., deals with pieces of data). This is done completely transparently.
    • Most imaging filters are multi-threaded for parallel execution
    • Fully integrated with 3D graphics/visualization pipeline

  • Filter types (a quick summary)
    • diffusion filters
    • Butterworth, low-pass, high-pass filters
    • dilation, erosion, skeleton
    • convolution
    • difference, arithmetic, magnitude, divergence, gradient, mean
    • distance
    • FFT
    • Fourier, Gaussian, Sobel
    • histogram
    • threshold
    • permutation, conversion, padding

In A Nutshell

  • What’s Cool About VTK
    • It’s free (although the books help!)
    • Easy to create graphics/visualization applications
    • C++ source code – you have a lot of control
    • Easy to derive new classes
    • Can prototype or build applications using « interpretive » languages Tcl, Python, and Java
    • User interface can be created fast with Tk or Java GUI class libraries
    • Can learn about graphics / visualization / imaging
    • Supports an extensive palette of 3D widgets
    • Platform/rendering library independent
    • Lots of advanced and very useful algorithms
    • Integrated software, not a bunch of unreleated snippets of code
    • You can convert data into pictures
    • Object-oriented
    • Heavily tested in real-world applications…not academic code
    • Large user base provides decent support
    • Commercial support and consulting available

  • What’s UnCool About VTK
    • Not a super-fast graphics engine…VTK uses C++ dynamic binding and a device independent graphics model.
    • C++ source code (so use Tcl, Python, or Java)
    • Very large…not a toy…you’ll need a decent system to use it effectively

The installer for the Windows platform contains vtk.exe which is essentially a wish.exe replacement that allows you to run VTK TCL scripts without doing any other installation or configuration. Tcl/Tk 8.4.13 is statically linked into the 5.0.4 build of vtk.exe. For Python or Java support, or for Linux or Macintosh systems, you will have to compile VTK from source code using CMake and a native build system for your platform.

Unsupported Linux Pre-Compiled Binaries (RPMS)

You can download RPMS for VTK from Creatis VTK web page. Thanks go to the Creatis team at Insa-Lyon (France) for maintaining them. Questions regarding these packages should be forwarded to a Creatis representative.You can also:

2matlab program packages for functional neuroimaging analysis

some matlab program packages for functional neuroimaging analysis.

The Lyngby Toolbox is a Matlab program package for functional neuroimaging analysis. The toolbox contains a number of models: FIR-filter, Lange-Zeger, K-means clustering among others, visualizations and reading of neuroimaging files.

The Brede Toolbox is a neuroinformatics toolbox primarily written in Matlab and it contains functions for handling bibliographic structures (such as PubMed/MEDLINE structure), volumes, sets of locations (3D Talairach coordinates), with transformation/analysis functions suchs as HTML and VRML generation, statistical analysis, affine transformations, functional volumes modeling with, e.g., independent component analysis, Corner Cube visualizations, … It also contains the Brede Database distributed as XML, see also the web-pages for the Brede Database that has visualizations of the data.


Marching Cubes code C++

marching cubes tuto and applet

the applet gives you the opportunity to view the algorithm running on different cases:

another tuto with codes:

« human visible project » impact on 3D …


Marching Cubes: Polygonisation

First we define a space size, this space is where the points in consideration for inclusion in our surface must reside. We could use a space of x-y-z size 320x320x320 for example.

Next we subdivide the space into a designated number of cubes in each direction, it doesn’t have to be the same number in each direction, but it’s advisable to keep the length of side of the cubes constant, otherwise you can get skewing of the surface.

A typical number of cubes might be 32x32x32, for our space above this gives us cubes of dimensions 10x10x10. Note that even small looking numbers of cubes like 32x32x32 are very large, 32x32x32 = 2^15 = 32,768 cubes.

The number of cubes and space size define how exact our constructed surface will be. The length of side of a cube is what counts in how accurate the constructed surface is, above 10x10x10 would probably give a pretty crappy looking surface. However, if we made our space a bit smaller, e.g. 160x160x160 it’d probably be very accurate.

Now, for marching cubes to work, we must be able to answer one question given any point and a surface: Is this point inside the surface? We’ll discuss answering this question in a moment, suppose for now, we always can.

We now generate the mesh of triangles to represent our surface.

Here is how it is done: for every vertex of every cube, we check is that vertex inside or outside the surface. This results in the fundamental cube configurations:

(i) The cube is totally inside the surface.
(ii) The cube is totally outside the surface.
(iii) Some of the cube’s vertices are inside, and some are outside of the surface (i.e. it intersects it).

The first two cases give us no information about rendering the surface. The third, however, if some are inside and some are outside, lets us find the intersection of the surface and the sides of the cube and generate some triangles to represent the surface at that intersection. To understand this here’s a diagram:

(btw, the surface is just represented by a line in this image, of course, it should be drawn in 3D)

So, if we can find the intersection of the surface and the cube sides, we’re all set to generate the mesh. There are two ways to do this, we’ll see the second one when we implement metaballs, the first one is binary search. Binary search works since we can always ask is the point inside or outside, and so we refine the estimate of the intersection of the surface and cube in the normal way.

So now we can generate those triangles to represent the surface as follows: Since every vertex of a cube can be either inside or outside the surface there are 256 possible triangulations, two of these are trivial, all outside, and all inside. So we have 254, as it turns out, by reflections and rotations of the cube there are only 15 different triangulations we have to special case in our code (e.g. we’d only have one special case for any one vertex of the cube outside the surface only, cutting our work down by 8 cases).

It sounds pretty boring to code the 15 special cases, the kind of boring code I try to avoid, so instead I do it a simpler way.

On Paul Bourke’s home page he uses some look up tables to get the triangulation. Here is how we do it: Each vertex outside is represented by a 1 and each vertex inside is represented by a 0, in binary, and we must have a consistent labeling system for our vertices. Then we generate an 8-bit index into the edge intersection table.

An example: Suppose vertices 5, 0 and 6 were outside (we number the vertices of a cube 0, 1, …, 7). Then we’d generate this index: 01010001. We then index an edge intersection table with that, and it gives us a 12 bit number (since a cube has twelve sides) telling us which sides of the cube are intersected, e.g. if edges 0, 1 and 2 were intersected then this number would pop out of the table: 000000000111. A ‘1’ representing an intersected edge for each bit of the number. Now we have to actually find the intersection and we have the mesh.

Finally we use our index again this time to index a triangulation table, which tells us which vertices to join to which in the mesh. These tables are provided with the sample source, and we’ll see below exactly how to do the above.

We’ve been doing things on a cube by cube basis, does this mean to actually generate the surface we have to go through EVERY cube in the space and check if its vertices are inside or outside the surface? Wouldn’t that be very slow? We don’t go through every cube in the space, because doing so would be too slow for realtime apps. Instead we use depth first search.

We simply note that every cube which intersects the surface is incident to at least one other cube which intersects the surface. So, given one intersecting cube we can just test all of the cubes touching it, and all the ones touching them, etc. So it’ll be recursive. Notice that each cube has eighteen incident cubes BUT we don’t need to recursively check all of them, only the ones stuck to its 6 faces, since when they recurse they will test the ones that it would have tested if we called it with all eighteen incident cubes. The termination condition for this recursive algorithm is when we reach a cube we have already encountered. Essentially what we are doing here is drawing the connected components of a graph.

a starting point for building 3D surface meshes or true volumetric tetrahedral grids

« nanosecond history »:


Since William Lorensen and Harvey Cline’s publication of Marching Cubes: A High
Resolution 3D Surface Construction Algorithm in 1987 Marching Cubes has become the
defining algorithm for the creation of 3D surface meshes.

Yet despite the success of Marching Cubes the resulting mesh exhibits several weaknesses, including aliasing and terracing artifacts, less-than-optimal triangle quality, and large numbers of triangles.  A
multitude of techniques have been introduced to address these issues, including surface
smoothing and triangle decimation algorithms. Beyond reducing artifacts, smoothing
improves the effectiveness of triangle decimation algorithms and reduces errors during
finite element analysis. However, many smoothing techniques fail to eliminate terracing
because their local filter neighborhood does not encompass the width of the terrace.
Additionally, smoothing a mesh without consideration of the original data may smooth
away crucial fine details as well as mesh generation artifacts.


In 1998 Sarah F. F. Gibson published Constrained Elastic Surface Nets: Generating
Smooth Surfaces from Binary Segmented Data. Her work attempts to preserve the fine
detail present in the original data by applying smoothing directly to the binary data and
introduces the concept of a constraint to limit the deviation of the smoothed data from the
Modified SurfaceNets attempts to apply Gibson’s SurfaceNet technique to the
problem of smoothing a Marching Cubes mesh. By defining SurfaceNet nodes on the
Marching Cubes mesh and constraining their movement to their Voronoi regions,
Modified SurfaceNets aims to reduce terracing while preserving the fine detail of the
original image.


and see this present bog :


This class of Surface Reconstruction methods is OK for immerged SURFACE and only for SURFACE.

If you want to generate not only surface models from your data but also to create true
volumetric tetrahedral grids suitable for advanced 3D finite-element simulations, then open your mind… Usually, these grids are constructed using a flexible advancing-front algorithm. Again, special care is taken to obtain meshes of high quality, i.e., tetrahedra with bad aspect ratio are avoided…

see a commercial software (with a quite good link with matlab):


In biophotonics, we have this process:

1/produce your images (exactly a stack of 2D images)

2/perform many image cleaning and many img processes with or without informations from the other images in the stack (often it is only a process for each image with imageJ)

3/the final step is segmentation & binarisation also with or without informations from the other images in the stack

4/generation of surface ( a/isosurface for rendering; b/ 3D surface mesh)

5/generation true  3D volumetric tetrahedral grids suitable for advanced 3D finite-element simulations

6/a 4D solver with time

7/statistics and comparison between biology, medical and multiphysics data and 4D simulations

mesh generators depend on a good a priori mesh size function

Mesh Size Functions:

Many mesh generators, including DistMesh, depend on a good a priori mesh size function. It should take into account curvature and feature size of the geometry, and external size functions such as user specifications or adaptive error estimators. In addition, the gradients of the size functions have to be bounded to ensure high quality elements. We compute curvature and feature sizes directly from the implicit geometry definition, and solve our gradient limiting equation to obtain an optimal size function.



Blog Stats

  • 221 476 hits


Flickr Photos

juillet 2008
« Juin   Août »