From a.janke at gmail.com  Fri Aug  1 00:32:48 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 1 Aug 2008 14:32:48 +1000
Subject: [MINC-users] reference for Display and Register
In-Reply-To: <Pine.SGI.4.58.0807291307490.1016680@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0807291307490.1016680@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50807312132k589f6ba1ofb88c2f319bff3b2@mail.gmail.com>

Hi Laurence,

The only "reference" that I know for them is the web one. ie:

   www.bic.mni.mcgill.ca/software/minc


a

On Wed, Jul 30, 2008 at 03:10, Laurence MERCIER
<laurence at bic.mni.mcgill.ca> wrote:
> Hello dear minc users,
>
> I am writing an article in which I mention Display and Register. I would
> like to know if there is an article or a tech report that
> describes these tools that I could use as reference?
>
> Thank you for your help!
>
> Laurence
>
> __________________________________
> Laurence Mercier, PhD student
>
> McConnell Brain Imaging Center
> Montreal Neurological Institute
> 3801 University St, room: WB-320
> Montreal (QC), H3A 2B4
> CANADA
>
> tel: +1 514.398.1573
> fax: +1 514.398.2975
> __________________________________
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From a.janke at gmail.com  Fri Aug  1 00:38:57 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 1 Aug 2008 14:38:57 +1000
Subject: [MINC-users] determinant of non-linear local deformation fields
In-Reply-To: <Pine.SGI.4.58.0807291121150.971893@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0807291121150.971893@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50807312138k1cb3600fuaf2a5b4dbc3233c@mail.gmail.com>

Hi Marc,

On Wed, Jul 30, 2008 at 01:38, Marc BOUFFARD <bouffard at bic.mni.mcgill.ca> wrote:
> I have a question about deformation grids obtained from non-linear
> registration using nlpfit.  These grids contain the 3D displacements at
> each voxel applied to the source to match the template or to the template
> to match the source?

(note that this all presumes you did something like this: where
fred.mnc is our input subject)

   bestlinreg fred.mnc template.mnc linear_part.xfm
   nlpfit -init_xfm linear_part.xfm fred.mnc template.mnc nonlinear_part.xfm

If this is so then the nlxfm is from the source to the target. (after
the linear transformation if there is one). This incidentally is why
we calculate a model to individual transformation when we want to
average a number of transformations during building a model.

> Now if the determinant is calculated from those grids with mincblob and it
> is found that voxel x has a value greater than 1.  Does this mean the
> region in the neighborhood of x has expanded relative to the source  or
> relative to the target?

Perhaps best by example:

0.5 == the area in question is 50% smaller in the template than the source
1 == no change
1.5 == the area in question is 50% larger in the template than the source.

> In a further step, to obtain modulated VBM data should the standard VBM
> data be multiplied by the determinant of the Jacobian matrix or its
> inverse?

You lost me, what do you define as "modulated" VBM data?  I would take
a punt there are a few different takes on it.


-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From bouffard at bic.mni.mcgill.ca  Thu Aug  7 11:42:59 2008
From: bouffard at bic.mni.mcgill.ca (Marc BOUFFARD)
Date: Thu, 7 Aug 2008 11:42:59 -0400
Subject: [MINC-users] determinant of non-linear local deformation fields
 (fwd)
Message-ID: <Pine.SGI.4.58.0808071137550.239127@yorick.bic.mni.mcgill.ca>



On Fri, 1 Aug 2008, Andrew Janke wrote:

> Hi Marc,
>
> On Wed, Jul 30, 2008 at 01:38, Marc BOUFFARD <bouffard at bic.mni.mcgill.ca> wrote:
> > I have a question about deformation grids obtained from non-linear
> > registration using nlpfit.  These grids contain the 3D displacements at
> > each voxel applied to the source to match the template or to the template
> > to match the source?
>
> (note that this all presumes you did something like this: where
> fred.mnc is our input subject)
>
>    bestlinreg fred.mnc template.mnc linear_part.xfm
>    nlpfit -init_xfm linear_part.xfm fred.mnc template.mnc nonlinear_part.xfm
>
> If this is so then the nlxfm is from the source to the target. (after
> the linear transformation if there is one). This incidentally is why
> we calculate a model to individual transformation when we want to
> average a number of transformations during building a model.
>
> > Now if the determinant is calculated from those grids with mincblob and it
> > is found that voxel x has a value greater than 1.  Does this mean the
> > region in the neighborhood of x has expanded relative to the source  or
> > relative to the target?
>
> Perhaps best by example:
>
> 0.5 == the area in question is 50% smaller in the template than the source
> 1 == no change
> 1.5 == the area in question is 50% larger in the template than the source.
>
> > In a further step, to obtain modulated VBM data should the standard VBM
> > data be multiplied by the determinant of the Jacobian matrix or its
> > inverse?
>
> You lost me, what do you define as "modulated" VBM data?  I would take
> a punt there are a few different takes on it.
>
I am trying to apply the method used in SPM VBM but with the minc tools.
Assuming we have the gray matter classified images linearly transformed
then in "standard VBM" we would just apply the linear model to that and
solve for a contrast of interest with glim_image, e.g., group 1 - group 2.
Now, if the data is additionally non-linearly transformed another step
called modulation can be applied:

"in order to preserve the actual amounts of gray matter within each
structure, a further processing step that multiplies (modulates) the
images by the relative voxel volumes can be incorporated.  These relative
volumes are simply the Jacobian determinants of the deformation field."
(Ashburner and Friston, Neuroimage 11 805-821)

So according to that we just need to multiply by the Jacobian determinants
but apparently the deformation fields calculated in SPM are relative to
the target and not the source like with nlpfit (does that make sense?).
So, logically if the deformation fields are relative to the source to the
target(as you mention above) we should multiply by the voxel-wise inverse
of the Jacobian determinant to get the same effect as with SPM?

Marc

From a.janke at gmail.com  Thu Aug  7 17:31:09 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 8 Aug 2008 07:31:09 +1000
Subject: [MINC-users] determinant of non-linear local deformation fields
	(fwd)
In-Reply-To: <Pine.SGI.4.58.0808071137550.239127@yorick.bic.mni.mcgill.ca>
References: <Pine.SGI.4.58.0808071137550.239127@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50808071431l7bb1cc5el73b6340a00e4a16c@mail.gmail.com>

2008/8/8 Marc BOUFFARD <bouffard at bic.mni.mcgill.ca>:

> I am trying to apply the method used in SPM VBM but with the minc tools.
> Assuming we have the gray matter classified images linearly transformed
> then in "standard VBM" we would just apply the linear model to that and
> solve for a contrast of interest with glim_image, e.g., group 1 - group 2.
> Now, if the data is additionally non-linearly transformed another step
> called modulation can be applied:
>
> "in order to preserve the actual amounts of gray matter within each
> structure, a further processing step that multiplies (modulates) the
> images by the relative voxel volumes can be incorporated.  These relative
> volumes are simply the Jacobian determinants of the deformation field."
> (Ashburner and Friston, Neuroimage 11 805-821)
>
> So according to that we just need to multiply by the Jacobian determinants
> but apparently the deformation fields calculated in SPM are relative to
> the target and not the source like with nlpfit (does that make sense?).
> So, logically if the deformation fields are relative to the source to the
> target(as you mention above) we should multiply by the voxel-wise inverse
> of the Jacobian determinant to get the same effect as with SPM?

Correct.  (hows that for a short answer to a long question! :)



-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From peter.neelin at gmail.com  Mon Aug 11 21:01:17 2008
From: peter.neelin at gmail.com (Peter Neelin)
Date: Mon, 11 Aug 2008 21:01:17 -0400
Subject: [MINC-users] MINC convention for oblique imaging
In-Reply-To: <d747ed50807231704g4a19630sd1dff96f4df4066e@mail.gmail.com>
References: <1216826665.12330.20.camel@mouse17.phenogenomics.ca>
	<d747ed50807231704g4a19630sd1dff96f4df4066e@mail.gmail.com>
Message-ID: <eb42a8160808111801n52f52043i5a4ca2dda0e5ad0d@mail.gmail.com>

I'm a little behind on my BIC e-mail, but I hope that I am not too
late to comment:

On 7/23/08, Andrew Janke <a.janke at gmail.com> wrote:
> > By MINC definition, xyz dimensions are defined in patient coordinates
>
>
> Um maybe? :)  I always was of the opinion that the world co-ordinates
>  referred to the scanner. And thus 0,0,0 for a MRI machine is at the
>  centre of the gradients and 0,0,0 on some PET machines is at the
>  patients feet.

Leila is right. Here's a quote from the 1.4 programmer's guide:

The MINC standard defines how spatial coordinates should be oriented
relative to patients. Files are free to have data stored in the
desired direction, but positive world coordinates are given a definite
meaning in the medical imaging context. The standard is that the
positive x axis points from the patient's left to right, the positive
y axis points from posterior to anterior and the positive z axis
points from inferior to superior.


>  > Therefore, in an oblique dataset, do MINC xyz dimensions refer to
>  > patient coordinates or MRI voxel coordinates?

The xyz dimensions are obviously along the sampling axes, but the
labels are chosen by finding the patient axis that is closest to the
sampling axis. You can, of course come up with pathological cases that
are ambiguous (especially with non-orthogonal axes), but then you just
have to break the tie. You should only use a label once (don't use two
x axes and no y axis).

> The answer to this is to just think of the MINC world space as a
>  sampling of the scanner, if a patient head happens to be in there then
>  good and well. :)  Of course this does beg the question of why there
>  are -coronal type options in MINC but my answer to this would be "ease
>  of use for 90% of users"

Actually, it's software developer laziness (me included) that leads to
using scanner coordinates. One should take into account whether the
patient is prone or supine, etc., but frequently software just uses
the scanner axes 'cause it's easier and people usually lie on their
backs (brains without bodies are another matter). Note that if you are
converting from DICOM, then you can just use Image Position Patient
and Image Orientation Patient since these are (fairly evidently)
patient-based, or should be if properly implemented and the patient
orientation is set correctly during the scan.

Peter
-- 
Peter Neelin
(peter.neelin at gmail.com)

From a.janke at gmail.com  Wed Aug 13 02:30:10 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 13 Aug 2008 16:30:10 +1000
Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug
In-Reply-To: <d747ed50807241923s79ef6fe8yc177863df4078c2e@mail.gmail.com>
References: <20080722135437.N18530@mrs.mni.mcgill.ca>
	<d747ed50807241923s79ef6fe8yc177863df4078c2e@mail.gmail.com>
Message-ID: <d747ed50808122330q2ba6a270see1ece58fc732331@mail.gmail.com>

> Thanks for the report.  However you lost me a bit as I cant reproduce
> this on my 64 bit Ubuntu hardy machine.

Ok, after a bunch of digging about and talking to Claude about this I
think we have a fix for this.  But I can't really test things as I
myself do not experience the bug! :)

In any case the fix is now in CVS, I will make a new MINC release soon
but would like to have this fix tested first. Alex, can you get the
latest version of MINC from CVS? (note that the fix will only be in
the 2.X release series and not in the 1.X branch.

What we decided to do in the end was to add an enum to rawtominc so
that it does not cause the bug in question via its use of ParseArgv.

Let me know if this works for you.


-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From Michel.Audette at medizin.uni-leipzig.de  Wed Aug 13 04:33:44 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 13 Aug 2008 10:33:44 +0200
Subject: [MINC-users] getting patient data out of minc volumes
Message-ID: <160E3DD4FB702C4CB860C65186686E6902425180@MRZS152229.medizin.uni-leipzig.de>

Hi all, 

 

I am writing ITK based processing of MINC volumes, and trying to make it as compatible as possible to DICOM processing that we have on our platform, which is based on OpenMAF in addition to ITK and VTK. 

 

This DICOM stuff displays patient information, such as patient name, patient ID, and so on. Does anyone have example code that does this with MINC? 

 

Best wishes, 

 

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 vikingy at gmail.com  Wed Aug 13 05:02:07 2008
From: vikingy at gmail.com (vikingy)
Date: Wed, 13 Aug 2008 17:02:07 +0800
Subject: [MINC-users] getting patient data out of minc volumes
References: <160E3DD4FB702C4CB860C65186686E6902425180@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <200808131702051697725@gmail.com>

Using " mincheader xxx.mnc", we can get the basic infornation of data, such as patient name,age and so on. So I guess you can refer to the code of the "mincheader" and "mincdump" in minc package.

bin lv


2008-08-13 



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



???????? Audette, Michel 
?????????? 2008-08-13  16:35:58 
???????? MINC users mailing list 
?????? 
?????? [MINC-users] getting patient data out of minc volumes 
 
Hi all, 

I am writing ITK based processing of MINC volumes, and trying to make it as compatible as possible to DICOM processing that we have on our platform, which is based on OpenMAF in addition to ITK and VTK. 

This DICOM stuff displays patient information, such as patient name, patient ID, and so on. Does anyone have example code that does this with MINC? 

Best wishes, 

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 baghdadi at phenogenomics.ca  Wed Aug 13 12:14:54 2008
From: baghdadi at phenogenomics.ca (Leila Baghdadi)
Date: Wed, 13 Aug 2008 12:14:54 -0400
Subject: [MINC-users] getting patient data out of minc volumes
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6902425180@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E6902425180@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <1218644094.5554.14.camel@mouse17.phenogenomics.ca>

Hi Michel,

I have written MINC2 support for ITK a few years ago. This code is now
part of review directory of ITK. you can use it to read and write
MINC2.0 files (no minc1.0 support) , however there is no code for
reading patient information.

so what you can do is add that code (minc function calls for retrieving
patient information) to the MINC2.0 itk factory. So all the information
can be read along with image information.

Hope this helps

Leila

On Wed, 2008-13-08 at 10:33 +0200, Audette, Michel wrote:
> Hi all, 
> 
>  
> 
> I am writing ITK based processing of MINC volumes, and trying to make it as compatible as possible to DICOM processing that we have on our platform, which is based on OpenMAF in addition to ITK and VTK. 
> 
>  
> 
> This DICOM stuff displays patient information, such as patient name, patient ID, and so on. Does anyone have example code that does this with MINC? 
> 
>  
> 
> Best wishes, 
> 
>  
> 
> 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  Thu Aug 14 03:32:49 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 14 Aug 2008 09:32:49 +0200
Subject: [MINC-users] getting patient data out of minc volumes
In-Reply-To: <1218644094.5554.14.camel@mouse17.phenogenomics.ca>
References: <160E3DD4FB702C4CB860C65186686E6902425180@MRZS152229.medizin.uni-leipzig.de>
	<1218644094.5554.14.camel@mouse17.phenogenomics.ca>
Message-ID: <160E3DD4FB702C4CB860C65186686E690242518D@MRZS152229.medizin.uni-leipzig.de>

Hi Leila, 

thanks for your kind reply. I have to get up to speed on this factory mechanism, but this soundsl like a way to proceed. I'll see if I can track down some examples. 

Best wishes, 

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: August 13, 2008 6:15 PM
To: MINC users mailing list
Subject: Re: [MINC-users] getting patient data out of minc volumes

Hi Michel,

I have written MINC2 support for ITK a few years ago. This code is now
part of review directory of ITK. you can use it to read and write
MINC2.0 files (no minc1.0 support) , however there is no code for
reading patient information.

so what you can do is add that code (minc function calls for retrieving
patient information) to the MINC2.0 itk factory. So all the information
can be read along with image information.

Hope this helps

Leila

On Wed, 2008-13-08 at 10:33 +0200, Audette, Michel wrote:
> Hi all, 
> 
>  
> 
> I am writing ITK based processing of MINC volumes, and trying to make it as compatible as possible to DICOM processing that we have on our platform, which is based on OpenMAF in addition to ITK and VTK. 
> 
>  
> 
> This DICOM stuff displays patient information, such as patient name, patient ID, and so on. Does anyone have example code that does this with MINC? 
> 
>  
> 
> Best wishes, 
> 
>  
> 
> 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 alex at bic.mni.mcgill.ca  Sun Aug 17 20:18:48 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sun, 17 Aug 2008 20:18:48 -0400
Subject: [MINC-users] Register's configure test for GLUT
Message-ID: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>

Hello all,

Is there anybody familiar enough with autoconf/make to fix Register's
(and probably Display's) configure setup? I just spent a somewhat
frustrating amount of time trying to figure out why I couldn't get
register to link on a ubuntu hardy box. As it turns out, the configure
phase of the register package runs some tests to determine whether the
GLUT library is available; but when these tests fail, it happily
continues, resulting an a bunch of awfully confusing linking errors at
the end, of this nature:

   Graphics/libbicgl.a(glut_windows.o): In function `WS_add_idle_function':
   Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1151: undefined
reference to `glutIdleFunc'
   Graphics/libbicgl.a(glut_windows.o): In function `flip_screen_y':
   Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:919: undefined
reference to `glutGet'

(and about 500 lines of same)

Now through all of this, I had libglut (and all other prerequisites I
thought) installed. Tracing things back, the error starts in the
configure phase:

   checking for GLUT library... no

But configure carries on, now leaving -lglut off the list of libraries
to link in. From config.log, it turns out that configure not actually
fails on a missing libglut, but on a missing libXmu and libXi.
However, these don't actually appear to be required at all; forcefully
adding -lglut to the linking stage produces a working executable.

In summary:

- the configure stage for Register-1.3.6 tests for libglut, but does
not throw an error when that test fails;
- the existing test for libglut depends on libXmu and libXi, but these
are not required at all

I think the solution is to modify the test for libglut such that it
does not depend on libXmu and libXi, and also to make it required that
the configure passes that test. I'm afraid I am not familiar enough
with this to make the change myself though - any takers? Googling I
see that I am not the first one to be stumped by this :)

Lastly, I should say that a bandaid (but working) solution on Ubuntu is to

  apt-get install libxmu-dev libxi-dev

But really, that is just installing some libraries just to convince a
broken configure script to do the right thing :)

-- Alex



So it seems like the check for the GLUT library is somewhat broken. I
would say it should either test for libXmu and libXi explicitly (if
these are actually needed!)

From a.janke at gmail.com  Sun Aug 17 20:42:12 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 18 Aug 2008 10:42:12 +1000
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
Message-ID: <d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>

2008/8/18 Alex Zijdenbos <alex at bic.mni.mcgill.ca>:
> Is there anybody familiar enough with autoconf/make to fix Register's
> (and probably Display's) configure setup? I just spent a somewhat
> frustrating amount of time trying to figure out why I couldn't get
> register to link on a ubuntu hardy box. As it turns out, the configure
> phase of the register package runs some tests to determine whether the
> GLUT library is available; but when these tests fail, it happily
> continues, resulting an a bunch of awfully confusing linking errors at
> the end, of this nature:

:) not that I should be laughing mind you... :)  Still this teaches
the value of checking config.log.
Still I only laugh because I have done the same thing countless times
with other packages.

> But configure carries on, now leaving -lglut off the list of libraries
> to link in. From config.log, it turns out that configure not actually
> fails on a missing libglut, but on a missing libXmu and libXi.
> However, these don't actually appear to be required at all; forcefully
> adding -lglut to the linking stage produces a working executable.

Well, they are required, just not by Register for the parts of glut
that it uses. I would be loathe to remove them as this is the
"standard" GLUT checking thing that you get from the autoconf archive.

> I think the solution is to modify the test for libglut such that it
> does not depend on libXmu and libXi, and also to make it required that
> the configure passes that test. I'm afraid I am not familiar enough
> with this to make the change myself though - any takers? Googling I
> see that I am not the first one to be stumped by this :)

Well to me the best fix is to fix the configure.in file so that it
checks the return values and dies "appropriately", I have attached
what I think it should be.  Try this and then autogen.sh and configure
again and let me know how it goes.

> Lastly, I should say that a bandaid (but working) solution on Ubuntu is to
>
>  apt-get install libxmu-dev libxi-dev

Or apt-get install mincbundle... :)

> But really, that is just installing some libraries just to convince a
> broken configure script to do the right thing :)

Not broken, just "optimistic".


a

From alex at bic.mni.mcgill.ca  Sun Aug 17 20:59:59 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sun, 17 Aug 2008 20:59:59 -0400
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
Message-ID: <e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>

> :) not that I should be laughing mind you... :)  Still this teaches
> the value of checking config.log.
> Still I only laugh because I have done the same thing countless times
> with other packages.

Same here it seems... in this case though it took me a long while to
even think to check the configure log, as it didn't fail :/

>> But configure carries on, now leaving -lglut off the list of libraries
>> to link in. From config.log, it turns out that configure not actually
>> fails on a missing libglut, but on a missing libXmu and libXi.
>> However, these don't actually appear to be required at all; forcefully
>> adding -lglut to the linking stage produces a working executable.
>
> Well, they are required, just not by Register for the parts of glut
> that it uses. I would be loathe to remove them as this is the
> "standard" GLUT checking thing that you get from the autoconf archive.

Hmmm - so I would say there is something that doesn't entirely line up
there. If these dependencies exist, shouldn't installing the glut
packages draw these other libraries in as well? I guess the
Ubuntu/Debian package dependencies don't follow the same conventions
or logic as the autoconf archive...

>> I think the solution is to modify the test for libglut such that it
>> does not depend on libXmu and libXi, and also to make it required that
>> the configure passes that test. I'm afraid I am not familiar enough
>> with this to make the change myself though - any takers? Googling I
>> see that I am not the first one to be stumped by this :)
>
> Well to me the best fix is to fix the configure.in file so that it
> checks the return values and dies "appropriately", I have attached
> what I think it should be.  Try this and then autogen.sh and configure
> again and let me know how it goes.

Attached where?

>> Lastly, I should say that a bandaid (but working) solution on Ubuntu is to
>>
>>  apt-get install libxmu-dev libxi-dev
>
> Or apt-get install mincbundle... :)

On that note, what is the 'minc-tools' package that has ended up in
the standard ubuntu distribution, and how did it get there? :)

>> But really, that is just installing some libraries just to convince a
>> broken configure script to do the right thing :)
>
> Not broken, just "optimistic".

As opposed to the state of its users I guess

-- A

From a.janke at gmail.com  Sun Aug 17 21:06:06 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 18 Aug 2008 11:06:06 +1000
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
	<e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
Message-ID: <d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>

> Hmmm - so I would say there is something that doesn't entirely line up
> there. If these dependencies exist, shouldn't installing the glut
> packages draw these other libraries in as well? I guess the
> Ubuntu/Debian package dependencies don't follow the same conventions
> or logic as the autoconf archive...

Very likely.  I would say it is more a case of GLUT being a crusty old
thing that is not used much anymore (in deference to QT/itk/vtk/GTK+
and thus the dependencies are not that well checked.

> Attached where?

I guess the list strips attachments. Try this:

http://mavis.anu.edu.au/minc-beta/configure.in

> On that note, what is the 'minc-tools' package that has ended up in
> the standard ubuntu distribution, and how did it get there? :)

Steve Robbins. (And he still maintains it).  It is a proper "Debian"
build of MINC itself in which the library, dev stuff and tools are
split up as they "should be" according to Debian policy.



a

From alex at bic.mni.mcgill.ca  Sun Aug 17 22:59:55 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sun, 17 Aug 2008 22:59:55 -0400
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
	<e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
	<d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
Message-ID: <e758a6650808171959t6c51f891nab85f6d806ff909b@mail.gmail.com>

That configure.in works - at least that will alert (loudly) anybody
trying to build Register and friends that something is amiss right at
the outset... I would suggest to put it in the next release of the
affected packages.

Thanks!

-- A

On Sun, Aug 17, 2008 at 9:06 PM, Andrew Janke <a.janke at gmail.com> wrote:
>> Hmmm - so I would say there is something that doesn't entirely line up
>> there. If these dependencies exist, shouldn't installing the glut
>> packages draw these other libraries in as well? I guess the
>> Ubuntu/Debian package dependencies don't follow the same conventions
>> or logic as the autoconf archive...
>
> Very likely.  I would say it is more a case of GLUT being a crusty old
> thing that is not used much anymore (in deference to QT/itk/vtk/GTK+
> and thus the dependencies are not that well checked.
>
>> Attached where?
>
> I guess the list strips attachments. Try this:
>
> http://mavis.anu.edu.au/minc-beta/configure.in
>
>> On that note, what is the 'minc-tools' package that has ended up in
>> the standard ubuntu distribution, and how did it get there? :)
>
> Steve Robbins. (And he still maintains it).  It is a proper "Debian"
> build of MINC itself in which the library, dev stuff and tools are
> split up as they "should be" according to Debian policy.
>
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Mon Aug 18 01:21:37 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 18 Aug 2008 15:21:37 +1000
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <e758a6650808171959t6c51f891nab85f6d806ff909b@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
	<e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
	<d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
	<e758a6650808171959t6c51f891nab85f6d806ff909b@mail.gmail.com>
Message-ID: <d747ed50808172221u21dd6232jccbdb890b3414f3d@mail.gmail.com>

2008/8/18 Alex Zijdenbos <alex at bic.mni.mcgill.ca>:
> That configure.in works - at least that will alert (loudly) anybody
> trying to build Register and friends that something is amiss right at
> the outset... I would suggest to put it in the next release of the
> affected packages.

OK, I have checked changes in to fix this in Register and Display to
CVS. expect to see them in the next release


a

From jammam2 at yahoo.com  Tue Aug 19 08:29:27 2008
From: jammam2 at yahoo.com (Jamila Ahdidan)
Date: Tue, 19 Aug 2008 05:29:27 -0700 (PDT)
Subject: [MINC-users] training classify
In-Reply-To: <d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
Message-ID: <952054.21698.qm@web65413.mail.ac4.yahoo.com>


Hi all,
  I'm trying to find out how precisely I can use classify. I have created one tag file per minc file and I have in all 10 images (1 image per subject). I know that classify can save a training and load one too. Now my question is, how can I create a new training on the basis of the previously saved training and the tag file of the next image? I have seen that classify only either take a tag file or a training file. Is there a way to make it take both, or how do I use all my tags and train recursively?
   
  Many regards,
  Jamila

       

From nikelski at bic.mni.mcgill.ca  Tue Aug 19 13:02:25 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Tue, 19 Aug 2008 13:02:25 -0400
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <d747ed50808172221u21dd6232jccbdb890b3414f3d@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
	<e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
	<d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
	<e758a6650808171959t6c51f891nab85f6d806ff909b@mail.gmail.com>
	<d747ed50808172221u21dd6232jccbdb890b3414f3d@mail.gmail.com>
Message-ID: <e12172550808191002l2c7a3ce4y31fb424ccfef16d6@mail.gmail.com>

Hi List,

   I keep inadvertently  using my gmail address when sending to the
list ... resulting in my mail being tossed.  So, I'm resending my
response from yesterday -- assuming it didn't make it to the list.
-Jim


---------- Forwarded message ----------

Hi all,

  I also encountered this exact problem a few months ago, i.e. the
GLUT error which is in fact a misreported libx* error.  I probably
should have posted something about this ... would have saved Alex some
degree of pain.  At any rate, although Andrew has written a fix for
this specific problem, I would suggest that the real solution to
problems such as these is to move to a build system which can be
easily groked by all.

  Enter CMake.  Having beaten my head against the autotools for more
time than I would like to admit, I've started to use CMake.  Unlike
the autotools, CMake is a tool that can be fairly easily understood
and used by those of us who just want to build software without having
to make it into a profession (no m4!!).  Conversion to CMake, while
obviously dependent upon project complexity, is generally a fairly
straight-forward process.  I myself have (as a proof of concept)
converted some BIC packages to CMake with little difficulty -- which
is impressive, given my general level of inadequacy in these things.
Andrew, I believe that you have been using CMake; how has your
experience been with it?

Cheers,

-Jim


On Mon, Aug 18, 2008 at 1:21 AM, Andrew Janke <a.janke at gmail.com> wrote:
> 2008/8/18 Alex Zijdenbos <alex at bic.mni.mcgill.ca>:
>> That configure.in works - at least that will alert (loudly) anybody
>> trying to build Register and friends that something is amiss right at
>> the outset... I would suggest to put it in the next release of the
>> affected packages.
>
> OK, I have checked changes in to fix this in Register and Display to
> CVS. expect to see them in the next release
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From Jean-Francois.Malouin at bic.mni.mcgill.ca  Tue Aug 19 15:46:19 2008
From: Jean-Francois.Malouin at bic.mni.mcgill.ca (Jean-Francois Malouin)
Date: Tue, 19 Aug 2008 15:46:19 -0400
Subject: [MINC-users] Display
In-Reply-To: <789977B7317DE4429C8F38E8A8A58C1801DBEEC6@usctmx1132.merck.com>
References: <789977B7317DE4429C8F38E8A8A58C1801DBEEC6@usctmx1132.merck.com>
Message-ID: <20080819194619.GA553167@yorick.bic.mni.mcgill.ca>

Any help for those fellows?

The biz displaimer frightens me. 
Will Merck launch their hound-lawyers at me? :)

jf

* Gurukar, Harsha <harsha_gurukar at merck.com> [20080819 15:39]:
> Folks --
> 
> We have Display compiled on SUSE Linux server running on AMD Opetron.
> The binary works on Redhat AS too.
> 
> Display works fine from Intel based 32 bit or 64 bit XP workstations
> connected to the Linux server via Reflections X, however, it crashes
> when connected from a AMD Opetron based 64 Bit XP workstation.
> 
> Any advise in troubleshooting would be helpful and appreciated.
> 
> Thanks! 
> Harsha
> 
> Harsha Gurukar
> Team Leader, Scientific Computing
> MRL Information Technology
> Merck & Co.,
> WP44C-2, West Point, PA. 19486
> +1 215-652-1709 (W)
> +1 267-421-8395 (Mobile)
> Harsha_Gurukar at Merck.com
> 
> 
> Notice:  This e-mail message, together with any attachments, contains
> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
> New Jersey, USA 08889), and/or its affiliates (which may be known
> outside the United States as Merck Frosst, Merck Sharp & Dohme or
> MSD and in Japan, as Banyu - direct contact information for affiliates is
> available at http://www.merck.com/contact/contacts.html) that may be
> confidential, proprietary copyrighted and/or legally privileged. It is
> intended solely for the use of the individual or entity named on this
> message. If you are not the intended recipient, and have received this
> message in error, please notify us immediately by reply e-mail and
> then delete it from your system.

-- 
<? ><

From a.janke at gmail.com  Tue Aug 19 18:09:50 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 20 Aug 2008 08:09:50 +1000
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <e12172550808191002l2c7a3ce4y31fb424ccfef16d6@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
	<e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
	<d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
	<e758a6650808171959t6c51f891nab85f6d806ff909b@mail.gmail.com>
	<d747ed50808172221u21dd6232jccbdb890b3414f3d@mail.gmail.com>
	<e12172550808191002l2c7a3ce4y31fb424ccfef16d6@mail.gmail.com>
Message-ID: <d747ed50808191509w1d23f7b9r502a82243e651735@mail.gmail.com>

Hi Jim,

2008/8/20 EJ Nikelski <nikelski at bic.mni.mcgill.ca>:
>   I keep inadvertently  using my gmail address when sending to the
> list ... resulting in my mail being tossed.  So, I'm resending my
> response from yesterday -- assuming it didn't make it to the list.

Nope, didnt make it.

> I would suggest that the real solution to
> problems such as these is to move to a build system which can be
> easily groked by all.
>
>  Enter CMake.

Well first of you will note that there is a CMakeLists.txt thingo in
the base MINC package. This was written (by me!) for use in the
itkMINC module.

My experience with it so far has been somewhat positive (once I got my
head around the bootstraping problem -- ie: getting CMake onto your
system to start with).

So comments (in no particular order).

* There are no inbuilt "make dist" "make distcheck" type things with
the same ease of use of autoconf.

* There is far less out there in terms of documentation. I refuse to
buy a $80? manual for something that is "free". Especially as the
manual will change.

* CMake is strongly slanted towards VTK/ITK (no surprise there).

* There are far far less macros out there for use in other things
(like find me GLUT, find me GL, etc). You will note that I have a
cmake-modules/ dir in MINC that contains a few of these that I have
found/written. Perhaps this will change in time.

* CMake seems to me to be written for the purpose of building
executables and libraries (fair enough) whereas autoconf/automake also
caters for the package builders and testers amongst us.

* I like the dashboard stuff associated with CMake but have not found
time to make it go just yet.

Note that I am not making a case for/against CMake but now I reckon I
will continue with autoconf if only because of the enormous amount of
work required right now to shift everything.


-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From a.janke at gmail.com  Tue Aug 19 18:17:41 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 20 Aug 2008 08:17:41 +1000
Subject: [MINC-users] Display
In-Reply-To: <20080819194619.GA553167@yorick.bic.mni.mcgill.ca>
References: <789977B7317DE4429C8F38E8A8A58C1801DBEEC6@usctmx1132.merck.com>
	<20080819194619.GA553167@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50808191517o408c8b2fj9b995c207112ca8d@mail.gmail.com>

Hi Harsha,

> * Gurukar, Harsha <harsha_gurukar at merck.com> [20080819 15:39]:
>> We have Display compiled on SUSE Linux server running on AMD Opetron.
>> The binary works on Redhat AS too.
>>
>> Display works fine from Intel based 32 bit or 64 bit XP workstations
>> connected to the Linux server via Reflections X, however, it crashes
>> when connected from a AMD Opetron based 64 Bit XP workstation.

I haven't tried this specific setup myself (Reflection X costs Money!
:) and instead use Cygwin/X to do these sort of things. However I
would be surprised if it is the CPU type that is causing the crash in
Windows land.

I would be more pointing a finger at the graphics sub-system. Does the
AMD have an ATI graphics chip and the Intel and Intel graphics chip?
If so I would be hunting for the problem via the many bazillions of
ATI driver combos that seem to be out there for Windows users.
(Catalyst vs ATI vs vendor ATI...)

Failing that is there a chance that you can run Display locally (via
cygwin), this is the usual approach that I take in such cases.


-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From nikelski at bic.mni.mcgill.ca  Wed Aug 20 00:14:11 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Wed, 20 Aug 2008 00:14:11 -0400
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <d747ed50808191509w1d23f7b9r502a82243e651735@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
	<e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
	<d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
	<e758a6650808171959t6c51f891nab85f6d806ff909b@mail.gmail.com>
	<d747ed50808172221u21dd6232jccbdb890b3414f3d@mail.gmail.com>
	<e12172550808191002l2c7a3ce4y31fb424ccfef16d6@mail.gmail.com>
	<d747ed50808191509w1d23f7b9r502a82243e651735@mail.gmail.com>
Message-ID: <e12172550808192114l37cf1e39yfe2a0185016012e4@mail.gmail.com>

Hi all,

   Thanks for your feedback, Andrew.  I *did* notice the
CMakeLists.txt file in the MINC distro and wondered what you were up
to  ;)      I do believe, however, that since CMake development is
moving rather quickly (there appears to be an astonishing growth in
*.cmake modules), some of your earlier experiences with CMake may no
longer reflect the current CMake.  Let me address some of your points
...

> * There are no inbuilt "make dist" "make distcheck" type things with
> the same ease of use of autoconf.

  Correct, I do believe that a "make distcheck" functionality does not
yet exist, however, the current CPack mechanism does seem to do a
fairly reasonable job creating packages. I test converted the
"arguments" package (since it was fairly simple-ish, and it needed
some TLC) and I did:

cmake .. (within the build dir for out-of-source builds)
make
make test
make install
make package (creates a binary package)
make package_source (creates a source package)
**done**

  CPack can create all sorts of packages: tar.gz, .deb, dmg (not
tested yet) ... although there are a few gotchas (bugs) to look out
for.


>
> * There is far less out there in terms of documentation. I refuse to
> buy a $80? manual for something that is "free". Especially as the
> manual will change.

   Yup, the price of the manual is a bit steep, although many open
source projects use printed documentation as a "value add" in order to
generate some income for the developers.  Happily, the online
documentation has gotten much better, and is pretty much as good as
the book.


>
> * CMake is strongly slanted towards VTK/ITK (no surprise there).

  Ummmm ... not sure what "slanted" implies.  Yes, they're big users,
but so is the KDE4 project.  I can't see any down-side here.

>
> * There are far far less macros out there for use in other things
> (like find me GLUT, find me GL, etc). You will note that I have a

  Yeah, but given that these modules are written with a consistent
syntax (CMake), we are seeing lots of macros being written ... I
suspect, many by people who would not have dared try the same with m4.
 BTW, "FindOpenGL" (includes find GLU as well), and "FindGLUT" are
standard modules in CMake 2.6.  All we need is FindSoQT and FindCoin,
and I would be able to finally build brain-view on my OS X machine
using -frameworks.  I would like that.


>
> * CMake seems to me to be written for the purpose of building
> executables and libraries (fair enough) whereas autoconf/automake also
> caters for the package builders and testers amongst us.

  Perhaps, but things are changing rapidly.  CPack can do a reasonable
job packaging, and CTest makes writing unit tests a breeze.  The
"arguments" package had one test (which was broken), which I replaced
with 7 (which work).  Super simple to do.

>
> Note that I am not making a case for/against CMake but now I reckon I
> will continue with autoconf if only because of the enormous amount of
> work required right now to shift everything.
>

  I agree.  But does it really need to be an "all or nothing"
approach? Perhaps we could try implementing new projects using CMake,
in addition to allowing inspired (or bored?) users to fix/enhance
existing packages (as I did with the "arguments" package).  The
purpose, with reference back to the original problem that Alex
reported, is to make writing and maintaining these build scripts
easier, so that average developers would feel comfortable
trouble-shooting build problems, which in turn would make them more
likely to offer a fix.  So the idea is actually to make it possible to
better distribute responsibility for build scripts.

Now -- off to sleep.

-Jim

From Michel.Audette at medizin.uni-leipzig.de  Wed Aug 20 09:55:45 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 20 Aug 2008 15:55:45 +0200
Subject: [MINC-users] FW: min and max coordinates in minc vs dicom
Message-ID: <160E3DD4FB702C4CB860C65186686E69024251D5@MRZS152229.medizin.uni-leipzig.de>

Hi all, 

I'm playing with a MINC volume that was converted from DICOM, which has some unusual direction cosines,  and entering both volumes, MINC and DICOM, with ITK importers. I'm finding that there is a difference in min and max coordinates, and I'm having trouble ascertaining where the trouble is. 

For example, when typing mincheader, one sees the line:
dicom_0x0020:el_0x0032 = "-26.902344\\-197.40057\\-45.887484" ;

which mostly coincides with what I see when we load the data in DICOM format:
minx: -26.9 maxx: 75.5
miny: -197.4 maxy: -95.2
minz: -51.89 maxz: -12.59

Other data in mincheader include:
                xspace:step = -0.1953125 ;
                xspace:start = 26.80468775 ;
                xspace:direction_cosines = 1., 0., 0. ;

                yspace:step = -0.1953125 ;
                yspace:start = 193.094103137385 ;
                yspace:direction_cosines = 0., 0.99691733368886, 0.0784590962903196 ;

                zspace:step = 0.299075200106658 ;
                zspace:start = -67.2154025304974 ;
                zspace:direction_cosines = 0., -0.0784590962903196, 0.99691733368886 ;


doing a mincinfo produces
maudette at icaw164201:~/data/work/earWork/goodEarData> mincinfo etzold_emma_12792115_003002_mri_xyz.mnc
file: etzold_emma_12792115_003002_mri_xyz.mnc
image: signed__ short -32768 to 32767
image dimensions: xspace yspace zspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    512    -0.195312      26.8047
    yspace                    512    -0.195312      193.094
    zspace                    129     0.299075     -67.2154

We implemented a program that inverts the sign of step and start if the step is negative, from a minc import, and it produces 
minx: -26.8 maxx: 73
miny: -197.77 maxy: -97.97
minz: -51.86 maxz: -13.58

Can anyone help me make heads or tails of this discrepancy? 

How does a dicom to minc conversion produce negative spacing in x and y, and can this converter make a mistake with start and spacing size? Does it round off anything, or is it sensitive to non-standard cosine angles? 

Best wishes, 

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 rupe.brooks at gmail.com  Wed Aug 20 22:37:14 2008
From: rupe.brooks at gmail.com (Rupert Brooks)
Date: Wed, 20 Aug 2008 22:37:14 -0400
Subject: [MINC-users] FW: min and max coordinates in minc vs dicom
In-Reply-To: <160E3DD4FB702C4CB860C65186686E69024251D5@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69024251D5@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <a6cc33f0808201937jd3024c1o53393b789fa1aad7@mail.gmail.com>

Hi Michel,

I guess im having a little trouble determining if the problem exists
solely in the tool you are implementing, or in the DICOM/minc
conversion, or both.  But i will hazard a guess anyway that it may be
due to the way MINC defines its coordinate system.

if A is the rotation matrix, S is a diagonal matrix of the step sizes,
and O is the start, as listed by mincinfo, then the position of the
center of pixel X, in minc world, is

A*S(X+O)

In ITK, and possibly in DICOM, but i am not sure, the coordinate
system is defined as.   A*S*X+O

The point being that in the minc case the start/origin, as such, is
not the coordinate of pixel zero, while in ITK world it is.  In the
minc world the origin is an offset parallel to the pixel axes.  When
the direction cosines are not the identity matrix, then this makes a
big difference.   Some of the small discrepancy in the coordinates
looks like it could be due to that.

But if you want to get rid of negative spacing, you either have to
reorder the data, or multiply the relevant direction cosines by -1.
AND switch the start/origin accordingly - i dont think you want to
just invert its sign, i think you want to swap it with the other
corner.  Multiplying the direction cosines could change the coordinate
system from right to left handed, which might or might not cause
problems, im not sure.

Oh - if you use my formulas above, please check em... its late here.

Rupert


On Wed, Aug 20, 2008 at 9:55 AM, Audette, Mi
chel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi all,
>
> I'm playing with a MINC volume that was converted from DICOM, which has some unusual direction cosines,  and entering both volumes, MINC and DICOM, with ITK importers. I'm finding that there is a difference in min and max coordinates, and I'm having trouble ascertaining where the trouble is.
>
> For example, when typing mincheader, one sees the line:
> dicom_0x0020:el_0x0032 = "-26.902344\\-197.40057\\-45.887484" ;
>
> which mostly coincides with what I see when we load the data in DICOM format:
> minx: -26.9 maxx: 75.5
> miny: -197.4 maxy: -95.2
> minz: -51.89 maxz: -12.59
>
> Other data in mincheader include:
>                xspace:step = -0.1953125 ;
>                xspace:start = 26.80468775 ;
>                xspace:direction_cosines = 1., 0., 0. ;
>
>                yspace:step = -0.1953125 ;
>                yspace:start = 193.094103137385 ;
>                yspace:direction_cosines = 0., 0.99691733368886, 0.0784590962903196 ;
>
>                zspace:step = 0.299075200106658 ;
>                zspace:start = -67.2154025304974 ;
>                zspace:direction_cosines = 0., -0.0784590962903196, 0.99691733368886 ;
>
>
> doing a mincinfo produces
> maudette at icaw164201:~/data/work/earWork/goodEarData> mincinfo etzold_emma_12792115_003002_mri_xyz.mnc
> file: etzold_emma_12792115_003002_mri_xyz.mnc
> image: signed__ short -32768 to 32767
> image dimensions: xspace yspace zspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    xspace                    512    -0.195312      26.8047
>    yspace                    512    -0.195312      193.094
>    zspace                    129     0.299075     -67.2154
>
> We implemented a program that inverts the sign of step and start if the step is negative, from a minc import, and it produces
> minx: -26.8 maxx: 73
> miny: -197.77 maxy: -97.97
> minz: -51.86 maxz: -13.58
>
> Can anyone help me make heads or tails of this discrepancy?
>
> How does a dicom to minc conversion produce negative spacing in x and y, and can this converter make a mistake with start and spacing size? Does it round off anything, or is it sensitive to non-standard cosine angles?
>
> Best wishes,
>
> 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
>



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


From Michel.Audette at medizin.uni-leipzig.de  Thu Aug 21 03:42:36 2008
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 21 Aug 2008 09:42:36 +0200
Subject: [MINC-users] FW: min and max coordinates in minc vs dicom
In-Reply-To: <a6cc33f0808201937jd3024c1o53393b789fa1aad7@mail.gmail.com>
References: <160E3DD4FB702C4CB860C65186686E69024251D5@MRZS152229.medizin.uni-leipzig.de>
	<a6cc33f0808201937jd3024c1o53393b789fa1aad7@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E69024251DE@MRZS152229.medizin.uni-leipzig.de>

Hi Rupert, 

thanks for this answer. I'll use it to backtrack, insert some prints in the minc stuff, and determine what is going on. 

See you at MICCAI. 

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 Rupert Brooks
Sent: August 21, 2008 4:37 AM
To: MINC users mailing list
Subject: Re: [MINC-users] FW: min and max coordinates in minc vs dicom

Hi Michel,

I guess im having a little trouble determining if the problem exists
solely in the tool you are implementing, or in the DICOM/minc
conversion, or both.  But i will hazard a guess anyway that it may be
due to the way MINC defines its coordinate system.

if A is the rotation matrix, S is a diagonal matrix of the step sizes,
and O is the start, as listed by mincinfo, then the position of the
center of pixel X, in minc world, is

A*S(X+O)

In ITK, and possibly in DICOM, but i am not sure, the coordinate
system is defined as.   A*S*X+O

The point being that in the minc case the start/origin, as such, is
not the coordinate of pixel zero, while in ITK world it is.  In the
minc world the origin is an offset parallel to the pixel axes.  When
the direction cosines are not the identity matrix, then this makes a
big difference.   Some of the small discrepancy in the coordinates
looks like it could be due to that.

But if you want to get rid of negative spacing, you either have to
reorder the data, or multiply the relevant direction cosines by -1.
AND switch the start/origin accordingly - i dont think you want to
just invert its sign, i think you want to swap it with the other
corner.  Multiplying the direction cosines could change the coordinate
system from right to left handed, which might or might not cause
problems, im not sure.

Oh - if you use my formulas above, please check em... its late here.

Rupert


On Wed, Aug 20, 2008 at 9:55 AM, Audette, Mi
chel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi all,
>
> I'm playing with a MINC volume that was converted from DICOM, which has some unusual direction cosines,  and entering both volumes, MINC and DICOM, with ITK importers. I'm finding that there is a difference in min and max coordinates, and I'm having trouble ascertaining where the trouble is.
>
> For example, when typing mincheader, one sees the line:
> dicom_0x0020:el_0x0032 = "-26.902344\\-197.40057\\-45.887484" ;
>
> which mostly coincides with what I see when we load the data in DICOM format:
> minx: -26.9 maxx: 75.5
> miny: -197.4 maxy: -95.2
> minz: -51.89 maxz: -12.59
>
> Other data in mincheader include:
>                xspace:step = -0.1953125 ;
>                xspace:start = 26.80468775 ;
>                xspace:direction_cosines = 1., 0., 0. ;
>
>                yspace:step = -0.1953125 ;
>                yspace:start = 193.094103137385 ;
>                yspace:direction_cosines = 0., 0.99691733368886, 0.0784590962903196 ;
>
>                zspace:step = 0.299075200106658 ;
>                zspace:start = -67.2154025304974 ;
>                zspace:direction_cosines = 0., -0.0784590962903196, 0.99691733368886 ;
>
>
> doing a mincinfo produces
> maudette at icaw164201:~/data/work/earWork/goodEarData> mincinfo etzold_emma_12792115_003002_mri_xyz.mnc
> file: etzold_emma_12792115_003002_mri_xyz.mnc
> image: signed__ short -32768 to 32767
> image dimensions: xspace yspace zspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    xspace                    512    -0.195312      26.8047
>    yspace                    512    -0.195312      193.094
>    zspace                    129     0.299075     -67.2154
>
> We implemented a program that inverts the sign of step and start if the step is negative, from a minc import, and it produces
> minx: -26.8 maxx: 73
> miny: -197.77 maxy: -97.97
> minz: -51.86 maxz: -13.58
>
> Can anyone help me make heads or tails of this discrepancy?
>
> How does a dicom to minc conversion produce negative spacing in x and y, and can this converter make a mistake with start and spacing size? Does it round off anything, or is it sensitive to non-standard cosine angles?
>
> Best wishes,
>
> 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
>



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

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


From alex at bic.mni.mcgill.ca  Sun Aug 24 13:20:06 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sun, 24 Aug 2008 13:20:06 -0400
Subject: [MINC-users] Mincinfo
Message-ID: <e758a6650808241020y452aa89byf6f26374ab399558@mail.gmail.com>

Hello all,

I'm attaching Mincinfo, an old perl script I wrote, at the time to
some extent to be able to run mincinfo on multiple files. Now later
versions of mincinfo can already do that, but I still like this script
as it allows you to have some control over the output formatting. I
just fixed it up to not depend on MNI::Spawn and friends but instead
use more standard perl libraries. I think it might be a useful
addition to the base minc distribution; and if not, well here it is
for anybody interested. I would check it in cvs myself but I wasn't
quite sure where one would put general utilities like this (of which I
am sure quite a number are floating around)

Example of use (a fixed-width font comes in handy :):

$ Mincinfo -quiet -tab -file -dimensions -trte site_project_123.001.*
site_project_123.001.flair.mnc.gz       46      256     256
8.0020000000000006679   0.11550000000000000544
site_project_123.001.pd.mnc.gz  54      256     256
3.2000000000000001776  0.021936001000000000111
site_project_123.001.t1.mnc.gz  110     256     256
0.021000000000000001305 0.0080000000000000001665
site_project_123.001.t2.mnc.gz  54      256     256
3.2000000000000001776  0.087744003000000000969

-- Alex

From alex at bic.mni.mcgill.ca  Sun Aug 24 13:35:55 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sun, 24 Aug 2008 13:35:55 -0400
Subject: [MINC-users] Mincinfo
In-Reply-To: <e758a6650808241020y452aa89byf6f26374ab399558@mail.gmail.com>
References: <e758a6650808241020y452aa89byf6f26374ab399558@mail.gmail.com>
Message-ID: <e758a6650808241035u35c4abeaoa29622158e99f498@mail.gmail.com>

It appears that mailman stripped off the attachment; you can also find it here

http://www.bic.mni.mcgill.ca/~alex/MINC/Mincinfo

On Sun, Aug 24, 2008 at 1:20 PM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
> Hello all,
>
> I'm attaching Mincinfo, an old perl script I wrote, at the time to
> some extent to be able to run mincinfo on multiple files. Now later
> versions of mincinfo can already do that, but I still like this script
> as it allows you to have some control over the output formatting. I
> just fixed it up to not depend on MNI::Spawn and friends but instead
> use more standard perl libraries. I think it might be a useful
> addition to the base minc distribution; and if not, well here it is
> for anybody interested. I would check it in cvs myself but I wasn't
> quite sure where one would put general utilities like this (of which I
> am sure quite a number are floating around)
>
> Example of use (a fixed-width font comes in handy :):
>
> $ Mincinfo -quiet -tab -file -dimensions -trte site_project_123.001.*
> site_project_123.001.flair.mnc.gz       46      256     256
> 8.0020000000000006679   0.11550000000000000544
> site_project_123.001.pd.mnc.gz  54      256     256
> 3.2000000000000001776  0.021936001000000000111
> site_project_123.001.t1.mnc.gz  110     256     256
> 0.021000000000000001305 0.0080000000000000001665
> site_project_123.001.t2.mnc.gz  54      256     256
> 3.2000000000000001776  0.087744003000000000969
>
> -- Alex
>

From a.janke at gmail.com  Sun Aug 24 22:08:43 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 25 Aug 2008 12:08:43 +1000
Subject: [MINC-users] Mincinfo
In-Reply-To: <e758a6650808241035u35c4abeaoa29622158e99f498@mail.gmail.com>
References: <e758a6650808241020y452aa89byf6f26374ab399558@mail.gmail.com>
	<e758a6650808241035u35c4abeaoa29622158e99f498@mail.gmail.com>
Message-ID: <d747ed50808241908r7fe63e92n70e171d07e4e587c@mail.gmail.com>

2008/8/25 Alex Zijdenbos <alex at bic.mni.mcgill.ca>:
> It appears that mailman stripped off the attachment; you can also find it here
>
> http://www.bic.mni.mcgill.ca/~alex/MINC/Mincinfo

Interesting, my current plan for these sorts of things is here:

   http://packages.bic.mni.mcgill.ca/scripts/

With eventually a write up of each of them in a wiki somewhere. (like
wikibooks). FWIW here is my (sort of) equivalent: :)

   http://mavis.anu.edu.au/minc-beta/mi

The major difference being that it is for the likes of myself with
busted hands so that you can just go in a dir and type:

   $ mi

And get a nice listing with nothing more needed. Same with:

   http://mavis.anu.edu.au/minc-beta/mp
   http://mavis.anu.edu.au/minc-beta/mc

which are the equivalent for mincpik (yes, yes Danish users, laugh
away) and minccomplete.

But you are right, I would be very wary of including anything in the
base MINC distro which has a dependency on mni_perllib.

-- 
Andrew Janke - andrew.janke at anu.edu.au
Department of Geriatric Medicine, ANU
(a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From alex at bic.mni.mcgill.ca  Sun Aug 24 23:42:19 2008
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sun, 24 Aug 2008 23:42:19 -0400
Subject: [MINC-users] Mincinfo
In-Reply-To: <d747ed50808241908r7fe63e92n70e171d07e4e587c@mail.gmail.com>
References: <e758a6650808241020y452aa89byf6f26374ab399558@mail.gmail.com>
	<e758a6650808241035u35c4abeaoa29622158e99f498@mail.gmail.com>
	<d747ed50808241908r7fe63e92n70e171d07e4e587c@mail.gmail.com>
Message-ID: <e758a6650808242042m33754f0av5ef8a1623654b976@mail.gmail.com>

On Sun, Aug 24, 2008 at 10:08 PM, Andrew Janke <a.janke at gmail.com> wrote:
> 2008/8/25 Alex Zijdenbos <alex at bic.mni.mcgill.ca>:
>> It appears that mailman stripped off the attachment; you can also find it here
>>
>> http://www.bic.mni.mcgill.ca/~alex/MINC/Mincinfo
>
> Interesting, my current plan for these sorts of things is here:
>
>   http://packages.bic.mni.mcgill.ca/scripts/

Then now you will find Mincinfo there too :) BTW I just added some
options I have been meaning to add for eons, allowing you to specify
the field width and precision of integers and floating point values.
This to avoid values like "0.021000000000000001305" for TR, for
example.

By the way, I was actually more wondering about where in CVS we would
keep this kind of stuff. Or are we moving to something else at some
point, like Google code?

> With eventually a write up of each of them in a wiki somewhere. (like
> wikibooks). FWIW here is my (sort of) equivalent: :)
>
>   http://mavis.anu.edu.au/minc-beta/mi

Sort of yes - I take it you like direction cosines a lot ;)

> which are the equivalent for mincpik (yes, yes Danish users, laugh
> away) and minccomplete.

Not just Danish users I might add :)

> But you are right, I would be very wary of including anything in the
> base MINC distro which has a dependency on mni_perllib.

Yup. Although I always liked the functionality of MNI::Spawn,
considering that I stick a simpler version of it every perl script I
write...

-- A

From a.janke at gmail.com  Mon Aug 25 00:05:28 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 25 Aug 2008 14:05:28 +1000
Subject: [MINC-users] Mincinfo
In-Reply-To: <e758a6650808242042m33754f0av5ef8a1623654b976@mail.gmail.com>
References: <e758a6650808241020y452aa89byf6f26374ab399558@mail.gmail.com>
	<e758a6650808241035u35c4abeaoa29622158e99f498@mail.gmail.com>
	<d747ed50808241908r7fe63e92n70e171d07e4e587c@mail.gmail.com>
	<e758a6650808242042m33754f0av5ef8a1623654b976@mail.gmail.com>
Message-ID: <d747ed50808242105p12468a34i9cfdb1fe0a12720d@mail.gmail.com>

> By the way, I was actually more wondering about where in CVS we would
> keep this kind of stuff. Or are we moving to something else at some
> point, like Google code?

Well I put mine in minc_dev/shell-hacks bit like yourself I am looking
to migrate everything MINC to "somewhere else" in due time if only so
that we can have true bug tracking and the likes.  For this reason
launchpad looks the best to me so far.  Still there are a few sticks
in the mud about who dont like change.. :)  (Hi Claude!)


a

From a.janke at gmail.com  Mon Aug 25 23:02:02 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 26 Aug 2008 13:02:02 +1000
Subject: [MINC-users] Register's configure test for GLUT
In-Reply-To: <e12172550808192114l37cf1e39yfe2a0185016012e4@mail.gmail.com>
References: <e758a6650808171718v4184687ax2253c76c1d5875d2@mail.gmail.com>
	<d747ed50808171742k57125f79tfcb8064ef67d15d6@mail.gmail.com>
	<e758a6650808171759k4225f175kde7dd21094c6dfde@mail.gmail.com>
	<d747ed50808171806h6f890eaande43c336cd3d24d8@mail.gmail.com>
	<e758a6650808171959t6c51f891nab85f6d806ff909b@mail.gmail.com>
	<d747ed50808172221u21dd6232jccbdb890b3414f3d@mail.gmail.com>
	<e12172550808191002l2c7a3ce4y31fb424ccfef16d6@mail.gmail.com>
	<d747ed50808191509w1d23f7b9r502a82243e651735@mail.gmail.com>
	<e12172550808192114l37cf1e39yfe2a0185016012e4@mail.gmail.com>
Message-ID: <d747ed50808252002r7a8984f6t45e02296d831d417@mail.gmail.com>

2008/8/20 EJ Nikelski <nikelski at bic.mni.mcgill.ca>:
>   Thanks for your feedback, Andrew.  I *did* notice the
> CMakeLists.txt file in the MINC distro and wondered what you were up
> to  ;)

Heh.  There is (generally) method in my madness.

>  I do believe, however, that since CMake development is
> moving rather quickly (there appears to be an astonishing growth in
> *.cmake modules), some of your earlier experiences with CMake may no
> longer reflect the current CMake.

No doubt.

>  Correct, I do believe that a "make distcheck" functionality does not
> yet exist, however, the current CPack mechanism does seem to do a
> fairly reasonable job creating packages.

That it does. Still to me it is clumsy to have a separate doo-hicky to
do this to CMake (but this is not a technical point!).

>  CPack can create all sorts of packages: tar.gz, .deb, dmg (not
> tested yet) ... although there are a few gotchas (bugs) to look out
> for.

Aye, that was my experience a while back too. easy to use for small
things but it can get hairy for larger projects.

>> * There is far less out there in terms of documentation. I refuse to
>> buy a $80? manual for something that is "free". Especially as the
>> manual will change.
>
>   Yup, the price of the manual is a bit steep, although many open
> source projects use printed documentation as a "value add" in order to
> generate some income for the developers.

I certainly don't disagree with this model, what I do disagree with
though is me making choice to shift to CMake (and thus buying the
manual) which will in turn force a bunch of others out there who might
want to extend MINC or fiddle with the build process to buy a copy
too. MINC is supposed to be free! :)

> Happily, the online documentation has gotten much better, and is pretty much as good as the book.

Good good, where is this docco?

>> * CMake is strongly slanted towards VTK/ITK (no surprise there).
>
>  Ummmm ... not sure what "slanted" implies.  Yes, they're big users,
> but so is the KDE4 project.  I can't see any down-side here.

The inbuilt macros are (not suprisingly) written for use in VTK/ITK programs.

>  Yeah, but given that these modules are written with a consistent
> syntax (CMake), we are seeing lots of macros being written ...

Is there a repository of these somewhere? I couldn't find them ala the
automake macros archive.

> suspect, many by people who would not have dared try the same with m4.
>  BTW, "FindOpenGL" (includes find GLU as well), and "FindGLUT" are
> standard modules in CMake 2.6.  All we need is FindSoQT and FindCoin,
> and I would be able to finally build brain-view on my OS X machine
> using -frameworks.  I would like that.

Be my guest... :)  I wrote FindMINC and friends...

>> Note that I am not making a case for/against CMake but now I reckon I
>> will continue with autoconf if only because of the enormous amount of
>> work required right now to shift everything.
>
>  I agree.  But does it really need to be an "all or nothing"
> approach? Perhaps we could try implementing new projects using CMake,
> in addition to allowing inspired (or bored?) users to fix/enhance
> existing packages (as I did with the "arguments" package).

I will never hinder the inspired who choose to write things for me. :)
 I am more than happy to add your CMakeLists.txt file to the arguments
package (and any others that you choose to do).

There is some automake -> CMake converter thing that I found a while
back but it doesn't capture everything.


a

From bouffard at bic.mni.mcgill.ca  Thu Aug 28 15:02:42 2008
From: bouffard at bic.mni.mcgill.ca (Marc BOUFFARD)
Date: Thu, 28 Aug 2008 15:02:42 -0400
Subject: [MINC-users] get_meansd_voi
Message-ID: <Pine.SGI.4.58.0808281500090.381410@yorick.bic.mni.mcgill.ca>

Hello, where can I get an executable for get_meansd_voi?  I would like to
use it to extract some values using a Linux system.

Marc