[MINC-development] MINC 2.0 draft

[Andrew Janke]

On Tue, 14 Jan 2003, Steve ROBBINS wrote:

> The changes proposed for the library code itself all seem reasonable.
> I worry a bit about changing the on-disk layout, since that will
> add complexity that can never be removed.

<big thumping tick>

> 1. Simple processing.  Scan through a file performing a computation on
> each voxel (or a neighbourhood of, say, 5x5x5 voxels) and perhaps writing the
> result to a new file.  Could be multiple input files.
> Think of mincmath or minccalc.

While you mention this, the fastest way I have found to prototype code to do
this is a mangy perl script of mine that calls mincreshape, minc_modify_header
and minccalc....  ie: create a few copies of the same file for all the offsets
you are interested in and then just use minccalc to fly through the volumes in
question doing your neighbourhood operation. :)

> I'm surely oversimplifying life here.  What kinds of access-patterns
> occur in your applications?

Very little apart from the ones you mention.

> 2. Visualization.  For large files, a multiresolution scheme that
> allows you to navigate through a low-res version and progressively
> fills in detail seems like a good idea.  It's less clear to me whether
> a block-structured file would help.  Would it?  Compression would
> likely be detrimental.

For the purposes of block-structured data and Visulisation, this is a bit of a
non-issue as OpenGL provides mip-mapping as it is. (from a high-res volume).
however for the sizes of most MINC volumes (excluding the MICe mob!) 256x256 is
ample.  This is all implemented in the recalcitrant viewnup.

> Visualizations would likely benefit from a multi-res layout if the file is too
> large to fit in memory.

Likely for home-grown visualisation, but not for OpenGL apps that use Texture
Mapping (the most logical choice for voxel data).



a