[MINC-development] Draft API for MINC 2.0

[Robert VINCENT]

On Mon, 16 Jun 2003, Andrew Janke wrote:

> Are you really really sure you want to add more data types?  (COMPLEX, etc) I
> for one was happy with the idea of a 'vector_dimension/complex_vector' for these
> as it allowed a fair bit more flexibility.
>

My assumption was that adding some intrinsic support for complex data
would be useful, and that we would ultimately allow arbitrarily-sized and
-structured voxel values.  So nothing would prevent you from continuing to
use a vector type.  Remember that 99% of the traditional MINC ways of
accomplishing things should continue to work!

> Do you return a pointer to a double and assume that double++ will contain the
> second part of the complex data point?  or do you return a struct?  or do you
> have a set of special functions like this:
>
>    get_complex_voxel_value(starts[], double *real, double *imag)
>

I think we would standardize the layout of the complex data types (real
first, imaginary second) so that a complex could reliably be returned as a
"C" structure or an array of alternating values (real0, imag0, real1,
imag1, etc...).  Some flavor of get_voxel_value() will just take a void *
and "do the right thing" based on the requested type.

>
> On a similar note, (and I don't know their real purpose yet), is there really a
> good reason to introduce things such as "TALAIRACH" types into a data format?
> these are head CT/MRI specific things are they not?  By all means include them
> but I would have thought such a thing was better included as a user attribute
> using some C/L tool. Granted you have included it as what appears to be an
> optional extra.
>

I don't know its true utility, but this is just a carryforward of the
"spacetype" attribute that was already specified in MINC 1.0.
MIspacetype, MI_TALAIRACH, MI_CALLOSAL etc. are already defined in minc.h

	-bert