[MINC-development] mincfft. was: [geeks] vector_diemsion and rawtominc

[Peter NEELIN]

On Thu, 21 Nov 2002, Andrew Janke wrote:

> On Wed, 20 Nov 2002, Peter NEELIN wrote:
>
> > Yes. I think that the default behaviour is to use the minc library magic
> > to make everything scalar. There is a volume_io option that allows this to
> > be turned off (I don't have time to look it up right now). Be warned,
> > however, that volume_io uses pointers to pointers to pointers for its
> > arrays (it was faster that way at the time that David benchmarked it). The
> > down side of this is that a complex vector short volume will have as much
> > pointer as data, even on a 32-bit system (one pointer for every 4 bytes of
> > data).
>
> Hrm, I see.  So what you are saying is: rewrite it using ICV's like you should
> have in the first place you slacker. :)

No, not really. You can still use volume_io. I looked it up - you just
need to declare "minc_input_options options;" and then call

   set_default_minc_input_options( &options );
   set_minc_input_vector_to_scalar_flag( &options, FALSE );
   if ( input_volume( ..., &options ) != OK )
   {
   }

As for the memory issue, you could either ignore it, or try to work around
it by loading two separate scalar volumes that do not include
vector_dimension (I think that you need to use advance_volume to get to
the second volume). I have not tried this, but if you can get volume_io to
treat the vector_dimension like any other dimension, it should work fine.
I believe that your current volume (with a name other than
vector_dimension) should suffer from the same issue if it is the
fastest-varying dimension of the file. Given enough memory, you would not
have noticed this problem.

            Peter
----
            Peter Neelin (neelin@bic.mni.mcgill.ca)