From acveilleux at mrs.mni.mcgill.ca  Tue Apr  1 16:16:16 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Tue, 1 Apr 2008 16:16:16 -0400
Subject: [MINC-users] 64-bit build on OSX 10.5
Message-ID: <20080401161616.G17157@mrs.mni.mcgill.ca>

Hello,

	I'm trying to get a clean build of Minc 2.0.15 for OSX 10.5 in
64-bit mode. Now I've got 32-bit working (thanks Andrew) but for some
reason I can't build hdf5 1.6 (either 1.6.1 or 1.6.7) in 64-bit and I
get segfaults if I link 1.8.0 in 1.6 compatiblity mode with minc2.

	Has anyone got this working and can clue me in on to this?

Alex

From claude at bic.mni.mcgill.ca  Tue Apr  1 16:27:32 2008
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Tue, 1 Apr 2008 16:27:32 -0400 (EDT)
Subject: [MINC-users] 64-bit build on OSX 10.5
Message-ID: <200804012027.m31KRW902131913@yorick.bic.mni.mcgill.ca>

Hi,

You definitely cannot use hdf5 1.8.0 in minc2. The API has changed from 1.6.X
and minc2 is not compatible with the new API. I haven't tried 1.6.7, but 1.6.6
works on Linux 32 and 64 bits. As far as minc2.0.15 is concerned, there is a
known (and fixed) bug in dcm2mnc in 64 bits (will go in next release). But all
other minc tools should be expected to work in 64 bits, even on a Mac.

Claude

> 	I'm trying to get a clean build of Minc 2.0.15 for OSX 10.5 in
> 64-bit mode. Now I've got 32-bit working (thanks Andrew) but for some
> reason I can't build hdf5 1.6 (either 1.6.1 or 1.6.7) in 64-bit and I
> get segfaults if I link 1.8.0 in 1.6 compatiblity mode with minc2.
> 
> 	Has anyone got this working and can clue me in on to this?
> 
> Alex
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 

From acveilleux at mrs.mni.mcgill.ca  Tue Apr  1 17:17:51 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Tue, 1 Apr 2008 17:17:51 -0400
Subject: [MINC-users] 64-bit build on OSX 10.5
In-Reply-To: <200804012027.m31KRW902131913@yorick.bic.mni.mcgill.ca>;
	from claude@bic.mni.mcgill.ca on Tue, Apr 01, 2008 at 04:27:32PM
	-0400
References: <200804012027.m31KRW902131913@yorick.bic.mni.mcgill.ca>
Message-ID: <20080401171751.H17157@mrs.mni.mcgill.ca>

	Well, if I run:
	
./configure CFLAGS="-O2 -arch x86_64" CXXFLAGS="-O2 -arch x86_64" --prefix=/usr/local --with-zlib=yes --with-szlib=yes

	for both hdf5 1.8.0 and 1.6.7 and then copy the libtool from 1.8.0 to
1.6.7, then 1.6.7 builds properly in 64-bit on OS X. Minc 2.0.15 links against
it and appears to work (though I haven't done extensive testing yet, it won't
Segfault anymore).

	So problem "solved".

Alex

On Tue, Apr 01, 2008 at 04:27:32PM -0400, Claude LEPAGE wrote:
> Date: Tue, 1 Apr 2008 16:27:32 -0400 (EDT)
> From: Claude LEPAGE <claude at bic.mni.mcgill.ca>
> To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
> Subject: Re: [MINC-users] 64-bit build on OSX 10.5
> 
> Hi,
> 
> You definitely cannot use hdf5 1.8.0 in minc2. The API has changed from 1.6.X
> and minc2 is not compatible with the new API. I haven't tried 1.6.7, but 1.6.6
> works on Linux 32 and 64 bits. As far as minc2.0.15 is concerned, there is a
> known (and fixed) bug in dcm2mnc in 64 bits (will go in next release). But all
> other minc tools should be expected to work in 64 bits, even on a Mac.
> 
> Claude
> 
> > 	I'm trying to get a clean build of Minc 2.0.15 for OSX 10.5 in
> > 64-bit mode. Now I've got 32-bit working (thanks Andrew) but for some
> > reason I can't build hdf5 1.6 (either 1.6.1 or 1.6.7) in 64-bit and I
> > get segfaults if I link 1.8.0 in 1.6 compatiblity mode with minc2.
> > 
> > 	Has anyone got this working and can clue me in on to this?
> > 
> > Alex
> > _______________________________________________
> > 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

From a.janke at gmail.com  Wed Apr  2 01:08:03 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 2 Apr 2008 16:08:03 +1100
Subject: [MINC-users] 64-bit build on OSX 10.5
In-Reply-To: <20080401171751.H17157@mrs.mni.mcgill.ca>
References: <200804012027.m31KRW902131913@yorick.bic.mni.mcgill.ca>
	<20080401171751.H17157@mrs.mni.mcgill.ca>
Message-ID: <d747ed50804012208u650075b0ufd47840563c660bd@mail.gmail.com>

>         for both hdf5 1.8.0 and 1.6.7 and then copy the libtool from 1.8.0 to
>  1.6.7, then 1.6.7 builds properly in 64-bit on OS X. Minc 2.0.15 links against
>  it and appears to work (though I haven't done extensive testing yet, it won't
>  Segfault anymore).
>
>         So problem "solved".

Good good.  I was hoping this was an OSX thing and not yet another HDF
version thing as per what Claude pointed out.


a

From Michel.Audette at medizin.uni-leipzig.de  Wed Apr  2 04:09:01 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 2 Apr 2008 10:09:01 +0200
Subject: [MINC-users] mincconvert -2 error
References: <200804012027.m31KRW902131913@yorick.bic.mni.mcgill.ca><20080401171751.H17157@mrs.mni.mcgill.ca>
	<d747ed50804012208u650075b0ufd47840563c660bd@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FF04@MRZS152229.medizin.uni-leipzig.de>

Hi all, 

I'm trying to get mincconvert to work on mnc files, to produce mnc2, and I'm seeing the following: 

maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> mincconvert -2 heartMarkersClass0a_iso_distlt5.mnc heartMarkersClass0a_iso_distlt5.mnc2 -clob
HDF5-DIAG: Error detected in HDF5 library version: 1.6.1 thread 0.  Back trace follows.
  #000: H5F.c line 3191 in H5Fclose(): decrementing file ID failed
    major(07): Atom layer
    minor(16): Unable to close file
  #001: H5F.c line 3119 in H5F_close(): unable to flush cache
    major(08): Meta data cache layer
    minor(36): Unable to flush data from cache
  #002: H5F.c line 2881 in H5F_flush(): low level flush failed
    major(05): Low-level I/O layer
    minor(23): Write failed
  #003: H5FD.c line 3265 in H5FD_flush(): driver flush request failed
    major(22): Virtual File Layer
    minor(27): Unable to initialize object
  #004: H5FDsec2.c line 822 in H5FD_sec2_flush(): unable to extend file properly
    major(05): Low-level I/O layer
    minor(21): Seek failed

Has anyone seen this before? Is there a simple fix? 

Thanks for your kind attention. 

Cheers,

Michel

Michel Audette, Ph.D.
Innovation Center Computer Assisted Surgery (ICCAS)
Semmelweisstra?e 14
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09

From Michel.Audette at medizin.uni-leipzig.de  Wed Apr  2 06:51:11 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 2 Apr 2008 12:51:11 +0200
Subject: [MINC-users] mincconvert -2 error
References: <200804012027.m31KRW902131913@yorick.bic.mni.mcgill.ca><20080401171751.H17157@mrs.mni.mcgill.ca><d747ed50804012208u650075b0ufd47840563c660bd@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E690201FF04@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FF09@MRZS152229.medizin.uni-leipzig.de>

Hi folks, 

looks like I got rid of the problem with a more recent version of minc software and hdf version 1.6.7. Not sure which one of the two did it... 

Perhaps this solution is relevant to someone in this community. 

Cheers, 

Michel

Michel Audette, Ph.D.
Innovation Center Computer Assisted Surgery (ICCAS)
Semmelweisstra?e 14
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Audette, Michel
Sent: Wed 4/2/2008 10:09 AM
To: MINC users mailing list
Subject: [MINC-users] mincconvert -2 error
 
Hi all, 

I'm trying to get mincconvert to work on mnc files, to produce mnc2, and I'm seeing the following: 

maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> mincconvert -2 heartMarkersClass0a_iso_distlt5.mnc heartMarkersClass0a_iso_distlt5.mnc2 -clob
HDF5-DIAG: Error detected in HDF5 library version: 1.6.1 thread 0.  Back trace follows.
  #000: H5F.c line 3191 in H5Fclose(): decrementing file ID failed
    major(07): Atom layer
    minor(16): Unable to close file
  #001: H5F.c line 3119 in H5F_close(): unable to flush cache
    major(08): Meta data cache layer
    minor(36): Unable to flush data from cache
  #002: H5F.c line 2881 in H5F_flush(): low level flush failed
    major(05): Low-level I/O layer
    minor(23): Write failed
  #003: H5FD.c line 3265 in H5FD_flush(): driver flush request failed
    major(22): Virtual File Layer
    minor(27): Unable to initialize object
  #004: H5FDsec2.c line 822 in H5FD_sec2_flush(): unable to extend file properly
    major(05): Low-level I/O layer
    minor(21): Seek failed

Has anyone seen this before? Is there a simple fix? 

Thanks for your kind attention. 

Cheers,

Michel

Michel Audette, Ph.D.
Innovation Center Computer Assisted Surgery (ICCAS)
Semmelweisstra?e 14
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09



From acveilleux at mrs.mni.mcgill.ca  Wed Apr  2 18:01:59 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Wed, 2 Apr 2008 18:01:59 -0400
Subject: [MINC-users] N3 bug?
Message-ID: <20080402180159.S28911@mrs.mni.mcgill.ca>

Hi,

	It seems N3 1.10.1 chops off the lowest slices of my volumes,
a behaviour that older nu_correct did not have. Is this a known bug?

Alex

From a.janke at gmail.com  Wed Apr  2 19:55:01 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 3 Apr 2008 10:55:01 +1100
Subject: [MINC-users] N3 bug?
In-Reply-To: <20080402180159.S28911@mrs.mni.mcgill.ca>
References: <20080402180159.S28911@mrs.mni.mcgill.ca>
Message-ID: <d747ed50804021655r3112b84ex993c1cfeaf642d13@mail.gmail.com>

On Thu, Apr 3, 2008 at 9:01 AM, Alexandre CARMEL-VEILLEUX
<acveilleux at mrs.mni.mcgill.ca> wrote:
>         It seems N3 1.10.1 chops off the lowest slices of my volumes,
>  a behaviour that older nu_correct did not have. Is this a known bug?

Certainly not to me..

ben:~$ nu_correct -version
Program nu_correct, built from:
Package MNI N3, version 1.10.1, compiled by rotor at ben
(x86_64-unknown-linux-gnu) on 2007-11-07 at 11:54:01
ben:~$ nu_correct data/me/a.mnc out.mnc
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Processing:.................................................................Done
Number of iterations: 26
CV of field change: 0.000954871
Transforming slices:......................................................................................Done
Transforming slices:................................................................................................................................................................................................................................................................Done
ben:~$ mi data/me/a.mnc out.mnc
file: data/me/a.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start     dircos
    --------------         ------         ----        -----     ------
    zspace                    256       0.9375     -116.135     0 0 1
    yspace                    256          0.9     -89.0348     0 1 0
    xspace                    256       0.9375     -118.179     1 0 0
file: out.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start     dircos
    --------------         ------         ----        -----     ------
    zspace                    256       0.9375     -116.135     0 0 1
    yspace                    256          0.9     -89.0348     0 1 0
    xspace                    256       0.9375     -118.179     1 0 0

What does nu_correct -verbose tell you about the process?  Are you
sure you are not being bitten by some irregular dimension spacing or
the likes?

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

From acveilleux at mrs.mni.mcgill.ca  Thu Apr  3 09:33:18 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Thu, 3 Apr 2008 09:33:18 -0400
Subject: [MINC-users] N3 bug?
In-Reply-To: <d747ed50804021655r3112b84ex993c1cfeaf642d13@mail.gmail.com>;
	from a.janke@gmail.com on Thu, Apr 03, 2008 at 10:55:01AM +1100
References: <20080402180159.S28911@mrs.mni.mcgill.ca>
	<d747ed50804021655r3112b84ex993c1cfeaf642d13@mail.gmail.com>
Message-ID: <20080403093317.A793@mrs.mni.mcgill.ca>

	The file has exactly the same dimensions, the lowest slice has all
its intensities set to 0. Sorry for the confusion. I'll give it more files.

Alex

On Thu, Apr 03, 2008 at 10:55:01AM +1100, Andrew Janke wrote:
> Date: Thu, 3 Apr 2008 10:55:01 +1100
> From: "Andrew Janke" <a.janke at gmail.com>
> To: "MINC users mailing list" <minc-users at bic.mni.mcgill.ca>
> Subject: Re: [MINC-users] N3 bug?
> 
> On Thu, Apr 3, 2008 at 9:01 AM, Alexandre CARMEL-VEILLEUX
> <acveilleux at mrs.mni.mcgill.ca> wrote:
> >         It seems N3 1.10.1 chops off the lowest slices of my volumes,
> >  a behaviour that older nu_correct did not have. Is this a known bug?
> 
> Certainly not to me..
> 
> ben:~$ nu_correct -version
> Program nu_correct, built from:
> Package MNI N3, version 1.10.1, compiled by rotor at ben
> (x86_64-unknown-linux-gnu) on 2007-11-07 at 11:54:01
> ben:~$ nu_correct data/me/a.mnc out.mnc
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Processing:.................................................................Done
> Number of iterations: 26
> CV of field change: 0.000954871
> Transforming slices:......................................................................................Done
> Transforming slices:................................................................................................................................................................................................................................................................Done
> ben:~$ mi data/me/a.mnc out.mnc
> file: data/me/a.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start     dircos
>     --------------         ------         ----        -----     ------
>     zspace                    256       0.9375     -116.135     0 0 1
>     yspace                    256          0.9     -89.0348     0 1 0
>     xspace                    256       0.9375     -118.179     1 0 0
> file: out.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start     dircos
>     --------------         ------         ----        -----     ------
>     zspace                    256       0.9375     -116.135     0 0 1
>     yspace                    256          0.9     -89.0348     0 1 0
>     xspace                    256       0.9375     -118.179     1 0 0
> 
> What does nu_correct -verbose tell you about the process?  Are you
> sure you are not being bitten by some irregular dimension spacing or
> the likes?
> 
> -- 
> 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 claude at bic.mni.mcgill.ca  Thu Apr  3 10:25:33 2008
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Thu, 3 Apr 2008 10:25:33 -0400 (EDT)
Subject: [MINC-users] N3 bug?
References: <20080402180159.S28911@mrs.mni.mcgill.ca>
	<d747ed50804021655r3112b84ex993c1cfeaf642d13@mail.gmail.com>
Message-ID: <200804031425.m33EPXeD2519233@yorick.bic.mni.mcgill.ca>

> 
> 	The file has exactly the same dimensions, the lowest slice has all
> its intensities set to 0. Sorry for the confusion. I'll give it more files.

This is a classic minc1 (netcdf) bug. Two fixes for this:
- make sure you are writing in minc2 (set the environment variable MINC_FORCE_V2 to 1).
- if you insist on using minc1, wipe out the history in the minc header of the 
  original image given as input to N3. 

To check the type of file you have, do "file image.mnc". If it reports netcdf,
it is minc1. If it reports hdf, it is minc2.

Claude

From Michel.Audette at medizin.uni-leipzig.de  Fri Apr  4 10:32:14 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 4 Apr 2008 16:32:14 +0200
Subject: [MINC-users] mincconvert to minc2 problems
References: <20080402180159.S28911@mrs.mni.mcgill.ca>
	<d747ed50804021655r3112b84ex993c1cfeaf642d13@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FF1F@MRZS152229.medizin.uni-leipzig.de>

Hi folks, 

I'm working with Rupert Brooks to apply his ITK-based registration that he's developing, and for some reason, my attempt to mincconvert to minc2 seems to fail. 

maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc>  mincconvert -2 heartMarkersClass0a_iso_distlt5.mnc heartMarkersClass0a_iso_distlt5.mnc2 -clob
maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> mincconvert -2 heartMarkersClass0b_iso_distlt5.mnc heartMarkersClass0b_iso_distlt5.mnc2 -clob
maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0a_iso_distlt5.mnc2
heartMarkersClass0a_iso_distlt5.mnc2: NetCDF Data Format data
maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0b_iso_distlt5.mnc2
heartMarkersClass0b_iso_distlt5.mnc2: NetCDF Data Format data

Can someone suggest a course of action? 

Cheers, 

Michel

Michel Audette, Ph.D.  
Innovation Center Computer Assisted Surgery (ICCAS)  
Semmelweisstra?e 14 
Leipzig, Germany 
Phone: ++49 (0) 341 / 97 - 1 20 13 
Fax: ++49 (0) 341 / 97 - 1 20 09


From baghdadi at phenogenomics.ca  Fri Apr  4 11:09:45 2008
From: baghdadi at phenogenomics.ca (Leila Baghdadi)
Date: Fri, 4 Apr 2008 11:09:45 -0400
Subject: [MINC-users] mincconvert to minc2 problems
In-Reply-To: <160E3DD4FB702C4CB860C65186686E690201FF1F@MRZS152229.medizin.uni-leipzig.de>
References: <20080402180159.S28911@mrs.mni.mcgill.ca>
Message-ID: <1207321785.20595.70.camel@mouse17.phenogenomics.ca>

Michel,

I do not work on minc2 at work but if you send me your image
information, I can check it this weekend and see if I can find out what
is going on. is this a multichannel data set by any chance.


Leila

On Fri, 2008-04-04 at 16:32 +0200, Audette, Michel wrote:
> Hi folks, 
> 
> I'm working with Rupert Brooks to apply his ITK-based registration that he's developing, and for some reason, my attempt to mincconvert to minc2 seems to fail. 
> 
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc>  mincconvert -2 heartMarkersClass0a_iso_distlt5.mnc heartMarkersClass0a_iso_distlt5.mnc2 -clob
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> mincconvert -2 heartMarkersClass0b_iso_distlt5.mnc heartMarkersClass0b_iso_distlt5.mnc2 -clob
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0a_iso_distlt5.mnc2
> heartMarkersClass0a_iso_distlt5.mnc2: NetCDF Data Format data
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0b_iso_distlt5.mnc2
> heartMarkersClass0b_iso_distlt5.mnc2: NetCDF Data Format data
> 
> Can someone suggest a course of action? 
> 
> Cheers, 
> 
> Michel
> 
> Michel Audette, Ph.D.  
> Innovation Center Computer Assisted Surgery (ICCAS)  
> Semmelweisstra?e 14 
> Leipzig, Germany 
> Phone: ++49 (0) 341 / 97 - 1 20 13 
> Fax: ++49 (0) 341 / 97 - 1 20 09
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From nikelski at bic.mni.mcgill.ca  Fri Apr  4 13:05:50 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Fri, 4 Apr 2008 13:05:50 -0400
Subject: [MINC-users] ecattominc and minc2
Message-ID: <e12172550804041005h7a36a0ecx1cb2df31b7f53725@mail.gmail.com>

Hi all,

   I seem to have stumbled upon a problem with creating a minc2 output
volume when using ecattominc.  With minc1, it works spiffingly ...
turn on minc2 (MINC_FORCE_V2=1), and it falls over thusly ...

>>Reading headers.
>>ncdimdef: ncid 67108864: NetCDF: Not a valid ID

    Falling over, rather surprisingly, with a netcdf error.  Problem
has been replicated on OS X and Ubuntu, so it's not platform-specific.
 Obviously not a rush to fix, as a clever combination of ecattominc
with minc1 out and mincconvert can get around the problem.

Sincerely,

-Jim

From Michel.Audette at medizin.uni-leipzig.de  Fri Apr  4 11:17:15 2008
From: Michel.Audette at medizin.uni-leipzig.de (Michel.Audette at medizin.uni-leipzig.de)
Date: Fri, 4 Apr 2008 17:17:15 +0200
Subject: [MINC-users] mincconvert to minc2 problems
References: <20080402180159.S28911@mrs.mni.mcgill.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FF21@MRZS152229.medizin.uni-leipzig.de>

Hi Leila, 

will do. I'll use yousendit.com and dispatch it to you right away. 

Cheers, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Leila Baghdadi
Sent: Fri 4/4/2008 5:09 PM
To: MINC users mailing list
Subject: Re: [MINC-users] mincconvert to minc2 problems
 
Michel,

I do not work on minc2 at work but if you send me your image
information, I can check it this weekend and see if I can find out what
is going on. is this a multichannel data set by any chance.


Leila

On Fri, 2008-04-04 at 16:32 +0200, Audette, Michel wrote:
> Hi folks, 
> 
> I'm working with Rupert Brooks to apply his ITK-based registration that he's developing, and for some reason, my attempt to mincconvert to minc2 seems to fail. 
> 
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc>  mincconvert -2 heartMarkersClass0a_iso_distlt5.mnc heartMarkersClass0a_iso_distlt5.mnc2 -clob
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> mincconvert -2 heartMarkersClass0b_iso_distlt5.mnc heartMarkersClass0b_iso_distlt5.mnc2 -clob
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0a_iso_distlt5.mnc2
> heartMarkersClass0a_iso_distlt5.mnc2: NetCDF Data Format data
> maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0b_iso_distlt5.mnc2
> heartMarkersClass0b_iso_distlt5.mnc2: NetCDF Data Format data
> 
> Can someone suggest a course of action? 
> 
> Cheers, 
> 
> Michel
> 
> Michel Audette, Ph.D.  
> Innovation Center Computer Assisted Surgery (ICCAS)  
> Semmelweisstra?e 14 
> Leipzig, Germany 
> Phone: ++49 (0) 341 / 97 - 1 20 13 
> Fax: ++49 (0) 341 / 97 - 1 20 09
> 
> _______________________________________________
> 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


From thomas_mansi at yahoo.fr  Sat Apr  5 16:10:49 2008
From: thomas_mansi at yahoo.fr (Thomas Mansi)
Date: Sat, 5 Apr 2008 22:10:49 +0200
Subject: [MINC-users] Linker errors on OS X Tiger when compiling ITK
	MINC2ImageIO
Message-ID: <E59B06EE-15CA-481F-8DFB-B77250DD98EA@yahoo.fr>

Dear all,

I would like to test the MINC IO factory of ITK but I am experiencing  
some linking problems when compiling the tools.

I am on Mac OS X Tiger (32bits), HDF5 v 1.6.1 and here is what I did  
so far.

+ I successfully compiled and installed netcdf 1.6.2 with -fno-common  
option

+ I successfully compiled minc 2.0.15 without -fno-common option.  
With -fno-common, I have the following linker error:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -fno-common   -o  
minctoecat conversion/minctoecat/minctoecat.o conversion/minctoecat/ 
ecat_write.o conversion/minctoecat/machine_indep.o libvolume_io2.la  
libminc2.la -lhdf5 -lz -lnetcdf -lm gcc -fno-common -o minctoecat  
conversion/minctoecat/minctoecat.o conversion/minctoecat/ecat_write.o  
conversion/minctoecat/machine_indep.o  ./.libs/ 
libvolume_io2.a ./.libs/libminc2.a /usr/local//lib/libhdf5.dylib -lz / 
usr/local//lib/libnetcdf.a -lm/usr/bin/ld: multiple definitions of  
symbol _matrix_errnoconversion/minctoecat/minctoecat.o definition of  
_matrix_errno in section (__DATA,__common)conversion/minctoecat/ 
ecat_write.o definition of _matrix_errno in section (__DATA,__common)/ 
usr/bin/ld: multiple definitions of symbol _matrix_errtxtconversion/ 
minctoecat/minctoecat.o definition of _matrix_errtxt in section  
(__DATA,__common)conversion/minctoecat/ecat_write.o definition of  
_matrix_errtxt in section (__DATA,__common)conversion/minctoecat/ 
machine_indep.o definition of _matrix_errno in section  
(__DATA,__common)conversion/minctoecat/machine_indep.o definition of  
_matrix_errtxt in section (__DATA,__common)collect2: ld returned 1  
exit status


+ I then compile a CVS version of ITK. I enabled MINC2 support as  
well as ITK_USE_REVIEW to compile the itkMINC2ImageIO files. But then  
I get these linker errors (with or without -fno-common option):


[ 95%] Building CXX object Code/Review/CMakeFiles/ITKIOMINC2.dir/ 
itkMINC2ImageIO.o[ 95%] Building CXX object Code/Review/CMakeFiles/ 
ITKIOMINC2.dir/itkMINC2ImageIOFactory.oLinking CXX shared  
library ../../bin/libITKIOMINC2.dylibld: common symbols not allowed  
with MH_DYLIB output format with the -multi_module option/usr/local/ 
lib/libminc2.a(hdf_convenience.o) definition of common __m2_list  
(size 16)/usr/local/lib/libminc2.a(minc_globdef.o) definition of  
common _minc_call_depth (size 16)/usr/local/lib/libminc2.a 
(minc_globdef.o) definition of common _minc_trash_var (size 16)/usr/ 
bin/libtool: internal link edit command failed


Do you have any idea about these issues? Have I missed something in  
the installation procedure of MINC2?

Thank you in advance for your precious help!

Thomas




From ayman.oweida at mail.mcgill.ca  Sun Apr  6 11:51:18 2008
From: ayman.oweida at mail.mcgill.ca (Ayman Oweida)
Date: Sun, 6 Apr 2008 11:51:18 -0400
Subject: [MINC-users] mean signal
Message-ID: <87016016B286AD429079D616EA89E51E688EEC@EXCHANGE2VS4.campus.mcgill.ca>


Hi,

I need to be able to obtain the mean signal intensity of an ROI in a brain MR image.  I thought of using Display to select the ROI, then save the selection as .mnc, then running volume_stats on the volume with a mask of the ROI.  However, two problems are associated with that: When running volume_stats on the mask alone, I get dimensions of the mask that are different than when running the mask on top of the volume (e.g. The mask has 9 voxels, but when I run volume_stats on the volume and mask, the # of voxels is now 32!!!), my other problem is that I always get the error: WARNING: Dimensions of RR_ROI_2.mnc do not match those of 0.mnc. Using world coordinates.  What does this imply for my measurements?  

Using mincstats will not work.  I just get the error: Files ROI.mnc and volume.mnc have different sizes of dimensions.

What am I doing wrong?  Is there a simpler way of obtaining signal measurement for an ROI?


Thanks,

Ayman


From mishkind at gmail.com  Sun Apr  6 13:24:38 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Sun, 6 Apr 2008 13:24:38 -0400
Subject: [MINC-users] mean signal
In-Reply-To: <87016016B286AD429079D616EA89E51E688EEC@EXCHANGE2VS4.campus.mcgill.ca>
References: <87016016B286AD429079D616EA89E51E688EEC@EXCHANGE2VS4.campus.mcgill.ca>
Message-ID: <9c5abb60804061024q5618c719u6fb6f63955f5c70b@mail.gmail.com>

Hi Ayman,

When you save your labels in Display there is an option to "Crop Save
Lbls" which is set to ON by default. If you set this to OFF, then your
ROI file will have the same dimensions as your volume and mincstats
won't complain.

(T)File -> (1)Crop Save lbls:Off -> (W)Save Labels .mnc

mishkin

On Sun, Apr 6, 2008 at 11:51 AM, Ayman Oweida
<ayman.oweida at mail.mcgill.ca> wrote:
>
>  Hi,
>
>  I need to be able to obtain the mean signal intensity of an ROI in a brain MR image.  I thought of using Display to select the ROI, then save the selection as .mnc, then running volume_stats on the volume with a mask of the ROI.  However, two problems are associated with that: When running volume_stats on the mask alone, I get dimensions of the mask that are different than when running the mask on top of the volume (e.g. The mask has 9 voxels, but when I run volume_stats on the volume and mask, the # of voxels is now 32!!!), my other problem is that I always get the error: WARNING: Dimensions of RR_ROI_2.mnc do not match those of 0.mnc. Using world coordinates.  What does this imply for my measurements?
>
>  Using mincstats will not work.  I just get the error: Files ROI.mnc and volume.mnc have different sizes of dimensions.
>
>  What am I doing wrong?  Is there a simpler way of obtaining signal measurement for an ROI?
>
>
>  Thanks,
>
>  Ayman
>
>  _______________________________________________
>  MINC-users at bic.mni.mcgill.ca
>  http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Sun Apr  6 13:36:17 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 7 Apr 2008 03:36:17 +1000
Subject: [MINC-users] mean signal
In-Reply-To: <87016016B286AD429079D616EA89E51E688EEC@EXCHANGE2VS4.campus.mcgill.ca>
References: <87016016B286AD429079D616EA89E51E688EEC@EXCHANGE2VS4.campus.mcgill.ca>
Message-ID: <d747ed50804061036i2e787680ja30648dce89421ef@mail.gmail.com>

Hi Ayman,

>  I need to be able to obtain the mean signal intensity of an ROI in a brain MR image.  I thought of using Display to select the ROI, then save the selection as .mnc, then running volume_stats on the volume with a mask of the ROI.  However, two problems are associated with that: When running volume_stats on the mask alone, I get dimensions of the mask that are different than when running the mask on top of the volume (e.g. The mask has 9 voxels, but when I run volume_stats on the volume and mask, the # of voxels is now 32!!!), my other problem is that I always get the error: WARNING: Dimensions of RR_ROI_2.mnc do not match those of 0.mnc. Using world coordinates.  What does this imply for my measurements?

As per what Mishkin said, Display tries to save space on your HDD (And
save a smaller mask). So this means that using masks in
mincmath/mincstats is generally a two-step process.

  1. create mask with Display

  2. resample the data to the file you want to use it with:

    $ mincresample -like T1.mnc -nearest_neighbour mask.mnc mask.resampled.mnc

  3. Then use the mask with mincstats (instead of volume_stats).

    $ mincstats -mask mask.resampled.mnc -mask_binvalue 1 T1.mnc


I would guess that you have the 22 voxels with what you are doing
above due to partial volume effects around the mask when you are
resampling. This should not happen with the above when you use the
-nearest_neighbour flag with mincresample.


a


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

From a.janke at gmail.com  Sun Apr  6 13:44:39 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 7 Apr 2008 03:44:39 +1000
Subject: [MINC-users] ecattominc and minc2
In-Reply-To: <e12172550804041005h7a36a0ecx1cb2df31b7f53725@mail.gmail.com>
References: <e12172550804041005h7a36a0ecx1cb2df31b7f53725@mail.gmail.com>
Message-ID: <d747ed50804061044q1fd7a1e6hd3cfcc6b60a55b0@mail.gmail.com>

Hi Jim,

On Sat, Apr 5, 2008 at 3:05 AM, EJ Nikelski <nikelski at bic.mni.mcgill.ca> wrote:
>    I seem to have stumbled upon a problem with creating a minc2 output
>  volume when using ecattominc.  With minc1, it works spiffingly ...
>  turn on minc2 (MINC_FORCE_V2=1), and it falls over thusly ...
>
>  >>Reading headers.
>  >>ncdimdef: ncid 67108864: NetCDF: Not a valid ID

This looks suspiciously like an error from a program that was compiled
against the minc2 libraries but not made "aware" of things by
including config.h in the build and thus not getting the magic

   #define MINC2 1

line.  I have just done a quick test compile of this and it seems to
fix the problem.  If you happened to have compiled MINC/ecattominc
from source (and given what I know of you I bet you did...) try
stuffing this at the top of
conversion/ecattominc/ecattominc.c

   #if HAVE_CONFIG_H
   #include "config.h"
   #endif

recompile and see if it works.  If so then I will check my changes for
this into CVS.

Thanks


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

From a.janke at gmail.com  Sun Apr  6 13:47:40 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 7 Apr 2008 03:47:40 +1000
Subject: [MINC-users] Linker errors on OS X Tiger when compiling ITK
	MINC2ImageIO
In-Reply-To: <E59B06EE-15CA-481F-8DFB-B77250DD98EA@yahoo.fr>
References: <E59B06EE-15CA-481F-8DFB-B77250DD98EA@yahoo.fr>
Message-ID: <d747ed50804061047l66da647ag85221ac43a4e31d5@mail.gmail.com>

On Sun, Apr 6, 2008 at 6:10 AM, Thomas Mansi <thomas_mansi at yahoo.fr> wrote:
>  I would like to test the MINC IO factory of ITK but I am experiencing
>  some linking problems when compiling the tools.
>  I am on Mac OS X Tiger (32bits), HDF5 v 1.6.1 and here is what I did
>  so far.
>  + I successfully compiled and installed netcdf 1.6.2 with -fno-common
>  option
>  + I successfully compiled minc 2.0.15 without -fno-common option.
>  With -fno-common, I have the following linker error:

Hi Tomas,

Just a quick question, are you using Cmake for the MINC build or the
GNU autoconf stuff?  (ie: configure).

As for the ecattominc problem I will take a bet that this is related
to Jims post that I just replied to (but haven't checked). In any case
when I build MINC2.X for ITK I generally build it using the
CMakeLists.txt file and use cmake.


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

From thomas_mansi at yahoo.fr  Sun Apr  6 16:08:31 2008
From: thomas_mansi at yahoo.fr (Thomas Mansi)
Date: Sun, 6 Apr 2008 22:08:31 +0200
Subject: [MINC-users] Linker errors on OS X Tiger when compiling ITK
	MINC2ImageIO
In-Reply-To: <d747ed50804061047l66da647ag85221ac43a4e31d5@mail.gmail.com>
References: <E59B06EE-15CA-481F-8DFB-B77250DD98EA@yahoo.fr>
	<d747ed50804061047l66da647ag85221ac43a4e31d5@mail.gmail.com>
Message-ID: <5C2823BB-AC0D-4519-AE60-8AAF77CB490C@yahoo.fr>

Hi Andrew,

Thank you for your tip! I was not aware about the CMake config for  
MINC, sorry. I always compiled it with the configure/make/make  
install ancestral method and never checker for that new method.

So, I recompiled MINC2 from scratch, using CMake, with -fno-common  
option, and it worked, thanks! The first problem is solved.

However, when I tried to compile ITK against it I obtained the same  
error



[ 95%] Building CXX object Code/Review/CMakeFiles/ITKIOMINC2.dir/ 
itkMINC2ImageIO.o[ 95%] Building CXX object Code/Review/CMakeFiles/ 
ITKIOMINC2.dir/itkMINC2ImageIOFactory.oLinking CXX shared  
library ../../bin/libITKIOMINC2.dylibld: common symbols not allowed  
with MH_DYLIB output format with the -multi_module option/Users/ 
tmansi/local/imaging/minc/install/lib/libminc2.a(hdf_convenience.o)  
definition of common __m2_list (size 16)/Users/tmansi/local/imaging/ 
minc/install/lib/libminc2.a(minc_globdef.o) definition of common  
_minc_call_depth (size 16)/Users/tmansi/local/imaging/minc/install/ 
lib/libminc2.a(minc_globdef.o) definition of common _minc_trash_var  
(size 16)/usr/bin/libtool: internal link edit command failedmake[2]:  
*** [bin/libITKIOMINC2.3.3.0.dylib] Error 1make[1]: *** [Code/Review/ 
CMakeFiles/ITKIOMINC2.dir/all] Error 2make: *** [all] Error 2




I tried with/without -fno-common option for MINC2 and ITK, without  
success... I enabled the ITK_USE_REVIEW and properly set the minc  
path, but nothing, always the same error.

By the way, I don't really understand the link with the problem  
raised by Jim, I am sorry. Should I had the #if ... #endif code  
somewhere to fix the problem?

Thank you so much for your help,

Best regards,
Thomas


Le 6 avr. 08 ? 19:47, Andrew Janke a ?crit :
> On Sun, Apr 6, 2008 at 6:10 AM, Thomas Mansi  
> <thomas_mansi at yahoo.fr> wrote:
>>  I would like to test the MINC IO factory of ITK but I am  
>> experiencing
>>  some linking problems when compiling the tools.
>>  I am on Mac OS X Tiger (32bits), HDF5 v 1.6.1 and here is what I did
>>  so far.
>>  + I successfully compiled and installed netcdf 1.6.2 with -fno- 
>> common
>>  option
>>  + I successfully compiled minc 2.0.15 without -fno-common option.
>>  With -fno-common, I have the following linker error:
>
> Hi Tomas,
>
> Just a quick question, are you using Cmake for the MINC build or the
> GNU autoconf stuff?  (ie: configure).
>
> As for the ecattominc problem I will take a bet that this is related
> to Jims post that I just replied to (but haven't checked). In any case
> when I build MINC2.X for ITK I generally build it using the
> CMakeLists.txt file and use cmake.
>
>
> -- 
> 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 Michel.Audette at medizin.uni-leipzig.de  Mon Apr  7 06:24:27 2008
From: Michel.Audette at medizin.uni-leipzig.de (Michel.Audette at medizin.uni-leipzig.de)
Date: Mon, 7 Apr 2008 12:24:27 +0200
Subject: [MINC-users] ***UNCHECKED*** ***UNCHECKED*** RE: mincconvert to
	minc2problems
References: <160E3DD4FB702C4CB860C65186686E690201FF1F@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FF31@MRZS152229.medizin.uni-leipzig.de>

<1207321785.20595.70.camel at mouse17.phenogenomics.ca>
<160E3DD4FB702C4CB860C65186686E6902424E5D at MRZS152229.medizin.uni-leipzig.de> <1207324635.20595.78.camel at mouse17.phenogenomics.ca>
From: "Audette, Michel" <Michel.Audette at medizin.uni-leipzig.de>
To: "Leila Baghdadi" <baghdadi at phenogenomics.ca>
Cc: <minc-users at bic.mni.mcgill.ca>

Hi Leila, 

stupidly, I did not enable --enable-minc2 when I last configured and built my minc stuff. I don't know where my mind was. 

Thanks for your help. 

Cheers, 

Michel


-----Original Message-----
From: Leila Baghdadi [mailto:baghdadi at phenogenomics.ca]
Sent: Fri 4/4/2008 5:57 PM
To: Audette, Michel
Subject: ***UNCHECKED*** ***UNCHECKED*** RE: [MINC-users] mincconvert to minc2problems
 
Michel

Not sure if I understand the problem here

 mincconvert heartMarkersClass0a_iso_distlt5.mnc leilaa.mnc -2

if I do the above I have no problem and further

baghdadi at gus:~/Desktop/michel$ mincinfo -minc_version leilaa.mnc
Version: 2 (HDF5)


and I can read it into ITK (you are probably using the same itk minc2
code that I have written) (snap attached)

I have attached the minc2 files

Leila


On Fri, 2008-04-04 at 17:34 +0200, Audette, Michel wrote:
> Hi Leila, 
> 
> turns out not to be too large, so I'm emailing the files to you. 
> 
> Cheers,
> 
> Michel
> 
> Michel Audette, Ph.D.   
> Innovation Center Computer Assisted Surgery (ICCAS)   
> Semmelweisstra?e 14  
> Leipzig, Germany  
> Phone: ++49 (0) 341 / 97 - 1 20 13  
> Fax: ++49 (0) 341 / 97 - 1 20 09 
>  
> 
> 
> 
> -----Original Message-----
> From: minc-users-bounces at bic.mni.mcgill.ca [mailto:minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Leila Baghdadi
> Sent: April 4, 2008 5:10 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] mincconvert to minc2 problems
> 
> Michel,
> 
> I do not work on minc2 at work but if you send me your image
> information, I can check it this weekend and see if I can find out what
> is going on. is this a multichannel data set by any chance.
> 
> 
> Leila
> 
> On Fri, 2008-04-04 at 16:32 +0200, Audette, Michel wrote:
> > Hi folks, 
> > 
> > I'm working with Rupert Brooks to apply his ITK-based registration that he's developing, and for some reason, my attempt to mincconvert to minc2 seems to fail. 
> > 
> > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc>  mincconvert -2 heartMarkersClass0a_iso_distlt5.mnc heartMarkersClass0a_iso_distlt5.mnc2 -clob
> > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> mincconvert -2 heartMarkersClass0b_iso_distlt5.mnc heartMarkersClass0b_iso_distlt5.mnc2 -clob
> > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0a_iso_distlt5.mnc2
> > heartMarkersClass0a_iso_distlt5.mnc2: NetCDF Data Format data
> > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0b_iso_distlt5.mnc2
> > heartMarkersClass0b_iso_distlt5.mnc2: NetCDF Data Format data
> > 
> > Can someone suggest a course of action? 
> > 
> > Cheers, 
> > 
> > Michel
> > 
> > Michel Audette, Ph.D.  
> > Innovation Center Computer Assisted Surgery (ICCAS)  
> > Semmelweisstra?e 14 
> > Leipzig, Germany 
> > Phone: ++49 (0) 341 / 97 - 1 20 13 
> > Fax: ++49 (0) 341 / 97 - 1 20 09
> > 
> > _______________________________________________
> > 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



From Michel.Audette at medizin.uni-leipzig.de  Mon Apr  7 10:28:06 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Mon, 7 Apr 2008 16:28:06 +0200
Subject: [MINC-users] mincconvert to minc2problems
Message-ID: <160E3DD4FB702C4CB860C65186686E6902424E6A@MRZS152229.medizin.uni-leipzig.de>

Hi folks, 

not sure if I copied this correctly, so here goes... My mincconvert issue was just the result of omitting to configure minc with --enable-minc2. If one tries to mincconvert -2 without the enable, it simply produces a minc1 file. 

Cheers,

Michel

Michel Audette, Ph.D.   
Innovation Center Computer Assisted Surgery (ICCAS)   
Semmelweisstra?e 14  
Leipzig, Germany  
Phone: ++49 (0) 341 / 97 - 1 20 13  
Fax: ++49 (0) 341 / 97 - 1 20 09 
 

 


-----Original Message-----
From: Leila Baghdadi [mailto:baghdadi at phenogenomics.ca] 
Sent: April 7, 2008 4:22 PM
To: Audette, Michel
Subject: RE: ***UNCHECKED*** ***UNCHECKED*** RE: [MINC-users] mincconvert to minc2problems

That's great!

can you please send an e-mail to list and mention the flag as well. So
people will know the problem was solved and also are reminded of the
flag for minc2.


thanks

Leila


On Mon, 2008-07-04 at 12:24 +0200, Michel.Audette at medizin.uni-leipzig.de
wrote:
> Hi Leila, 
> 
> stupidly, I did not enable --enable-minc2 when I last configured and built my minc stuff. I don't know where my mind was. 
> 
> Thanks for your help. 
> 
> Cheers, 
> 
> Michel
> 
> 
> -----Original Message-----
> From: Leila Baghdadi [mailto:baghdadi at phenogenomics.ca]
> Sent: Fri 4/4/2008 5:57 PM
> To: Audette, Michel
> Subject: ***UNCHECKED*** ***UNCHECKED*** RE: [MINC-users] mincconvert to minc2problems
>  
> Michel
> 
> Not sure if I understand the problem here
> 
>  mincconvert heartMarkersClass0a_iso_distlt5.mnc leilaa.mnc -2
> 
> if I do the above I have no problem and further
> 
> baghdadi at gus:~/Desktop/michel$ mincinfo -minc_version leilaa.mnc
> Version: 2 (HDF5)
> 
> 
> and I can read it into ITK (you are probably using the same itk minc2
> code that I have written) (snap attached)
> 
> I have attached the minc2 files
> 
> Leila
> 
> 
> On Fri, 2008-04-04 at 17:34 +0200, Audette, Michel wrote:
> > Hi Leila, 
> > 
> > turns out not to be too large, so I'm emailing the files to you. 
> > 
> > Cheers,
> > 
> > Michel
> > 
> > Michel Audette, Ph.D.   
> > Innovation Center Computer Assisted Surgery (ICCAS)   
> > Semmelweisstra?e 14  
> > Leipzig, Germany  
> > Phone: ++49 (0) 341 / 97 - 1 20 13  
> > Fax: ++49 (0) 341 / 97 - 1 20 09 
> >  
> > 
> > 
> > 
> > -----Original Message-----
> > From: minc-users-bounces at bic.mni.mcgill.ca [mailto:minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Leila Baghdadi
> > Sent: April 4, 2008 5:10 PM
> > To: MINC users mailing list
> > Subject: Re: [MINC-users] mincconvert to minc2 problems
> > 
> > Michel,
> > 
> > I do not work on minc2 at work but if you send me your image
> > information, I can check it this weekend and see if I can find out what
> > is going on. is this a multichannel data set by any chance.
> > 
> > 
> > Leila
> > 
> > On Fri, 2008-04-04 at 16:32 +0200, Audette, Michel wrote:
> > > Hi folks, 
> > > 
> > > I'm working with Rupert Brooks to apply his ITK-based registration that he's developing, and for some reason, my attempt to mincconvert to minc2 seems to fail. 
> > > 
> > > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc>  mincconvert -2 heartMarkersClass0a_iso_distlt5.mnc heartMarkersClass0a_iso_distlt5.mnc2 -clob
> > > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> mincconvert -2 heartMarkersClass0b_iso_distlt5.mnc heartMarkersClass0b_iso_distlt5.mnc2 -clob
> > > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0a_iso_distlt5.mnc2
> > > heartMarkersClass0a_iso_distlt5.mnc2: NetCDF Data Format data
> > > maudette at icaw164201:~/data/data/heartData/mincdata/01446397_mnc> file heartMarkersClass0b_iso_distlt5.mnc2
> > > heartMarkersClass0b_iso_distlt5.mnc2: NetCDF Data Format data
> > > 
> > > Can someone suggest a course of action? 
> > > 
> > > Cheers, 
> > > 
> > > Michel
> > > 
> > > Michel Audette, Ph.D.  
> > > Innovation Center Computer Assisted Surgery (ICCAS)  
> > > Semmelweisstra?e 14 
> > > Leipzig, Germany 
> > > Phone: ++49 (0) 341 / 97 - 1 20 13 
> > > Fax: ++49 (0) 341 / 97 - 1 20 09
> > > 
> > > _______________________________________________
> > > 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
> 



From Michel.Audette at medizin.uni-leipzig.de  Tue Apr  8 09:06:11 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 8 Apr 2008 15:06:11 +0200
Subject: [MINC-users] using EMMA: possible without Mex?
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>

Hi all, 

I'd like to use Emma for Matlab-based visualization, but my Matlab license here does not include Mex (at least for the time being). I don't have much expectations, but I was wondering: is there any way around this in order to use Emma? 

Cheers, 

Michel

Michel Audette, Ph.D.  
Innovation Center Computer Assisted Surgery (ICCAS)  
Semmelweisstra?e 14 
Leipzig, Germany 
Phone: ++49 (0) 341 / 97 - 1 20 13 
Fax: ++49 (0) 341 / 97 - 1 20 09
 


From Michel.Audette at medizin.uni-leipzig.de  Tue Apr  8 10:00:42 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 8 Apr 2008 16:00:42 +0200
Subject: [MINC-users] using EMMA: possible without Mex?
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>
	<20080408095541.C21126@mrs.mni.mcgill.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>

Hello Alex, 

thanks for your kind reply. 

What I want is the voxel values at specific tag points, once Matlab reads the tag files, so that I can visualize these tag points in feature space. 

Cheers, 

Michel

-----Original Message-----
From: Alexandre CARMEL-VEILLEUX [mailto:acveilleux at mrs.mni.mcgill.ca]
Sent: Tue 4/8/2008 3:55 PM
To: Audette, Michel
Subject: Re: [MINC-users] using EMMA: possible without Mex?
 
	If all you want are the voxel values, use minctoraw and load the
raw into matlab.

Alex

On Tue, Apr 08, 2008 at 03:06:11PM +0200, Audette, Michel wrote:
> Date: Tue, 8 Apr 2008 15:06:11 +0200
> From: "Audette, Michel" <Michel.Audette at medizin.uni-leipzig.de>
> To: <minc-users at bic.mni.mcgill.ca>
> Subject: [MINC-users] using EMMA: possible without Mex?
> 
> Hi all, 
> 
> I'd like to use Emma for Matlab-based visualization, but my Matlab license here does not include Mex (at least for the time being). I don't have much expectations, but I was wondering: is there any way around this in order to use Emma? 
> 
> Cheers, 
> 
> Michel
> 
> Michel Audette, Ph.D.  
> Innovation Center Computer Assisted Surgery (ICCAS)  
> Semmelweisstra?e 14 
> Leipzig, Germany 
> Phone: ++49 (0) 341 / 97 - 1 20 13 
> Fax: ++49 (0) 341 / 97 - 1 20 09
>  
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From a.janke at gmail.com  Tue Apr  8 17:53:56 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 9 Apr 2008 07:53:56 +1000
Subject: [MINC-users] using EMMA: possible without Mex?
In-Reply-To: <160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>
	<20080408095541.C21126@mrs.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>

On Wed, Apr 9, 2008 at 12:00 AM, Audette, Michel
<Michel.Audette at medizin.uni-leipzig.de> wrote:
>  What I want is the voxel values at specific tag points, once Matlab reads the tag files, so that I can visualize these tag points in feature space.

Hi Michel,

I once wrote a program called mincsample for doing this sort of thing.
 The only spanner in the works is that I primarily wrote it for doing
random samples from files based upon a mask.  It allows you to do
things like this:

gordon:~$ mincsample -random_samples 10 -coords ~/data/me/a.mnc
-97.553589999999999804  -10.734777364705921698  -108.63487000000000648
 1.9928282597085527073
-97.553589999999999804  107.16522058039204524   -88.947370000000006485
 1.0070954451819638109
-81.616089999999999804  117.06522040784302874   -75.822370000000006485
 7.0038910505836575737
-1.9285899999999998045  62.165221364705800511   -66.447370000000006485
 46.982528419928279106
-23.491089999999999804  131.46522015686261398   -66.447370000000006485
 2.0080872816052490748
-31.928589999999999804  67.565221270588153857   -9.2598700000000064847
 38.989852750438693363
97.446410000000000196   90.965220862744999408   4.8026299999999935153
 11.996643015182726799
-111.6160899999999998   84.665220972548922873   74.177629999999993515
 1.9958800640878919808
-115.3660899999999998   58.565221427450900649   106.99012999999999352
 1.0070954451819638109
36.508910000000000196   -28.734777050980419233  122.92762999999999352   0

Where here the output is the coordinate followed by the value.

gordon:~$ mincsample -help
Command-specific options:
General options:
 -version:        print version info and exit.
 -verbose:        print out extra information.
 -quiet:          be very quiet.
 -clobber:        clobber existing files.
 -max_buffer:     maximum size of buffers (in kbytes)
                Default value: 4096
 -mask:           select voxels within the specified mask
 -mask_val:       mask value to use
                Default value: 1

Sampling Types:
 -all:            sample all the data (Default)
 -random_seed:    Random seed to use (use to get reproducible runs)
Default: use tv_usec
                Default value: -1
 -random_samples: take # random samples from the input data
                Default value: 0

Output Options:
 -sample:         Output a <mask.mnc> file of chosen points
 -outfile:        <file> for output data (Default: stdout)
 -append:         append output data to existing file
 -ascii:          Write out data as ascii strings (default)
 -double:         Write out data as double precision floating-point values
 -coords:         Write out world co-ordinates as well as values

Generic options for all commands:
 -help:           Print summary of command-line options and abort
 -version:        Print version number of program and exit

Usage: mincsample [options] <in1.mnc> <in2.mnc> ...
       mincsample -help

The help output is above, so in essence if you can convert your tag
points to a mask then all you would need to do is this:

   mincsample -coords -ascii -mask tag_mask.mnc infile.mnc

if you wanted output like the above example. If you wanted to save a
bit of space and output in double then just swap the -ascii flag with
a -double.   You can find mincsample (in deb and source form) on
packages.bic.mni.mcgill.ca.

Let me know if you need any more help with it, the simple answer here
is that I should add tag support to mincsample (Anders Rodell is
already requesting this!) but just haven't got to it yet... :)


a

From xtomas at gmail.com  Thu Apr 10 17:15:18 2008
From: xtomas at gmail.com (=?ISO-8859-1?Q?Xavier_Tom=E1s?=)
Date: Thu, 10 Apr 2008 23:15:18 +0200
Subject: [MINC-users] generating tags for INSECT training
Message-ID: <7702fa7d0804101415s2cf90386h4e07a49f2c374111@mail.gmail.com>

Hi all,

I'm interested in using INSECT to segment brain tissues in a paediatric
population, in order to account the differences in this data with adult
population I prepared a specific atlas.

Then, my question is about how to generate a new group of training tags for
INSECT from my atlas. I was trying with extracttag function but I'm not
successful. What you would recommend for this purpose?

Thanks in advance,

-- 
Xavier Tom?s Fern?ndez
xtomas at gmail.com

From alex at bic.mni.mcgill.ca  Thu Apr 10 19:19:04 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Thu, 10 Apr 2008 19:19:04 -0400
Subject: [MINC-users] generating tags for INSECT training
In-Reply-To: <7702fa7d0804101415s2cf90386h4e07a49f2c374111@mail.gmail.com>
References: <7702fa7d0804101415s2cf90386h4e07a49f2c374111@mail.gmail.com>
Message-ID: <47FEA068.8020802@bic.mni.mcgill.ca>

Hello Xavier,

Albeit a bit old, I would have suggested to use extracttag which worked 
fine last time I tried it. I guess the question is why you are not 
successful using it? What doesn't work?

-- Alex

Xavier Tom?s wrote:
> Hi all,
> 
> I'm interested in using INSECT to segment brain tissues in a paediatric
> population, in order to account the differences in this data with adult
> population I prepared a specific atlas.
> 
> Then, my question is about how to generate a new group of training tags for
> INSECT from my atlas. I was trying with extracttag function but I'm not
> successful. What you would recommend for this purpose?
> 
> Thanks in advance,
> 

From a.janke at gmail.com  Thu Apr 10 22:53:50 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 11 Apr 2008 12:53:50 +1000
Subject: [MINC-users] For the OSX 10.5 crash test dummies.
Message-ID: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>

Thanks to Alexandre (the current "record" holder in the minc benchmarks) here:

   http://en.wikibooks.org/wiki/MINC/Benchmarks

I have now compiled some Leopard 10.5 64bit MINC2 binaries here:

   http://packages.bic.mni.mcgill.ca/osx-10.5/

These have been compiled on a 10.5 MacPro using 64 bit libraries.  I
myself did not compile netcdf/hdf/netpbm in 64 bit but understand from
the person who did that it took a bit of pain. ;)

So feel free to try these if you want but be aware that I can't help
you compiling HDF/netcdf in 64 bit!.  Alexandre did this for me and
for that I am very gratefull!  I suspect he can be bribed into helping
others get this going on their own machines also.


a

From a.janke at gmail.com  Fri Apr 11 01:22:43 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 11 Apr 2008 15:22:43 +1000
Subject: [MINC-users] Linker errors on OS X Tiger when compiling ITK
	MINC2ImageIO
In-Reply-To: <5C2823BB-AC0D-4519-AE60-8AAF77CB490C@yahoo.fr>
References: <E59B06EE-15CA-481F-8DFB-B77250DD98EA@yahoo.fr>
	<d747ed50804061047l66da647ag85221ac43a4e31d5@mail.gmail.com>
	<5C2823BB-AC0D-4519-AE60-8AAF77CB490C@yahoo.fr>
Message-ID: <d747ed50804102222u4f9982d5o6f0f53648b265f8e@mail.gmail.com>

Hi again Thomas,

I have just made a change in CVS (rewrote the error code) that should
fix this.  If you happen to have access to the BIC system could you
give this version a go please?

   cvs -d cvs.bic.mni.mcgill.ca:/private-cvsroot checkout minc

should do the trick.


a

>  However, when I tried to compile ITK against it I obtained the same
>  error
>
>  [ 95%] Building CXX object Code/Review/CMakeFiles/ITKIOMINC2.dir/
>  itkMINC2ImageIO.o[ 95%] Building CXX object Code/Review/CMakeFiles/
>  ITKIOMINC2.dir/itkMINC2ImageIOFactory.oLinking CXX shared
>  library ../../bin/libITKIOMINC2.dylibld: common symbols not allowed
>  with MH_DYLIB output format with the -multi_module option/Users/
>  tmansi/local/imaging/minc/install/lib/libminc2.a(hdf_convenience.o)
>  definition of common __m2_list (size 16)/Users/tmansi/local/imaging/
>  minc/install/lib/libminc2.a(minc_globdef.o) definition of common
>  _minc_call_depth (size 16)/Users/tmansi/local/imaging/minc/install/
>
> lib/libminc2.a(minc_globdef.o) definition of common _minc_trash_var
>  (size 16)/usr/bin/libtool: internal link edit command failedmake[2]:
>  *** [bin/libITKIOMINC2.3.3.0.dylib] Error 1make[1]: *** [Code/Review/
>  CMakeFiles/ITKIOMINC2.dir/all] Error 2make: *** [all] Error 2

From Michel.Audette at medizin.uni-leipzig.de  Fri Apr 11 03:21:08 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 11 Apr 2008 09:21:08 +0200
Subject: [MINC-users] using EMMA: possible without Mex?
In-Reply-To: <d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de><20080408095541.C21126@mrs.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6902424E76@MRZS152229.medizin.uni-leipzig.de>

Hi Andrew, 

thanks for your kind reply. Sorry too that mine is late. I'll look around for mincsample, if it comes with the BIC toolbox. 

Cheers, 

Michel

Michel Audette, Ph.D.   
Innovation Center Computer Assisted Surgery (ICCAS)   
Semmelweisstra?e 14  
Leipzig, Germany  
Phone: ++49 (0) 341 / 97 - 1 20 13  
Fax: ++49 (0) 341 / 97 - 1 20 09 
 

 


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca [mailto:minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Andrew Janke
Sent: April 8, 2008 11:54 PM
To: MINC users mailing list
Subject: Re: [MINC-users] using EMMA: possible without Mex?

On Wed, Apr 9, 2008 at 12:00 AM, Audette, Michel
<Michel.Audette at medizin.uni-leipzig.de> wrote:
>  What I want is the voxel values at specific tag points, once Matlab reads the tag files, so that I can visualize these tag points in feature space.

Hi Michel,

I once wrote a program called mincsample for doing this sort of thing.
 The only spanner in the works is that I primarily wrote it for doing
random samples from files based upon a mask.  It allows you to do
things like this:

gordon:~$ mincsample -random_samples 10 -coords ~/data/me/a.mnc
-97.553589999999999804  -10.734777364705921698  -108.63487000000000648
 1.9928282597085527073
-97.553589999999999804  107.16522058039204524   -88.947370000000006485
 1.0070954451819638109
-81.616089999999999804  117.06522040784302874   -75.822370000000006485
 7.0038910505836575737
-1.9285899999999998045  62.165221364705800511   -66.447370000000006485
 46.982528419928279106
-23.491089999999999804  131.46522015686261398   -66.447370000000006485
 2.0080872816052490748
-31.928589999999999804  67.565221270588153857   -9.2598700000000064847
 38.989852750438693363
97.446410000000000196   90.965220862744999408   4.8026299999999935153
 11.996643015182726799
-111.6160899999999998   84.665220972548922873   74.177629999999993515
 1.9958800640878919808
-115.3660899999999998   58.565221427450900649   106.99012999999999352
 1.0070954451819638109
36.508910000000000196   -28.734777050980419233  122.92762999999999352   0

Where here the output is the coordinate followed by the value.

gordon:~$ mincsample -help
Command-specific options:
General options:
 -version:        print version info and exit.
 -verbose:        print out extra information.
 -quiet:          be very quiet.
 -clobber:        clobber existing files.
 -max_buffer:     maximum size of buffers (in kbytes)
                Default value: 4096
 -mask:           select voxels within the specified mask
 -mask_val:       mask value to use
                Default value: 1

Sampling Types:
 -all:            sample all the data (Default)
 -random_seed:    Random seed to use (use to get reproducible runs)
Default: use tv_usec
                Default value: -1
 -random_samples: take # random samples from the input data
                Default value: 0

Output Options:
 -sample:         Output a <mask.mnc> file of chosen points
 -outfile:        <file> for output data (Default: stdout)
 -append:         append output data to existing file
 -ascii:          Write out data as ascii strings (default)
 -double:         Write out data as double precision floating-point values
 -coords:         Write out world co-ordinates as well as values

Generic options for all commands:
 -help:           Print summary of command-line options and abort
 -version:        Print version number of program and exit

Usage: mincsample [options] <in1.mnc> <in2.mnc> ...
       mincsample -help

The help output is above, so in essence if you can convert your tag
points to a mask then all you would need to do is this:

   mincsample -coords -ascii -mask tag_mask.mnc infile.mnc

if you wanted output like the above example. If you wanted to save a
bit of space and output in double then just swap the -ascii flag with
a -double.   You can find mincsample (in deb and source form) on
packages.bic.mni.mcgill.ca.

Let me know if you need any more help with it, the simple answer here
is that I should add tag support to mincsample (Anders Rodell is
already requesting this!) but just haven't got to it yet... :)


a
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From a.janke at gmail.com  Fri Apr 11 04:27:34 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 11 Apr 2008 18:27:34 +1000
Subject: [MINC-users] using EMMA: possible without Mex?
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6902424E76@MRZS152229.medizin.uni-leipzig.de>
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>
	<20080408095541.C21126@mrs.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6902424E76@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50804110127n8c7f268m9fd490288ab054df@mail.gmail.com>

On Fri, Apr 11, 2008 at 5:21 PM, Audette, Michel
<Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi Andrew,
>
>  thanks for your kind reply. Sorry too that mine is late. I'll look around for mincsample, if it comes with the BIC toolbox.

It is not part of minc "proper" but you will find it on
packages.bic.mni.mcgill.ca

It uses the Mersenne Twister for random number generation and I am not
entirely sure on the license restrictions so dont include it MINC
proper until I can find out for sure.


a

From acveilleux at mrs.mni.mcgill.ca  Fri Apr 11 12:20:31 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Fri, 11 Apr 2008 12:20:31 -0400
Subject: [MINC-users] For the OSX 10.5 crash test dummies.
In-Reply-To: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>;
	from a.janke@gmail.com on Fri, Apr 11, 2008 at 12:53:50PM +1000
References: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>
Message-ID: <20080411122030.E27748@mrs.mni.mcgill.ca>

Hello,

	Compiling the packages isn't overly hard for most of them.
Libraries needed:

netcdf
hdf5 (1.6.x)
libjpeg-6b
libpng
libtiff
netpbm (the above three are for netpbm)

	CFLAGS and CXXFLAGS need to have "-arch x86_64" in them, I used
"-arch x86_64 -m64 -O2". Some of the older libraries can be very annoying
and ignore some/all of those if merely provided to ./configure.

	Some of the libtool generated on the mac are broken. In the case
of hdf5 for example, I ran configure with the same options on 1.8.0 and
then copied the resulting libtool to the 1.6.7 directory. They've evidently
fixed the problem in the newer version. For some of the older libs I used
a combination of hacking the libtool to have CC="cc -arch x86_64 -m64" and
manual compile command-lines. The main errors you'll see involve files
being of the "wrong architecture type" as libtool will ignore your parameters
and let gcc default to i386. There might be better "Apple-blessed" methods
of doing this however (like somehow making gcc default to x86_64 globally).

	Those wanting to save time can have a copy of my /usr/local/lib...

	Oh, and postf is probably broken (unless Andrew worked some magic
while compiling it) as on my system it suffers from a 32/64 bit issue.

Alex

On Fri, Apr 11, 2008 at 12:53:50PM +1000, Andrew Janke wrote:
> Date: Fri, 11 Apr 2008 12:53:50 +1000
> From: "Andrew Janke" <a.janke at gmail.com>
> To: "MINC users mailing list" <minc-users at bic.mni.mcgill.ca>
> Subject: [MINC-users] For the OSX 10.5 crash test dummies.
> 
> Thanks to Alexandre (the current "record" holder in the minc benchmarks) here:
> 
>    http://en.wikibooks.org/wiki/MINC/Benchmarks
> 
> I have now compiled some Leopard 10.5 64bit MINC2 binaries here:
> 
>    http://packages.bic.mni.mcgill.ca/osx-10.5/
> 
> These have been compiled on a 10.5 MacPro using 64 bit libraries.  I
> myself did not compile netcdf/hdf/netpbm in 64 bit but understand from
> the person who did that it took a bit of pain. ;)
> 
> So feel free to try these if you want but be aware that I can't help
> you compiling HDF/netcdf in 64 bit!.  Alexandre did this for me and
> for that I am very gratefull!  I suspect he can be bribed into helping
> others get this going on their own machines also.
> 
> 
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From acveilleux at mrs.mni.mcgill.ca  Fri Apr 11 12:48:46 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Fri, 11 Apr 2008 12:48:46 -0400
Subject: [MINC-users] For the OSX 10.5 crash test dummies.
In-Reply-To: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>;
	from a.janke@gmail.com on Fri, Apr 11, 2008 at 12:53:50PM +1000
References: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>
Message-ID: <20080411124846.H27748@mrs.mni.mcgill.ca>

	I put a tar of my /usr/local with 64-bit MINC (./mni for MINC1,
./bic for MINC2) including an (hopefully) 64-bit clean postf build that
won't segfault on execution on to yorick:/data/scratch/scratch1 for
those who are interested. The tar expects to be extracted from /usr/local
but it would be much safer to extract it in some temporary folder and
cherry pick the stuff you actually want/need so you don't overwrite what
you already have.

	Feedback about broken bits would be appreciated.

	These are not the same binaries as Andrew's but the ./lib directory
contains the same libraries he used I believe.

Alex

On Fri, Apr 11, 2008 at 12:53:50PM +1000, Andrew Janke wrote:
> Date: Fri, 11 Apr 2008 12:53:50 +1000
> From: "Andrew Janke" <a.janke at gmail.com>
> To: "MINC users mailing list" <minc-users at bic.mni.mcgill.ca>
> Subject: [MINC-users] For the OSX 10.5 crash test dummies.
> 
> Thanks to Alexandre (the current "record" holder in the minc benchmarks) here:
> 
>    http://en.wikibooks.org/wiki/MINC/Benchmarks
> 
> I have now compiled some Leopard 10.5 64bit MINC2 binaries here:
> 
>    http://packages.bic.mni.mcgill.ca/osx-10.5/
> 
> These have been compiled on a 10.5 MacPro using 64 bit libraries.  I
> myself did not compile netcdf/hdf/netpbm in 64 bit but understand from
> the person who did that it took a bit of pain. ;)
> 
> So feel free to try these if you want but be aware that I can't help
> you compiling HDF/netcdf in 64 bit!.  Alexandre did this for me and
> for that I am very gratefull!  I suspect he can be bribed into helping
> others get this going on their own machines also.
> 
> 
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From mhough at fmrib.ox.ac.uk  Mon Apr 14 05:50:56 2008
From: mhough at fmrib.ox.ac.uk (Morgan Hough)
Date: Mon, 14 Apr 2008 10:50:56 +0100
Subject: [MINC-users] using EMMA: possible without Mex?
In-Reply-To: <d747ed50804110127n8c7f268m9fd490288ab054df@mail.gmail.com>
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>	<160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>	<20080408095541.C21126@mrs.mni.mcgill.ca>	<160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>	<d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>	<160E3DD4FB702C4CB860C65186686E6902424E76@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804110127n8c7f268m9fd490288ab054df@mail.gmail.com>
Message-ID: <48032900.1070707@fmrib.ox.ac.uk>

Hi Andrew,

Is that the Mersenne Twister from Makoto Matsumoto. If it is newran 
(associated with newmat) also uses this code but the link their seems to 
be dead. I was trying to find out about the license on this as well. 
Matsumoto's new website is here:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html

with updated license information.

Cheers,

-Morgan

Andrew Janke wrote:
> On Fri, Apr 11, 2008 at 5:21 PM, Audette, Michel
> <Michel.Audette at medizin.uni-leipzig.de> wrote:
>   
>> Hi Andrew,
>>
>>  thanks for your kind reply. Sorry too that mine is late. I'll look around for mincsample, if it comes with the BIC toolbox.
>>     
>
> It is not part of minc "proper" but you will find it on
> packages.bic.mni.mcgill.ca
>
> It uses the Mersenne Twister for random number generation and I am not
> entirely sure on the license restrictions so dont include it MINC
> proper until I can find out for sure.
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>   


-- 
-----------------------------------------------------------------------
Morgan Hough, D. Phil. Student,  Oxford University FMRIB Centre

FMRIB, JR Hospital, Headington, Oxford  OX3 9DU, UK
+44 (0) 1865 222466  (fax 222717)
mhough at fmrib.ox.ac.uk  http://www.fmrib.ox.ac.uk/~mhough
-----------------------------------------------------------------------




From thomas_mansi at yahoo.fr  Mon Apr 14 15:28:15 2008
From: thomas_mansi at yahoo.fr (Thomas Mansi)
Date: Mon, 14 Apr 2008 21:28:15 +0200
Subject: [MINC-users] Linker errors on OS X Tiger when compiling ITK
	MINC2ImageIO
In-Reply-To: <d747ed50804102222u4f9982d5o6f0f53648b265f8e@mail.gmail.com>
References: <E59B06EE-15CA-481F-8DFB-B77250DD98EA@yahoo.fr>
	<d747ed50804061047l66da647ag85221ac43a4e31d5@mail.gmail.com>
	<5C2823BB-AC0D-4519-AE60-8AAF77CB490C@yahoo.fr>
	<d747ed50804102222u4f9982d5o6f0f53648b265f8e@mail.gmail.com>
Message-ID: <FE88541F-2E9C-4EAA-962C-3702FE443467@yahoo.fr>

Dear Andrew, sorry for the late answer.

Thank you for the tip! I am going to get the CVS version and try to  
compile it as soon as possible. I keep you informed.

Thanks again for your help,

Best regards
Thomas


Le 11 avr. 08 ? 07:22, Andrew Janke a ?crit :
> Hi again Thomas,
>
> I have just made a change in CVS (rewrote the error code) that should
> fix this.  If you happen to have access to the BIC system could you
> give this version a go please?
>
>    cvs -d cvs.bic.mni.mcgill.ca:/private-cvsroot checkout minc
>
> should do the trick.
>
>
> a
>
>>  However, when I tried to compile ITK against it I obtained the same
>>  error
>>
>>  [ 95%] Building CXX object Code/Review/CMakeFiles/ITKIOMINC2.dir/
>>  itkMINC2ImageIO.o[ 95%] Building CXX object Code/Review/CMakeFiles/
>>  ITKIOMINC2.dir/itkMINC2ImageIOFactory.oLinking CXX shared
>>  library ../../bin/libITKIOMINC2.dylibld: common symbols not allowed
>>  with MH_DYLIB output format with the -multi_module option/Users/
>>  tmansi/local/imaging/minc/install/lib/libminc2.a(hdf_convenience.o)
>>  definition of common __m2_list (size 16)/Users/tmansi/local/imaging/
>>  minc/install/lib/libminc2.a(minc_globdef.o) definition of common
>>  _minc_call_depth (size 16)/Users/tmansi/local/imaging/minc/install/
>>
>> lib/libminc2.a(minc_globdef.o) definition of common _minc_trash_var
>>  (size 16)/usr/bin/libtool: internal link edit command failedmake[2]:
>>  *** [bin/libITKIOMINC2.3.3.0.dylib] Error 1make[1]: *** [Code/ 
>> Review/
>>  CMakeFiles/ITKIOMINC2.dir/all] Error 2make: *** [all] Error 2
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From burt.crepeault at crulrg.ulaval.ca  Tue Apr 15 09:21:49 2008
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Tue, 15 Apr 2008 09:21:49 -0400
Subject: [MINC-users] dcm2mnc produces xspace:spacing = "irregular"
In-Reply-To: <ac2a7d1f0804150538wea4b657u92036fcc54bed7d7@mail.gmail.com>
References: <ac2a7d1f0804150538wea4b657u92036fcc54bed7d7@mail.gmail.com>
Message-ID: <ac2a7d1f0804150621r655d63a3u22f647931060e173@mail.gmail.com>

Hi all,

I'm new to MINC (and to image processing in general) and have encountered
the problem herein:
http://www2.bic.mni.mcgill.ca/pipermail/minc-users/2006-September/001341.html.
The proposed solution appears to work all right but I'm curious as to the
nature of the irregularity. What causes dcm2mnc to set the xspace:spacing
variable to "irregular"? Could there be a problem with the original DICOM
series? How would I verify that?

Burt Cr?peault
Research Assistant
Centre de Recherche de l'Universit? Laval - Robert-Giffard
418-663-5741, ext 6844
<http://www.bic.mni.mcgill.ca/software/>

From thomas_mansi at yahoo.fr  Tue Apr 15 15:43:09 2008
From: thomas_mansi at yahoo.fr (Thomas Mansi)
Date: Tue, 15 Apr 2008 21:43:09 +0200
Subject: [MINC-users] Linker errors on OS X Tiger when compiling ITK
	MINC2ImageIO
In-Reply-To: <FE88541F-2E9C-4EAA-962C-3702FE443467@yahoo.fr>
References: <E59B06EE-15CA-481F-8DFB-B77250DD98EA@yahoo.fr>
	<d747ed50804061047l66da647ag85221ac43a4e31d5@mail.gmail.com>
	<5C2823BB-AC0D-4519-AE60-8AAF77CB490C@yahoo.fr>
	<d747ed50804102222u4f9982d5o6f0f53648b265f8e@mail.gmail.com>
	<FE88541F-2E9C-4EAA-962C-3702FE443467@yahoo.fr>
Message-ID: <E928DE91-F3BD-4D61-980F-D44F0736F3B8@yahoo.fr>

Hi Andrew,

I managed to compile MINC2 CVS but unfortunately I still have the  
same linker error with ITK. I am going to do more tests, and in  
particular try on other systems to see if it is a Mac related issue  
(which I strongly suspect)

Anyway, I had some troubles though to compile MINC2 CVS on my system  
(gcc, MacOS X, Tiger) and here is the hacks I did to get it. It might  
interest somebody.

First, CMake did not find the files ncgentab.h and ncgentab.c in  
progs/mincgen. I manually copied these files from the 2.0.15 release,  
but maybe it is not a viable solution

Second, bison and flex were unable to correctly find the source  
codes. I slightly modified the CMakeLists.txt that is in progs/ to  
add the full path in the BISON and FLEX targets (I just added $ 
{CMAKE_SOURCE_DIR} in front of the source codes). I join you the  
modified CMakeLists.txt

Are those two issues known? Maybe I made some mistakes here and  
that's why ITK still resists me.

Thanks again for your help!
Best

Thomas


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
Url: http://www2.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20080415/8feb07f0/attachment.txt 
-------------- next part --------------



Le 14 avr. 08 ? 21:28, Thomas Mansi a ?crit :
> Dear Andrew, sorry for the late answer.
>
> Thank you for the tip! I am going to get the CVS version and try to
> compile it as soon as possible. I keep you informed.
>
> Thanks again for your help,
>
> Best regards
> Thomas
>
>
> Le 11 avr. 08 ? 07:22, Andrew Janke a ?crit :
>> Hi again Thomas,
>>
>> I have just made a change in CVS (rewrote the error code) that should
>> fix this.  If you happen to have access to the BIC system could you
>> give this version a go please?
>>
>>    cvs -d cvs.bic.mni.mcgill.ca:/private-cvsroot checkout minc
>>
>> should do the trick.
>>
>>
>> a
>>
>>>  However, when I tried to compile ITK against it I obtained the same
>>>  error
>>>
>>>  [ 95%] Building CXX object Code/Review/CMakeFiles/ITKIOMINC2.dir/
>>>  itkMINC2ImageIO.o[ 95%] Building CXX object Code/Review/CMakeFiles/
>>>  ITKIOMINC2.dir/itkMINC2ImageIOFactory.oLinking CXX shared
>>>  library ../../bin/libITKIOMINC2.dylibld: common symbols not allowed
>>>  with MH_DYLIB output format with the -multi_module option/Users/
>>>  tmansi/local/imaging/minc/install/lib/libminc2.a(hdf_convenience.o)
>>>  definition of common __m2_list (size 16)/Users/tmansi/local/ 
>>> imaging/
>>>  minc/install/lib/libminc2.a(minc_globdef.o) definition of common
>>>  _minc_call_depth (size 16)/Users/tmansi/local/imaging/minc/install/
>>>
>>> lib/libminc2.a(minc_globdef.o) definition of common _minc_trash_var
>>>  (size 16)/usr/bin/libtool: internal link edit command failedmake 
>>> [2]:
>>>  *** [bin/libITKIOMINC2.3.3.0.dylib] Error 1make[1]: *** [Code/
>>> Review/
>>>  CMakeFiles/ITKIOMINC2.dir/all] Error 2make: *** [all] Error 2
>> _______________________________________________
>> 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


From burt.crepeault at crulrg.ulaval.ca  Tue Apr 15 16:45:17 2008
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Tue, 15 Apr 2008 16:45:17 -0400
Subject: [MINC-users] Running MINC tools from the www user
Message-ID: <ac2a7d1f0804151345m2f122ba7x172fd138d30b8050@mail.gmail.com>

Hi again,

In my current development, I'm executing MINC tools from an Apache-run PHP
script, therefore running under the default www user. The following command
runs well from the command prompt but gives errors when run from www:

/usr/local/minc2/bin/nu_correct -clobber -mapping_dir
/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007 -iterations
100 -shrink 3 -fwhm 0.1 -distance 100
/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1004/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1004.1.10004.[mnc.d2m].Br.12_p2.mnc
/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1007.1.10007.[mnc.d2m+mnc.nuc].Br.22_p2.mnc

   [7]:     [_www at pita.crulrg.local:/Library/WebServer/Documents/]
[2008-04-15 16:19:39] running:
   [8]:       /usr/local/minc2/bin/nu_estimate_np_and_em -parzen -log
-sharpen 0.1 0.01 -iterations 100 -stop 0.001 -shrink 3 -auto_mask
-nonotify -b_spline 1 -distance 100 -quiet -execute -clobber
-nokeeptmp -tmpdir /var/tmp/nu_correct_32893/
'/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1004/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1004.1.10004.[mnc.d2m].Br.12_p2.mnc'
'/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1007.1.10007.[mnc.d2m+mnc.nuc].Br.22_p2.imp'
   [9]:
   [10]:     Assertion failed at line 742 in file templates/CachedArray.cc
   [11]:     nu_estimate_np_and_em: crashed while running volume_stats
(termination status=256)
   [12]:     nu_correct: crashed while running nu_estimate_np_and_em
(termination status=256)

Usually, this type of error can be traced to a bad permission somewhere, or
to an environment variable that's incorrectly set for the www user.
Unfortunately in this case, I'm a little short on data to troubleshoot it
myself. What does "Assertion failed" on line [10] mean?

Any help would be greatly appreciated.

Thanks,

-- 
Burt Cr?peault
Research Assistant
Centre de Recherche de l'Universit? Laval - Robert-Giffard
418-663-5741, ext 6844

From paulclyon at gmail.com  Tue Apr 15 18:22:40 2008
From: paulclyon at gmail.com (Paul Lyon)
Date: Tue, 15 Apr 2008 18:22:40 -0400
Subject: [MINC-users] New to MINC libraries,
	image dimensions are causing me trouble!
Message-ID: <4bd8ecf80804151522p14db7fe9k689a9a6cf93fcbb3@mail.gmail.com>

Dear MINC Community

I am doing some research under Dr. Thiel at the JGH/MNI in the
analysis of PET scans. I have a background in software engineering
but I am struggling to get my head around using the MINC libraries
correctly, especially w.r.t. manipulating image data.

I am compling against the MINC 1.5 libraries using Cygwin on WinXP.
I have a MNC image file containing PET scan data.
The file has 4 dimensions in that the fourth dimension is time.
The mincinfo utility reveals the following information for my input file:

$ mincinfo.exe test.mnc
file: test.mnc
image: signed__ short -32000 to 32000
image dimensions: time zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    time                       21      unknown      unknown
    zspace                     63       -2.425      -447.26
    yspace                    128      2.05941     -130.772
    xspace                    128      2.05941     -130.772

I have slightly modified Peter Neelin's mincexample1.c source code
which comes as part of the MINC 1.5 release (under progs/) so that
it now reads and writes 4 dimensional data, rather than just 3d.
I thought this would be a useful starting point for me as I need to
read in a 4D MINC file, process it (e.g. apply Guassian filter) and
output the resulting 4D MINC file. Should be straight-forward.

The program compiles and runs happily to produce an output file of
a comparible number of bytes with the following output:

File test.mnc:
  maximum =    1147.13, minimum =   -786.393
  times   =       time: n= 21, step=         1, start=         0
  slices  =     zspace: n= 63, step=    -2.425, start=   -447.26
  rows    =     yspace: n=128, step=   2.05941, start=  -130.772
  columns =     xspace: n=128, step=   2.05941, start=  -130.772
miicv_put 21 63 128 128


I have a few probably very basic problems which I struggling to get
to the bottom of:

1. My program produces an 'empty' output file as shown here:

$ mincextract.exe out.mnc -ascii | head -n10
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392
-786.39315877937258392

The file has this value throughout. Interestingly this value is the same as the
minimum value for the input file (see program output above). I have checked the
return code of the miicv_put call and it is 0. I was thinking it might be some
thing to do with datatypes, but my file contains signed shorts, which I have
updated in the code accordingly.

Where as the original has what I would expect - some noise around zero:

$ mincextract.exe test.mnc -ascii | head -n10
7.1762131193147012109e-05
7.1762131193147012109e-05
7.1762131193147012109e-05
0.0059746876000823061215
-0.0058311633376960120972
7.1762131193147012109e-05
7.1762131193147012109e-05
7.1762131193147012109e-05
0.031062120842861230818
-0.013209820173807460333

The source code which I have modified to handle the 4d file is attached.


2. Once I have this sorted out I hope to apply a FFT algorithm to the data.
   However, I am struggling to get my head around the image data that
is returned
   by my call to miicv_get(icvid, start, count, volume->data). It
seems to be one
   long contigous array, rather than data[21][63][128][128] as I would
have hoped.
   Ultimately I would like to work at a 2D slice at a time, for a give
time frame.

   Am I able to manipulate this data array directly and if so how do I index it?
   I obviously want to be efficient and don't want to call mivarget1()
repeatedly.

   The alternative is I guess to use 2D hyperslabs through a call to
miicv_get(),
   but again, I assume this would return a continous array. How would I index
   the image data in this case, perhaps using a bit of multiplication to work
   out the index e.g. [i*DIM+j] for [i][j]? I am not sure as I cannot
seem to find
   any detailed documentation or examples on this. Maybe I am missing a
   resource?

What makes this more tricky for me is that I cannot compile my code
using lccwin32 and therefore am lacking debugging facilities. If
anyone knows how to get MINC 1.5 libraries working in lccwin32 this
would be a big help. At the moment when I try to compile in this
environment the linker just crashes out on me with a windows error box
with no error message. So I am just using Cygwin, vim and gcc as my
development environment currently. Is this the norm?

Sorry to ask what are probably trivial fundamentals on here, but I was
struggling to
find any detailed documentation on the API, for example explaining
exactly what is
values set to by a call miicv_get() in terms of data structure and dimensions.

If anyone has the time to spare to help me with these question via
email I would be extremely grateful.

More so if anyone from the MNI could spare an hour to take me through
some of the basics of using the MINC libraries that I might be misunderstanding
this would be fantastic, please let me know when you might be
available and I would be more than happy to pop round.

Kind regards
Paul Lyon
paulclyon at gmail.com
+5149653076
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pet-srtm.c.userlist
Url: http://www2.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20080415/f8c205d3/attachment-0001.txt 

From alex at bic.mni.mcgill.ca  Wed Apr 16 00:24:34 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Wed, 16 Apr 2008 00:24:34 -0400
Subject: [MINC-users] Running MINC tools from the www user
In-Reply-To: <ac2a7d1f0804151345m2f122ba7x172fd138d30b8050@mail.gmail.com>
References: <ac2a7d1f0804151345m2f122ba7x172fd138d30b8050@mail.gmail.com>
Message-ID: <48057F82.1040108@bic.mni.mcgill.ca>

Hi Burt,

I am not sure what is happening here, but one possible cause I could 
imagine is that you ran out of temp space. CachedArray is something I 
wrote some decades ago; it is an array class that is cached to disk (and 
thus will let you generate large arrays with a small memory footprint). 
The bit of code that fails is:

     _s.open(path, ios::in | ios::out | ios::trunc);

     // Unlink the file so it will be deleted automatically when
     // closed.
     //
     unlink(path);

     assert(_s.is_open());

That last assertion fails in your case, which I suspect means that it 
was unable to create the temporary disk cache file, or the temporary 
filename used for the cache file is foobar. The temporary filename is 
generated in get_temp_filename in FileIO.cc, which jumps through a few 
hoops trying to generate a usable temporary filename. You may want to 
try to set the TMPDIR environment var and check whether /tmp has space.

-- Alex


Burt Cr?peault wrote:
> Hi again,
> 
> In my current development, I'm executing MINC tools from an Apache-run PHP
> script, therefore running under the default www user. The following command
> runs well from the command prompt but gives errors when run from www:
> 
> /usr/local/minc2/bin/nu_correct -clobber -mapping_dir
> /Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007 -iterations
> 100 -shrink 3 -fwhm 0.1 -distance 100
> /Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1004/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1004.1.10004.[mnc.d2m].Br.12_p2.mnc
> /Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1007.1.10007.[mnc.d2m+mnc.nuc].Br.22_p2.mnc
> 
>    [7]:     [_www at pita.crulrg.local:/Library/WebServer/Documents/]
> [2008-04-15 16:19:39] running:
>    [8]:       /usr/local/minc2/bin/nu_estimate_np_and_em -parzen -log
> -sharpen 0.1 0.01 -iterations 100 -stop 0.001 -shrink 3 -auto_mask
> -nonotify -b_spline 1 -distance 100 -quiet -execute -clobber
> -nokeeptmp -tmpdir /var/tmp/nu_correct_32893/
> '/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1004/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1004.1.10004.[mnc.d2m].Br.12_p2.mnc'
> '/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1007.1.10007.[mnc.d2m+mnc.nuc].Br.22_p2.imp'
>    [9]:
>    [10]:     Assertion failed at line 742 in file templates/CachedArray.cc
>    [11]:     nu_estimate_np_and_em: crashed while running volume_stats
> (termination status=256)
>    [12]:     nu_correct: crashed while running nu_estimate_np_and_em
> (termination status=256)
> 
> Usually, this type of error can be traced to a bad permission somewhere, or
> to an environment variable that's incorrectly set for the www user.
> Unfortunately in this case, I'm a little short on data to troubleshoot it
> myself. What does "Assertion failed" on line [10] mean?
> 
> Any help would be greatly appreciated.
> 
> Thanks,
> 


-- 
========================================================================
| Alex P. Zijdenbos, Ph.D.        |                                    |
| McConnell Brain Imaging Centre  | Phone: [+1] 514 398-5220  (office) |
| Montreal Neurological Institute |        [+1] 514 398-1996   (dept.) |
| 3801 University St., WB-208     |   Fax: [+1] 514 398-8952  (office) |
| Montreal, Quebec, H3A 2B4       |        [+1] 708 810-3309 (private) |
| CANADA                          | Email:      alex at bic.mni.mcgill.ca |
========================================================================


From jason at bic.mni.mcgill.ca  Wed Apr 16 14:06:17 2008
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Wed, 16 Apr 2008 14:06:17 -0400
Subject: [MINC-users] MICe-minc-tools available
Message-ID: <48064019.6060705@bic.mni.mcgill.ca>

Hello all,

a bunch of MINC utilities created here at the Mouse Imaging Centre by 
Matthijs van Eede, John Sled, and myself can now be found here:

http://wiki.phenogenomics.ca:8080/display/MICePub/MICe-minc-tools

They mostly deal with non-linear registration. A quick summary of what 
is contained in that tarball is here:

minc_displacement: Create a vector volume containing the displacements 
at each voxel specified by a transform (.xfm file).
label_volumes_from_jacobians: Compute the volume of segmented structures 
given an atlas and Jacobian determinants.
xfm2tag: Create a tag file from a transform.
lin_from_nlin: Compute the linear part of a non-linear transform.
scale_voxels: Multiply values in a file by the combined scale factor of 
a linear transform.
smooth_vector: Blur a vector file.
grid_object_manipulator: Pretty pictures of deformation fields
add_noise_to_volume: Add normally distributed noise to a volume.

Cheers,

Jason

From jason at bic.mni.mcgill.ca  Wed Apr 16 14:08:21 2008
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Wed, 16 Apr 2008 14:08:21 -0400
Subject: [MINC-users] RMINC v0.5
Message-ID: <48064095.1090104@bic.mni.mcgill.ca>

Hi all,

the next version of RMINC can be found here:

https://code.launchpad.net/rminc/1.0/0.5

That link contains the source code, the updated manual, and some sample 
data if people want to follow along with the examples in the manual.

Quick summary of the changes:

* mincApply can now produce more than one output per voxel.
* mincFDR can now compute both the False Discovery Rate (default) as
  well as the positive False Discovery Rate.
* some more bits of documentation.
* ability to create pretty pictures through ray-trace.
* various bug fixes.

Many thanks go out to Matthijs van Eede for the ray_trace interface.

Comments, feature requests, bug reports, etc. are as usual welcome.

Cheers,

Jason

From a.janke at gmail.com  Wed Apr 16 16:31:53 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 17 Apr 2008 06:31:53 +1000
Subject: [MINC-users] using EMMA: possible without Mex?
In-Reply-To: <48035645.4050808@ilmarin.info>
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>
	<20080408095541.C21126@mrs.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6902424E76@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804110127n8c7f268m9fd490288ab054df@mail.gmail.com>
	<48035645.4050808@ilmarin.info>
Message-ID: <d747ed50804161331p205ab0f7gb6687bc185842d17@mail.gmail.com>

> > It uses the Mersenne Twister for random number generation and I am not
> > entirely sure on the license restrictions so dont include it MINC
> > proper until I can find out for sure.
> >
>
>  Maybe you could use GSL library, it includes this random number generator:
> http://www.gnu.org/software/gsl/manual/html_node/Random-number-generator-algorithms.html

I could, (and originally did!) but the GPL is somewhat restrictive in
terms of the current MINC license. I would prefer a BSD license and I
think the current version I use is compatible with this but have to
check.


a


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

From burt.crepeault at crulrg.ulaval.ca  Wed Apr 16 17:01:53 2008
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Wed, 16 Apr 2008 17:01:53 -0400
Subject: [MINC-users]  Running MINC tools from the www user
Message-ID: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>

Hi Alex,

I went ahead and tried your suggestions, unfortunately I'm still
stuck. The /tmp folder still has plenty of space and it is writable by
anyone. I still get the following error from running the process:


   [7]:     [_www at pita.crulrg.local:/Library/WebServer/Documents/]
[2008-04-16 12:32:14] running:
   [8]:       /usr/local/minc2/bin/nu_estimate_np_and_em -parzen -log
-sharpen 0.1 0.01 -iterations 100
                -stop 0.001 -shrink 3 -auto_mask -nonotify -b_spline 1
-distance 100 -quiet -execute

                -clobber -nokeeptmp -tmpdir /tmp/nu_correct_1361/

'/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1004/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1004.1.10004.[mnc.d2m].Br.12_p2.mnc'


'/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1007.1.10007.[mnc.d2m+mnc.nuc].Br.22_p2.imp'
   [9]:
   [10]:     Assertion failed at line 742 in file templates/CachedArray.cc

   [11]:     nu_estimate_np_and_em: crashed while running volume_stats
(termination status=256)
   [12]:     nu_correct: crashed while running nu_estimate_np_and_em
(termination status=256)

I've listed my environment variables below:


       [TMPDIR] => /tmp
       [FOO] => /bar
       [PERL5LIB] =>
:/usr/local/minc2/lib:/Library/Perl/5.8.8:/usr/local/minc2/lib/perl5/site_perl/:/Users/burt/lib/perl
       [LD_LIBRARY_PATH] => :/Applications/MATLAB72/dip/Darwin/lib

       [PATH] =>
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/minc2/bin:/opt/local/bin:/opt/local/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/mysql/bin
       [PWD] => /Library/WebServer/Documents

       [SHLVL] => 1
       [DYLD_LIBRARY_PATH] => :/usr/local/minc2/external-libs

I tried the command at line [8] of my log directly in a terminal and
everything runs fine. There is a /tmp/nu_correct_xxxx dir that is
being created. However, that directory does not appear when the
process is launched from the web app, therefore your assumption that
CachedArray.cc is unable to create the temp file (or more likely dir)
appears to be correct.


This is where I'm stuck at the moment, any other ideas?


-- 
Burt Cr?peault
Research Assistant
Centre de Recherche de l'Universit? Laval - Robert-Giffard
418-663-5741, ext 6844

From a.janke at gmail.com  Thu Apr 17 08:54:14 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 17 Apr 2008 22:54:14 +1000
Subject: [MINC-users] dcm2mnc produces xspace:spacing = "irregular"
In-Reply-To: <ac2a7d1f0804150621r655d63a3u22f647931060e173@mail.gmail.com>
References: <ac2a7d1f0804150538wea4b657u92036fcc54bed7d7@mail.gmail.com>
	<ac2a7d1f0804150621r655d63a3u22f647931060e173@mail.gmail.com>
Message-ID: <d747ed50804170554x14703ba7r9175efa05364457f@mail.gmail.com>

>  I'm new to MINC (and to image processing in general) and have encountered
>  the problem herein:
>  http://www2.bic.mni.mcgill.ca/pipermail/minc-users/2006-September/001341.html.
>  The proposed solution appears to work all right but I'm curious as to the
>  nature of the irregularity. What causes dcm2mnc to set the xspace:spacing
>  variable to "irregular"?  Could there be a problem with the original DICOM
>  series? How would I verify that?

In order:   Differing interpretations of the dicom "standard", yes
(and no), easy.

Unfortunately DICOM does not always unambiguously describe the
position of the slices in an image volume (some scanners use
origin/angle, some use absolute position of centre of slices, some use
offsets, etc). What this means is that at times you hit a DICOM
acquisition where the slices might be spaced as such (eg: centres in
Z)

   1.0mm,   2.0mm, 3.0mm, 4.000001mm, 5.0mm, etc

Now we can all guess that the 4.000001 is likely a rounding error and
that this acquisition is indeed 1mm spaced, but in code we have to
define this "epsilon" value. In dcm2mnc's case it is set pretty low so
a few will slip through the cracks as "irregular" when they in all
reality likely were not.

As for how to test this just run dcm2mnc -debug and you will see all
the slice co-ordinate information.


a

From pvcorrection at yahoo.com  Fri Apr 18 15:04:40 2008
From: pvcorrection at yahoo.com (Olivier Rousset)
Date: Fri, 18 Apr 2008 12:04:40 -0700 (PDT)
Subject: [MINC-users] For the OSX 10.5 crash test dummies.
Message-ID: <813396.18110.qm@web30604.mail.mud.yahoo.com>

Alex,

I'd be very interested in trying to build MINC2 on my new 64-bit Mac Pro...

Would you mind putting your ./lib and ./bin back to an accessible place? 
I was too late on the /scratch directory and think it's been cleaned up since.

Thanks in advance, and best wishes,

- Olivier


----- Original Message ----
From: Alexandre CARMEL-VEILLEUX <acveilleux at mrs.mni.mcgill.ca>
To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
Sent: Friday, April 11, 2008 12:48:46 PM
Subject: Re: [MINC-users] For the OSX 10.5 crash test dummies.

    I put a tar of my /usr/local with 64-bit MINC (./mni for MINC1,
./bic for MINC2) including an (hopefully) 64-bit clean postf build that
won't segfault on execution on to yorick:/data/scratch/scratch1 for
those who are interested. The tar expects to be extracted from /usr/local
but it would be much safer to extract it in some temporary folder and
cherry pick the stuff you actually want/need so you don't overwrite what
you already have.

    Feedback about broken bits would be appreciated.

    These are not the same binaries as Andrew's but the ./lib directory
contains the same libraries he used I believe.

Alex

On Fri, Apr 11, 2008 at 12:53:50PM +1000, Andrew Janke wrote:
> Date: Fri, 11 Apr 2008 12:53:50 +1000
> From: "Andrew Janke" <a.janke at gmail.com>
> To: "MINC users mailing list" <minc-users at bic.mni.mcgill.ca>
> Subject: [MINC-users] For the OSX 10.5 crash test dummies.
> 
> Thanks to Alexandre (the current "record" holder in the minc benchmarks) here:
> 
>    http://en.wikibooks.org/wiki/MINC/Benchmarks
> 
> I have now compiled some Leopard 10.5 64bit MINC2 binaries here:
> 
>    http://packages.bic.mni.mcgill.ca/osx-10.5/
> 
> These have been compiled on a 10.5 MacPro using 64 bit libraries.  I
> myself did not compile netcdf/hdf/netpbm in 64 bit but understand from
> the person who did that it took a bit of pain. ;)
> 
> So feel free to try these if you want but be aware that I can't help
> you compiling HDF/netcdf in 64 bit!.  Alexandre did this for me and
> for that I am very gratefull!  I suspect he can be bribed into helping
> others get this going on their own machines also.
> 
> 
> a
> _______________________________________________
> 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

From nikelski at bic.mni.mcgill.ca  Sat Apr 19 13:07:28 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Sat, 19 Apr 2008 13:07:28 -0400
Subject: [MINC-users] nii2mnc problem
Message-ID: <e12172550804191007v4cb0b0cejbb6f4bd4cff3d4bf@mail.gmail.com>

Hi All,

    I'm not sure if anyone there is actively supporting nii2mnc, but
I've run into what appears to be a problem with nii2mnc.  I've run a
few hundred ADNI volumes (nifti-1) through nii2mnc, and after
determining the proper -flip parameters, all seemed OK ... except,
that a few volumes, using the same input parameters, were flipped
along the inferior-superior axis (i.e., the brains were upside-down).
Now, the problem does not lie with the volume meta-data, as any number
of other nifti-1 viewers are able to display the volumes normally ...
only nii2mnc has problems.  I have a samples of both "good" and
"upside-down" volumes, if anyone wants to take a look.

Cheers,

-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
Tel: (514) 340-8222 x 2298
Fax: (514) 340-8295

From a.janke at gmail.com  Sun Apr 20 10:36:25 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 21 Apr 2008 00:36:25 +1000
Subject: [MINC-users] nii2mnc problem
In-Reply-To: <e12172550804191007v4cb0b0cejbb6f4bd4cff3d4bf@mail.gmail.com>
References: <e12172550804191007v4cb0b0cejbb6f4bd4cff3d4bf@mail.gmail.com>
Message-ID: <d747ed50804200736t4556389fv516a7f42d51c23d7@mail.gmail.com>

>  I've run into what appears to be a problem with nii2mnc.  I've run a
>  few hundred ADNI volumes (nifti-1) through nii2mnc, and after
>  determining the proper -flip parameters, all seemed OK ... except,
>  that a few volumes, using the same input parameters, were flipped
>  along the inferior-superior axis (i.e., the brains were upside-down).
>  Now, the problem does not lie with the volume meta-data, as any number
>  of other nifti-1 viewers are able to display the volumes normally ...
>  only nii2mnc has problems.  I have a samples of both "good" and
>  "upside-down" volumes, if anyone wants to take a look.

Hi Jim,

Sounds "interesting".  Can you put these recalcitrant volumes up
somewhere that I can get at them?

Thanks


a

From acveilleux at mrs.mni.mcgill.ca  Sun Apr 20 11:16:51 2008
From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX)
Date: Sun, 20 Apr 2008 11:16:51 -0400
Subject: [MINC-users] display/register for leopard --- 64 bit intel
	binaries
In-Reply-To: <d747ed50804190140l78ef43a7u3a937af51d537346@mail.gmail.com>;
	from a.janke@gmail.com on Sat, Apr 19, 2008 at 06:40:19PM +1000
References: <5BE45949-E4F1-423A-AAD6-058D25512B58@mednet.ucla.edu>
	<70AAA267-BE71-4B45-96A1-6895F4311FDD@mednet.ucla.edu>
	<d747ed50804101956g8b8c25by133ce57ca15cda08@mail.gmail.com>
	<B73B1E61-8EE8-4580-9A08-BB631BA707FE@mednet.ucla.edu>
	<d747ed50804131801o7444b174rbbb49f6adb5b540b@mail.gmail.com>
	<95F9696F-42C1-42E5-9181-0478E53E8D76@mednet.ucla.edu>
	<d747ed50804190140l78ef43a7u3a937af51d537346@mail.gmail.com>
Message-ID: <20080420111651.B15888@mrs.mni.mcgill.ca>

Hello,

	I've put my "package" on http://packages.bic.mni.mcgill.ca,
it's in the osx-10.5-x86_64-alex folder along with a README. I highly
recommend that people who want to try the package read the README first.

	I'd like feedbacks on problems, if any.

Alex

On Sat, Apr 19, 2008 at 06:40:19PM +1000, Andrew Janke wrote:
> Date: Sat, 19 Apr 2008 18:40:19 +1000
> From: "Andrew Janke" <a.janke at gmail.com>
> To: CCliff <ccliff at mednet.ucla.edu>
> Subject: Re: display/register for leopard --- 64 bit intel binaries
> Cc: "Allan MacKenzie-Graham" <amg at ucla.edu>,
>    "Alexandre CARMEL-VEILLEUX" <acveilleux at mrs.mni.mcgill.ca>
> 
> True, you wont have access to yorick.
> 
> Alex: Can you please put your binaries up somewhere a bit more public
> given that there seems to be a fair amount of call for them?
> 
> Thanks
> 
> 
> a
> 
> On Fri, Apr 18, 2008 at 12:09 AM, CCliff <ccliff at mednet.ucla.edu> wrote:
> > Hi Andrew,
> >
> >  Shortly after sending the previous email about the link to download the
> > 64-bit netcdf and Hdf5, I found a minc-users post digest with Alexandre's
> > posted link. However, its seems that its on a server  "yorick" but I don't
> > have access to it. Is public access to "yorick" and if so, what's the full
> > name of that server?
> 
> 
> -- 
> Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia +61 (402) 700 883

From rupe.brooks at gmail.com  Mon Apr 21 09:50:33 2008
From: rupe.brooks at gmail.com (Rupert Brooks)
Date: Mon, 21 Apr 2008 09:50:33 -0400
Subject: [MINC-users] using EMMA: possible without Mex?
In-Reply-To: <d747ed50804161331p205ab0f7gb6687bc185842d17@mail.gmail.com>
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>
	<20080408095541.C21126@mrs.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6902424E76@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804110127n8c7f268m9fd490288ab054df@mail.gmail.com>
	<48035645.4050808@ilmarin.info>
	<d747ed50804161331p205ab0f7gb6687bc185842d17@mail.gmail.com>
Message-ID: <a6cc33f0804210650k30a86055heb9d1e24066af2c5@mail.gmail.com>

Just in case what you are currentlly using is not ok, the
MersenneTwister in ITK seems to have an acceptable license - Copyright
notice must be reproduced, no warranty.

http://www.itk.org/Doxygen36/html/classitk_1_1Statistics_1_1MersenneTwisterRandomVariateGenerator.html

IIRC its ITK macros and namespaces wrapped around relatively
standalone code.  Been  a while since i looked under the hood of that
one though.

Rupert

On Wed, Apr 16, 2008 at 4:31 PM, Andrew Janke <a.janke at gmail.com> wrote:
> > > It uses the Mersenne Twister for random number generation and I am not
> > > entirely sure on the license restrictions so dont include it MINC
> > > proper until I can find out for sure.
> > >
> >
> >  Maybe you could use GSL library, it includes this random number generator:
> > http://www.gnu.org/software/gsl/manual/html_node/Random-number-generator-algorithms.html
>
> I could, (and originally did!) but the GPL is somewhat restrictive in
> terms of the current MINC license. I would prefer a BSD license and I
> think the current version I use is compatible with this but have to
> check.
>
>
> a
>
>
> --
> 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
>



-- 
--------------------------------------------------------------
Rupert Brooks
McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
Ph.D Student, Electrical and Computer Engineering
http://www.cyberus.ca/~rbrooks

From rupe.brooks at gmail.com  Mon Apr 21 09:50:33 2008
From: rupe.brooks at gmail.com (Rupert Brooks)
Date: Mon, 21 Apr 2008 09:50:33 -0400
Subject: [MINC-users] using EMMA: possible without Mex?
In-Reply-To: <d747ed50804161331p205ab0f7gb6687bc185842d17@mail.gmail.com>
References: <mailman.1972.1207564012.12296.minc-users@bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF4F@MRZS152229.medizin.uni-leipzig.de>
	<20080408095541.C21126@mrs.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E690201FF52@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804081453y7aaa895cn3e263abe32ff3e2@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6902424E76@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50804110127n8c7f268m9fd490288ab054df@mail.gmail.com>
	<48035645.4050808@ilmarin.info>
	<d747ed50804161331p205ab0f7gb6687bc185842d17@mail.gmail.com>
Message-ID: <a6cc33f0804210650k30a86055heb9d1e24066af2c5@mail.gmail.com>

Just in case what you are currentlly using is not ok, the
MersenneTwister in ITK seems to have an acceptable license - Copyright
notice must be reproduced, no warranty.

http://www.itk.org/Doxygen36/html/classitk_1_1Statistics_1_1MersenneTwisterRandomVariateGenerator.html

IIRC its ITK macros and namespaces wrapped around relatively
standalone code.  Been  a while since i looked under the hood of that
one though.

Rupert

On Wed, Apr 16, 2008 at 4:31 PM, Andrew Janke <a.janke at gmail.com> wrote:
> > > It uses the Mersenne Twister for random number generation and I am not
> > > entirely sure on the license restrictions so dont include it MINC
> > > proper until I can find out for sure.
> > >
> >
> >  Maybe you could use GSL library, it includes this random number generator:
> > http://www.gnu.org/software/gsl/manual/html_node/Random-number-generator-algorithms.html
>
> I could, (and originally did!) but the GPL is somewhat restrictive in
> terms of the current MINC license. I would prefer a BSD license and I
> think the current version I use is compatible with this but have to
> check.
>
>
> a
>
>
> --
> 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
>



-- 
--------------------------------------------------------------
Rupert Brooks
McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
Ph.D Student, Electrical and Computer Engineering
http://www.cyberus.ca/~rbrooks

From steve at sumost.ca  Mon Apr 21 11:03:12 2008
From: steve at sumost.ca (Steve M. Robbins)
Date: Mon, 21 Apr 2008 10:03:12 -0500
Subject: [MINC-users] dcm2mnc produces xspace:spacing = "irregular"
Message-ID: <20080421150312.GA3762@sumost.ca>

On Thu, Apr 17, 2008 at 10:54:14PM +1000, Andrew Janke wrote:

> Unfortunately DICOM does not always unambiguously describe the
> position of the slices in an image volume (some scanners use
> origin/angle, some use absolute position of centre of slices, some use
> offsets, etc).

That's news to me.  

What modalities are you talking about?  I grant you that NM does weird
things (possibly US, too).  However for MR, CT, and PET, my reading of
DICOM suggests they all use the same (0020,0032) Image Position
(Patient) and (0020,0037) Image Orientation (Patient) attributes to
specify the location and orientation of the slices.

What ambiguity are you referring to?

-Steve

From a.janke at gmail.com  Mon Apr 21 11:12:08 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 22 Apr 2008 01:12:08 +1000
Subject: [MINC-users] dcm2mnc produces xspace:spacing = "irregular"
In-Reply-To: <20080421150312.GA3762@sumost.ca>
References: <20080421150312.GA3762@sumost.ca>
Message-ID: <d747ed50804210812r6c15445ar5cb52215d53d9e2b@mail.gmail.com>

>  > Unfortunately DICOM does not always unambiguously describe the
>  > position of the slices in an image volume (some scanners use
>  > origin/angle, some use absolute position of centre of slices, some use
>  > offsets, etc).
>
>  What modalities are you talking about?  I grant you that NM does weird
>  things (possibly US, too).  However for MR, CT, and PET, my reading of
>  DICOM suggests they all use the same (0020,0032) Image Position
>  (Patient) and (0020,0037) Image Orientation (Patient) attributes to
>  specify the location and orientation of the slices.
>
>  What ambiguity are you referring to?

That is correct they are _supposed_ to put things in the right
places... To put the first spanner in the works, consider the special
case of "mosaic" images.  I figure they came about to get around some
of the issues of bazillions of files in a directory for functional
data.

Then we will shift on to how some scanners define a slice gap as being
part of a slice thickness and some dont.  Ah, where would we be
without diversity? :)


-- 
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  Mon Apr 21 11:38:49 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Mon, 21 Apr 2008 11:38:49 -0400
Subject: [MINC-users] nii2mnc problem
In-Reply-To: <d747ed50804200736t4556389fv516a7f42d51c23d7@mail.gmail.com>
References: <e12172550804191007v4cb0b0cejbb6f4bd4cff3d4bf@mail.gmail.com>
	<d747ed50804200736t4556389fv516a7f42d51c23d7@mail.gmail.com>
Message-ID: <e12172550804210838x727fedbbia1e1294ec32f90e0@mail.gmail.com>

Hi all,

   Thanks Andrew.  I placed a couple of samples into
"/data/scratch/scratch1/jim/nifti".  There you will find volumes for 2
subjects: (1) subject 0002, who is reflective of most of my subjects,
and (2) subject 0008, who, following conversion using the same input
params as used for S0002, is upside-down (according to Display).  I
used the following to convert:

nii2mnc -xyz -flipz -flipx 0002-M-NC.nii

   Yup, removing the '-flipz' would likely solve my problem for S0008,
but would likely mess everyone else up.  Just for fun, I ran these
volumes through the LONI debabeler (results are in the 'debabel'
subdir), which appears to have converted them both to minc, without
the need to enter any parameters at all -- suggesting that the nifti-1
meta-data is sufficient to perform the conversion correctly.

Thanks for the help, and pls let me know if you require anything else.

-Jim



On Sun, Apr 20, 2008 at 10:36 AM, Andrew Janke <a.janke at gmail.com> wrote:
> >  I've run into what appears to be a problem with nii2mnc.  I've run a
>  >  few hundred ADNI volumes (nifti-1) through nii2mnc, and after
>  >  determining the proper -flip parameters, all seemed OK ... except,
>  >  that a few volumes, using the same input parameters, were flipped
>  >  along the inferior-superior axis (i.e., the brains were upside-down).
>  >  Now, the problem does not lie with the volume meta-data, as any number
>  >  of other nifti-1 viewers are able to display the volumes normally ...
>  >  only nii2mnc has problems.  I have a samples of both "good" and
>  >  "upside-down" volumes, if anyone wants to take a look.
>
>  Hi Jim,
>
>  Sounds "interesting".  Can you put these recalcitrant volumes up
>  somewhere that I can get at them?
>
>  Thanks
>
>
>  a
>  _______________________________________________
>  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
Tel: (514) 340-8222 x 2298
Fax: (514) 340-8295

From steve at sumost.ca  Mon Apr 21 12:05:13 2008
From: steve at sumost.ca (Steve M. Robbins)
Date: Mon, 21 Apr 2008 11:05:13 -0500
Subject: [MINC-users] dcm2mnc produces xspace:spacing = "irregular"
In-Reply-To: <d747ed50804210812r6c15445ar5cb52215d53d9e2b@mail.gmail.com>
References: <20080421150312.GA3762@sumost.ca>
	<d747ed50804210812r6c15445ar5cb52215d53d9e2b@mail.gmail.com>
Message-ID: <20080421160513.GB3762@sumost.ca>

On Tue, Apr 22, 2008 at 01:12:08AM +1000, Andrew Janke wrote:
> >  > Unfortunately DICOM does not always unambiguously describe the
> >  > position of the slices in an image volume (some scanners use
> >  > origin/angle, some use absolute position of centre of slices, some use
> >  > offsets, etc).
> >
> >  What modalities are you talking about?  I grant you that NM does weird
> >  things (possibly US, too).  However for MR, CT, and PET, my reading of
> >  DICOM suggests they all use the same (0020,0032) Image Position
> >  (Patient) and (0020,0037) Image Orientation (Patient) attributes to
> >  specify the location and orientation of the slices.
> >
> >  What ambiguity are you referring to?
> 
> That is correct they are _supposed_ to put things in the right
> places... To put the first spanner in the works, consider the special
> case of "mosaic" images.  I figure they came about to get around some
> of the issues of bazillions of files in a directory for functional
> data.

Sure.  But your problem is not with DICOM per se, but rather with
interpreting the vendor private attributes that presumably define the
slice positions.  I've never seen a mosaic image; I'd be interested to
have a look if you have an example handy.

You could rightly argue the problem stems from DICOM not having a
useful 3D or 4D format when fMRI was developed.  Now that they have
the Enhanced MR IOD, is anyone using it for fMRI?


> Then we will shift on to how some scanners define a slice gap as being
> part of a slice thickness and some dont.  Ah, where would we be
> without diversity? :)

Not sure how this is relevant to the position.  Slice position is
unambiguously defined using (0020,0032).  Slice Thickness is an
optional attribute and useless (for location) even when present
because thickness is completely independent of slice-to-slice spacing.
I've never heard of a Slice Gap attribute.


Both these examples, however, are a far cry from "some scanners use
origin/angle, some use absolute position of centre of slices, some use
offsets, etc", which is what I was curious about.

Chimo,
-Steve

From burt.crepeault at crulrg.ulaval.ca  Mon Apr 21 15:08:47 2008
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Mon, 21 Apr 2008 15:08:47 -0400
Subject: [MINC-users] Running MINC tools from the www user
In-Reply-To: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
Message-ID: <ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>

Although I haven't moved an inch on solving the issue (thanks Alex for the
help), here's more information on my problem:


1) If I type type the following command in a terminal window, everything
works fine:
/usr/local/minc2/bin/nu_correct -clobber -mapping_dir /Library/MEDICS/tmp
-tmpdir /Library/MEDICS/tmp/ -iterations 100 -shrink 3 -fwhm 0.1 -distance
100 -verbose /Library/MEDICS/tmp/abc1.mnc /Library/MEDICS/tmp/abc.mnc


2) If I precede the previous command with sudo -u _www, I get an error:
sudo -u _www /usr/local/minc2/bin/nu_correct -clobber -mapping_dir
/Library/MEDICS/tmp -tmpdir /Library/MEDICS/tmp/ -iterations 100 -shrink 3
-fwhm 0.1 -distance 100 -verbose /Library/MEDICS/tmp/abc1.mnc
/Library/MEDICS/tmp/abc.mnc

[nu_correct] [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
[2008-04-21 14:44:23] /usr/local/minc2/bin/nu_estimate_np_and_em -parzen
-log -sharpen 0.1 0.01 -iterations 100 -stop 0.001 -shrink 3 -auto_mask
-nonotify -b_spline 1 -distance 100 -verbose -execute -clobber -nokeeptmp
-tmpdir /Library/MEDICS/tmp/ /Library/MEDICS/tmp/abc1.mnc
/Library/MEDICS/tmp/abc.imp

Uncorrected volume (input): /Library/MEDICS/tmp/abc1.mnc
Intensity mapping (output): /Library/MEDICS/tmp/abc.imp

# Start of NU estimation algorithm
[nu_estimate_np_and_em]
[_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
[2008-04-21 14:44:23] /usr/local/minc2/bin/mincresample -clobber -verbose
-nearest_neighbour -nelements 20 30 30 -step 10.8 -9.14058 -9.14058
/Library/MEDICS/tmp/abc1.mnc /Library/MEDICS/tmp/abc1___.mnc
Transforming slices:....................Done
[nu_estimate_np_and_em]
[_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
[2008-04-21 14:44:23] /usr/local/minc2/bin/mincmath -clobber -verbose -clamp
-const2 1 1.7e+308 /Library/MEDICS/tmp/abc1___.mnc
/Library/MEDICS/tmp/abc_log.mnc.temp
Processing:....................Done
[nu_estimate_np_and_em]
[_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
[2008-04-21 14:44:23] /usr/local/minc2/bin/mincmath -clobber -verbose -zero
-log /Library/MEDICS/tmp/abc_log.mnc.temp /Library/MEDICS/tmp/abc_log.mnc
Processing:....................Done
[nu_estimate_np_and_em]
[_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
[2008-04-21 14:44:23] /bin/rm /Library/MEDICS/tmp/abc_log.mnc.temp
[nu_estimate_np_and_em]
[_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
[2008-04-21 14:44:23] /usr/local/minc2/bin/mincinfo -attvalue
xspace:spacetype -attvalue yspace:spacetype -attvalue zspace:spacetype
/Library/MEDICS/tmp/abc1___.mnc
[nu_estimate_np_and_em]
[_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
[2008-04-21 14:44:23] /usr/local/minc2/bin/volume_stats -quiet -biModalT
/Library/MEDICS/tmp/abc1___.mnc
Assertion failed at line 742 in file templates/CachedArray.cc
nu_estimate_np_and_em: crashed while running volume_stats (termination
status=256)
nu_correct: crashed while running nu_estimate_np_and_em (termination
status=256)


3) The directory /Library/MEDICS/tmp is writable by everyone (mode 777). The
owner of the directory is _www.


4) Temporary files abc1_.mnc, abc1__.mnc, abc1___.mnc and abc_log.mnc all
get created so I don't suspect a permission problem being the case here.


5) I don't quite understand the MINC source code just yet (hey, that's a lot
of code), where would I find CachedArray.cc?


6) I noticed that in volumeStats.cc, there is the following:

    if (args.cached)
      voxels = new CachedArray<float>(0);
    else
      voxels = new SimpleArray<float>(0);

Is there a way I could just bypass the call to CachedArray and not bother
with trying to save memory (after all, GBytes are cheaper than the time
we're spending to try to make this work... ;)


Again, many thanks,

Burt.


On Wed, Apr 16, 2008 at 5:01 PM, Burt Cr?peault <
burt.crepeault at crulrg.ulaval.ca> wrote:

> Hi Alex,
>
> I went ahead and tried your suggestions, unfortunately I'm still stuck. The /tmp folder still has plenty of space and it is writable by anyone. I still get the following error from running the process:
>
>
>    [7]:     [_www at pita.crulrg.local:/Library/WebServer/Documents/] [2008-04-16 12:32:14] running:
>    [8]:       /usr/local/minc2/bin/nu_estimate_np_and_em -parzen -log -sharpen 0.1 0.01 -iterations 100
>                 -stop 0.001 -shrink 3 -auto_mask -nonotify -b_spline 1 -distance 100 -quiet -execute
>
>                 -clobber -nokeeptmp -tmpdir /tmp/nu_correct_1361/
>                 '/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1004/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1004.1.10004.[mnc.d2m].Br.12_p2.mnc'
>
>                 '/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1007.1.10007.[mnc.d2m+mnc.nuc].Br.22_p2.imp'
>    [9]:
>    [10]:     Assertion failed at line 742 in file templates/CachedArray.cc
>
>    [11]:     nu_estimate_np_and_em: crashed while running volume_stats (termination status=256)
>    [12]:     nu_correct: crashed while running nu_estimate_np_and_em (termination status=256)
>
> I've listed my environment variables below:
>
>
>        [TMPDIR] => /tmp
>        [FOO] => /bar
>        [PERL5LIB] => :/usr/local/minc2/lib:/Library/Perl/5.8.8:/usr/local/minc2/lib/perl5/site_perl/:/Users/burt/lib/perl
>        [LD_LIBRARY_PATH] => :/Applications/MATLAB72/dip/Darwin/lib
>
>        [PATH] => /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/minc2/bin:/opt/local/bin:/opt/local/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/mysql/bin
>        [PWD] => /Library/WebServer/Documents
>
>        [SHLVL] => 1
>        [DYLD_LIBRARY_PATH] => :/usr/local/minc2/external-libs
>
> I tried the command at line [8] of my log directly in a terminal and everything runs fine. There is a /tmp/nu_correct_xxxx dir that is being created. However, that directory does not appear when the process is launched from the web app, therefore your assumption that CachedArray.cc is unable to create the temp file (or more likely dir) appears to be correct.
>
>
> This is where I'm stuck at the moment, any other ideas?
>
>
> --
> Burt Cr?peault
> Research Assistant
> Centre de Recherche de l'Universit? Laval - Robert-Giffard
> 418-663-5741, ext 6844




-- 
Burt Cr?peault
Research Assistant
Centre de Recherche de l'Universit? Laval - Robert-Giffard
418-663-5741, ext 6844

From alex at bic.mni.mcgill.ca  Mon Apr 21 16:21:30 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Mon, 21 Apr 2008 16:21:30 -0400
Subject: [MINC-users] Running MINC tools from the www user
In-Reply-To: <ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
	<ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
Message-ID: <480CF74A.3070106@bic.mni.mcgill.ca>

Hi Burt,

This remains curious - clearly something in the change to your _www user 
affects the ability of CachedArray to generate a temporary file. I have 
no idea why but since it is very reproducible you can probably figure it 
out somehow.

The CachedArray source lives in the EBTKS library

    http://packages.bic.mni.mcgill.ca/tgz/ebtks-1.6.1.tar.gz

in

    ebtks-1.6.1/templates/

Alternatively, if you wanted to try to move on without identifying the 
source of this problem, you could add a '-nocache' flag to the call(s) 
to volume_stats in the nu_correct scripts (specifically in 
nu_estimate_np_and_em which throws this error). That should tell 
volume_stats to use the non-cached SimpleArray class instead of 
CachedArray as shown in the code snippet you listed.

-- Alex

Burt Cr?peault wrote:
> Although I haven't moved an inch on solving the issue (thanks Alex for the
> help), here's more information on my problem:
> 
> 
> 1) If I type type the following command in a terminal window, everything
> works fine:
> /usr/local/minc2/bin/nu_correct -clobber -mapping_dir /Library/MEDICS/tmp
> -tmpdir /Library/MEDICS/tmp/ -iterations 100 -shrink 3 -fwhm 0.1 -distance
> 100 -verbose /Library/MEDICS/tmp/abc1.mnc /Library/MEDICS/tmp/abc.mnc
> 
> 
> 2) If I precede the previous command with sudo -u _www, I get an error:
> sudo -u _www /usr/local/minc2/bin/nu_correct -clobber -mapping_dir
> /Library/MEDICS/tmp -tmpdir /Library/MEDICS/tmp/ -iterations 100 -shrink 3
> -fwhm 0.1 -distance 100 -verbose /Library/MEDICS/tmp/abc1.mnc
> /Library/MEDICS/tmp/abc.mnc
> 
> [nu_correct] [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
> [2008-04-21 14:44:23] /usr/local/minc2/bin/nu_estimate_np_and_em -parzen
> -log -sharpen 0.1 0.01 -iterations 100 -stop 0.001 -shrink 3 -auto_mask
> -nonotify -b_spline 1 -distance 100 -verbose -execute -clobber -nokeeptmp
> -tmpdir /Library/MEDICS/tmp/ /Library/MEDICS/tmp/abc1.mnc
> /Library/MEDICS/tmp/abc.imp
> 
> Uncorrected volume (input): /Library/MEDICS/tmp/abc1.mnc
> Intensity mapping (output): /Library/MEDICS/tmp/abc.imp
> 
> # Start of NU estimation algorithm
> [nu_estimate_np_and_em]
> [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
> [2008-04-21 14:44:23] /usr/local/minc2/bin/mincresample -clobber -verbose
> -nearest_neighbour -nelements 20 30 30 -step 10.8 -9.14058 -9.14058
> /Library/MEDICS/tmp/abc1.mnc /Library/MEDICS/tmp/abc1___.mnc
> Transforming slices:....................Done
> [nu_estimate_np_and_em]
> [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
> [2008-04-21 14:44:23] /usr/local/minc2/bin/mincmath -clobber -verbose -clamp
> -const2 1 1.7e+308 /Library/MEDICS/tmp/abc1___.mnc
> /Library/MEDICS/tmp/abc_log.mnc.temp
> Processing:....................Done
> [nu_estimate_np_and_em]
> [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
> [2008-04-21 14:44:23] /usr/local/minc2/bin/mincmath -clobber -verbose -zero
> -log /Library/MEDICS/tmp/abc_log.mnc.temp /Library/MEDICS/tmp/abc_log.mnc
> Processing:....................Done
> [nu_estimate_np_and_em]
> [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
> [2008-04-21 14:44:23] /bin/rm /Library/MEDICS/tmp/abc_log.mnc.temp
> [nu_estimate_np_and_em]
> [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
> [2008-04-21 14:44:23] /usr/local/minc2/bin/mincinfo -attvalue
> xspace:spacetype -attvalue yspace:spacetype -attvalue zspace:spacetype
> /Library/MEDICS/tmp/abc1___.mnc
> [nu_estimate_np_and_em]
> [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
> [2008-04-21 14:44:23] /usr/local/minc2/bin/volume_stats -quiet -biModalT
> /Library/MEDICS/tmp/abc1___.mnc
> Assertion failed at line 742 in file templates/CachedArray.cc
> nu_estimate_np_and_em: crashed while running volume_stats (termination
> status=256)
> nu_correct: crashed while running nu_estimate_np_and_em (termination
> status=256)
> 
> 
> 3) The directory /Library/MEDICS/tmp is writable by everyone (mode 777). The
> owner of the directory is _www.
> 
> 
> 4) Temporary files abc1_.mnc, abc1__.mnc, abc1___.mnc and abc_log.mnc all
> get created so I don't suspect a permission problem being the case here.
> 
> 
> 5) I don't quite understand the MINC source code just yet (hey, that's a lot
> of code), where would I find CachedArray.cc?
> 
> 
> 6) I noticed that in volumeStats.cc, there is the following:
> 
>     if (args.cached)
>       voxels = new CachedArray<float>(0);
>     else
>       voxels = new SimpleArray<float>(0);
> 
> Is there a way I could just bypass the call to CachedArray and not bother
> with trying to save memory (after all, GBytes are cheaper than the time
> we're spending to try to make this work... ;)
> 
> 
> Again, many thanks,
> 
> Burt.
> 
> 
> On Wed, Apr 16, 2008 at 5:01 PM, Burt Cr?peault <
> burt.crepeault at crulrg.ulaval.ca> wrote:
> 
>> Hi Alex,
>>
>> I went ahead and tried your suggestions, unfortunately I'm still stuck. The /tmp folder still has plenty of space and it is writable by anyone. I still get the following error from running the process:
>>
>>
>>    [7]:     [_www at pita.crulrg.local:/Library/WebServer/Documents/] [2008-04-16 12:32:14] running:
>>    [8]:       /usr/local/minc2/bin/nu_estimate_np_and_em -parzen -log -sharpen 0.1 0.01 -iterations 100
>>                 -stop 0.001 -shrink 3 -auto_mask -nonotify -b_spline 1 -distance 100 -quiet -execute
>>
>>                 -clobber -nokeeptmp -tmpdir /tmp/nu_correct_1361/
>>                 '/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1004/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1004.1.10004.[mnc.d2m].Br.12_p2.mnc'
>>
>>                 '/Library/MEDICS/data/images/10188/bl/MR.T1.MP-RAGE/1007/Library.MEDICS.data.images.10188.bl.MR.T1.MP-RAGE.1007.1.10007.[mnc.d2m+mnc.nuc].Br.22_p2.imp'
>>    [9]:
>>    [10]:     Assertion failed at line 742 in file templates/CachedArray.cc
>>
>>    [11]:     nu_estimate_np_and_em: crashed while running volume_stats (termination status=256)
>>    [12]:     nu_correct: crashed while running nu_estimate_np_and_em (termination status=256)
>>
>> I've listed my environment variables below:
>>
>>
>>        [TMPDIR] => /tmp
>>        [FOO] => /bar
>>        [PERL5LIB] => :/usr/local/minc2/lib:/Library/Perl/5.8.8:/usr/local/minc2/lib/perl5/site_perl/:/Users/burt/lib/perl
>>        [LD_LIBRARY_PATH] => :/Applications/MATLAB72/dip/Darwin/lib
>>
>>        [PATH] => /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/minc2/bin:/opt/local/bin:/opt/local/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/mysql/bin
>>        [PWD] => /Library/WebServer/Documents
>>
>>        [SHLVL] => 1
>>        [DYLD_LIBRARY_PATH] => :/usr/local/minc2/external-libs
>>
>> I tried the command at line [8] of my log directly in a terminal and everything runs fine. There is a /tmp/nu_correct_xxxx dir that is being created. However, that directory does not appear when the process is launched from the web app, therefore your assumption that CachedArray.cc is unable to create the temp file (or more likely dir) appears to be correct.
>>
>>
>> This is where I'm stuck at the moment, any other ideas?
>>
>>
>> --
>> Burt Cr?peault
>> Research Assistant
>> Centre de Recherche de l'Universit? Laval - Robert-Giffard
>> 418-663-5741, ext 6844

From a.janke at gmail.com  Mon Apr 21 21:55:22 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 22 Apr 2008 11:55:22 +1000
Subject: [MINC-users] Running MINC tools from the www user
In-Reply-To: <ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
	<ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
Message-ID: <d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>

Hi Burt,

>  2) If I precede the previous command with sudo -u _www, I get an error:
>  sudo -u _www /usr/local/minc2/bin/nu_correct -clobber -mapping_dir
>  /Library/MEDICS/tmp -tmpdir /Library/MEDICS/tmp/ -iterations 100 -shrink 3
>  -fwhm 0.1 -distance 100 -verbose /Library/MEDICS/tmp/abc1.mnc
>  /Library/MEDICS/tmp/abc.mnc
>
> ...
>
>  [_www at pita.crulrg.local:/usr/local/minc2/lib/perl5/site_perl]
>  [2008-04-21 14:44:23] /usr/local/minc2/bin/volume_stats -quiet -biModalT
>  /Library/MEDICS/tmp/abc1___.mnc
>
> Assertion failed at line 742 in file templates/CachedArray.cc
>
> nu_estimate_np_and_em: crashed while running volume_stats (termination
>  status=256)

I feel like I have just stepped into the middle of something here but
I would take a punt that this is OSX specific as I cannot seem to
replicate this under Ubuntu or Debian.   In my case I made a test user
and sudo'ed to there from root.  All seems to work fine but then
perhaps I have enough RAM that EBTKS behaves itself.

My first suggestion would be to dumb down your command to something like this:

   sudo -u _www /usr/local/minc2/bin/nu_correct -iterations 1 -verbose \
   /tmp/abc1.mnc /tmp/abc-out.mnc

To be sure that there are not permission errors.

>  5) I don't quite understand the MINC source code just yet (hey, that's a lot
>  of code), where would I find CachedArray.cc?

As per Alex said (given that he is the author of EBTKS!) however I
would be loathe to dig in the innards of that particular library as
other strange effects may surface elsewhere.

>  Is there a way I could just bypass the call to CachedArray and not bother
>  with trying to save memory (after all, GBytes are cheaper than the time
>  we're spending to try to make this work... ;)

My first suggestion would be to add the -nocache options to all the
volume_stats calls, I would also do this on a system level ie:

   cd /usr/local/minc2/bin
   mv volume_stats volume_stats.orig

   echo "#! /bin/sh" > volume_stats
   echo "volume_stats.orig -nocache $*" >> volume_stats
   chmod +x volume_stats

If this is still failing there is another option,....  but I will
likely be castigated for it.  I have long suggested that volume_stats
should be replaced with mincstats in nu_correct but there are
differences between the two in how they interpret histogram bins and
this results in a differing bimodalT for some histograms.  The results
from using mincstats are comparable to volume_stats but are not the
same.  It would be a difficult argument to prove which is better given
the simulations I have done on this so far.

In any case I have attached a patch for this (For
nu_estimate_np_and_em) but note that sharpen_volume still uses
volume_hist (something that mincstats can also do) so the differences
between the outputs of N3 are still very similar.

Good luck!


a

From bilal_mujeeb at hotmail.com  Tue Apr 22 01:57:14 2008
From: bilal_mujeeb at hotmail.com (Bilal Abdul Mujeeb)
Date: Tue, 22 Apr 2008 07:57:14 +0200
Subject: [MINC-users] Problem Compiling Minc
Message-ID: <BAY141-W43C231C5E48D3D1048D649EAE00@phx.gbl>


Hi,
I am using minc library 1.5 to develop some applications. I am working simple c++ classes using minc headers. 
I am using them on OS X 10.5.2 with GCC 4.x.x for MAC, it works fine on my mac. But when i took the same code on a linux machine it gives me linking errors. The link libraries for minc in both mac and linux sytem are .a and .la.

 I have added the library path in make file as well but no use. I have tried using Extern "C" to declare function again in my code but in mac it dont give me any error but on linux its gives error of redecleration.

my compiler output is as follow: 
------------------------------------------------------------------
bilal at BILAL:~/workspace/MincTest$ make
g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincThreshold.o MincThreshold.cpp
MincThreshold.cpp:172:2: warning: no newline at end of file
MincThreshold.cpp: In member function ?void MincThreshold::printVolumeInfo(volume_struct*, int*)?:
MincThreshold.cpp:28: warning: unused variable ?value?
MincThreshold.cpp: In member function ?int MincThreshold::saveVolume(volume_struct*, char*, char*)?:
MincThreshold.cpp:168: warning: deprecated conversion from string constant to ?char*?
g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincCorrectPV.o MincCorrectPV.cpp
MincCorrectPV.cpp: In member function ?int MincCorrectPV::saveVolume(volume_struct*, char*, char*)?:
MincCorrectPV.cpp:82: warning: deprecated conversion from string constant to ?char*?
g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o CheckDimensions.o CheckDimensions.cpp
CheckDimensions.cpp:49:2: warning: no newline at end of file
CheckDimensions.cpp: In member function ?int CheckDimensions::saveVolume(volume_struct*, char*, char*)?:
CheckDimensions.cpp:45: warning: deprecated conversion from string constant to ?char*?
g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincTest.o MincTest.cpp
MincTest.cpp:33:2: warning: no newline at end of file
g++ -lminc -lnetcdf -lvolume_io -Wl -o MincTest MincThreshold.o MincCorrectPV.o CheckDimensions.o MincTest.o
MincThreshold.o: In function `MincThreshold::saveVolume(volume_struct*, char*, char*)':
/home/bilal/workspace/MincTest/MincThreshold.cpp:168: undefined reference to `output_modified_volume'
MincThreshold.o: In function `MincThreshold::normalThreshold(volume_struct*, int*, double, int)':
/home/bilal/workspace/MincTest/MincThreshold.cpp:150: undefined reference to `get_volume_real_value'
/home/bilal/workspace/MincTest/MincThreshold.cpp:158: undefined reference to `set_volume_real_value'
MincThreshold.o: In function `MincThreshold::bandThreshold(volume_struct*, int*, double, double, int)':
/home/bilal/workspace/MincTest/MincThreshold.cpp:128: undefined reference to `get_volume_real_value'
/home/bilal/workspace/MincTest/MincThreshold.cpp:136: undefined reference to `set_volume_real_value'
MincThreshold.o: In function `~MincThreshold':
/home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
MincThreshold.o: In function `MincThreshold::printVolumeInfo(volume_struct*, int*)':
/home/bilal/workspace/MincTest/MincThreshold.cpp:36: undefined reference to `get_volume_nc_data_type'
/home/bilal/workspace/MincTest/MincThreshold.cpp:40: undefined reference to `get_volume_n_dimensions'
/home/bilal/workspace/MincTest/MincThreshold.cpp:45: undefined reference to `get_volume_voxel_max'
/home/bilal/workspace/MincTest/MincThreshold.cpp:46: undefined reference to `get_volume_voxel_min'
/home/bilal/workspace/MincTest/MincThreshold.cpp:50: undefined reference to `get_volume_real_max'
/home/bilal/workspace/MincTest/MincThreshold.cpp:51: undefined reference to `get_volume_real_min'
MincThreshold.o: In function `MincThreshold::parseArguments(int, char**)':
/home/bilal/workspace/MincTest/MincThreshold.cpp:97: undefined reference to `input_volume'
/home/bilal/workspace/MincTest/MincThreshold.cpp:98: undefined reference to `get_volume_sizes'
/home/bilal/workspace/MincTest/MincThreshold.cpp:106: undefined reference to `input_volume'
/home/bilal/workspace/MincTest/MincThreshold.cpp:107: undefined reference to `get_volume_sizes'
/home/bilal/workspace/MincTest/MincThreshold.cpp:85: undefined reference to `input_volume'
/home/bilal/workspace/MincTest/MincThreshold.cpp:86: undefined reference to `get_volume_sizes'
/home/bilal/workspace/MincTest/MincThreshold.cpp:75: undefined reference to `input_volume'
/home/bilal/workspace/MincTest/MincThreshold.cpp:76: undefined reference to `get_volume_sizes'
MincThreshold.o: In function `~MincThreshold':
/home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
/home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:114: undefined reference to `copy_volume'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:122: undefined reference to `get_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:123: undefined reference to `set_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:128: undefined reference to `set_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:129: undefined reference to `set_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:143: undefined reference to `get_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:149: undefined reference to `get_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:150: undefined reference to `get_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:164: undefined reference to `get_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:166: undefined reference to `get_volume_real_value'
MincCorrectPV.o:/home/bilal/workspace/MincTest/MincCorrectPV.cpp:164: more undefined references to `get_volume_real_value' follow
MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:173: undefined reference to `set_volume_real_value'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:167: undefined reference to `set_volume_real_value'
MincCorrectPV.o: In function `MincCorrectPV::saveVolume(volume_struct*, char*, char*)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:82: undefined reference to `output_modified_volume'
MincCorrectPV.o: In function `MincCorrectPV::correct_GM_PV(char*, char*)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:91: undefined reference to `copy_volume'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:92: undefined reference to `copy_volume'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:106: undefined reference to `delete_volume'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:107: undefined reference to `delete_volume'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:108: undefined reference to `delete_volume'
MincCorrectPV.o: In function `MincCorrectPV::checkMincRange(volume_struct*, double, double)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:75: undefined reference to `get_volume_real_min'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:75: undefined reference to `get_volume_real_max'
MincCorrectPV.o: In function `MincCorrectPV::praseParameters(int, char**)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:40: undefined reference to `input_volume'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:40: undefined reference to `input_volume'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:42: undefined reference to `get_volume_sizes'
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:43: undefined reference to `get_volume_sizes'
MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:182: undefined reference to `delete_volume'
MincCorrectPV.o: In function `MincCorrectPV::correct_GM_PV(char*, char*)':
/home/bilal/workspace/MincTest/MincCorrectPV.cpp:109: undefined reference to `delete_volume'
CheckDimensions.o: In function `CheckDimensions::saveVolume(volume_struct*, char*, char*)':
/home/bilal/workspace/MincTest/CheckDimensions.cpp:45: undefined reference to `output_modified_volume'
CheckDimensions.o: In function `CheckDimensions::viewDimensions(volume_struct*, int*)':
/home/bilal/workspace/MincTest/CheckDimensions.cpp:31: undefined reference to `get_volume_voxel_max'
/home/bilal/workspace/MincTest/CheckDimensions.cpp:35: undefined reference to `set_volume_real_value'
CheckDimensions.o: In function `CheckDimensions::parseArguments(int, char**)':
/home/bilal/workspace/MincTest/CheckDimensions.cpp:18: undefined reference to `input_volume'
/home/bilal/workspace/MincTest/CheckDimensions.cpp:19: undefined reference to `get_volume_sizes'
CheckDimensions.o: In function `~CheckDimensions':
/home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
/home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
/home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
collect2: ld returned 1 exit status
make: *** [MincTest] Error 1
--------------------------------------------------------------------------------------

my make file......

LDFLAGS = -lminc -lnetcdf -lvolume_io -Wl

CXXFLAGS =    -O2 -g -Wall -fmessage-length=0 -Wno-deprecated

OBJS =        MincThreshold.o MincCorrectPV.o CheckDimensions.o MincTest.o    

LIBS =

TARGET =    MincTest

$(TARGET):    $(OBJS)
    $(CXX) $(LDFLAGS) -o $(TARGET) $(OBJS) $(LIBS)

all:    $(TARGET)

clean:
    rm -f $(OBJS) $(TARGET)



Regards,
Bilal

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

From se at hst.aau.dk  Tue Apr 22 05:40:50 2008
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Tue, 22 Apr 2008 11:40:50 +0200
Subject: [MINC-users] Problem Compiling Minc
In-Reply-To: <BAY141-W43C231C5E48D3D1048D649EAE00@phx.gbl>
References: <BAY141-W43C231C5E48D3D1048D649EAE00@phx.gbl>
Message-ID: <480DB2A2.3030200@hst.aau.dk>

Hi Bilal,
Try putting the linker libraries at the end of the g++ statements and 
change the order so the dependency goes from left to right (that usually 
works with gcc):
g++ -o MincTest MincThreshold.o MincCorrectPV.o CheckDimensions.o 
MincTest.o -lvolume_io -lminc -lnetcdf

I have omitted the -Wl option above, as I'm not sure what you're trying 
to pass to the linker.
Also, in your makefile, LDFLAGS should point at the library paths, e.g. 
-L/usr/local/mni/lib, while LIBS should hold the dynamic libraries, e.g. 
-lvolume_io ...

And finally, newline at end of file ;)

Hope it helps,
Simon

Bilal Abdul Mujeeb wrote:
> Hi,
> I am using minc library 1.5 to develop some applications. I am working simple c++ classes using minc headers. 
> I am using them on OS X 10.5.2 with GCC 4.x.x for MAC, it works fine on my mac. But when i took the same code on a linux machine it gives me linking errors. The link libraries for minc in both mac and linux sytem are .a and .la.
> 
>  I have added the library path in make file as well but no use. I have tried using Extern "C" to declare function again in my code but in mac it dont give me any error but on linux its gives error of redecleration.
> 
> my compiler output is as follow: 
> ------------------------------------------------------------------
> bilal at BILAL:~/workspace/MincTest$ make
> g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincThreshold.o MincThreshold.cpp
> MincThreshold.cpp:172:2: warning: no newline at end of file
> MincThreshold.cpp: In member function ?void MincThreshold::printVolumeInfo(volume_struct*, int*)?:
> MincThreshold.cpp:28: warning: unused variable ?value?
> MincThreshold.cpp: In member function ?int MincThreshold::saveVolume(volume_struct*, char*, char*)?:
> MincThreshold.cpp:168: warning: deprecated conversion from string constant to ?char*?
> g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincCorrectPV.o MincCorrectPV.cpp
> MincCorrectPV.cpp: In member function ?int MincCorrectPV::saveVolume(volume_struct*, char*, char*)?:
> MincCorrectPV.cpp:82: warning: deprecated conversion from string constant to ?char*?
> g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o CheckDimensions.o CheckDimensions.cpp
> CheckDimensions.cpp:49:2: warning: no newline at end of file
> CheckDimensions.cpp: In member function ?int CheckDimensions::saveVolume(volume_struct*, char*, char*)?:
> CheckDimensions.cpp:45: warning: deprecated conversion from string constant to ?char*?
> g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincTest.o MincTest.cpp
> MincTest.cpp:33:2: warning: no newline at end of file
> g++ -lminc -lnetcdf -lvolume_io -Wl -o MincTest MincThreshold.o MincCorrectPV.o CheckDimensions.o MincTest.o
> MincThreshold.o: In function `MincThreshold::saveVolume(volume_struct*, char*, char*)':
> /home/bilal/workspace/MincTest/MincThreshold.cpp:168: undefined reference to `output_modified_volume'
> MincThreshold.o: In function `MincThreshold::normalThreshold(volume_struct*, int*, double, int)':
> /home/bilal/workspace/MincTest/MincThreshold.cpp:150: undefined reference to `get_volume_real_value'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:158: undefined reference to `set_volume_real_value'
> MincThreshold.o: In function `MincThreshold::bandThreshold(volume_struct*, int*, double, double, int)':
> /home/bilal/workspace/MincTest/MincThreshold.cpp:128: undefined reference to `get_volume_real_value'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:136: undefined reference to `set_volume_real_value'
> MincThreshold.o: In function `~MincThreshold':
> /home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
> MincThreshold.o: In function `MincThreshold::printVolumeInfo(volume_struct*, int*)':
> /home/bilal/workspace/MincTest/MincThreshold.cpp:36: undefined reference to `get_volume_nc_data_type'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:40: undefined reference to `get_volume_n_dimensions'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:45: undefined reference to `get_volume_voxel_max'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:46: undefined reference to `get_volume_voxel_min'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:50: undefined reference to `get_volume_real_max'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:51: undefined reference to `get_volume_real_min'
> MincThreshold.o: In function `MincThreshold::parseArguments(int, char**)':
> /home/bilal/workspace/MincTest/MincThreshold.cpp:97: undefined reference to `input_volume'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:98: undefined reference to `get_volume_sizes'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:106: undefined reference to `input_volume'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:107: undefined reference to `get_volume_sizes'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:85: undefined reference to `input_volume'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:86: undefined reference to `get_volume_sizes'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:75: undefined reference to `input_volume'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:76: undefined reference to `get_volume_sizes'
> MincThreshold.o: In function `~MincThreshold':
> /home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
> /home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
> MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:114: undefined reference to `copy_volume'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:122: undefined reference to `get_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:123: undefined reference to `set_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:128: undefined reference to `set_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:129: undefined reference to `set_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:143: undefined reference to `get_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:149: undefined reference to `get_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:150: undefined reference to `get_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:164: undefined reference to `get_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:166: undefined reference to `get_volume_real_value'
> MincCorrectPV.o:/home/bilal/workspace/MincTest/MincCorrectPV.cpp:164: more undefined references to `get_volume_real_value' follow
> MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:173: undefined reference to `set_volume_real_value'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:167: undefined reference to `set_volume_real_value'
> MincCorrectPV.o: In function `MincCorrectPV::saveVolume(volume_struct*, char*, char*)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:82: undefined reference to `output_modified_volume'
> MincCorrectPV.o: In function `MincCorrectPV::correct_GM_PV(char*, char*)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:91: undefined reference to `copy_volume'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:92: undefined reference to `copy_volume'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:106: undefined reference to `delete_volume'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:107: undefined reference to `delete_volume'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:108: undefined reference to `delete_volume'
> MincCorrectPV.o: In function `MincCorrectPV::checkMincRange(volume_struct*, double, double)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:75: undefined reference to `get_volume_real_min'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:75: undefined reference to `get_volume_real_max'
> MincCorrectPV.o: In function `MincCorrectPV::praseParameters(int, char**)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:40: undefined reference to `input_volume'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:40: undefined reference to `input_volume'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:42: undefined reference to `get_volume_sizes'
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:43: undefined reference to `get_volume_sizes'
> MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:182: undefined reference to `delete_volume'
> MincCorrectPV.o: In function `MincCorrectPV::correct_GM_PV(char*, char*)':
> /home/bilal/workspace/MincTest/MincCorrectPV.cpp:109: undefined reference to `delete_volume'
> CheckDimensions.o: In function `CheckDimensions::saveVolume(volume_struct*, char*, char*)':
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:45: undefined reference to `output_modified_volume'
> CheckDimensions.o: In function `CheckDimensions::viewDimensions(volume_struct*, int*)':
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:31: undefined reference to `get_volume_voxel_max'
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:35: undefined reference to `set_volume_real_value'
> CheckDimensions.o: In function `CheckDimensions::parseArguments(int, char**)':
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:18: undefined reference to `input_volume'
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:19: undefined reference to `get_volume_sizes'
> CheckDimensions.o: In function `~CheckDimensions':
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
> /home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
> collect2: ld returned 1 exit status
> make: *** [MincTest] Error 1
> --------------------------------------------------------------------------------------
> 
> my make file......
> 
> LDFLAGS = -lminc -lnetcdf -lvolume_io -Wl
> 
> CXXFLAGS =    -O2 -g -Wall -fmessage-length=0 -Wno-deprecated
> 
> OBJS =        MincThreshold.o MincCorrectPV.o CheckDimensions.o MincTest.o    
> 
> LIBS =
> 
> TARGET =    MincTest
> 
> $(TARGET):    $(OBJS)
>     $(CXX) $(LDFLAGS) -o $(TARGET) $(OBJS) $(LIBS)
> 
> all:    $(TARGET)
> 
> clean:
>     rm -f $(OBJS) $(TARGET)
> 
> 
> 
> Regards,
> Bilal
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From bilal_mujeeb at hotmail.com  Tue Apr 22 06:19:07 2008
From: bilal_mujeeb at hotmail.com (Bilal Abdul Mujeeb)
Date: Tue, 22 Apr 2008 12:19:07 +0200
Subject: [MINC-users] Problem Compiling Minc
In-Reply-To: <480DB2A2.3030200@hst.aau.dk>
References: <BAY141-W43C231C5E48D3D1048D649EAE00@phx.gbl>
	<480DB2A2.3030200@hst.aau.dk>
Message-ID: <BAY141-W45FEA1400F7784AB7A474BEAE00@phx.gbl>

Thanks Simon,

I found the problem. In the header file I have to define on linux machine 
extern "C" {// C header names} rather than the function names. I guess OSX compiler is intelligent to do it on its own.
it complies sweetly. 

Regards,
Bilal



> Date: Tue, 22 Apr 2008 11:40:50 +0200
> From: se at hst.aau.dk
> To: minc-users at bic.mni.mcgill.ca
> Subject: Re: [MINC-users] Problem Compiling Minc
> 
> Hi Bilal,
> Try putting the linker libraries at the end of the g++ statements and 
> change the order so the dependency goes from left to right (that usually 
> works with gcc):
> g++ -o MincTest MincThreshold.o MincCorrectPV.o CheckDimensions.o 
> MincTest.o -lvolume_io -lminc -lnetcdf
> 
> I have omitted the -Wl option above, as I'm not sure what you're trying 
> to pass to the linker.
> Also, in your makefile, LDFLAGS should point at the library paths, e.g. 
> -L/usr/local/mni/lib, while LIBS should hold the dynamic libraries, e.g. 
> -lvolume_io ...
> 
> And finally, newline at end of file ;)
> 
> Hope it helps,
> Simon
> 
> Bilal Abdul Mujeeb wrote:
> > Hi,
> > I am using minc library 1.5 to develop some applications. I am working simple c++ classes using minc headers. 
> > I am using them on OS X 10.5.2 with GCC 4.x.x for MAC, it works fine on my mac. But when i took the same code on a linux machine it gives me linking errors. The link libraries for minc in both mac and linux sytem are .a and .la.
> > 
> >  I have added the library path in make file as well but no use. I have tried using Extern "C" to declare function again in my code but in mac it dont give me any error but on linux its gives error of redecleration.
> > 
> > my compiler output is as follow: 
> > ------------------------------------------------------------------
> > bilal at BILAL:~/workspace/MincTest$ make
> > g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincThreshold.o MincThreshold.cpp
> > MincThreshold.cpp:172:2: warning: no newline at end of file
> > MincThreshold.cpp: In member function ?void MincThreshold::printVolumeInfo(volume_struct*, int*)?:
> > MincThreshold.cpp:28: warning: unused variable ?value?
> > MincThreshold.cpp: In member function ?int MincThreshold::saveVolume(volume_struct*, char*, char*)?:
> > MincThreshold.cpp:168: warning: deprecated conversion from string constant to ?char*?
> > g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincCorrectPV.o MincCorrectPV.cpp
> > MincCorrectPV.cpp: In member function ?int MincCorrectPV::saveVolume(volume_struct*, char*, char*)?:
> > MincCorrectPV.cpp:82: warning: deprecated conversion from string constant to ?char*?
> > g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o CheckDimensions.o CheckDimensions.cpp
> > CheckDimensions.cpp:49:2: warning: no newline at end of file
> > CheckDimensions.cpp: In member function ?int CheckDimensions::saveVolume(volume_struct*, char*, char*)?:
> > CheckDimensions.cpp:45: warning: deprecated conversion from string constant to ?char*?
> > g++ -O2 -g -Wall -fmessage-length=0 -Wno-deprecated   -c -o MincTest.o MincTest.cpp
> > MincTest.cpp:33:2: warning: no newline at end of file
> > g++ -lminc -lnetcdf -lvolume_io -Wl -o MincTest MincThreshold.o MincCorrectPV.o CheckDimensions.o MincTest.o
> > MincThreshold.o: In function `MincThreshold::saveVolume(volume_struct*, char*, char*)':
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:168: undefined reference to `output_modified_volume'
> > MincThreshold.o: In function `MincThreshold::normalThreshold(volume_struct*, int*, double, int)':
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:150: undefined reference to `get_volume_real_value'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:158: undefined reference to `set_volume_real_value'
> > MincThreshold.o: In function `MincThreshold::bandThreshold(volume_struct*, int*, double, double, int)':
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:128: undefined reference to `get_volume_real_value'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:136: undefined reference to `set_volume_real_value'
> > MincThreshold.o: In function `~MincThreshold':
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
> > MincThreshold.o: In function `MincThreshold::printVolumeInfo(volume_struct*, int*)':
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:36: undefined reference to `get_volume_nc_data_type'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:40: undefined reference to `get_volume_n_dimensions'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:45: undefined reference to `get_volume_voxel_max'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:46: undefined reference to `get_volume_voxel_min'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:50: undefined reference to `get_volume_real_max'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:51: undefined reference to `get_volume_real_min'
> > MincThreshold.o: In function `MincThreshold::parseArguments(int, char**)':
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:97: undefined reference to `input_volume'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:98: undefined reference to `get_volume_sizes'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:106: undefined reference to `input_volume'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:107: undefined reference to `get_volume_sizes'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:85: undefined reference to `input_volume'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:86: undefined reference to `get_volume_sizes'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:75: undefined reference to `input_volume'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:76: undefined reference to `get_volume_sizes'
> > MincThreshold.o: In function `~MincThreshold':
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
> > /home/bilal/workspace/MincTest/MincThreshold.cpp:12: undefined reference to `delete_volume'
> > MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:114: undefined reference to `copy_volume'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:122: undefined reference to `get_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:123: undefined reference to `set_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:128: undefined reference to `set_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:129: undefined reference to `set_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:143: undefined reference to `get_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:149: undefined reference to `get_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:150: undefined reference to `get_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:164: undefined reference to `get_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:166: undefined reference to `get_volume_real_value'
> > MincCorrectPV.o:/home/bilal/workspace/MincTest/MincCorrectPV.cpp:164: more undefined references to `get_volume_real_value' follow
> > MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:173: undefined reference to `set_volume_real_value'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:167: undefined reference to `set_volume_real_value'
> > MincCorrectPV.o: In function `MincCorrectPV::saveVolume(volume_struct*, char*, char*)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:82: undefined reference to `output_modified_volume'
> > MincCorrectPV.o: In function `MincCorrectPV::correct_GM_PV(char*, char*)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:91: undefined reference to `copy_volume'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:92: undefined reference to `copy_volume'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:106: undefined reference to `delete_volume'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:107: undefined reference to `delete_volume'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:108: undefined reference to `delete_volume'
> > MincCorrectPV.o: In function `MincCorrectPV::checkMincRange(volume_struct*, double, double)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:75: undefined reference to `get_volume_real_min'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:75: undefined reference to `get_volume_real_max'
> > MincCorrectPV.o: In function `MincCorrectPV::praseParameters(int, char**)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:40: undefined reference to `input_volume'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:40: undefined reference to `input_volume'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:42: undefined reference to `get_volume_sizes'
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:43: undefined reference to `get_volume_sizes'
> > MincCorrectPV.o: In function `MincCorrectPV::correctPV_Morphology(volume_struct*, int*, volume_struct*, int*, int, double, volume_struct*, volume_struct*)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:182: undefined reference to `delete_volume'
> > MincCorrectPV.o: In function `MincCorrectPV::correct_GM_PV(char*, char*)':
> > /home/bilal/workspace/MincTest/MincCorrectPV.cpp:109: undefined reference to `delete_volume'
> > CheckDimensions.o: In function `CheckDimensions::saveVolume(volume_struct*, char*, char*)':
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:45: undefined reference to `output_modified_volume'
> > CheckDimensions.o: In function `CheckDimensions::viewDimensions(volume_struct*, int*)':
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:31: undefined reference to `get_volume_voxel_max'
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:35: undefined reference to `set_volume_real_value'
> > CheckDimensions.o: In function `CheckDimensions::parseArguments(int, char**)':
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:18: undefined reference to `input_volume'
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:19: undefined reference to `get_volume_sizes'
> > CheckDimensions.o: In function `~CheckDimensions':
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
> > /home/bilal/workspace/MincTest/CheckDimensions.cpp:12: undefined reference to `delete_volume'
> > collect2: ld returned 1 exit status
> > make: *** [MincTest] Error 1
> > --------------------------------------------------------------------------------------
> > 
> > my make file......
> > 
> > LDFLAGS = -lminc -lnetcdf -lvolume_io -Wl
> > 
> > CXXFLAGS =    -O2 -g -Wall -fmessage-length=0 -Wno-deprecated
> > 
> > OBJS =        MincThreshold.o MincCorrectPV.o CheckDimensions.o MincTest.o    
> > 
> > LIBS =
> > 
> > TARGET =    MincTest
> > 
> > $(TARGET):    $(OBJS)
> >     $(CXX) $(LDFLAGS) -o $(TARGET) $(OBJS) $(LIBS)
> > 
> > all:    $(TARGET)
> > 
> > clean:
> >     rm -f $(OBJS) $(TARGET)
> > 
> > 
> > 
> > Regards,
> > Bilal
> > 
> > _________________________________________________________________
> > Express yourself instantly with MSN Messenger! Download today it's FREE!
> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

From burt.crepeault at crulrg.ulaval.ca  Tue Apr 22 09:13:11 2008
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Tue, 22 Apr 2008 09:13:11 -0400
Subject: [MINC-users] Running MINC tools from the www user
In-Reply-To: <ac2a7d1f0804220602u765da8f2hf754b03e23b50324@mail.gmail.com>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
	<ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
	<d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
	<ac2a7d1f0804220602u765da8f2hf754b03e23b50324@mail.gmail.com>
Message-ID: <ac2a7d1f0804220613y75238c28k9ef55e31f4f513d6@mail.gmail.com>

Hi Alex and Andrew,

I feel like I have just stepped into the middle of something here but
> I would take a punt that this is OSX specific as I cannot seem to
> replicate this under Ubuntu or Debian.   In my case I made a test user
> and sudo'ed to there from root.  All seems to work fine but then
> perhaps I have enough RAM that EBTKS behaves itself.


Give it a try with sudo -u www-data on Ubuntu, the equivalent to _www under
OS X.

My first suggestion would be to dumb down your command to something like
> this:
>
>   sudo -u _www /usr/local/minc2/bin/nu_correct -iterations 1 -verbose \
>   /tmp/abc1.mnc /tmp/abc-out.mnc
>
> To be sure that there are not permission errors.
>

Same as before.


> As per Alex said (given that he is the author of EBTKS!) however I
> would be loathe to dig in the innards of that particular library as
> other strange effects may surface elsewhere.
>

I must say I totally agree with you on this. I've a feeling I'd lose a
tremendous amount of time in there and end up doing more harm than good...


>  Alternatively, if you wanted to try to move on without identifying the
> source of this problem, you could add a '-nocache' flag to the call(s)
> to volume_stats in the nu_correct scripts (specifically in
> nu_estimate_np_and_em which throws this error). That should tell
> volume_stats to use the non-cached SimpleArray class instead of
> CachedArray as shown in the code snippet you listed.
>

[...]

 My first suggestion would be to add the -nocache options to all the
> volume_stats calls, I would also do this on a system level ie:
>
  cd /usr/local/minc2/bin
>   mv volume_stats volume_stats.orig
>
>   echo "#! /bin/sh" > volume_stats
>   echo "volume_stats.orig -nocache $*" >> volume_stats
>   chmod +x volume_stats
>

That's it!! It works! And the solution is delightfully simple too.


> If this is still failing there is another option,....  but I will
> likely be castigated for it.  I have long suggested that volume_stats
> should be replaced with mincstats in nu_correct but there are
> differences between the two in how they interpret histogram bins and
> this results in a differing bimodalT for some histograms.  The results
> from using mincstats are comparable to volume_stats but are not the
> same.  It would be a difficult argument to prove which is better given
> the simulations I have done on this so far.
>
> In any case I have attached a patch for this (For
> nu_estimate_np_and_em) but note that sharpen_volume still uses
> volume_hist (something that mincstats can also do) so the differences
> between the outputs of N3 are still very similar.
>

I'm afraid that's something I'll have to let the scientists debate. For now,
I'll just use that marvelous workaround above.

Thank you so much,


-- 
Burt Cr?peault
Research Assistant
Centre de Recherche de l'Universit? Laval - Robert-Giffard
+1-418-663-5741, ext 6844



-- 
Burt Cr?peault
Research Assistant
Centre de Recherche de l'Universit? Laval - Robert-Giffard
418-663-5741, ext 6844

From alex at bic.mni.mcgill.ca  Tue Apr 22 09:20:29 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Tue, 22 Apr 2008 09:20:29 -0400
Subject: [MINC-users] Running MINC tools from the www user
In-Reply-To: <d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>	<ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
	<d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
Message-ID: <480DE61D.5090606@bic.mni.mcgill.ca>

Andrew Janke wrote:
> I feel like I have just stepped into the middle of something here but
> I would take a punt that this is OSX specific as I cannot seem to
> replicate this under Ubuntu or Debian.   In my case I made a test user
> and sudo'ed to there from root.  All seems to work fine but then
> perhaps I have enough RAM that EBTKS behaves itself.

I *suspect* it is not a memory issue though (but then, any C/C++ problem 
could be a memory problem :). It seems to clearly fail in the generation 
of a temporary file.

> My first suggestion would be to dumb down your command to something like this:
> 
>    sudo -u _www /usr/local/minc2/bin/nu_correct -iterations 1 -verbose \
>    /tmp/abc1.mnc /tmp/abc-out.mnc
> 
> To be sure that there are not permission errors.
> 
>>  5) I don't quite understand the MINC source code just yet (hey, that's a lot
>>  of code), where would I find CachedArray.cc?
> 
> As per Alex said (given that he is the author of EBTKS!) however I
> would be loathe to dig in the innards of that particular library as
> other strange effects may surface elsewhere.

Well there is a reasonable likelihood that the error occurs in  the 
get_temp_filename function from EBTKs' src/FileIO.cc, which is riddled 
with #ifdefs that I'm pretty sure I didn't put there :-)

However, that function is called using

     char path[256];
     get_temp_filename(path);

in CachedArray.cc, which *ick* is of course somewhat bad/volatile if for 
some reason the path generated would be longer than 256 characters. Hey 
when I wrote this memory was still at a premium and I didn't anticipate 
that this would still be in use in the next century :)

>>  Is there a way I could just bypass the call to CachedArray and not bother
>>  with trying to save memory (after all, GBytes are cheaper than the time
>>  we're spending to try to make this work... ;)
> 
> My first suggestion would be to add the -nocache options to all the
> volume_stats calls, I would also do this on a system level ie:
> 
>    cd /usr/local/minc2/bin
>    mv volume_stats volume_stats.orig
> 
>    echo "#! /bin/sh" > volume_stats
>    echo "volume_stats.orig -nocache $*" >> volume_stats
>    chmod +x volume_stats
> 
> If this is still failing there is another option,....  but I will
> likely be castigated for it.  I have long suggested that volume_stats
> should be replaced with mincstats in nu_correct but there are
> differences between the two in how they interpret histogram bins and
> this results in a differing bimodalT for some histograms.  The results
> from using mincstats are comparable to volume_stats but are not the
> same.  It would be a difficult argument to prove which is better given
> the simulations I have done on this so far.

I was thinking the same thing - there appear to be some issues propping 
up now again relating to differences between mincstats and volume_stats, 
but by and large they should be interchangeable, and it seems to make 
more sense to standardize on one. Perhaps a good reason to perform a 
major version upgrade of N3? Although it would be nice to actually 
improve its performance while at it, such it doesn't need to be run 5 or 
10 times in a row to deliver good results. Still hoping to find time to 
deal with that. One of these years...

-- A

From a.janke at gmail.com  Wed Apr 23 00:46:40 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 23 Apr 2008 14:46:40 +1000
Subject: [MINC-users] dcm2mnc produces xspace:spacing = "irregular"
In-Reply-To: <20080421160513.GB3762@sumost.ca>
References: <20080421150312.GA3762@sumost.ca>
	<d747ed50804210812r6c15445ar5cb52215d53d9e2b@mail.gmail.com>
	<20080421160513.GB3762@sumost.ca>
Message-ID: <d747ed50804222146w4da6bfdx8458b6f01ac0e640@mail.gmail.com>

>  Sure.  But your problem is not with DICOM per se, but rather with
>  interpreting the vendor private attributes that presumably define the
>  slice positions.  I've never seen a mosaic image; I'd be interested to
>  have a look if you have an example handy.

Completely agree.  In most cases I suspect this is because the
manufacturers wanted to do more with DICOM that they could easily
implement.  Siemens "Phoenix" technology for example.  Thus they added
their own data in there.  Do a string search for ASCCONV in you
Siemens dicom data for example.. :)

   http://www.enac.northwestern.edu/~tew/archives/2003/02/25/incomplete-dicom-headers/

Has a nice explanation of some of the mosaic issues.

>  You could rightly argue the problem stems from DICOM not having a
>  useful 3D or 4D format when fMRI was developed.  Now that they have
>  the Enhanced MR IOD, is anyone using it for fMRI?

I would bet they stuck with what they know. :)  Haven't looked too
much further though, we tend to just keep patching dcm2mnc as needs
arise.  We are certainly not alone though, nearly all the DICOM
converters out there contain a massive case statement that is
essentially a switch on the (hardware/software) source of the data.

>  Both these examples, however, are a far cry from "some scanners use
> origin/angle, some use absolute position of centre of slices, some use
>  offsets, etc", which is what I was curious about.

Correct, in this case I was referring to Mosaic formats.


a

From a.janke at gmail.com  Tue Apr 29 02:07:51 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 29 Apr 2008 16:07:51 +1000
Subject: [MINC-users] Ubuntu Hardy amd64 packages
Message-ID: <d747ed50804282307r381ecab6idde862b28c875252@mail.gmail.com>

For the early adopters...

I am currently uploading a bunch of packages to here:

   packages.bic.mni.mcgill.ca/ubuntu-hardy



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

From Michel.Audette at medizin.uni-leipzig.de  Tue Apr 29 10:19:37 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 29 Apr 2008 16:19:37 +0200
Subject: [MINC-users] mincreshape +xdirection not robust
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com><ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
	<d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6902020045@MRZS152229.medizin.uni-leipzig.de>

Hi all, 

is there a way to enforce a mincreshape +direction command? For some reason, my attempt reveals that it is not robust.

maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction etzold_emma_12792115_003002_mri_xyz_flt_2.mnc etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob
Copying chunks:................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Done.
maudette at icaw164201:~/data/data/work/goodEarData> mincinfo etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
image: signed__ float -3.8880898500792682171e-11 to 4019
image dimensions: xspace yspace zspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    512    -0.195312      26.8047
    yspace                    512     0.195312      93.2894
    zspace                    129     0.299075     -67.2154

maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +xdirection +ydirection +zdirection etzold_emma_12792115_003002_mri_xyz_flt_2.mnc etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob
Copying chunks:................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Done.
maudette at icaw164201:~/data/data/work/goodEarData> mincinfo etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
image: signed__ float -3.8880898500792682171e-11 to 4019
image dimensions: xspace yspace zspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    512    -0.195312      26.8047
    yspace                    512     0.195312      93.2894
    zspace                    129     0.299075     -67.2154

Just wondering... 

Best regards, 

Michel

Michel Audette, Ph.D.  
Innovation Center Computer Assisted Surgery (ICCAS)  
Semmelweisstra?e 14 
Leipzig, Germany 
Phone: ++49 (0) 341 / 97 - 1 20 13 
Fax: ++49 (0) 341 / 97 - 1 20 09




From claude at bic.mni.mcgill.ca  Tue Apr 29 10:28:55 2008
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Tue, 29 Apr 2008 10:28:55 -0400 (EDT)
Subject: [MINC-users] mincreshape +xdirection not robust
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com><ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
	<d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
Message-ID: <200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca>

> is there a way to enforce a mincreshape +direction command? For some reason, my attempt reveals that it is not robust.
> 
> maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction etzold_emma_12792115_003002_mri_xyz_flt_2.mnc etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob


-dimorder zspace,yspace,xspace

From Michel.Audette at medizin.uni-leipzig.de  Tue Apr 29 10:40:18 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 29 Apr 2008 16:40:18 +0200
Subject: [MINC-users] mincreshape +xdirection not robust
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com><ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com><d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
	<200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de>

Hi Claude, 

thanks for the tip but...

maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction etzold_emma_12792115_003002_mri_xyz_flt_2.mnc etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob -dimorder zspace,yspace,xspace
Copying chunks:...................................Done.
maudette at icaw164201:~/data/data/work/goodEarData> !mincin
mincinfo etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
image: signed__ float -3.8880898500792682171e-11 to 4019
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                    129     0.299075     -67.2154
    yspace                    512     0.195312      93.2894
    xspace                    512    -0.195312      26.8047

My best recourse appears to be to opt for mincresample and figure out the new start point. 

maudette at icaw164201:~/data/data/work/goodEarData> mincresample -xstart -72.999732 -xstep 0.195312 -ystart 93.2894 -ystep 0.195312 etzold_emma_12792115_003002_mri_xyz_flt_2.mnc etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob
T
maudette at icaw164201:~/data/data/work/goodEarData> mincinfo etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
image: signed__ float -5.8522943435779239962e-12 to 4018.716796875
image dimensions: xspace yspace zspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    512     0.195312     -72.9997
    yspace                    512     0.195312      93.2894
    zspace                    129     0.299075     -67.2154

Sorry for the trouble. This bug is really odd, though. 

Cheers,

Michel
-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Claude LEPAGE
Sent: Tue 4/29/2008 4:28 PM
To: MINC users mailing list
Subject: Re: [MINC-users] mincreshape +xdirection not robust
 
> is there a way to enforce a mincreshape +direction command? For some reason, my attempt reveals that it is not robust.
> 
> maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction etzold_emma_12792115_003002_mri_xyz_flt_2.mnc etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob


-dimorder zspace,yspace,xspace
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From sorench at gmail.com  Tue Apr 29 10:54:52 2008
From: sorench at gmail.com (Soren Christensen)
Date: Tue, 29 Apr 2008 16:54:52 +0200
Subject: [MINC-users] mincreshape +xdirection not robust
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
	<ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
	<d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
	<200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d6e2d6550804290754u1941aa03l97113061d50749bd@mail.gmail.com>

Hi,
 Isn't this fixable by
mincreshape +direction
-dimsize xspace=-1
-dimsize yspace=-1
-dimsize zspace=-1
-dimorder zspace,yspace,xspace
infile.mnc outfile.mnc
as stated here.
http://brainbody.nottingham.ac.uk/users/wiki/pmwiki.php?n=MincUsersGroup.FAQDataFormats
I think Andrew had an explanation for it.

Cheers
Soren


2008/4/29 Audette, Michel <Michel.Audette at medizin.uni-leipzig.de>:

> Hi Claude,
>
> thanks for the tip but...
>
> maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction
> etzold_emma_12792115_003002_mri_xyz_flt_2.mnc
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob -dimorder
> zspace,yspace,xspace
> Copying chunks:...................................Done.
> maudette at icaw164201:~/data/data/work/goodEarData> !mincin
> mincinfo etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> image: signed__ float -3.8880898500792682171e-11 to 4019
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                    129     0.299075     -67.2154
>    yspace                    512     0.195312      93.2894
>    xspace                    512    -0.195312      26.8047
>
> My best recourse appears to be to opt for mincresample and figure out the
> new start point.
>
> maudette at icaw164201:~/data/data/work/goodEarData> mincresample -xstart
> -72.999732 -xstep 0.195312 -ystart 93.2894 -ystep 0.195312
> etzold_emma_12792115_003002_mri_xyz_flt_2.mnc
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob
> T
> maudette at icaw164201:~/data/data/work/goodEarData> mincinfo
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> image: signed__ float -5.8522943435779239962e-12 to 4018.716796875
> image dimensions: xspace yspace zspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    xspace                    512     0.195312     -72.9997
>    yspace                    512     0.195312      93.2894
>    zspace                    129     0.299075     -67.2154
>
> Sorry for the trouble. This bug is really odd, though.
>
> Cheers,
>
> Michel
>  -----Original Message-----
> From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Claude LEPAGE
> Sent: Tue 4/29/2008 4:28 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] mincreshape +xdirection not robust
>
> > is there a way to enforce a mincreshape +direction command? For some
> reason, my attempt reveals that it is not robust.
> >
> > maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction
> etzold_emma_12792115_003002_mri_xyz_flt_2.mnc
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob
>
>
> -dimorder zspace,yspace,xspace
> _______________________________________________
> 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
>
>

From Michel.Audette at medizin.uni-leipzig.de  Tue Apr 29 11:00:18 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Tue, 29 Apr 2008 17:00:18 +0200
Subject: [MINC-users] mincreshape +xdirection not robust
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com><ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com><d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com><200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de>
	<d6e2d6550804290754u1941aa03l97113061d50749bd@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E690202004A@MRZS152229.medizin.uni-leipzig.de>

Hi Soren, 

thanks for the kind email. Apparently it is. Vladimir just sent me the answer. 

Cheers,

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Soren Christensen
Sent: Tue 4/29/2008 4:54 PM
To: MINC users mailing list
Subject: Re: [MINC-users] mincreshape +xdirection not robust
 
Hi,
 Isn't this fixable by
mincreshape +direction
-dimsize xspace=-1
-dimsize yspace=-1
-dimsize zspace=-1
-dimorder zspace,yspace,xspace
infile.mnc outfile.mnc
as stated here.
http://brainbody.nottingham.ac.uk/users/wiki/pmwiki.php?n=MincUsersGroup.FAQDataFormats
I think Andrew had an explanation for it.

Cheers
Soren


2008/4/29 Audette, Michel <Michel.Audette at medizin.uni-leipzig.de>:

> Hi Claude,
>
> thanks for the tip but...
>
> maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction
> etzold_emma_12792115_003002_mri_xyz_flt_2.mnc
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob -dimorder
> zspace,yspace,xspace
> Copying chunks:...................................Done.
> maudette at icaw164201:~/data/data/work/goodEarData> !mincin
> mincinfo etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> image: signed__ float -3.8880898500792682171e-11 to 4019
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                    129     0.299075     -67.2154
>    yspace                    512     0.195312      93.2894
>    xspace                    512    -0.195312      26.8047
>
> My best recourse appears to be to opt for mincresample and figure out the
> new start point.
>
> maudette at icaw164201:~/data/data/work/goodEarData> mincresample -xstart
> -72.999732 -xstep 0.195312 -ystart 93.2894 -ystep 0.195312
> etzold_emma_12792115_003002_mri_xyz_flt_2.mnc
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob
> T
> maudette at icaw164201:~/data/data/work/goodEarData> mincinfo
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> file: etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc
> image: signed__ float -5.8522943435779239962e-12 to 4018.716796875
> image dimensions: xspace yspace zspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    xspace                    512     0.195312     -72.9997
>    yspace                    512     0.195312      93.2894
>    zspace                    129     0.299075     -67.2154
>
> Sorry for the trouble. This bug is really odd, though.
>
> Cheers,
>
> Michel
>  -----Original Message-----
> From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Claude LEPAGE
> Sent: Tue 4/29/2008 4:28 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] mincreshape +xdirection not robust
>
> > is there a way to enforce a mincreshape +direction command? For some
> reason, my attempt reveals that it is not robust.
> >
> > maudette at icaw164201:~/data/data/work/goodEarData> mincreshape +direction
> etzold_emma_12792115_003002_mri_xyz_flt_2.mnc
> etzold_emma_12792115_003002_mri_+xyz_flt_2.mnc -clob
>
>
> -dimorder zspace,yspace,xspace
> _______________________________________________
> 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
>
>
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From a.janke at gmail.com  Tue Apr 29 17:51:48 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 30 Apr 2008 07:51:48 +1000
Subject: [MINC-users] mincreshape +xdirection not robust
In-Reply-To: <d6e2d6550804290754u1941aa03l97113061d50749bd@mail.gmail.com>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
	<ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
	<d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
	<200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de>
	<d6e2d6550804290754u1941aa03l97113061d50749bd@mail.gmail.com>
Message-ID: <d747ed50804291451q2bd8980agaae893214d1a1dc6@mail.gmail.com>

2008/4/30 Soren Christensen <sorench at gmail.com>:
>  http://brainbody.nottingham.ac.uk/users/wiki/pmwiki.php?n=MincUsersGroup.FAQDataFormats
>  I think Andrew had an explanation for it.

Or more succinctly:

   man mincreshape

But now I am being slightly trite.. :)


a

From Michel.Audette at medizin.uni-leipzig.de  Wed Apr 30 10:03:22 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 30 Apr 2008 16:03:22 +0200
Subject: [MINC-users] dicom3_to_minc error,
	seems related to slice position/orientation
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com><ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com><d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>	<200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de>
	<48173587.4050909@ilmarin.info>
Message-ID: <160E3DD4FB702C4CB860C65186686E6902020054@MRZS152229.medizin.uni-leipzig.de>

Hi folks, 

sorry to make a nuisance of myself these days. I'm confronting dicom3_to_minc errors once again: 

maudette at icaw164201:~/data/data/Dyna_CT> dicom3_to_minc Kust_mnc/ Kust/*IMA
Reading headers from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA"
************** Error reading slice position ***************
************* Error reading slice orientation *************
... (a bunch more like this)
Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA"
************** Error reading slice position ***************
************* Error reading slice orientation *************
Creating minc file "Kust_mnc//k_st_martin_1_013013_mri.mnc"
Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.110.2008.04.29.10.16.22.890625.796193.IMA
Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.118.2008.04.29.10.16.22.890625.796206.IMA
Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.1.2008.04.29.10.16.22.890625.795985.IMA
... (a few more like this)
Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.86.2008.04.29.10.16.22.890625.796154.IMA
Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.9.2008.04.29.10.16.22.890625.795998.IMA
Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.94.2008.04.29.10.16.22.890625.796167.IMA
Getting data from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA" for slice 0.
(from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
micreate_group_variable: MINC package entry point
... (a few more like this)
(from micreate_group_variable): Variable 'dicom_0x0040' is not a standard MINC variable
micreate_group_variable: MINC package entry point
Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA"
Creating minc file "Kust_mnc//k_st_martin_1_010010_mri.mnc"
Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA" for slice 0.
(from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
micreate_group_variable: MINC package entry point
... (a few more like this)
(from micreate_group_variable): Variable 'dicom_0x5000' is not a standard MINC variable
micreate_group_variable: MINC package entry point
Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.101.2008.04.29.10.16.22.890625.799255.IMA"
...
Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.11.1.2008.04.29.10.16.22.890625.1702201.IMA"
************** Error reading slice position ***************
************* Error reading slice orientation *************
Creating minc file "Kust_mnc//k_st_martin_1_001001_mri.mnc"
Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.10.2008.04.29.10.16.22.890625.797890.IMA" for slice 0.
Using blank image for slice 1 (:).
... (same message for slices 2-87)
Using blank image for slice 88 (:).
Using blank image for slice 89 (:).
Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA" for slice 90.
G

The end result is a bunch of minc files featuring large blank subvolumes. 

Can anyone suggest a course of action? 

Cheers, 

Michel

Michel Audette, Ph.D.
Innovation Center Computer Assisted Surgery (ICCAS)
Semmelweisstra?e 14
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09



From jharlap at bic.mni.mcgill.ca  Wed Apr 30 10:25:02 2008
From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap)
Date: Wed, 30 Apr 2008 10:25:02 -0400
Subject: [MINC-users] dicom3_to_minc error,
	seems related to slice position/orientation
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6902020054@MRZS152229.medizin.uni-leipzig.de>
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com>
	<ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com>
	<d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com>
	<200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca>
	<160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de>
	<48173587.4050909@ilmarin.info>
	<160E3DD4FB702C4CB860C65186686E6902020054@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <115a643d0804300725r1a08c04cy65781de14404369@mail.gmail.com>

My first suggestion would be to use dcm2mnc instead of dicom3_to_minc,
given that dicom3_to_minc isn't being worked on anymore and dcm2mnc
handles a lot of scanner-specific weirdnesses that dicom3_to_minc
doesn't.

Cheers,
J

On Wed, Apr 30, 2008 at 10:03 AM, Audette, Michel
<Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi folks,
>
>  sorry to make a nuisance of myself these days. I'm confronting dicom3_to_minc errors once again:
>
>  maudette at icaw164201:~/data/data/Dyna_CT> dicom3_to_minc Kust_mnc/ Kust/*IMA
>  Reading headers from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  ... (a bunch more like this)
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  Creating minc file "Kust_mnc//k_st_martin_1_013013_mri.mnc"
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.110.2008.04.29.10.16.22.890625.796193.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.118.2008.04.29.10.16.22.890625.796206.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.1.2008.04.29.10.16.22.890625.795985.IMA
>  ... (a few more like this)
>  Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.86.2008.04.29.10.16.22.890625.796154.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.9.2008.04.29.10.16.22.890625.795998.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.94.2008.04.29.10.16.22.890625.796167.IMA
>  Getting data from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA" for slice 0.
>  (from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  ... (a few more like this)
>  (from micreate_group_variable): Variable 'dicom_0x0040' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA"
>  Creating minc file "Kust_mnc//k_st_martin_1_010010_mri.mnc"
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA" for slice 0.
>  (from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  ... (a few more like this)
>  (from micreate_group_variable): Variable 'dicom_0x5000' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.101.2008.04.29.10.16.22.890625.799255.IMA"
>  ...
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.11.1.2008.04.29.10.16.22.890625.1702201.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  Creating minc file "Kust_mnc//k_st_martin_1_001001_mri.mnc"
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.10.2008.04.29.10.16.22.890625.797890.IMA" for slice 0.
>  Using blank image for slice 1 (:).
>  ... (same message for slices 2-87)
>  Using blank image for slice 88 (:).
>  Using blank image for slice 89 (:).
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA" for slice 90.
>  G
>
>  The end result is a bunch of minc files featuring large blank subvolumes.
>
>  Can anyone suggest a course of action?
>
>  Cheers,
>
>  Michel
>
>  Michel Audette, Ph.D.
>  Innovation Center Computer Assisted Surgery (ICCAS)
>  Semmelweisstra?e 14
>  Leipzig, Germany
>  Phone: ++49 (0) 341 / 97 - 1 20 13
>  Fax: ++49 (0) 341 / 97 - 1 20 09
>
>
>  _______________________________________________
>  MINC-users at bic.mni.mcgill.ca
>  http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


From Michel.Audette at medizin.uni-leipzig.de  Wed Apr 30 10:32:31 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 30 Apr 2008 16:32:31 +0200
Subject: [MINC-users] dicom3_to_minc error,
	seems related to slice position/orientation
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com><ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com><d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com><200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de><48173587.4050909@ilmarin.info><160E3DD4FB702C4CB860C65186686E6902020054@MRZS152229.medizin.uni-leipzig.de>
	<115a643d0804300725r1a08c04cy65781de14404369@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6902020055@MRZS152229.medizin.uni-leipzig.de>

Hi Jonathan, 

sorry about that... I probably should have noted this before. I'll rename my dicom3_to_minc to something else, or delete it altogether. 

Cheers, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Jonathan Harlap
Sent: Wed 4/30/2008 4:25 PM
To: MINC users mailing list
Subject: Re: [MINC-users] dicom3_to_minc error,seems related to slice position/orientation
 
My first suggestion would be to use dcm2mnc instead of dicom3_to_minc,
given that dicom3_to_minc isn't being worked on anymore and dcm2mnc
handles a lot of scanner-specific weirdnesses that dicom3_to_minc
doesn't.

Cheers,
J

On Wed, Apr 30, 2008 at 10:03 AM, Audette, Michel
<Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi folks,
>
>  sorry to make a nuisance of myself these days. I'm confronting dicom3_to_minc errors once again:
>
>  maudette at icaw164201:~/data/data/Dyna_CT> dicom3_to_minc Kust_mnc/ Kust/*IMA
>  Reading headers from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  ... (a bunch more like this)
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  Creating minc file "Kust_mnc//k_st_martin_1_013013_mri.mnc"
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.110.2008.04.29.10.16.22.890625.796193.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.118.2008.04.29.10.16.22.890625.796206.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.1.2008.04.29.10.16.22.890625.795985.IMA
>  ... (a few more like this)
>  Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.86.2008.04.29.10.16.22.890625.796154.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.9.2008.04.29.10.16.22.890625.795998.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.94.2008.04.29.10.16.22.890625.796167.IMA
>  Getting data from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA" for slice 0.
>  (from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  ... (a few more like this)
>  (from micreate_group_variable): Variable 'dicom_0x0040' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA"
>  Creating minc file "Kust_mnc//k_st_martin_1_010010_mri.mnc"
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA" for slice 0.
>  (from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  ... (a few more like this)
>  (from micreate_group_variable): Variable 'dicom_0x5000' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.101.2008.04.29.10.16.22.890625.799255.IMA"
>  ...
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.11.1.2008.04.29.10.16.22.890625.1702201.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  Creating minc file "Kust_mnc//k_st_martin_1_001001_mri.mnc"
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.10.2008.04.29.10.16.22.890625.797890.IMA" for slice 0.
>  Using blank image for slice 1 (:).
>  ... (same message for slices 2-87)
>  Using blank image for slice 88 (:).
>  Using blank image for slice 89 (:).
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA" for slice 90.
>  G
>
>  The end result is a bunch of minc files featuring large blank subvolumes.
>
>  Can anyone suggest a course of action?
>
>  Cheers,
>
>  Michel
>
>  Michel Audette, Ph.D.
>  Innovation Center Computer Assisted Surgery (ICCAS)
>  Semmelweisstra?e 14
>  Leipzig, Germany
>  Phone: ++49 (0) 341 / 97 - 1 20 13
>  Fax: ++49 (0) 341 / 97 - 1 20 09
>
>
>  _______________________________________________
>  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



From Michel.Audette at medizin.uni-leipzig.de  Wed Apr 30 10:44:14 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 30 Apr 2008 16:44:14 +0200
Subject: [MINC-users] dcm2mnc error,
	seems related to slice position/orientation
References: <ac2a7d1f0804161401q77e469b7s66452f4bcd6e8065@mail.gmail.com><ac2a7d1f0804211208q824a0ai8b4dbe515f2829df@mail.gmail.com><d747ed50804211855q4a9efd1agb4740fb41693c85b@mail.gmail.com><200804291428.m3TEStA8690867@yorick.bic.mni.mcgill.ca><160E3DD4FB702C4CB860C65186686E6902020048@MRZS152229.medizin.uni-leipzig.de><48173587.4050909@ilmarin.info><160E3DD4FB702C4CB860C65186686E6902020054@MRZS152229.medizin.uni-leipzig.de>
	<115a643d0804300725r1a08c04cy65781de14404369@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6902020056@MRZS152229.medizin.uni-leipzig.de>

Hi again, 

in any event, dcm2mnc winges with this particular data set: 
maudette at icaw164201:~/data/data/Dyna_CT> dcm2mnc Kann/*.IMA Kann_mnc/ -clob -verbose
Checking file types...
File Kann/KANN.OT.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.1000.1.2008.04.21.13.58.31.718750.1245303.IMA appears to be DICOM (CD/Export).
WARNING: Failed to find image position
...
WARNING: Failed to find image position
Using 482 files
Sorting 482 files...
num  filename                         studyid        serialno acq      nec  iec  ndy  idy  nsl  isl  acol rcol mrow img#  seq
   0 4.21.13.54.58.187500.1214558.IMA 20080420.090629    55032        1   -1   -1   -1    1    1   -1   -1 1024   -1   300
 ... (bunch of lines like this)
  481 4.21.13.58.31.718750.1245323.IMA 20080420.090629    11532     1000   -1   -1   -1   -1   -1   -1   -1  128   -1     2
Done sorting files.
Processing files, one series at a time...
Using directory 'Kann_mnc/'
file_prefix:  [Kann_mnc/]

Series    1                 Kann Fluoro Card Klappen2 (   2 files):
     Kann/KANN.XA.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.1.300.2008.04.21.13.54.58.187500.1214558.IMA
     Kann/KANN.XA.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.1.301.2008.04.21.13.54.58.187500.1214593.IMA
WARNING: Image coordinates absent or incomplete.
WARNING: Slice location is untrustworthy.
WARNING: Failed to find image orientation!
Using default direction cosines
WARNING: Can't find pixel size element
 0. Slice axis length 1
 1. Echo axis length 1
 2. Time axis length 1
 3. Phase axis length 1
 4. ChmSh axis length 1
 0. Z axis length 1 step -1.000, start -1.000, cosines -0.000,-0.000,1.000
 1. Y axis length 1024 step -1.000, start 0.000, cosines -0.000,1.000,-0.000
 2. X axis length 1024 step -1.000, start 0.000, cosines 1.000,-0.000,-0.000
SOP Class UID: 1.2.840.10008.5.1.4.1.1.12.1
Images in acquisition: 1
Acquisitions in series: -1
3D raw partitions: -1
Pixel minimum 0.0000000000 maximum 4095.0000000000
Window minimum 0.0000000000 maximum 4096.0000000000
WARNING: Failed to find image orientation!
Using default direction cosines
WARNING: Can't find pixel size element
Directory Kann_mnc/kann_20080421_090629 exists...
MINC file name:  Kann_mnc/kann_20080421_090629/kann_20080421_090629_1.mnc
Patient name:    Kann
Study ID:        20080420.090629
Acquisition ID:  1
Registration date:  20080421
Registration time:  090629.015000
Rows 1024 columns 1024 slices 1/1
Writing 2 images to MINC file
Created minc file Kann_mnc/kann_20080421_090629/kann_20080421_090629_1.mnc.

Series    2                 Kann Fluoro Card Klappen2 (   1 files):
     Kann/KANN.XA.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.2.100.2008.04.21.13.54.58.187500.1214628.IMA
WARNING: Image coordinates absent or incomplete.
WARNING: Failed to find image orientation!
Using default direction cosines
WARNING: Can't find pixel size element
WARNING: Failed to find image position
 0. Slice axis length 1
 1. Echo axis length 1
 2. Time axis length 1
 3. Phase axis length 1
 4. ChmSh axis length 1
 0. Z axis length 1 step -1.000, start 1.000, cosines -0.000,-0.000,1.000
 1. Y axis length 1024 step -1.000, start 0.000, cosines -0.000,1.000,-0.000
 2. X axis length 1024 step -1.000, start 0.000, cosines 1.000,-0.000,-0.000
SOP Class UID: 1.2.840.10008.5.1.4.1.1.12.1
Images in acquisition: 1
Acquisitions in series: -1
3D raw partitions: -1
Pixel minimum 0.0000000000 maximum 4095.0000000000
Window minimum 750.0000000000 maximum 3450.0000000000
Directory Kann_mnc/kann_20080421_090629 exists...
MINC file name:  Kann_mnc/kann_20080421_090629/kann_20080421_090629_2.mnc
Patient name:    Kann
Study ID:        20080420.090629
Acquisition ID:  2
Registration date:  20080421
Registration time:  090629.015000
Rows 1024 columns 1024 slices 1/1
Writing 1 images to MINC file
Created minc file Kann_mnc/kann_20080421_090629/kann_20080421_090629_2.mnc.

Series    3                 Kann             5s-1k DR ( 465 files):
     Kann/KANN.OT.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.3.1.2008.04.21.13.54.58.187500.625726.IMA
... (bunch of lines like this)
     Kann/KANN.XA.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.3.222.2008.04.21.13.54.58.187500.635182.IMA
WARNING: Image coordinates absent or incomplete.
WARNING: Slice location is untrustworthy.
WARNING: Failed to find image orientation!
Using default direction cosines
WARNING: Can't find pixel size element
 0. Slice axis length 1
 1. Echo axis length 1
 2. Time axis length 1
 3. Phase axis length 1
 4. ChmSh axis length 1
 0. Z axis length 1 step -1.000, start -1.000, cosines -0.000,-0.000,1.000
 1. Y axis length 1024 step -1.000, start 0.000, cosines -0.000,1.000,-0.000
 2. X axis length 1024 step -1.000, start 0.000, cosines 1.000,-0.000,-0.000
SOP Class UID: 1.2.840.10008.5.1.4.1.1.12.1
Images in acquisition: -1
Acquisitions in series: -1
3D raw partitions: -1
Pixel minimum 0.0000000000 maximum 4095.0000000000
Window minimum 0.0000000000 maximum 4096.0000000000
WARNING: Failed to find image orientation!
WARNING: Failed to find image position
WARNING: No image position found

... (skipping info again)

Mismatched rows/columns, marking invalid
WARNING: Inconsistent pixel minimum and maximum
    0.000000 4095.000000, 0.000000 65535.000000
Mismatched rows/columns, marking invalid
WARNING: Coordinate spacing (1) differs from DICOM slice spacing (-1)
 (perhaps you should consider the -usecoordinates option)
 Using -1 for the slice spacing value.
Directory Kann_mnc/kann_20080421_090629 exists...
MINC file name:  Kann_mnc/kann_20080421_090629/kann_20080421_090629_3.mnc
Patient name:    Kann
Study ID:        20080420.090629
Acquisition ID:  3
Registration date:  20080421
Registration time:  090629.015000
Rows 1024 columns 1024 slices 133/133
Writing 465 images to MINC file
WARNING: Failed to find image orientation!
WARNING: Failed to find image position
WARNING: No image position found
WARNING: Failed to find image position
WARNING: Failed to find image orientation!
WARNING: Failed to find image position
WARNING: No image position found
WARNING: Failed to find image position
Segmentation fault

ends with this fault. 

Thanks again for your kind consideration. 

Best regards,

Michel

Michel Audette, Ph.D.
Innovation Center Computer Assisted Surgery (ICCAS)
Semmelweisstra?e 14
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Jonathan Harlap
Sent: Wed 4/30/2008 4:25 PM
To: MINC users mailing list
Subject: Re: [MINC-users] dicom3_to_minc error,seems related to slice position/orientation
 
My first suggestion would be to use dcm2mnc instead of dicom3_to_minc,
given that dicom3_to_minc isn't being worked on anymore and dcm2mnc
handles a lot of scanner-specific weirdnesses that dicom3_to_minc
doesn't.

Cheers,
J

On Wed, Apr 30, 2008 at 10:03 AM, Audette, Michel
<Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi folks,
>
>  sorry to make a nuisance of myself these days. I'm confronting dicom3_to_minc errors once again:
>
>  maudette at icaw164201:~/data/data/Dyna_CT> dicom3_to_minc Kust_mnc/ Kust/*IMA
>  Reading headers from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  ... (a bunch more like this)
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  Creating minc file "Kust_mnc//k_st_martin_1_013013_mri.mnc"
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.110.2008.04.29.10.16.22.890625.796193.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.118.2008.04.29.10.16.22.890625.796206.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.1.2008.04.29.10.16.22.890625.795985.IMA
>  ... (a few more like this)
>  Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.86.2008.04.29.10.16.22.890625.796154.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.9.2008.04.29.10.16.22.890625.795998.IMA
>  Duplicate slice position: ignoring file Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.94.2008.04.29.10.16.22.890625.796167.IMA
>  Getting data from file "Kust/K_ST_MARTIN.OT.CARD_KLAPPEN.13.102.2008.04.29.10.16.22.890625.796180.IMA" for slice 0.
>  (from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  ... (a few more like this)
>  (from micreate_group_variable): Variable 'dicom_0x0040' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA"
>  Creating minc file "Kust_mnc//k_st_martin_1_010010_mri.mnc"
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.10.1.2008.04.29.10.16.22.890625.1702044.IMA" for slice 0.
>  (from micreate_group_variable): Variable 'dicom_0x0002' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  ... (a few more like this)
>  (from micreate_group_variable): Variable 'dicom_0x5000' is not a standard MINC variable
>  micreate_group_variable: MINC package entry point
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.101.2008.04.29.10.16.22.890625.799255.IMA"
>  ...
>  Reading headers from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.11.1.2008.04.29.10.16.22.890625.1702201.IMA"
>  ************** Error reading slice position ***************
>  ************* Error reading slice orientation *************
>  Creating minc file "Kust_mnc//k_st_martin_1_001001_mri.mnc"
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.10.2008.04.29.10.16.22.890625.797890.IMA" for slice 0.
>  Using blank image for slice 1 (:).
>  ... (same message for slices 2-87)
>  Using blank image for slice 88 (:).
>  Using blank image for slice 89 (:).
>  Getting data from file "Kust/K_ST_MARTIN.XA.CARD_KLAPPEN.1.100.2008.04.29.10.16.22.890625.799240.IMA" for slice 90.
>  G
>
>  The end result is a bunch of minc files featuring large blank subvolumes.
>
>  Can anyone suggest a course of action?
>
>  Cheers,
>
>  Michel
>
>  Michel Audette, Ph.D.
>  Innovation Center Computer Assisted Surgery (ICCAS)
>  Semmelweisstra?e 14
>  Leipzig, Germany
>  Phone: ++49 (0) 341 / 97 - 1 20 13
>  Fax: ++49 (0) 341 / 97 - 1 20 09
>
>
>  _______________________________________________
>  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


From steve at sumost.ca  Wed Apr 30 14:16:21 2008
From: steve at sumost.ca (Steve M. Robbins)
Date: Wed, 30 Apr 2008 13:16:21 -0500
Subject: [MINC-users] dcm2mnc error,
 seems related to slice	position/orientation
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6902020056@MRZS152229.medizin.uni-leipzig.de>
References: <115a643d0804300725r1a08c04cy65781de14404369@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6902020056@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <20080430181621.GA28243@sumost.ca>

On Wed, Apr 30, 2008 at 04:44:14PM +0200, Audette, Michel wrote:
> Hi again, 
> 
> in any event, dcm2mnc winges with this particular data set: 
> maudette at icaw164201:~/data/data/Dyna_CT> dcm2mnc Kann/*.IMA Kann_mnc/ -clob -verbose
> Checking file types...
> File Kann/KANN.OT.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.1000.1.2008.04.21.13.58.31.718750.1245303.IMA appears to be DICOM (CD/Export).
> WARNING: Failed to find image position
> ...

It appears that you've got X-ray, which is projection data.  From the
errors (about direction cosines), I'd bet that dcm2mnc expects 3D data


-Steve

From Michel.Audette at medizin.uni-leipzig.de  Wed Apr 30 15:08:33 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 30 Apr 2008 21:08:33 +0200
Subject: [MINC-users] dcm2mnc error,
	seems related to slice	position/orientation
References: <115a643d0804300725r1a08c04cy65781de14404369@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6902020056@MRZS152229.medizin.uni-leipzig.de>
	<20080430181621.GA28243@sumost.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E690202005A@MRZS152229.medizin.uni-leipzig.de>

Hi Steve, 
 
that would make sense. I don't know much about these data. I was expecting something 3D, as it is called  DynaCT. I'll look at it with a Dicom viewer. 
 
Best regards, 
 
Michel

________________________________

From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Steve M. Robbins
Sent: Wed 4/30/2008 8:16 PM
To: MINC users mailing list
Subject: Re: [MINC-users] dcm2mnc error, seems related to slice position/orientation



On Wed, Apr 30, 2008 at 04:44:14PM +0200, Audette, Michel wrote:
> Hi again,
>
> in any event, dcm2mnc winges with this particular data set:
> maudette at icaw164201:~/data/data/Dyna_CT> dcm2mnc Kann/*.IMA Kann_mnc/ -clob -verbose
> Checking file types...
> File Kann/KANN.OT.CORONARY_DIAGNOSTIC_CORONARY_CATHETERIZATION.1000.1.2008.04.21.13.58.31.718750.1245303.IMA appears to be DICOM (CD/Export).
> WARNING: Failed to find image position
> ...

It appears that you've got X-ray, which is projection data.  From the
errors (about direction cosines), I'd bet that dcm2mnc expects 3D data


-Steve
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From sean at rogue-research.com  Wed Apr 30 16:11:19 2008
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 30 Apr 2008 16:11:19 -0400
Subject: [MINC-users] For the OSX 10.5 crash test dummies.
In-Reply-To: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>
References: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>
Message-ID: <20080430201119.1405142100@kingu.local>

On 4/11/08 12:53 PM, Andrew Janke said:

>Thanks to Alexandre (the current "record" holder in the minc
benchmarks) here:
>
>   http://en.wikibooks.org/wiki/MINC/Benchmarks
>
>I have now compiled some Leopard 10.5 64bit MINC2 binaries here:
>
>   http://packages.bic.mni.mcgill.ca/osx-10.5/
>
>These have been compiled on a 10.5 MacPro using 64 bit libraries.  I
>myself did not compile netcdf/hdf/netpbm in 64 bit but understand from
>the person who did that it took a bit of pain. ;)

Are there installers anywhere for a Universal Binary version of minc? 
Or at least for 32bit PowerPC?  I've looked on <http://
packages.bic.mni.mcgill.ca> but everything seems to be Intel-only or
several years old.

Thanks,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From kojinet at bic.mni.mcgill.ca  Wed Apr 30 17:56:48 2008
From: kojinet at bic.mni.mcgill.ca (Ji Hyum KO)
Date: Wed, 30 Apr 2008 17:56:48 -0400
Subject: [MINC-users] t threshold for corrected p value of Aston's method
Message-ID: <Pine.SGI.4.58.0804301727290.1048411@yorick.bic.mni.mcgill.ca>

Hi all,

I am trying to understand how the statistics works in the raclopride PET
studies using Aston's method.

It may sound ridiculous, but I don't really understand what the t
threshould should be for the corrected p value.

As far as I understand, I should calculate the t threshold based on
Worsely et al., Human Brain Mapping, 1996.
I am really sure that it is very well-written famous paper, but I
couldn't figure out how to calculate the t-threshold in the given
conditions.

I found a raclopride instruction in the phpwiki in the follwoing link.
http://wiki.bic.mni.mcgill.ca/index.php/RacloprideInstructions
It says everything (t value) above 3.5 or less than -3.5 is significant.
I don't think this is true since I found the following papers saying
different t threshold, probably due to the different number of subjects.

Boileau et al., 2007, t>4.2, 8 subjects.
Hakyemex et al., 2008, t>3.85, 10 subjects.

Is there any easy way to calculate t threshold for p<0.05 (corrected)?

And, is it going to be the same even if I consider the whole brain rather
than just striatum, e.g., fallypride study?

Thanks,

Ji Hyun



From a.janke at gmail.com  Wed Apr 30 19:57:54 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 1 May 2008 09:57:54 +1000
Subject: [MINC-users] For the OSX 10.5 crash test dummies.
In-Reply-To: <20080430201119.1405142100@kingu.local>
References: <d747ed50804101953m3e89e779x9b1cfa69ff5f16d3@mail.gmail.com>
	<20080430201119.1405142100@kingu.local>
Message-ID: <d747ed50804301657m42389b04m1b007306848871f8@mail.gmail.com>

>  Are there installers anywhere for a Universal Binary version of minc?
>  Or at least for 32bit PowerPC?  I've looked on <http://
>  packages.bic.mni.mcgill.ca> but everything seems to be Intel-only or
>  several years old.


I build essentially what people ask for and for what platforms I have
access to! :)

The only access I have to older Mac hardware is a PowerPC Tiger
machine.  Will this do what you want?  I have no idea how to build a
universal binary (never looked into it as I figured in 6 months there
would be no point) though...



a