From a.janke at gmail.com  Sun Aug  2 09:21:49 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 2 Aug 2009 23:21:49 +1000
Subject: [MINC-users] EMMA replacement?
In-Reply-To: <e12172550907311340k6d28a729qdbcd9b46013f8ceb@mail.gmail.com>
References: <e12172550907281210p7679f969n3ddb2ba13f2bc91c@mail.gmail.com> 
	<Pine.LNX.4.64.0907301551280.13576@grumio.bic.mni.mcgill.ca> 
	<6fe841c70907301401h491f5d36g33d66238b7fbea78@mail.gmail.com> 
	<Pine.LNX.4.64.0907301718450.17684@grumio.bic.mni.mcgill.ca> 
	<a04b995f0907311004n6e80d7p900777ad1501161@mail.gmail.com> 
	<e12172550907311340k6d28a729qdbcd9b46013f8ceb@mail.gmail.com>
Message-ID: <d747ed50908020621p4e32c000je3c5249f97865df6@mail.gmail.com>

On Sat, Aug 1, 2009 at 06:40, EJ Nikelski<nikelski at bic.mni.mcgill.ca> wrote:
> ? ?Thanks Pierre for sharing your views and experiences. ?Matlab does
> indeed seem to be the currently reigning champ with regard to
> high-level multi-platform image manipulation software. ?Of course,
> most compelling is the fact that it can certainly do the job, as
> evidenced by Pierre's work, as well as by that done by the SPM group.

Agree, Matlab is a nice albeit expensive toy, especially if you decide
to run it on a 1000CPU cluster.

> ? Firstly, and quite significantly, IMHO Octave
> is a second class citizen, which simply looks like an inferior Matlab
> wanna-be. ?I've been following Octave for years, and its development
> has always been stop-and-go, and the developers really don't seem
> willing to plot their own course. Personally, I would think long and
> hard before hitching my wagon to Octave.

Why so cautious? I use Octave on a daily basis (with NIAK -- thanks
Pierre!) and have not hit any bumps. If things do go wonky just pull
out the chequebook and run your code on MATLAB. The differences for
numerical code (not display/etc) are minimal.

The other advantage of Octave/Matlab that hasn't been discussed is the
ability to transform critical routines to C code by using the API
instead of scripting. Note that as of yet I haven't had to resort to
this as like Jason if I find an nice discrete area than needs
en-fastening I simply write a quick MINC program to achieve the same.

> ?But wait, there's more! R can also make use of multiple
> cores, permitting easy parallelization (sp?) of processing (see the
> "doMC" and "foreach" packages).

I wouldn't choose your platform based upon whether it can parallelise
things, I generally find parallel code is an evil thing to debug and
in any case nearly everything I do is "embarrassingly parallel"
meaning 1000 patients on 1000CPUs, certainly makes it easier to
schedule things on a large cluster as you don't have to wait for 10
CPU's to become available to run your magic parallel program. It also
becomes very easy to "game" a shared parallel cluster by making sure
that your jobs can fill in all the spare 1 cores left over from large
parallel jobs that need x CPU's when the cluster has x+4 CPU's.

> ?Finally, nobody has addressed the gorilla in the room --- has
> nifti-1 basically already killed minc, making all of this rather
> academic?

Well this conversation for one would say no. There are still a number
of "good things" and "killer features" in MINC that Nifti-1 doesn't
have. Still I don't see them as competitors, they both serve their
purpose, I use Nifti-1 on a weekly basis to transfer data to other
labs, (and thus have to daily deal with L-R issues.....) I am slowly
educating them all but it takes time.... ;)

One thing that hasn't been mentioned in this discussion (yet) and
should be considered is that of the hairy issue of Licensing. Be very
sure that if you are developing something that you hope to (possibly)
use for commercial gain in the future that you figure out what your
responsibilities are.


--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883


From a.janke at gmail.com  Tue Aug  4 01:39:29 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 4 Aug 2009 15:39:29 +1000
Subject: [MINC-users] volume_io
In-Reply-To: <Pine.SGI.4.58.0907101421180.2533737@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0907101421180.2533737@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50908032239n76411ccek825557418d9309f7@mail.gmail.com>

Hi Anthonin,

Don't think I replied to this so here goes.

On Sat, Jul 11, 2009 at 04:38, Anthonin
REILHAC<anthonin at bic.mni.mcgill.ca> wrote:

> I would like to read a whole minc file (time,z,y,x) in one shot (using
> input_volume) and save it back in one shot using ouput_volume().
> When I do this, the min/max values per xy-slice the original file
> contains are lost, and replaced by min/max values for the whole 4D volume.
>
> Is there a way to fix this?

In short no. Your best bet is if you really really want to retain
precision to this degree is to first convert the volume to float or
double (either before you read in your volume or in your code). Once
you have done this then slice scaling and max and min values become
irrelevant.

> Also, I am trying a variant: I load the whole volume with
> input_volume in a Volume variable and
> save the same volume back (using the same Volume variable) in a new file,
> xy-slice wise (using loops over time and z), with
> output_volume_to_minc_file_position() function. But this does not work.
> In this last variant, should the Volume passed to
> output_volume_to_minc_file_position be of the dimension of the subset of
> the whole volume we want to write on disk(of a xy-slice?) or
> can it be of the dimension of the whole volume and we specify the part we
> want to write with volumes_counts and file_start?

I am not quite sure what you mean here. Perhaps post some code and I
might be able to figure out exactly what you mean.


--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From anthonin at biospective.com  Tue Aug  4 13:01:03 2009
From: anthonin at biospective.com (Anthonin Reilhac)
Date: Tue, 4 Aug 2009 13:01:03 -0400
Subject: [MINC-users] volume_io
In-Reply-To: <d747ed50908032239n76411ccek825557418d9309f7@mail.gmail.com>
References: <Pine.SGI.4.58.0907101421180.2533737@yorick.bic.mni.mcgill.ca>
	<d747ed50908032239n76411ccek825557418d9309f7@mail.gmail.com>
Message-ID: <44da421f0908041001kdcf6277h5df3c2cfc6972bb9@mail.gmail.com>

Hi Andrew,

>
>
> > I would like to read a whole minc file (time,z,y,x) in one shot (using
> > input_volume) and save it back in one shot using ouput_volume().
> > When I do this, the min/max values per xy-slice the original file
> > contains are lost, and replaced by min/max values for the whole 4D
> volume.
> >
> > Is there a way to fix this?
>
> In short no. Your best bet is if you really really want to retain
> precision to this degree is to first convert the volume to float or
> double (either before you read in your volume or in your code). Once
> you have done this then slice scaling and max and min values become
> irrelevant.



Ok. Thanks for your answer.
Very helpful.




>
>
> > Also, I am trying a variant: I load the whole volume with
> > input_volume in a Volume variable and
> > save the same volume back (using the same Volume variable) in a new file,
> > xy-slice wise (using loops over time and z), with
> > output_volume_to_minc_file_position() function. But this does not work.
> > In this last variant, should the Volume passed to
> > output_volume_to_minc_file_position be of the dimension of the subset of
> > the whole volume we want to write on disk(of a xy-slice?) or
> > can it be of the dimension of the whole volume and we specify the part we
> > want to write with volumes_counts and file_start?
>
> I am not quite sure what you mean here. Perhaps post some code and I
> might be able to figure out exactly what you mean.


Yes me too, now that I have read it again ;)

Anthonin



>
>
>
> --
> Andrew Janke
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From nikelski at bic.mni.mcgill.ca  Wed Aug  5 18:20:39 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Wed, 5 Aug 2009 18:20:39 -0400
Subject: [MINC-users] minc2 api question - miget_volume_dimensions
Message-ID: <e12172550908051520o117f9c0ak559e7084c5087ad3@mail.gmail.com>

Hi all,

   Ok, when I went to college, we were taught Cobol and RPG, and ever
since, I've been struggling with pointers.  I am coding a call to
miget_volume_dimensions (minc2 API), and when I allocate the
dimensional information to the stack, it all works fine.  If, however,
I want to get fancy and allocate to the heap, I get a heap load of
trouble from the compiler (default Apple gcc on 10.5).  For example,
consider:

midimhandle_t		*dimensions;    // declare pointer

/* get the dimension info for all dimensions*/
dimensions = (midimhandle_t) malloc( sizeof(struct midimhandle_t) *
nDimensions );
result = miget_volume_dimensions(minc_volume, MI_DIMCLASS_ANY,
MI_DIMATTR_ALL, MI_DIMORDER_FILE, nDimensions, dimensions);

  I get a compiler error on the malloc line:

minc2_io.c:141: error: invalid application of ?sizeof? to incomplete
type ?struct midimhandle_t?
minc2_io.c:141: warning: assignment from incompatible pointer type

  I am willing to bet real money that I'm doing something
embarrassingly stupid.  Any ideas?

-Jim

-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University


From nikelski at bic.mni.mcgill.ca  Wed Aug  5 19:14:55 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Wed, 5 Aug 2009 19:14:55 -0400
Subject: [MINC-users] minc2 api question - miget_volume_dimensions
In-Reply-To: <200908052254.n75Msmlj024478@grumio.bic.mni.mcgill.ca>
References: <e12172550908051541q7f95b897td2d10dd3e8c8a2ce@mail.gmail.com>
	<200908052254.n75Msmlj024478@grumio.bic.mni.mcgill.ca>
Message-ID: <e12172550908051614g27372cb9jf15b3f5a0f693f92@mail.gmail.com>

Hi Claude (and list),

  Yes. That compiles and runs without a seg fault (always a bonus).
Although I'm a little confused by the fact that when I do a
"printf("Size of:%d.\n", sizeof(midimhandle_t));", I get a size of 4
(the pointer, I suppose).  Should malloc not be allocating enough
space for the entire struct?

  Anyways, nuff work for one day -- I'm off to feed the beagle.

Thanks,

-Jim


On Wed, Aug 5, 2009 at 6:54 PM, Claude LEPAGE<claude at bic.mni.mcgill.ca> wrote:
>> > On Wed, Aug 5, 2009 at 6:29 PM, Claude LEPAGE<claude at bic.mni.mcgill.ca> wrote:
>> >>>
>> >>> midimhandle_t ? ? ? ? *dimensions; ? ?// declare pointer
>> >>>
>> >>> /* get the dimension info for all dimensions*/
>> >>> dimensions = (midimhandle_t) malloc( sizeof(struct midimhandle_t) *
>> >>> nDimensions );
>> >>
>> >> Try this:
>> >>
>> >> ? ? ? ? ? ? = (midimhandle_t*) malloc( ... )
>
> I deleted the original message, so I no longer have the 1st error. But
> let me guess...
>
> midimhandle_t is a typedef of a struct, so don't use struct.
>
> dimensions = (midimhandle_t *) malloc( sizeof( midimhandle_t ) * nDimensions );
>
>
>
>



-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University


From nikelski at bic.mni.mcgill.ca  Thu Aug  6 12:19:09 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Thu, 6 Aug 2009 12:19:09 -0400
Subject: [MINC-users] minc2 API - miget_space_name yields unexpected results
Message-ID: <e12172550908060919i101d94ffgefb1e4294e95329f@mail.gmail.com>

Hi List,

   A quick question for the minc2 users out there.  I'm calling
miget_space_name in order to get the space type (tal, native, etc),
but am always getting "native____" returned (even for Tal volumes).
The doc states that MI_NATIVE is returned if type is not found, so it
would seem as if the space type is not being found. Ok. So where is it
looking for the space type attribute?  This attribute is usually
attached to each dimension, so one would expect an midimension
argument would have to be passed, ... not so.  The call looks like
this:

int miget_space_name( mihandle_t volume, char **name );

  So, only the volume is passed.  Question is, where is it looking for
the space type? Is it looking at each dimension and grabbing the first
one where it finds the space type? If so, we may have a bug. Or is it
looking somewhere else? My current mincy environment is at 2.0.15.
Ideas?  Is anyone using the minc2 API?

-Jim


-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University

From a.janke at gmail.com  Fri Aug  7 10:54:06 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Sat, 8 Aug 2009 00:54:06 +1000
Subject: [MINC-users] minc2 API - miget_space_name yields unexpected
	results
In-Reply-To: <e12172550908060919i101d94ffgefb1e4294e95329f@mail.gmail.com>
References: <e12172550908060919i101d94ffgefb1e4294e95329f@mail.gmail.com>
Message-ID: <d747ed50908070754h6cf7ac3aq4bc2900baec8fcc1@mail.gmail.com>

Hi Jim,

> ? A quick question for the minc2 users out there. ?I'm calling
> miget_space_name in order to get the space type (tal, native, etc),
> but am always getting "native____" returned (even for Tal volumes).
> The doc states that MI_NATIVE is returned if type is not found, so it
> would seem as if the space type is not being found.

Correct.

> Ok. So where is it looking for the space type attribute?

Attached to each dimension.

> ?So, only the volume is passed. ?Question is, where is it looking for
> the space type? Is it looking at each dimension and grabbing the first
> one where it finds the space type?

In general the spacetype will be set the same for all the (image)
dimensions. In any case as per:

http://en.wikibooks.org/wiki/MINC/Reference/MINC1-programmers-reference

You will note that the spacetype really only defines if the MINC
file's co-ordinate system is WRT a scanner (MI_NATIVE) or some other
space (MI_TALAIRACH for example). In short while the convention may
have been a good thing to think about when MINC was implemented it is
not used much (at all). minctracc at one stage set this variable IIRC.

The only program that I know that uses this value is mnc2nii in an
attempt to set the S-form and Q-Form matrices in some sensical form.

So my advice is to just ignore it unless of course you have a (real
good!) reason as very few other MINC programs will take notice of this
variable.


--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883


From nikelski at bic.mni.mcgill.ca  Fri Aug  7 11:54:45 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Fri, 7 Aug 2009 11:54:45 -0400
Subject: [MINC-users] minc2 API - miget_space_name yields unexpected
	results
In-Reply-To: <d747ed50908070754h6cf7ac3aq4bc2900baec8fcc1@mail.gmail.com>
References: <e12172550908060919i101d94ffgefb1e4294e95329f@mail.gmail.com>
	<d747ed50908070754h6cf7ac3aq4bc2900baec8fcc1@mail.gmail.com>
Message-ID: <e12172550908070854l326bd937y7b9fb78ded969651@mail.gmail.com>

Hi All,

   Andrew, thanks for the explanation.  So, I'm correct in assuming
that the API call *should* be returning the space type that is
generally attached to each dimension.  So, if you look at some sample
minc header output ...

        double zspace ;
                zspace:length = 181 ;
                zspace:varid = "MINC standard variable" ;
                zspace:vartype = "dimension____" ;
                zspace:version = "MINC Version    1.0" ;
                zspace:comments = "Z increases from patient inferior
to superior" ;
                zspace:spacing = "regular__" ;
                zspace:alignment = "centre" ;
                zspace:step = 1. ;
                zspace:start = -72. ;
                zspace:units = "mm" ;
                zspace:spacetype = "talairach_" ;

... miget_space_name *should* be returning the attribute stored under
"zspace:spacetype"="talairach_", correct?  Pls let me know if I'm
looking at the wrong field.  On the other hand, if I am looking at the
correct attribute, then I'd like to suggest:

(1) If the API call does not work, it should either be fixed or removed.

(2) The failure of the call could be indicative of another error.
Specifically, I believe that I ran into this problem approximately a
year ago, and found that the failure was due to an error in the
attribute search function which is called by miget_space_name.  I may
be mis-remembering this, but I'm pretty certain.  I dunno whether this
general attribute search problem was fixed in minc 2.0.16 or not.

(3) Although you suggest that this field is not heavily used, I've (1)
usually seen that it *is* set in the volumes that I'm processing, and
(2) I've never seen it set incorrectly.  As such, it should permit one
to do a quick check to see whether a given volume is in stereotactic
space or not -- which is certainly useful (or can be).

Cheers,

-Jim

On Fri, Aug 7, 2009 at 10:54 AM, Andrew Janke<a.janke at gmail.com> wrote:
> Hi Jim,
>
>> ? A quick question for the minc2 users out there. ?I'm calling
>> miget_space_name in order to get the space type (tal, native, etc),
>> but am always getting "native____" returned (even for Tal volumes).
>> The doc states that MI_NATIVE is returned if type is not found, so it
>> would seem as if the space type is not being found.
>
> Correct.
>
>> Ok. So where is it looking for the space type attribute?
>
> Attached to each dimension.
>
>> ?So, only the volume is passed. ?Question is, where is it looking for
>> the space type? Is it looking at each dimension and grabbing the first
>> one where it finds the space type?
>
> In general the spacetype will be set the same for all the (image)
> dimensions. In any case as per:
>
> http://en.wikibooks.org/wiki/MINC/Reference/MINC1-programmers-reference
>
> You will note that the spacetype really only defines if the MINC
> file's co-ordinate system is WRT a scanner (MI_NATIVE) or some other
> space (MI_TALAIRACH for example). In short while the convention may
> have been a good thing to think about when MINC was implemented it is
> not used much (at all). minctracc at one stage set this variable IIRC.
>
> The only program that I know that uses this value is mnc2nii in an
> attempt to set the S-form and Q-Form matrices in some sensical form.
>
> So my advice is to just ignore it unless of course you have a (real
> good!) reason as very few other MINC programs will take notice of this
> variable.
>
>
> --
> Andrew Janke
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia ? ?+61 (402) 700 883
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University


From nikelski at bic.mni.mcgill.ca  Fri Aug  7 19:02:57 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Fri, 7 Aug 2009 19:02:57 -0400
Subject: [MINC-users] Reading time-width data with minc2 API
Message-ID: <e12172550908071602s3c8f83a0na10edad29c65e916@mail.gmail.com>

Hi List (yet again),

   I have a 4-d volume (time, zspace, yspace, xspace) and I need to
read the time-related information, specifically the offset and width
info.  Looking at the volume itself, I can see 34 values each for the
"time" and "time-width" variables.

"miget_dimension_offsets" (minc2 API) had no trouble pulling in the 34
"time" values, however, I'm stumped on how to read in the 34
"time-width" values.  I tried "miget_dimension_widths" and got zeros.
Am I using the correct API call?  Here's what I'm doing ...

-----------------------------------------------------------
midimhandle_t		*dimensions;
double			time_widths[34];

result = miget_dimension_widths(dimensions[0], MI_ORDER_FILE, 34, 0,
time_widths);
if ( result == MI_ERROR ) { error("Error returned from
miget_dimension_widths.\n"); }
-----------------------------------------------------------

   Forgive the hard-coding of 34 ... I'm testing.  My immediately
preceding call to "miget_dimension_offsets" (also using dimensions[0])
worked just fine.  Any idea what's going on here?

Thanks,

-Jim

-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University

From acaroli at fatebenefratelli.it  Fri Aug  7 19:08:14 2009
From: acaroli at fatebenefratelli.it (auto-reply from acaroli@fatebenefratelli.it)
Date: Sat, 08 Aug 2009 01:08:14 +0200
Subject: [MINC-users] Reading time-width data with minc2 API
In-Reply-To: <e12172550908071602s3c8f83a0na10edad29c65e916@mail.gmail.com>
Message-ID: <200908072310.n77N9dMZ000933@mail.bic.mni.mcgill.ca>

Thank you for your message.
I am out of office till August 31st with no access to e-
mail, and I will answer as soon as I come back.
Best regards

Anna Caroli

From claude at bic.mni.mcgill.ca  Fri Aug  7 19:45:20 2009
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Fri, 7 Aug 2009 19:45:20 -0400
Subject: [MINC-users] Reading time-width data with minc2 API
In-Reply-To: <e12172550908071602s3c8f83a0na10edad29c65e916@mail.gmail.com>
Message-ID: <200908072345.n77NjKp0006447@grumio.bic.mni.mcgill.ca>

Hi Jim,

ok, this one looks like a bug to me.

See libsrc2/dimension.c:

miget_dimension_widths(midimhandle_t dimension,
                       mivoxel_order_t voxel_order,
                       unsigned long array_length,
                       unsigned long start_position,
                       double widths[])
{

  /* Allocate space for the widths array
   */
  widths = (double *) malloc(diff*sizeof(double));

    for (i=start_position; i <= diff; i++) {
      widths[j] = dimension->width;
      j++;
    }

Well, the memory has been allocated from outside, so this malloc
simply redefines widths to be some new location in memory. It ends
up that your array is not updated.

As a quick fix, try to comment out the above malloc line in your 
minc2 library, then rebuild minc2 and relink your application.

If widths is to be allocated from within this function (bad idea),
then you need to pass a double * widths[] and assign it as
*widths = (double*)malloc(...); 

Let me know if this works so that I can commit the change in cvs.

By the way *** IMPORTANT ***, since you are using 4-D volumes, please
update to minc-2.0.18 which fixes internal compression for 4-D volumes.
For some images (fMRI, DTI), this is the difference between 90 minutes
vs 15 seconds to read a volume.

bye

Claude




> Hi List (yet again),
>
>    I have a 4-d volume (time, zspace, yspace, xspace) and I need to
> read the time-related information, specifically the offset and width
> info.  Looking at the volume itself, I can see 34 values each for the
> "time" and "time-width" variables.
>
> "miget_dimension_offsets" (minc2 API) had no trouble pulling in the 34
> "time" values, however, I'm stumped on how to read in the 34
> "time-width" values.  I tried "miget_dimension_widths" and got zeros.
> Am I using the correct API call?  Here's what I'm doing ...
>
> -----------------------------------------------------------
> midimhandle_t		*dimensions;
> double			time_widths[34];
>
> result = miget_dimension_widths(dimensions[0], MI_ORDER_FILE, 34, 0,
> time_widths);
> if ( result == MI_ERROR ) { error("Error returned from
> miget_dimension_widths.\n"); }
> -----------------------------------------------------------
>
>    Forgive the hard-coding of 34 ... I'm testing.  My immediately
> preceding call to "miget_dimension_offsets" (also using dimensions[0])
> worked just fine.  Any idea what's going on here?
>
> Thanks,
>
> -Jim
>
> -- 
> =================================
> Jim Nikelski, Ph.D.
> Postdoctoral Research Fellow
> Bloomfield Centre for Research in Aging
> Lady Davis Institute for Medical Research
> Sir Mortimer B. Davis - Jewish General Hospital
> McGill University
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From nikelski at bic.mni.mcgill.ca  Mon Aug 10 13:27:42 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Mon, 10 Aug 2009 13:27:42 -0400
Subject: [MINC-users] Reading time-width data with minc2 API
In-Reply-To: <200908072345.n77NjKp0006447@grumio.bic.mni.mcgill.ca>
References: <e12172550908071602s3c8f83a0na10edad29c65e916@mail.gmail.com>
	<200908072345.n77NjKp0006447@grumio.bic.mni.mcgill.ca>
Message-ID: <e12172550908101027n6c9a829fuc8fc2d80d86fd11b@mail.gmail.com>

Hi Claude (and List),

   Thanks for the suggestion. I did as you suggested and commented out
the malloc in libsrc2/dimension.c and rebuilt using minc-2.0.18.  No
success, however, after tossing in liberal printf's I found that it's
going here ...

  if (dimension->widths == NULL) {
    for (i=start_position; i <= diff; i++) {
      widths[j] = dimension->width;
      j++;
    }
  }

In other words, it's returning zeros because the dimension->widths
pointer is null.  So either the pointer is not being initialized, or
"miget_dimension_widths" does not do what I expect it to do --- which
in this case is return the 34 time-width values from the volume.  The
API does not seem to suggest any other obvious routines, although, all
we really need is to be able to read the values from the "time-width"
variable. I feel like I'm missing something really obvious.

Suggestions?

-Jim



On Fri, Aug 7, 2009 at 7:45 PM, Claude LEPAGE<claude at bic.mni.mcgill.ca> wrote:
> Hi Jim,
>
> ok, this one looks like a bug to me.
>
> See libsrc2/dimension.c:
>
> miget_dimension_widths(midimhandle_t dimension,
> ? ? ? ? ? ? ? ? ? ? ? mivoxel_order_t voxel_order,
> ? ? ? ? ? ? ? ? ? ? ? unsigned long array_length,
> ? ? ? ? ? ? ? ? ? ? ? unsigned long start_position,
> ? ? ? ? ? ? ? ? ? ? ? double widths[])
> {
>
> ?/* Allocate space for the widths array
> ? */
> ?widths = (double *) malloc(diff*sizeof(double));
>
> ? ?for (i=start_position; i <= diff; i++) {
> ? ? ?widths[j] = dimension->width;
> ? ? ?j++;
> ? ?}
>
> Well, the memory has been allocated from outside, so this malloc
> simply redefines widths to be some new location in memory. It ends
> up that your array is not updated.
>
> As a quick fix, try to comment out the above malloc line in your
> minc2 library, then rebuild minc2 and relink your application.
>
> If widths is to be allocated from within this function (bad idea),
> then you need to pass a double * widths[] and assign it as
> *widths = (double*)malloc(...);
>
> Let me know if this works so that I can commit the change in cvs.
>
> By the way *** IMPORTANT ***, since you are using 4-D volumes, please
> update to minc-2.0.18 which fixes internal compression for 4-D volumes.
> For some images (fMRI, DTI), this is the difference between 90 minutes
> vs 15 seconds to read a volume.
>
> bye
>
> Claude
>
>
>
>
>> Hi List (yet again),
>>
>> ? ?I have a 4-d volume (time, zspace, yspace, xspace) and I need to
>> read the time-related information, specifically the offset and width
>> info. ?Looking at the volume itself, I can see 34 values each for the
>> "time" and "time-width" variables.
>>
>> "miget_dimension_offsets" (minc2 API) had no trouble pulling in the 34
>> "time" values, however, I'm stumped on how to read in the 34
>> "time-width" values. ?I tried "miget_dimension_widths" and got zeros.
>> Am I using the correct API call? ?Here's what I'm doing ...
>>
>> -----------------------------------------------------------
>> midimhandle_t ? ? ? ? *dimensions;
>> double ? ? ? ? ? ? ? ? ? ? ? ?time_widths[34];
>>
>> result = miget_dimension_widths(dimensions[0], MI_ORDER_FILE, 34, 0,
>> time_widths);
>> if ( result == MI_ERROR ) { error("Error returned from
>> miget_dimension_widths.\n"); }
>> -----------------------------------------------------------
>>
>> ? ?Forgive the hard-coding of 34 ... I'm testing. ?My immediately
>> preceding call to "miget_dimension_offsets" (also using dimensions[0])
>> worked just fine. ?Any idea what's going on here?
>>
>> Thanks,
>>
>> -Jim
>>
>> --
>> =================================
>> Jim Nikelski, Ph.D.
>> Postdoctoral Research Fellow
>> Bloomfield Centre for Research in Aging
>> Lady Davis Institute for Medical Research
>> Sir Mortimer B. Davis - Jewish General Hospital
>> McGill University
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University


From claude at bic.mni.mcgill.ca  Mon Aug 10 14:32:42 2009
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Mon, 10 Aug 2009 14:32:42 -0400
Subject: [MINC-users] Reading time-width data with minc2 API
In-Reply-To: <e12172550908101027n6c9a829fuc8fc2d80d86fd11b@mail.gmail.com>
Message-ID: <200908101832.n7AIWgTU027770@grumio.bic.mni.mcgill.ca>

Hi Jim,

The malloc is wrong and must be commented out. 

>    Thanks for the suggestion. I did as you suggested and commented out
> the malloc in libsrc2/dimension.c and rebuilt using minc-2.0.18.  No
> success, however, after tossing in liberal printf's I found that it's
> going here ...
>
>   if (dimension->widths == NULL) {
>     for (i=start_position; i <= diff; i++) {
>       widths[j] = dimension->width;
>       j++;
>     }
>   }
>
> In other words, it's returning zeros because the dimension->widths
> pointer is null.  So either the pointer is not being initialized, or
> "miget_dimension_widths" does not do what I expect it to do --- which
> in this case is return the 34 time-width values from the volume.  The
> API does not seem to suggest any other obvious routines, although, all
> we really need is to be able to read the values from the "time-width"
> variable. I feel like I'm missing something really obvious.

I think dimension->widths is NULL because the widths are uniform and
all equal to dimension->width, if which case the widths vector does
not need to exist. This is a simple copy. dimension->width should not
be zero. Hard-code a non-zero value in there, like 3.1415, and see if 
it can be returned  to the calling program?

>     for (i=start_position; i <= diff; i++) {
>       widths[j] = 3.1415;         //  dimension->width;
>       j++;
>     }

Next, we'll have to figure out why dimension->width is zero.

Claude

From nikelski at bic.mni.mcgill.ca  Mon Aug 10 15:00:04 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Mon, 10 Aug 2009 15:00:04 -0400
Subject: [MINC-users] Reading time-width data with minc2 API
In-Reply-To: <200908101832.n7AIWgTU027770@grumio.bic.mni.mcgill.ca>
References: <e12172550908101027n6c9a829fuc8fc2d80d86fd11b@mail.gmail.com>
	<200908101832.n7AIWgTU027770@grumio.bic.mni.mcgill.ca>
Message-ID: <e12172550908101200k2b614d58w3f91b30ad8350612@mail.gmail.com>

Hi Claude,

  Done.  malloc is commented out and 3.1415 is indeed returned.

> I think dimension->widths is NULL because the widths are uniform and
> all equal to dimension->width, if which case the widths vector does

Hmmm .... don't think so.  When I look at the header, the "time" and
"time-width" variables are designated as "irregular".  Note the
attributes and the actual data values:
--------------------------------------
        double time(time) ;
                time:length = 34 ;
                time:dimorder = "time" ;
                time:varid = "MINC standard variable" ;
                time:vartype = "dimension____" ;
                time:version = "MINC Version    1.0" ;
                time:spacing = "irregular" ;
                time:alignment = "start_" ;
                time:units = "seconds" ;
                time:start = 0.016 ;
                time:step = 145.454545454545 ;
        double time-width(time) ;
                time-width:dimorder = "time" ;
                time-width:varid = "MINC standard variable" ;
                time-width:vartype = "dim-width____" ;
                time-width:version = "MINC Version    1.0" ;
                time-width:spacing = "irregular" ;
                time-width:filtertype = "square____" ;
                time-width:units = "seconds" ;

 time = 0.016, 15.016, 30.016, 45.016, 60.016, 90.016, 120.016, 150.016,
    180.016, 210.016, 240.016, 270.016, 300.016, 360.016, 420.016, 480.016,
    540.016, 600.016, 660.016, 720.016, 780.016, 840.016, 1020.016, 1200.016,
    1500.016, 1800.016, 2100.016, 2400.016, 2700.016, 3000.016, 3300.016,
    3600.016, 4200.016, 4800.016 ;
 time-width = 15, 15, 15, 15, 30, 30, 30, 30, 30, 30, 30, 30, 60, 60, 60, 60,
    60, 60, 60, 60, 60, 180, 180, 300, 300, 300, 300, 300, 300, 300, 300,
    600, 600, 600 ;

-Jim



On Mon, Aug 10, 2009 at 2:32 PM, Claude LEPAGE<claude at bic.mni.mcgill.ca> wrote:
> Hi Jim,
>
> The malloc is wrong and must be commented out.
>
>> ? ?Thanks for the suggestion. I did as you suggested and commented out
>> the malloc in libsrc2/dimension.c and rebuilt using minc-2.0.18. ?No
>> success, however, after tossing in liberal printf's I found that it's
>> going here ...
>>
>> ? if (dimension->widths == NULL) {
>> ? ? for (i=start_position; i <= diff; i++) {
>> ? ? ? widths[j] = dimension->width;
>> ? ? ? j++;
>> ? ? }
>> ? }
>>
>> In other words, it's returning zeros because the dimension->widths
>> pointer is null. ?So either the pointer is not being initialized, or
>> "miget_dimension_widths" does not do what I expect it to do --- which
>> in this case is return the 34 time-width values from the volume. ?The
>> API does not seem to suggest any other obvious routines, although, all
>> we really need is to be able to read the values from the "time-width"
>> variable. I feel like I'm missing something really obvious.
>
> I think dimension->widths is NULL because the widths are uniform and
> all equal to dimension->width, if which case the widths vector does
> not need to exist. This is a simple copy. dimension->width should not
> be zero. Hard-code a non-zero value in there, like 3.1415, and see if
> it can be returned ?to the calling program?
>
>> ? ? for (i=start_position; i <= diff; i++) {
>> ? ? ? widths[j] = 3.1415; ? ? ? ? // ?dimension->width;
>> ? ? ? j++;
>> ? ? }
>
> Next, we'll have to figure out why dimension->width is zero.
>
> Claude
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University


From claude at bic.mni.mcgill.ca  Mon Aug 10 15:12:41 2009
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Mon, 10 Aug 2009 15:12:41 -0400
Subject: [MINC-users] Reading time-width data with minc2 API
In-Reply-To: <e12172550908101200k2b614d58w3f91b30ad8350612@mail.gmail.com>
Message-ID: <200908101912.n7AJCf1U031483@grumio.bic.mni.mcgill.ca>

Jim,

>   Done.  malloc is commented out and 3.1415 is indeed returned.

Great! we know this function works now.

> Hmmm .... don't think so.  When I look at the header, the "time" and
> "time-width" variables are designated as "irregular".  Note the
> attributes and the actual data values:
> --------------------------------------
>         double time(time) ;
>                 time:length = 34 ;
>                 time:dimorder = "time" ;
>                 time:varid = "MINC standard variable" ;
>                 time:vartype = "dimension____" ;
>                 time:version = "MINC Version    1.0" ;
>                 time:spacing = "irregular" ;
>                 time:alignment = "start_" ;
>                 time:units = "seconds" ;
>                 time:start = 0.016 ;
>                 time:step = 145.454545454545 ;
>         double time-width(time) ;
>                 time-width:dimorder = "time" ;
>                 time-width:varid = "MINC standard variable" ;
>                 time-width:vartype = "dim-width____" ;
>                 time-width:version = "MINC Version    1.0" ;
>                 time-width:spacing = "irregular" ;
>                 time-width:filtertype = "square____" ;
>                 time-width:units = "seconds" ;
>
>  time = 0.016, 15.016, 30.016, 45.016, 60.016, 90.016, 120.016, 150.016,
>     180.016, 210.016, 240.016, 270.016, 300.016, 360.016, 420.016, 480.016,
>     540.016, 600.016, 660.016, 720.016, 780.016, 840.016, 1020.016, 1200.016,
>     1500.016, 1800.016, 2100.016, 2400.016, 2700.016, 3000.016, 3300.016,
>     3600.016, 4200.016, 4800.016 ;
>  time-width = 15, 15, 15, 15, 30, 30, 30, 30, 30, 30, 30, 30, 60, 60, 60, 60,
>     60, 60, 60, 60, 60, 180, 180, 300, 300, 300, 300, 300, 300, 300, 300,
>     600, 600, 600 ;

Now we have to figure out why the time intervals are not being read properly.
Sounds like fun. Maybe Andrew wants to jump on the bandwagon...

Claude

From vikingy at gmail.com  Tue Aug 11 22:21:24 2009
From: vikingy at gmail.com (vikingy)
Date: Wed, 12 Aug 2009 10:21:24 +0800
Subject: [MINC-users] brain-view's texture file
Message-ID: <200908121021219840986@gmail.com>

Hi MINC lister,

I installed the brain-view followed the instructions at http://wiki.bic.mni.mcgill.ca/index.php/BrainView. It's works but still has a warning message:

WARNING: environment file (~/.brain-view or /data/aces/aces1/quarantines/Linux-i686/Oct-10-2007/share/brain-view/brain-view-config) could not be found so textures will not be available 

In this way, I cann't use the texture file to color the map. Is there any method to specify the textures path instead of the default path (such as here is /data/aces/aces1/quarantines/Linux-i686/Oct-10-2007/share/brain-view/)?

Thanks in advance!

Bin Lv

2009-08-12 



The Key Lab of Complex Systems and Intelligence Science,
Institute of Automation,
Chinese Academy of Sciences. 

From acaroli at fatebenefratelli.it  Tue Aug 11 22:29:14 2009
From: acaroli at fatebenefratelli.it (auto-reply from acaroli@fatebenefratelli.it)
Date: Wed, 12 Aug 2009 04:29:14 +0200
Subject: [MINC-users] brain-view's texture file
In-Reply-To: <200908121021219840986@gmail.com>
Message-ID: <200908120230.n7C2Tb42021602@mail.bic.mni.mcgill.ca>

Thank you for your message.
I am out of office till August 31st with no access to e-
mail, and I will answer as soon as I come back.
Best regards

Anna Caroli

From claude at bic.mni.mcgill.ca  Tue Aug 11 23:35:59 2009
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Tue, 11 Aug 2009 23:35:59 -0400
Subject: [MINC-users] brain-view's texture file
In-Reply-To: <200908121021219840986@gmail.com>
Message-ID: <200908120335.n7C3ZxBe032328@grumio.bic.mni.mcgill.ca>

Hi,

Create a file called .brain-view in your $HOME directory,
with the file containing these two lines:

Texturedir: /data/aces/aces1/quarantines/textures
Texture: spectral.rgb

Change the above path in the file to point to your local
path containing the texture files.

Claude

> I installed the brain-view followed the instructions at http://wiki.bic.mni.mcgill.ca/index.php/BrainView. It's works but still has a warning message:
>
> WARNING: environment file (~/.brain-view or /data/aces/aces1/quarantines/Linux-i686/Oct-10-2007/share/brain-view/brain-view-config) could not be found so textures will not be available 
>
> In this way, I cann't use the texture file to color the map. Is there any method to specify the textures path instead of the default path (such as here is /data/aces/aces1/quarantines/Linux-i686/Oct-10-2007/share/brain-view/)?
>
> Thanks in advance!
>
> Bin Lv
>
> 2009-08-12 
>




From nikelski at bic.mni.mcgill.ca  Fri Aug 14 10:49:05 2009
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Fri, 14 Aug 2009 10:49:05 -0400
Subject: [MINC-users] minc2, hdf5, and shared libraries
Message-ID: <e12172550908140749m28e6ffa6nfa3264ff7c1eb293@mail.gmail.com>

Hi all,

    I'm currently dealing with a weird problem and could use some
suggestions.  Specifically, I'm working on an R extension which calls
a minc2 shared library, which, in turn, calls a shared hdf5 library
(yup, just like RMINC).  The problem that I'm seeing is that when I
unload the minc2 library (from R) after an IO call, R aborts with a
segfault.  Note that I'm working on OS X.

   Now, after some valgrind-ing, I found that HDF5 registers a
clean-up routine using an atexit() call, which gets called when my
minc2 extension library is unloaded.  IF the HDF5 shared library is
already unloaded when the extension library is unloaded, a jump is
made into oblivion.

   So I can see a few options here:
(1) keep the HDF5 library from unloading (not sure how to do this)
(2) go through the minc2 API code and try to keep the HDF5 library
from registering the atexit() clean-up function.  The HDF5 function
H5dont_atexit() exists for this purpose, however I'm not clear about
the repercussions of doing this, and am also unsure about where best
to call this function.
(3) map the minc2 and hdf5 libraries together, so that one cannot be
unloaded without the other.  I'm not sure what ./configure switches
might allow me to do this (if any).

Suggestions?

-Jim

-- 
=================================
Jim Nikelski, Ph.D.
Postdoctoral Research Fellow
Bloomfield Centre for Research in Aging
Lady Davis Institute for Medical Research
Sir Mortimer B. Davis - Jewish General Hospital
McGill University

From acaroli at fatebenefratelli.it  Fri Aug 14 11:00:36 2009
From: acaroli at fatebenefratelli.it (auto-reply from acaroli@fatebenefratelli.it)
Date: Fri, 14 Aug 2009 17:00:36 +0200
Subject: [MINC-users] minc2, hdf5, and shared libraries
In-Reply-To: <e12172550908140749m28e6ffa6nfa3264ff7c1eb293@mail.gmail.com>
Message-ID: <200908141501.n7EF0wJ8013847@mail.bic.mni.mcgill.ca>

Thank you for your message.
I am out of office till August 31st with no access to e-
mail, and I will answer as soon as I come back.
Best regards

Anna Caroli

From a.janke at gmail.com  Mon Aug 17 08:23:44 2009
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 17 Aug 2009 22:23:44 +1000
Subject: [MINC-users] minc2, hdf5, and shared libraries
In-Reply-To: <e12172550908140749m28e6ffa6nfa3264ff7c1eb293@mail.gmail.com>
References: <e12172550908140749m28e6ffa6nfa3264ff7c1eb293@mail.gmail.com>
Message-ID: <d747ed50908170523k19ad7e7do86fa34be1672a644@mail.gmail.com>

Hi Jim,

> (1) keep the HDF5 library from unloading (not sure how to do this)
> (2) go through the minc2 API code and try to keep the HDF5 library
> from registering the atexit() clean-up function. ?The HDF5 function
> H5dont_atexit() exists for this purpose, however I'm not clear about
> the repercussions of doing this, and am also unsure about where best
> to call this function.
> (3) map the minc2 and hdf5 libraries together, so that one cannot be
> unloaded without the other. ?I'm not sure what ./configure switches
> might allow me to do this (if any).


As a first off dirty hack I would try:

(4) Either drop back to MINC 1.X or compile MINC2 without HDF support
(configure --disable-minc2) and see if this really is an issue with
HDF or MINC.

Once you know this then I would try removing MINC and seeing if HDF5
breaks in the same way just by itself. If it does then you really only
have one option (1). Or add the call as per (2), I would punt that
there might not be complete memory clean up though.


--
Andrew Janke
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883


From michel.audette at kitware.com  Thu Aug 20 07:54:53 2009
From: michel.audette at kitware.com (Michel Audette)
Date: Thu, 20 Aug 2009 07:54:53 -0400
Subject: [MINC-users] Contest: Best Biomedical Visualization Using
	Open-Source Software
In-Reply-To: <68a07c2d0908200418i6e504b6fvf8c80e152b31f212@mail.gmail.com>
References: <68a07c2d0908180616v4175d8b5h8cc108089e4bbcb6@mail.gmail.com>
	<68a07c2d0908200418i6e504b6fvf8c80e152b31f212@mail.gmail.com>
Message-ID: <b16f21b00908200454g2ca60f98v9588bdb224b221a3@mail.gmail.com>

Dear all,

Kitware is holding a contest to find the best biomedical visualization
that was made using the freely-available, open-source Insight Toolkit
(http://www.itk.org) or Visualization Toolkit (http://www.vtk.org).

?* First-place prize is $750 and a shirt or hat with the Kitware logo.
?* Second-place prize is $250 and a shirt or hat with the Kitware logo.
?* Select entries will also appear on the Kitware website

?* Submissions must be received by September 10th, 2009

?* Winners will be announced at the 2009 MICCAI conference

The contest website is:

?http://www.kitware.com/ImageVote/

Entries will be judged based on scientific significance, the use of
ITK or VTK, and aesthetics. ?More information is given below and on
the contest website:
?* Visualizations may be charts, graphs, photographs, or renderings
from the biomedical field.
?* You may submit more than one visualization.
?* You must explain how VTK and/or ITK played a role in generating
your visualizations.
?* Images from open-source and commercial applications that use ITK
and VTK are eligible, including:
? ? * 3D Slicer
? ? * Osirix
? ? * BioImageXD
? ? * MedINRIA
? ? * Farsight
? ? * VisTrails
? ? * caBIG-XIP
? ? * VR-Render
? ? * ParaView
? ? * VolView
?* Public voting will be used by a panel of expert judges to determine
the winners.
?* Images generated by Kitware employees are not eligible.
?* Anyone may submit visualizations and cast votes, after registering
on this website.
?* Registration is free.

As you prepare your presentations for MICCAI, SPIE Medical Imaging,
and other events, consider entering the best of your visualizations in
the contest!

We look forward to seeing your entries!

Best regards,
The Kitware Team

-- 
Michel Audette, Ph.D.
R & D Engineer,
Kitware Inc.,
Chapel Hill, N.C.


From acaroli at fatebenefratelli.it  Thu Aug 20 08:01:56 2009
From: acaroli at fatebenefratelli.it (auto-reply from acaroli@fatebenefratelli.it)
Date: Thu, 20 Aug 2009 14:01:56 +0200
Subject: [MINC-users] Contest: Best Biomedical Visualization
	Using	Open-Source Software
In-Reply-To: <b16f21b00908200454g2ca60f98v9588bdb224b221a3@mail.gmail.com>
Message-ID: <200908201203.n7KC2c1v005441@mail.bic.mni.mcgill.ca>

Thank you for your message.
I am out of office till August 31st with no access to e-
mail, and I will answer as soon as I come back.
Best regards

Anna Caroli