NAME: Scientific Data

QUESTION: What coordinate system should I use?

Use the coordinate system the data was given to you in.

QUESTION: What if I have to enlarge or shrink the data?

If you need to enlarge or shrink the data, scale the viewer not the
data in order to keep the data of constant value.

"Scaling the viewer" can be done easily by scaling the viewing
location and movements before setting or changing parameters on a
standard or head-tracked camera.  (See Java 3D's "Platform" concept
which is also used in GLUE via the "ROOM_TO_WORLD" transform.)

QUESTION: Volume data issues

Volume data
 - a "sample point" is located at the center of a voxel (typically????)
 - volumes may be given to you as arrays of samples, in index form (e.g., MRI)
 - a single 4x4 matrix can transform between index-space and a "world space".

Units
 - if you want to use a different metric (e.g., cm not feet), then use a
   4x4 transform to scale the data.
 - [*** Q: is this a pre-process operation or a per-call operation?  Each may 
   have advantages and disadvantages under different circumstances.  For
   example, if you will use many different units or only sample a few
   points, per-call may be more efficient.  If you will just change
   units once, pre-process may be more efficient.]

Registration
 - if you want to merge two data sets that are in different coordinate
   systems, find a 4x4 matrix that transforms points between the two
   spaces.  For non-linear registration, use .... ???????

QUESTION: How's the data repository structured?

The $G stuff is that same idea as what you used for cs237 and with the
particlevis stuff.  Docs are in $G/shared/man.  So, you should be pretty
cool with that.  The data idea is that there will always be a link to
visualization data at $G/data/.  Within that directory, we're still
trying to figure the organization out.  One thing is for sure, whatever
the organization is, it needs to be clear and documented and we need to
stick to it.  Leor is in the process of putting some MRI data into that
directory and this might help determine the structure, you 2 should meet
and talk more about it for sure..


I suggest something like this:

   this is where the         this is the format of the data
     data came from          nektar, would mean .rea, .rst files
          |                  pathlines is after it has been converted
          |                  to pathlines, pathlines-with-data is asf's
          |                  new format that dbk is using, and you
          |                  might want to use too, etc..
          |                       |
          V                       V
$G/data/nektar/bat/dataset-name/nektar
$G/data/nektar/bat/dataset-name/pathlines
$G/data/nektar/bat/dataset-name/pathlines-with-data
$G/data/nektar/bat/dataset-name/etc..


For the MRI stuff, it would be:

$G/data/dti/susumo1/raw
$G/data/dti/susumo1/streamtubes
$G/data/dti/susumo1/streamsurfaces
$G/data/dti/susumo1/T2-volume-256x256
$G/data/dti/susumo1/hair-volume-256x256
$G/data/dti/susumo1/hair-nvidia-compressed-volume-256x256
$G/data/dti/susumo1/etc..


Much of the data is a processed version of the original.  In each
directory where this is the case (pathlines derived from .rea .rst files
for example) there should be a Makefile that will remake the dataset if
anything should ever happen to it or we get a new one and want to use it
as an example.  So when you get jason's programs working to generate
pathlines, put a command in a makefile to call it automatically with the
correct settings for regenerating the dataset.

QUESTION: What's the naming convention for data subdirectories in the repository?

raw -- what came from an outside source
orig - what it was converted to in our local data formats


ENDFAQ: DO NOT DELETE THIS LINE