[Nipy-devel] data structures for brain surfaces

[mcc@uchicag...]

I can't speak for the rest of the nipy project, but pbrain has
two different types of geometric data visualization: 

1) electrode grids (represented by simple .csv files which
describe, 3d point by 3d point, a combination of 1-dimensional
'strips' or 2-dimensional 'grids'; derived from CT scans and
created with the 'loc3djr' pbrain application)

2) vtk mesh data (e.g., for our usage, a segmented cortex)
(represented by .vtk files of type STRUCTURED_POINTS; derived
from MRI scans segmented with ITK-Snap; registered to CT-scan
coordinate-space)

When 1) is loaded, triangle meshes are generated based on the
user-specified geometry (e.g. 1x8, 8x8) for each grid. When 2)
is loaded, the data (in our case, exported from ITK-Snap, and
consisting of a long binary list of 0s and 1s for every voxel)
is tossed through a vtkContourFilter (which transforms it into
a surface triangle mesh).

Currently, there isn't any way to import .vtk files of other
types. In the case of these OOGL-type files that you linked
to, the vtk POLYDATA format is probably the most similar, and
could easily be supported by pbrain (specifically, eegview's
'view3d' window, which renders everything via the vtk library.)

As far as I know, the python implementation/wrapping of vtk is
independent of numpy, and has its own vector/matrix/etc.
primitives. vtk does depend on opengl, but obviates (or at
least deeply discourages) the need for interacting with the
opengl interface directly.

mc

>Consider some simple geometric data files, eg:
>
>http://www.geomview.org/docs/oogltour.html
>
>how would you best work with them in nipy/pbrain?  Would you
read the
>data into a numpy array or matrix?  Would you use OpenGL data
structures
>or maybe VTK data structures?
>
>I assume that however this is done, the same process would
apply for
>data IO and visualization for surfaces derived from MRI
segmentation and
>tesellation (eg, freesurfer data, among others).
>
>I guess my preference is to try to stay close to any c/c++
wrapping.  If
>OpenGL, vtk, etc. are wrapped somehow (swig), I guess it's
best to use
>their functions directly.  However, the data structures
involved are not
>trivial and they are not necessarily portable from one
package to another.
>
>I'm wondering about how pyOpenGL and pyVTK relate to the numpy
>developments.  maybe there is no dependency of pyOpenGL or
pyVTK on
>numpy?  Maybe they do depend on numpy, are they catching up
with the new
>numpy?