Scientific Data

1. What coordinate system should I use?
2. What if I have to enlarge or shrink the data?
3. Volume data issues
4. How's the data repository structured?
5. What's the naming convention for data subdirectories in the repository?

1. What coordinate system should I use?

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

Top

2. 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.)

Top

3. 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 .... ???????

Top

4. 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.

Top

5. 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

Top