From ed.gronenschild at mi.unimaas.nl  Tue Sep  4 09:37:20 2007
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Tue, 4 Sep 2007 15:37:20 +0200
Subject: [MINC-users] mincdefrag
Message-ID: <80203C0E-D1A7-4666-9C54-B0D047CD8161@mi.unimaas.nl>

Hi,

I came across a log file in which I found the use of a tool called  
'mincdefrag'.
It was used in combination with the tool cortical_surface. What does
mincdefrag do and where can I get it?

Ed

From a.janke at gmail.com  Tue Sep  4 09:44:41 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 4 Sep 2007 23:44:41 +1000
Subject: [MINC-users] mincdefrag
In-Reply-To: <80203C0E-D1A7-4666-9C54-B0D047CD8161@mi.unimaas.nl>
References: <80203C0E-D1A7-4666-9C54-B0D047CD8161@mi.unimaas.nl>
Message-ID: <d747ed50709040644l6c095abw882ad724b1c6d0bf@mail.gmail.com>

On 9/4/07, Ed Gronenschild <ed.gronenschild at mi.unimaas.nl> wrote:
> I came across a log file in which I found the use of a tool called
> 'mincdefrag'.
> It was used in combination with the tool cortical_surface. What does
> mincdefrag do and where can I get it?

Hi Ed,

It is a tool developed by Claude at the BIC.  It does a bit of
morphological "pruning" for want of a better word. :)


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

From a.janke at gmail.com  Wed Sep  5 02:19:47 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 5 Sep 2007 16:19:47 +1000
Subject: [MINC-users] Regional CBF differences
In-Reply-To: <LDECIOJNCEPJFCAHFLCCEEDNCAAA.john@absherneurology.com>
References: <mailman.1.1188489624.1074796.minc-users@bic.mni.mcgill.ca>
	<LDECIOJNCEPJFCAHFLCCEEDNCAAA.john@absherneurology.com>
Message-ID: <d747ed50709042319p3e0ee9f4n8eb2f9480b9c17ba@mail.gmail.com>

Hi John,

I at a bit of a loss as to what your question is...  Do you want help
with the registrations (using either mritopet or mritotal) or with the
subtractions of the individuals (after registration to each other?)

?

a


On 8/31/07, John Absher <john at absherneurology.com> wrote:
> I have data from CBF PET for 4 subjects, 4 scans each, all normalized into
> sterotaxic space in mnc and analyze formats.  Two scans were at baseline BP,
> and 2 scans were done under low BP conditions.  I would like to map, for
> each subject, the regional changes in absolute CBF using the HBM templates
> or another standard Talairach reference system.  I've already done the spm
> analysis, and know where the significant changes occurred.  However, due to
> the small number of subjects, I needed to do the spm based on relative CBF
> changes, smoothed data, etc.


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

From se at hst.aau.dk  Wed Sep  5 03:56:40 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Wed, 05 Sep 2007 09:56:40 +0200
Subject: [MINC-users] mincdefrag
In-Reply-To: <80203C0E-D1A7-4666-9C54-B0D047CD8161@mi.unimaas.nl>
References: <80203C0E-D1A7-4666-9C54-B0D047CD8161@mi.unimaas.nl>
Message-ID: <46DE6138.5080804@hst.aau.dk>

Ed Gronenschild wrote:
> I came across a log file in which I found the use of a tool called  
> 'mincdefrag'.
> It was used in combination with the tool cortical_surface. What does
> mincdefrag do and where can I get it?

As Claude writes in the source: "Remove disconnected islands of voxels 
of a given label." In other words you can extract the largest connected 
component with a given label.

It's part of the latest conglomerate:
http://packages.bic.mni.mcgill.ca/tgz/conglomerate-1.6.4.tar.gz

Simon

From luis.ibanez at kitware.com  Wed Sep  5 17:40:54 2007
From: luis.ibanez at kitware.com (Luis Ibanez)
Date: Wed, 05 Sep 2007 17:40:54 -0400
Subject: [MINC-users] Undefined symbols in MacOS
Message-ID: <46DF2266.2040708@kitware.com>


We are using MINC2 as a support library for ITK (www.itk.org),
and one of our Nightly builds is reporting the following link error:

http://www.itk.org/Testing/Sites/RogueResearch2/MacOSXTiger-univ/20070905-0100-Nightly/BuildError.html


/usr/bin/ld: Undefined symbols:
_fputs$UNIX2003
_close$UNIX2003
_open$UNIX2003
_read$UNIX2003
_write$UNIX2003
_strerror$UNIX2003


We are wondering if the error may be related to MINC2
or to one of the underlying libraries HDF5 or NetCDF.


Has anyone seen similar errors when building an
application based on MINC2 under MacOS ?


    Thanks for any hints,



        Luis



From a.janke at gmail.com  Wed Sep  5 19:43:39 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 6 Sep 2007 09:43:39 +1000
Subject: [MINC-users] Undefined symbols in MacOS
In-Reply-To: <46DF2266.2040708@kitware.com>
References: <46DF2266.2040708@kitware.com>
Message-ID: <d747ed50709051643s1dd53062y1352e343c80ff78a@mail.gmail.com>

Hi Luis,

I certainly have not seen this before, but it would hazzard a guess
that there might be a missing extern "C" {} somewhere given the lack
of function mangling. (unless of course the error output from
compilers is more helpful these days! :)

Is this particular spotty cat Intel or PPC based?  (And Sean, if you
are reading this, can you organise SSH access for me to it so that I
can have a look at this?)


a



On 9/6/07, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> We are using MINC2 as a support library for ITK (www.itk.org),
> and one of our Nightly builds is reporting the following link error:
>
> http://www.itk.org/Testing/Sites/RogueResearch2/MacOSXTiger-univ/20070905-0100-Nightly/BuildError.html
>
>
> /usr/bin/ld: Undefined symbols:
> _fputs$UNIX2003
> _close$UNIX2003
> _open$UNIX2003
> _read$UNIX2003
> _write$UNIX2003
> _strerror$UNIX2003
>
>
> We are wondering if the error may be related to MINC2
> or to one of the underlying libraries HDF5 or NetCDF.
>
>
> Has anyone seen similar errors when building an
> application based on MINC2 under MacOS ?
>
>
>     Thanks for any hints,
>
>
>
>         Luis
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


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

From se at hst.aau.dk  Thu Sep  6 04:20:17 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 06 Sep 2007 10:20:17 +0200
Subject: [MINC-users] Bug reports?
Message-ID: <46DFB841.3090901@hst.aau.dk>

Hi,

Is someone maintaining a list of bugs in the minc tools?
I occasionally come across minor bugs in various tools. Today, I noticed 
a discrepancy between version 1.4 and 1.5.1 of mincstats.

Running mincstats on a zero-filled volume:

 > mincstats test.mnc
Segmentation fault
 > mincstats -version
program: 1.5.1
libminc: 1.5.1
netcdf : "3.6.2" of Jun 19 2007 10:38:40 $

]$ mincstats -version
program: 1.4
libminc: 1.4
netcdf : 3.5.1 of Oct  5 2004 10:28:35 $
]$ mincstats test.mnc
File:              test.mnc
Mask file:         (null)
Total voxels:      7109137
...snip...

Things like this should be tracked I guess.

Simon

From a.janke at gmail.com  Thu Sep  6 07:09:29 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 6 Sep 2007 21:09:29 +1000
Subject: [MINC-users] Bug reports?
In-Reply-To: <46DFB841.3090901@hst.aau.dk>
References: <46DFB841.3090901@hst.aau.dk>
Message-ID: <d747ed50709060409r1b78e29dq1ae873cbbc106477@mail.gmail.com>

Hi Simon,

I did set this up a while ago:

   http://bugs.bic.mni.mcgill.ca/

There is a project in there called MINC-core but it wasnt used much!
In the meantime, can you make you test.mnc available that breaks
mincstats?

ta

a


On 9/6/07, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
> Hi,
>
> Is someone maintaining a list of bugs in the minc tools?
> I occasionally come across minor bugs in various tools. Today, I noticed
> a discrepancy between version 1.4 and 1.5.1 of mincstats.
>
> Running mincstats on a zero-filled volume:
>
>  > mincstats test.mnc
> Segmentation fault
>  > mincstats -version
> program: 1.5.1
> libminc: 1.5.1
> netcdf : "3.6.2" of Jun 19 2007 10:38:40 $
>
> ]$ mincstats -version
> program: 1.4
> libminc: 1.4
> netcdf : 3.5.1 of Oct  5 2004 10:28:35 $
> ]$ mincstats test.mnc
> File:              test.mnc
> Mask file:         (null)
> Total voxels:      7109137
> ...snip...
>
> Things like this should be tracked I guess.
>
> Simon
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>



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

From se at hst.aau.dk  Thu Sep  6 08:00:20 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 06 Sep 2007 14:00:20 +0200
Subject: [MINC-users] Bug reports?
In-Reply-To: <d747ed50709060409r1b78e29dq1ae873cbbc106477@mail.gmail.com>
References: <46DFB841.3090901@hst.aau.dk>
	<d747ed50709060409r1b78e29dq1ae873cbbc106477@mail.gmail.com>
Message-ID: <46DFEBD4.3020505@hst.aau.dk>

Hi Andrew,

Well, not much on MINC-core in there.

Creating test.mnc with
 > minccalc -expr "0" icbm_avg_152_t1_tal_lin.mnc test.mnc
will give you a volume where mincstats crashes.

My version is here
http://www.hst.aau.dk/~se/andrew/test.mnc.gz
(compressed nicely when there is only zeros in there :-) )

Simon

Andrew Janke wrote:
> Hi Simon,
> 
> I did set this up a while ago:
> 
>    http://bugs.bic.mni.mcgill.ca/
> 
> There is a project in there called MINC-core but it wasnt used much!
> In the meantime, can you make you test.mnc available that breaks
> mincstats?
> 
> ta
> 
> a
> 
> 
> On 9/6/07, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
>> Hi,
>>
>> Is someone maintaining a list of bugs in the minc tools?
>> I occasionally come across minor bugs in various tools. Today, I noticed
>> a discrepancy between version 1.4 and 1.5.1 of mincstats.
>>
>> Running mincstats on a zero-filled volume:
>>
>>  > mincstats test.mnc
>> Segmentation fault
>>  > mincstats -version
>> program: 1.5.1
>> libminc: 1.5.1
>> netcdf : "3.6.2" of Jun 19 2007 10:38:40 $
>>
>> ]$ mincstats -version
>> program: 1.4
>> libminc: 1.4
>> netcdf : 3.5.1 of Oct  5 2004 10:28:35 $
>> ]$ mincstats test.mnc
>> File:              test.mnc
>> Mask file:         (null)
>> Total voxels:      7109137
>> ...snip...
>>
>> Things like this should be tracked I guess.
>>
>> Simon
>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>>
> 
> 
> 

From john at absherneurology.com  Thu Sep  6 08:15:59 2007
From: john at absherneurology.com (John Absher)
Date: Thu, 6 Sep 2007 08:15:59 -0400
Subject: [MINC-users] Regional CBF differences
In-Reply-To: <mailman.3.1189008038.1162719.minc-users@bic.mni.mcgill.ca>
Message-ID: <LDECIOJNCEPJFCAHFLCCMEFDCAAA.john@absherneurology.com>

Hi, Andrew,

Sorry, I didn't make this clear.  I don't need help with the registrations.
The 16 CBF PET scans, and the 4 MRIs for these 4 subjects are already in
Talairach space.

I seek an automated way to determine the quantitative CBF PET changes on a
region-by-region basis (rather than voxel by voxel).  I have 2 "baseline
blood pressure" scans and 2 "low-blood-pressure" scans per subject.  I want
to know how much blood pressure declined/changed in the thalamus, the
caudate, the cingulate gyrus, and all other "standard" brain regions, like
those defined by the Talairach atlas.

I'm hoping there's an automated way to calculate these regional CBF
differences.  I can use mincmath (Baseline1 - LowBP1, Baseline2-LowBP1,
etc.) to run all 4 possible subtractions for each of the 4 subjects, then
average these differnece images, again using mincmath.  However, I still
need some way to analyze the voxels in the difference images (one per
subject).  I'd like to do the whole brain, and print a table showing these
average differences, by region, by subject.

I hope that makes sense, now.  Thanks, for any help you can provide.

John


Date: Wed, 5 Sep 2007 16:19:47 +1000
From: "Andrew Janke" <a.janke at gmail.com>
Subject: Re: [MINC-users] Regional CBF differences
To: "MINC users mailing list" <minc-users at bic.mni.mcgill.ca>
Message-ID:
	<d747ed50709042319p3e0ee9f4n8eb2f9480b9c17ba at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi John,

I at a bit of a loss as to what your question is...  Do you want help
with the registrations (using either mritopet or mritotal) or with the
subtractions of the individuals (after registration to each other?)

?

a


On 8/31/07, John Absher <john at absherneurology.com> wrote:
> I have data from CBF PET for 4 subjects, 4 scans each, all normalized into
> sterotaxic space in mnc and analyze formats.  Two scans were at baseline
BP,
> and 2 scans were done under low BP conditions.  I would like to map, for
> each subject, the regional changes in absolute CBF using the HBM templates
> or another standard Talairach reference system.  I've already done the spm
> analysis, and know where the significant changes occurred.  However, due
to
> the small number of subjects, I needed to do the spm based on relative CBF
> changes, smoothed data, etc.


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




From walkerlin at mail.nih.gov  Fri Sep  7 11:46:46 2007
From: walkerlin at mail.nih.gov (Walker, Lindsay (NIH/NICHD) [V])
Date: Fri, 7 Sep 2007 11:46:46 -0400
Subject: [MINC-users] conversion to analyze problem
Message-ID: <C190860B1ADC834399CE250C583BE5460118CB85@NIHCESMLBX7.nih.gov>

I need to convert some minc images to analyze format.  I have been using
the mnc2nii tool from minc-1.5.1 with the -analyze option.

 

The images I converted have an indicator dot on the anatomical right of
the image.  When I run the minc to analyze conversion program, the
resulting analyze image shows the indicator dot on the anatomical left.
So the program appears to be flipping the labels for the left and right.

 

I have tried opening the analyze image with multiple pieces of software
to make sure it is not just a display issue (i.e. radiological versus
neurological coordinates).  The left and right labels appear to be
incorrect using fslview, medx and mipav.

 

Has anyone else encountered or noticed this problem?

 

Thank you.

 

Lindsay Walker.

 


From najma at bic.mni.mcgill.ca  Fri Sep  7 15:48:52 2007
From: najma at bic.mni.mcgill.ca (Najmeh Khalili M.)
Date: Fri, 7 Sep 2007 15:48:52 -0400
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <C190860B1ADC834399CE250C583BE5460118CB85@NIHCESMLBX7.nih.gov>
References: <C190860B1ADC834399CE250C583BE5460118CB85@NIHCESMLBX7.nih.gov>
Message-ID: <Pine.SGI.4.58.0709071544300.9464662@yorick.bic.mni.mcgill.ca>


Hi,

Yes I have too.
I did something like:
             fslswapdim data.nii.gz x -y z flipped_data.nii.gz
to correct the left-right flip problem.

Hope this helps,
Naj


On Fri, 7 Sep 2007, Walker, Lindsay (NIH/NICHD) [V] wrote:

> I need to convert some minc images to analyze format.  I have been using
> the mnc2nii tool from minc-1.5.1 with the -analyze option.
>
>
>
> The images I converted have an indicator dot on the anatomical right of
> the image.  When I run the minc to analyze conversion program, the
> resulting analyze image shows the indicator dot on the anatomical left.
> So the program appears to be flipping the labels for the left and right.
>
>
>
> I have tried opening the analyze image with multiple pieces of software
> to make sure it is not just a display issue (i.e. radiological versus
> neurological coordinates).  The left and right labels appear to be
> incorrect using fslview, medx and mipav.
>
>
>
> Has anyone else encountered or noticed this problem?
>
>
>
> Thank you.
>
>
>
> Lindsay Walker.
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

=========================================================
http://www.bic.mni.mcgill.ca/~najma

From alex at bic.mni.mcgill.ca  Fri Sep  7 16:33:41 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Fri, 7 Sep 2007 16:33:41 -0400
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <Pine.SGI.4.58.0709071544300.9464662@yorick.bic.mni.mcgill.ca>
References: <C190860B1ADC834399CE250C583BE5460118CB85@NIHCESMLBX7.nih.gov>
	<Pine.SGI.4.58.0709071544300.9464662@yorick.bic.mni.mcgill.ca>
Message-ID: <e758a6650709071333i5816f404h226b9ee3f8e4c54f@mail.gmail.com>

I suppose flipping the minc volume prior to conversion should amount
up to the same thing, e.g.,

   flip_volume <in.mnc> <out.mnc>

flip_volume is part of the 'conglomerate' package.

However, what I would like to know is whether this is a conceptually
unsolvable problem due to the specifics of ANALYZE and MINC coordinate
handling, or if this is in fact fixable (i.e., a bug). I don't believe
I have *ever* encountered a MINC <-> ANALYZE conversion that did not
require flipping of some sort, so at first glance I would assume we
are looking at a bug.

Does anybody more familiar with the inner workings of mnc2nii and the
like perhaps have some insight into this? Andrew, Bert, ...?

Thanks,

-- Alex

On 9/7/07, Najmeh Khalili M. <najma at bic.mni.mcgill.ca> wrote:
>
> Hi,
>
> Yes I have too.
> I did something like:
>              fslswapdim data.nii.gz x -y z flipped_data.nii.gz
> to correct the left-right flip problem.
>
> Hope this helps,
> Naj
>
>
> On Fri, 7 Sep 2007, Walker, Lindsay (NIH/NICHD) [V] wrote:
>
> > I need to convert some minc images to analyze format.  I have been using
> > the mnc2nii tool from minc-1.5.1 with the -analyze option.
> >
> >
> >
> > The images I converted have an indicator dot on the anatomical right of
> > the image.  When I run the minc to analyze conversion program, the
> > resulting analyze image shows the indicator dot on the anatomical left.
> > So the program appears to be flipping the labels for the left and right.
> >
> >
> >
> > I have tried opening the analyze image with multiple pieces of software
> > to make sure it is not just a display issue (i.e. radiological versus
> > neurological coordinates).  The left and right labels appear to be
> > incorrect using fslview, medx and mipav.
> >
> >
> >
> > Has anyone else encountered or noticed this problem?
> >
> >
> >
> > Thank you.
> >
> >
> >
> > Lindsay Walker.
> >
> >
> >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
> =========================================================
> http://www.bic.mni.mcgill.ca/~najma
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From walkerlin at mail.nih.gov  Fri Sep  7 16:35:59 2007
From: walkerlin at mail.nih.gov (Walker, Lindsay (NIH/NICHD) [V])
Date: Fri, 7 Sep 2007 16:35:59 -0400
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <Pine.SGI.4.58.0709071544300.9464662@yorick.bic.mni.mcgill.ca>
Message-ID: <C190860B1ADC834399CE250C583BE5460118CB87@NIHCESMLBX7.nih.gov>

That definitely helps.  I will give it a try.

Is there a newer version of this tool where this bug has been addressed?
Or is it possible for someone to fix this bug?

Lindsay.

-----Original Message-----
From: Najmeh Khalili M. [mailto:najma at bic.mni.mcgill.ca] 
Sent: Friday, September 07, 2007 3:49 PM
To: MINC users mailing list
Subject: Re: [MINC-users] conversion to analyze problem


Hi,

Yes I have too.
I did something like:
             fslswapdim data.nii.gz x -y z flipped_data.nii.gz
to correct the left-right flip problem.

Hope this helps,
Naj


On Fri, 7 Sep 2007, Walker, Lindsay (NIH/NICHD) [V] wrote:

> I need to convert some minc images to analyze format.  I have been
using
> the mnc2nii tool from minc-1.5.1 with the -analyze option.
>
>
>
> The images I converted have an indicator dot on the anatomical right
of
> the image.  When I run the minc to analyze conversion program, the
> resulting analyze image shows the indicator dot on the anatomical
left.
> So the program appears to be flipping the labels for the left and
right.
>
>
>
> I have tried opening the analyze image with multiple pieces of
software
> to make sure it is not just a display issue (i.e. radiological versus
> neurological coordinates).  The left and right labels appear to be
> incorrect using fslview, medx and mipav.
>
>
>
> Has anyone else encountered or noticed this problem?
>
>
>
> Thank you.
>
>
>
> Lindsay Walker.
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

=========================================================
http://www.bic.mni.mcgill.ca/~najma
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From a.janke at gmail.com  Fri Sep  7 22:48:53 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sat, 8 Sep 2007 12:48:53 +1000
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <C190860B1ADC834399CE250C583BE5460118CB87@NIHCESMLBX7.nih.gov>
References: <Pine.SGI.4.58.0709071544300.9464662@yorick.bic.mni.mcgill.ca>
	<C190860B1ADC834399CE250C583BE5460118CB87@NIHCESMLBX7.nih.gov>
Message-ID: <d747ed50709071948h3ddbcac6o1d9fb2c72e4833e@mail.gmail.com>

Hi Lindsay, (and others!)

As Alex has alluded to, the problems with "analyze" to MINC conversion
are systemic and not really bugs.

In short there is no way to canonically convert between the two
formats and ensure that the orientation will always be correct as it
depends on the package that you will be using with your
"analyze/Nifti" images. What generally happens is that users have to
figure out a path that works for them and stick to it.

This in itself is endemic in any Nifti/Analyze conversion but what I
can assure you of are the following...

1) mnc2nii follows the official specifications of Analyze and Nifti.

2) The issue of Radiological vs Neurological orientation _should_ have
nothing to do with a file format and only concern a file viewer. In
MINC this is the case. There is also a defined co-ordinate system for
ANALYZE and Nifti-1 but these are not always followed to the letter.

3) Further to #2 you need to very careful of what you package is doing
to your files as some like SPM define a file like "spm_defaults.m"
that defines as to whether your data is "neurological" or
"radiological" that will flip your data inside the package itself.

Sorry I cant offer a simple answer to your problems but the above is
one of the primary motivating factors that caused Peter (Neelin) to
write MINC nigh on 12 years ago! :)

That all said there is a new MINC due out very soon that will have an
updated version of Nifti conversion that may alleviate your concerns
as we  now use the same version of the Nifti Libraries that is used by
FSL and thus supports a few extra things like compression of Nifti
files and the likes.


a


On 9/8/07, Walker, Lindsay (NIH/NICHD) [V] <walkerlin at mail.nih.gov> wrote:
> That definitely helps.  I will give it a try.
>
> Is there a newer version of this tool where this bug has been addressed?
> Or is it possible for someone to fix this bug?
>
> Lindsay.
>
> -----Original Message-----
> From: Najmeh Khalili M. [mailto:najma at bic.mni.mcgill.ca]
> Sent: Friday, September 07, 2007 3:49 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] conversion to analyze problem
>
> Hi,
>
> Yes I have too.
> I did something like:
>              fslswapdim data.nii.gz x -y z flipped_data.nii.gz
> to correct the left-right flip problem.
>
> On Fri, 7 Sep 2007, Walker, Lindsay (NIH/NICHD) [V] wrote:
>
> > I need to convert some minc images to analyze format.  I have been
> using
> > the mnc2nii tool from minc-1.5.1 with the -analyze option.
> >
> > The images I converted have an indicator dot on the anatomical right
> of
> > the image.  When I run the minc to analyze conversion program, the
> > resulting analyze image shows the indicator dot on the anatomical
> left.
> > So the program appears to be flipping the labels for the left and
> right.
> >
> > I have tried opening the analyze image with multiple pieces of
> software
> > to make sure it is not just a display issue (i.e. radiological versus
> > neurological coordinates).  The left and right labels appear to be
> > incorrect using fslview, medx and mipav.
> >
> > Has anyone else encountered or noticed this problem?


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

From alex at bic.mni.mcgill.ca  Sat Sep  8 10:34:04 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sat, 8 Sep 2007 10:34:04 -0400
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <d747ed50709071948h3ddbcac6o1d9fb2c72e4833e@mail.gmail.com>
References: <Pine.SGI.4.58.0709071544300.9464662@yorick.bic.mni.mcgill.ca>
	<C190860B1ADC834399CE250C583BE5460118CB87@NIHCESMLBX7.nih.gov>
	<d747ed50709071948h3ddbcac6o1d9fb2c72e4833e@mail.gmail.com>
Message-ID: <e758a6650709080734i646b3bc0l339977b0f7862d82@mail.gmail.com>

Hi Andrew,

Although I am sympathetic to systemic problems and possible
ambiguities of the MINC <-> ANALYZE format conversions, I am as yet
not convinced that we are not looking at a bug; nor that the behaviour
of mnc2nii/nii2mnc can/should not be improved to "work" for users in
95% of the cases instead of 5% (if that). Reasons being:

1. I am yet to encounter the first case where flipping was not
necessary (and I have done my fair share - probably more - of these
types of conversions)

2. If I take a MINC volume (without funky directions cosines and etc),
run mnc2nii (-analyze) followed by nii2mnc, the x-axis comes out
flipped.

3. In the case that Lindsay reports, at least 3 different analyze
viewers agree that the x-axis is flipped (which I understand not to be
an issue of viewer/radiological/neurological convention, as evidenced
by a physical marker in the image).

So notwithstanding MINC's conceptual superiority w/respect to
coordinate space handling and etc, it still makes no sense to me that
this conversion appears to not *ever* work correctly, nor that the
conversion on 'simple' files is not bijective when using the
conversion tools provided by MINC itself. Something just smells wrong
here...

Where does one actually find the formal specifications of
ANALYZE/NIFTi? For ANALYZE I keep stumbling on the same pdf describing
the ANALYZE 7.5 file format, but that is less than informative.

-- A

On 9/7/07, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Lindsay, (and others!)
>
> As Alex has alluded to, the problems with "analyze" to MINC conversion
> are systemic and not really bugs.
>
> In short there is no way to canonically convert between the two
> formats and ensure that the orientation will always be correct as it
> depends on the package that you will be using with your
> "analyze/Nifti" images. What generally happens is that users have to
> figure out a path that works for them and stick to it.
>
> This in itself is endemic in any Nifti/Analyze conversion but what I
> can assure you of are the following...
>
> 1) mnc2nii follows the official specifications of Analyze and Nifti.
>
> 2) The issue of Radiological vs Neurological orientation _should_ have
> nothing to do with a file format and only concern a file viewer. In
> MINC this is the case. There is also a defined co-ordinate system for
> ANALYZE and Nifti-1 but these are not always followed to the letter.
>
> 3) Further to #2 you need to very careful of what you package is doing
> to your files as some like SPM define a file like "spm_defaults.m"
> that defines as to whether your data is "neurological" or
> "radiological" that will flip your data inside the package itself.
>
> Sorry I cant offer a simple answer to your problems but the above is
> one of the primary motivating factors that caused Peter (Neelin) to
> write MINC nigh on 12 years ago! :)
>
> That all said there is a new MINC due out very soon that will have an
> updated version of Nifti conversion that may alleviate your concerns
> as we  now use the same version of the Nifti Libraries that is used by
> FSL and thus supports a few extra things like compression of Nifti
> files and the likes.
>
>
> a
>
>
> On 9/8/07, Walker, Lindsay (NIH/NICHD) [V] <walkerlin at mail.nih.gov> wrote:
> > That definitely helps.  I will give it a try.
> >
> > Is there a newer version of this tool where this bug has been addressed?
> > Or is it possible for someone to fix this bug?
> >
> > Lindsay.
> >
> > -----Original Message-----
> > From: Najmeh Khalili M. [mailto:najma at bic.mni.mcgill.ca]
> > Sent: Friday, September 07, 2007 3:49 PM
> > To: MINC users mailing list
> > Subject: Re: [MINC-users] conversion to analyze problem
> >
> > Hi,
> >
> > Yes I have too.
> > I did something like:
> >              fslswapdim data.nii.gz x -y z flipped_data.nii.gz
> > to correct the left-right flip problem.
> >
> > On Fri, 7 Sep 2007, Walker, Lindsay (NIH/NICHD) [V] wrote:
> >
> > > I need to convert some minc images to analyze format.  I have been
> > using
> > > the mnc2nii tool from minc-1.5.1 with the -analyze option.
> > >
> > > The images I converted have an indicator dot on the anatomical right
> > of
> > > the image.  When I run the minc to analyze conversion program, the
> > > resulting analyze image shows the indicator dot on the anatomical
> > left.
> > > So the program appears to be flipping the labels for the left and
> > right.
> > >
> > > I have tried opening the analyze image with multiple pieces of
> > software
> > > to make sure it is not just a display issue (i.e. radiological versus
> > > neurological coordinates).  The left and right labels appear to be
> > > incorrect using fslview, medx and mipav.
> > >
> > > Has anyone else encountered or noticed this problem?
>
>
> --
> 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://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Sun Sep  9 07:51:35 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 9 Sep 2007 21:51:35 +1000
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <e758a6650709080734i646b3bc0l339977b0f7862d82@mail.gmail.com>
References: <Pine.SGI.4.58.0709071544300.9464662@yorick.bic.mni.mcgill.ca>
	<C190860B1ADC834399CE250C583BE5460118CB87@NIHCESMLBX7.nih.gov>
	<d747ed50709071948h3ddbcac6o1d9fb2c72e4833e@mail.gmail.com>
	<e758a6650709080734i646b3bc0l339977b0f7862d82@mail.gmail.com>
Message-ID: <d747ed50709090451t3d7063dboa8cac8dcda8f37a8@mail.gmail.com>

> Although I am sympathetic to systemic problems and possible
> ambiguities of the MINC <-> ANALYZE format conversions, I am as yet
> not convinced that we are not looking at a bug; nor that the behaviour
> of mnc2nii/nii2mnc can/should not be improved to "work" for users in
> 95% of the cases instead of 5% (if that). Reasons being:

Okie doke...

> 1. I am yet to encounter the first case where flipping was not
> necessary (and I have done my fair share - probably more - of these
> types of conversions)

OK.  (has not been my experience?  I will check with the XNAT guys and
see what their experience is).

> 2. If I take a MINC volume (without funky directions cosines and etc),
> run mnc2nii (-analyze) followed by nii2mnc, the x-axis comes out
> flipped.

oh?  not so for me?  Although I questions why you are adding the
-analyze flag. This will cause mnc2nii to write an old style (non
oriented) analyze file as opposed to a Nifti 2-file format which I
suspect is what you want.  My test:

   $ mincreshape -dimrange xspace=0,100 \
      icbm_avg_152_t1_tal_lin.mnc /tmp/out.mnc

   $ mnc2nii out.mnc out.hdr
   $ nii2mnc out.hdr two.mnc

   $ register out.mnc two.mnc

Beyond image scaling issues, this is fine?  What versions are you
running?  myself:

gordon:tmp$ nii2mnc -version
program: 2.0.09
libminc: 2.0.09
netcdf : 3.6.1 of Mar  5 2007 07:16:16 $

> 3. In the case that Lindsay reports, at least 3 different analyze
> viewers agree that the x-axis is flipped (which I understand not to be
> an issue of viewer/radiological/neurological convention, as evidenced
> by a physical marker in the image).

Is this when using a -analyze flag?

> So notwithstanding MINC's conceptual superiority w/respect to
> coordinate space handling and etc, it still makes no sense to me that
> this conversion appears to not *ever* work correctly, nor that the
> conversion on 'simple' files is not bijective when using the
> conversion tools provided by MINC itself. Something just smells wrong
> here...

Myself I prefer to code to the spec and then add kludges later on for
specific cases if needs be.  Meaning I dont think there would be a
problem to write a quick and dirty conversion (shell) script called
mnc2fsl for example.

> Where does one actually find the formal specifications of
> ANALYZE/NIFTi? For ANALYZE I keep stumbling on the same pdf describing
> the ANALYZE 7.5 file format, but that is less than informative.

The old analyze spec used to be on the Mayo site. But I just went
looking for it an found nothing.  There is always the old .h file that
went with it.  As for nifti, the best site is the sourceforge page.

   http://niftilib.sourceforge.net/

In any case, if what you describe above really is a bug I am more than
happy to fix it.


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

From sorench at gmail.com  Mon Sep 10 03:22:38 2007
From: sorench at gmail.com (Soren Christensen)
Date: Mon, 10 Sep 2007 17:22:38 +1000
Subject: [MINC-users] Display and slice plane rendering
Message-ID: <d6e2d6550709100022u7f732fa0nfe19bb507815da92@mail.gmail.com>

Hi,
 I am trying to create a 3D sliceplane rendering from an arbitrary
slice plane but have problems doing this in Display.
I:
1) turn on the "fourth window" in Display (S-S)
2) Toggle on the cut plane in the 3D window (S-Q) and orient it as I want.
3) Try to do S-A from the fourth window in order to render the
arbitrary slice-cut to the 3D window.

Step 3 is where I have the problem. I cannot render the arbitrary
slice-cut to the 3D window. The other standard view planes render
fine.

If this functionality is not available using the approach above, is
there pherhaps another way to achieve it? eg. resampling volume
differently or so?

Thanks
Soren

From walkerlin at mail.nih.gov  Mon Sep 10 11:32:53 2007
From: walkerlin at mail.nih.gov (Walker, Lindsay (NIH/NICHD) [V])
Date: Mon, 10 Sep 2007 11:32:53 -0400
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <d747ed50709090451t3d7063dboa8cac8dcda8f37a8@mail.gmail.com>
Message-ID: <C190860B1ADC834399CE250C583BE5460118CB88@NIHCESMLBX7.nih.gov>

Andrew,

I can answer some of these questions.  Yes, I am using the -analyze
flag, as I need to have my data in analyze format for a software
pipeline that I use.

In fact, mnc2nii converts the data correctly to nifti format (no issues
with orientation), but when I add the -analyze flag it flips the x-axis.

This axis is flipped when viewed in mipav, medx and fslview - so it is
not just one software package that is handling the data incorrectly.

The version of mnc2nii that I am using is:

mnc2nii -version
program: 1.5.1
libminc: 1.5.1
netcdf : "3.6.2"

Lindsay.

-----Original Message-----
From: Andrew Janke [mailto:a.janke at gmail.com] 
Sent: Sunday, September 09, 2007 7:52 AM
To: MINC users mailing list
Subject: Re: [MINC-users] conversion to analyze problem

> Although I am sympathetic to systemic problems and possible
> ambiguities of the MINC <-> ANALYZE format conversions, I am as yet
> not convinced that we are not looking at a bug; nor that the behaviour
> of mnc2nii/nii2mnc can/should not be improved to "work" for users in
> 95% of the cases instead of 5% (if that). Reasons being:

Okie doke...

> 1. I am yet to encounter the first case where flipping was not
> necessary (and I have done my fair share - probably more - of these
> types of conversions)

OK.  (has not been my experience?  I will check with the XNAT guys and
see what their experience is).

> 2. If I take a MINC volume (without funky directions cosines and etc),
> run mnc2nii (-analyze) followed by nii2mnc, the x-axis comes out
> flipped.

oh?  not so for me?  Although I questions why you are adding the
-analyze flag. This will cause mnc2nii to write an old style (non
oriented) analyze file as opposed to a Nifti 2-file format which I
suspect is what you want.  My test:

   $ mincreshape -dimrange xspace=0,100 \
      icbm_avg_152_t1_tal_lin.mnc /tmp/out.mnc

   $ mnc2nii out.mnc out.hdr
   $ nii2mnc out.hdr two.mnc

   $ register out.mnc two.mnc

Beyond image scaling issues, this is fine?  What versions are you
running?  myself:

gordon:tmp$ nii2mnc -version
program: 2.0.09
libminc: 2.0.09
netcdf : 3.6.1 of Mar  5 2007 07:16:16 $

> 3. In the case that Lindsay reports, at least 3 different analyze
> viewers agree that the x-axis is flipped (which I understand not to be
> an issue of viewer/radiological/neurological convention, as evidenced
> by a physical marker in the image).

Is this when using a -analyze flag?

> So notwithstanding MINC's conceptual superiority w/respect to
> coordinate space handling and etc, it still makes no sense to me that
> this conversion appears to not *ever* work correctly, nor that the
> conversion on 'simple' files is not bijective when using the
> conversion tools provided by MINC itself. Something just smells wrong
> here...

Myself I prefer to code to the spec and then add kludges later on for
specific cases if needs be.  Meaning I dont think there would be a
problem to write a quick and dirty conversion (shell) script called
mnc2fsl for example.

> Where does one actually find the formal specifications of
> ANALYZE/NIFTi? For ANALYZE I keep stumbling on the same pdf describing
> the ANALYZE 7.5 file format, but that is less than informative.

The old analyze spec used to be on the Mayo site. But I just went
looking for it an found nothing.  There is always the old .h file that
went with it.  As for nifti, the best site is the sourceforge page.

   http://niftilib.sourceforge.net/

In any case, if what you describe above really is a bug I am more than
happy to fix it.


-- 
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://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From claude at bic.mni.mcgill.ca  Mon Sep 10 13:40:22 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Mon, 10 Sep 2007 13:40:22 -0400 (EDT)
Subject: [MINC-users]  Bug reports?
Message-ID: <200709101740.l8AHeMRt9727270@yorick.bic.mni.mcgill.ca>


Hi Simon,

I tried to reproduce the segmentation fault "bug" with mincstats on a zero
volume. I used your test.mnc.gz but couldn't reproduce the bug with a 32-bit
Linux (Debian) compilation:

scarus //tmp/claude > mincstats -version
program: 1.5.1
libminc: 1.5.1
netcdf : 3.6.1 of Sep 10 2007 13:19:36 $

Is netcdf 3.6.2 the cause of the problem??? I'll try it out.

On what type of architecture have you encountered this problem? 32 or 64 bits?
Which compiler? I'm using gcc 3.3.5. 

Out of curiosity, is this a version of minc-1.5.1 that you modified to free
some memory? Beware that your added free for volume->coordinate_system_name
is incorrect - it should only be present in delete_volume. 

bye

Claude

From se at hst.aau.dk  Tue Sep 11 05:12:41 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Tue, 11 Sep 2007 11:12:41 +0200
Subject: [MINC-users] Bug reports?
In-Reply-To: <200709101740.l8AHeMRt9727270@yorick.bic.mni.mcgill.ca>
References: <200709101740.l8AHeMRt9727270@yorick.bic.mni.mcgill.ca>
Message-ID: <46E65C09.40309@hst.aau.dk>

Hi Claude,

> On what type of architecture have you encountered this problem? 32 or 64 bits?
> Which compiler? I'm using gcc 3.3.5.

It's 64 bit ubuntu and gcc 4.1.2:
]$ uname -rm
2.6.20.3-ubuntu1-custom.bai1bai01 x86_64
]$ gcc --version
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

I have now noticed that the kernel gives these messages:

Sep  6 16:16:42 cerebrum01 kernel: [58715.118098] mincmorph[4404]: 
segfault at 00000000000159a0 rip 0000000000409d61 rsp 00007fff0c884480 
error 4
Sep  6 17:20:29 cerebrum01 kernel: [46126.845545] mincstats[16042]: 
segfault at fffffffe0064b250 rip 0000000000402892 rsp 00007fff7c9d39e0 
error 4

Apparently the processes fail silently as no seg. faults are present i 
my user space logfiles...?

> Out of curiosity, is this a version of minc-1.5.1 that you modified to free
> some memory? Beware that your added free for volume->coordinate_system_name
> is incorrect - it should only be present in delete_volume. 

No, it's a clean minc-1.5.1 version. I realized that i probably 
shouldn't fiddle too much with volume_io interior, so I compiled a fresh 
version.

Simon

From mojdeh.zamyadi at utoronto.ca  Wed Sep 12 11:07:57 2007
From: mojdeh.zamyadi at utoronto.ca (mojdeh.zamyadi@utoronto.ca)
Date: Wed, 12 Sep 2007 11:07:57 -0400
Subject: [MINC-users] minctracc (matlab and measure options)
Message-ID: <20070912110757.1rywy7i7kscc8gs0@webmail.utoronto.ca>

Hi all,

I was wondering if anyone of you has used 'matlab' and 'measure'  
options of "minctracc".

Here is the description of these two options in minctracc -help:
####################################################
Options for measurement comparison.
  -matlab: Output curves for selected objective function vs parameter. ""
  -num_steps: Number of steps at which to measure obj fn for matlab output.
              Default value: 15
  -measure: Output value of each obj. func. for given x-form. ""
####################################################
To use the -matlab option I type the following command:

minctracc -step 0.25 0.25 0.25 -simplex 1 -est_center  
-est_translations -w_translation 0.4 0.4 0.4 -lsq6  
My_Documents/mouseEmbryo/MRI/source.mnc  
My_Documents/mouseEmbryo/MRI/target.mnc -debug -verbose 3 -matlab  
testMatlab

and when I open 'testMatlab' file using matlab (or any text editor), I  
have the following:

tx = [
-0.400000 -2.074393 0.070810
-0.373333 -2.047726 0.069301
...
];
ty = [
-0.400000 -0.332535 0.078986
-0.373333 -0.305869 0.077093
...
];
tz = [
-0.400000 -0.219742 0.091168
-0.373333 -0.193076 0.087828
...
];
rx = [
-0.017453 -0.017453 0.064778
-0.016290 -0.016290 0.064691
...
];
ry = [
-0.017453 -0.017453 0.062866
-0.016290 -0.016290 0.062887
...
];
rz = [
-0.017453 -0.017453 0.064487
-0.016290 -0.016290 0.064405
...
];

(by ... I mean there are more rows that I didn't include here!!)

I am not sure what these numbers represent. Does anyone have an idea  
what these numbers are?

Thanks a lot,

Mojdeh





From a.janke at gmail.com  Wed Sep 12 11:14:45 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 13 Sep 2007 01:14:45 +1000
Subject: [MINC-users] minctracc (matlab and measure options)
In-Reply-To: <20070912110757.1rywy7i7kscc8gs0@webmail.utoronto.ca>
References: <20070912110757.1rywy7i7kscc8gs0@webmail.utoronto.ca>
Message-ID: <d747ed50709120814l5e46c079v6f4296fddf84c97b@mail.gmail.com>

Hi,

This output could be considered as "debug" from minctracc. I myself
have never used it but I suspect that it will have something to do
with plots of the simplex space for each of the indicated axes. (ie:
ry == rotation about the Y axis).

I would guess that there is probably only one person who knows for
sure though and that would be Louis Collins (the Author).


a

On 9/13/07, mojdeh.zamyadi at utoronto.ca <mojdeh.zamyadi at utoronto.ca> wrote:
> Hi all,
>
> I was wondering if anyone of you has used 'matlab' and 'measure'
> options of "minctracc".
>
> Here is the description of these two options in minctracc -help:
> ####################################################
> Options for measurement comparison.
>   -matlab: Output curves for selected objective function vs parameter. ""
>   -num_steps: Number of steps at which to measure obj fn for matlab output.
>               Default value: 15
>   -measure: Output value of each obj. func. for given x-form. ""
> ####################################################
> To use the -matlab option I type the following command:
>
> minctracc -step 0.25 0.25 0.25 -simplex 1 -est_center
> -est_translations -w_translation 0.4 0.4 0.4 -lsq6
> My_Documents/mouseEmbryo/MRI/source.mnc
> My_Documents/mouseEmbryo/MRI/target.mnc -debug -verbose 3 -matlab
> testMatlab
>
> and when I open 'testMatlab' file using matlab (or any text editor), I
> have the following:
>
> tx = [
> -0.400000 -2.074393 0.070810
> -0.373333 -2.047726 0.069301
> ...
> ];
> ty = [
> -0.400000 -0.332535 0.078986
> -0.373333 -0.305869 0.077093
> ...
> ];
> tz = [
> -0.400000 -0.219742 0.091168
> -0.373333 -0.193076 0.087828
> ...
> ];
> rx = [
> -0.017453 -0.017453 0.064778
> -0.016290 -0.016290 0.064691
> ...
> ];
> ry = [
> -0.017453 -0.017453 0.062866
> -0.016290 -0.016290 0.062887
> ...
> ];
> rz = [
> -0.017453 -0.017453 0.064487
> -0.016290 -0.016290 0.064405
> ...
> ];
>
> (by ... I mean there are more rows that I didn't include here!!)
>
> I am not sure what these numbers represent. Does anyone have an idea
> what these numbers are?
>
> Thanks a lot,
>
> Mojdeh
>
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



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

From mojdeh.zamyadi at utoronto.ca  Wed Sep 12 12:57:14 2007
From: mojdeh.zamyadi at utoronto.ca (mojdeh.zamyadi@utoronto.ca)
Date: Wed, 12 Sep 2007 12:57:14 -0400
Subject: [MINC-users] more minctracc questions!
Message-ID: <20070912125714.gu3q1512dwoocsss@webmail.utoronto.ca>

Hi all,

Can someone please explain what exactly '-w_rotation' and  
'w_translation' mean in minctracc? I know these are weight parameters  
that are used in the simplex optimization method that is used in  
minctracc, but I was wondering if anyone can give a more detailed  
description of these params.

I am trying to register mouse embryos using minctracc. Since the  
parameters in minctracc has been optimized for human brain (right?!) I  
have to change them since mouse embryos are about 20 times smaller  
than human brain. The other thing is that, unlike brains, these  
embryos can be in very different orientations (eg. one can face left  
and the other one can be upside down and facing right!). Considering  
the scale and orientation, can someone suggest how I should optimize  
these params for registration of mouse embryos?

Also, how are -step and -simplex values determined.

Sorry for so many questions ;) and thanks in advance :)

Mojdeh


###################################
Mojdeh Zamyadi
MSc Candidate
Mouse Imaging Centre (MICe)
Hospital for Sick Children
Toronto Centre for Phenogenomics


From rcomeau at mac.com  Wed Sep 12 18:05:29 2007
From: rcomeau at mac.com (Roch M. Comeau)
Date: Wed, 12 Sep 2007 18:05:29 -0400
Subject: [MINC-users] mritotal on OS X
Message-ID: <3B0C90CA-2D26-42B2-8710-1515E2B2593F@mac.com>

Hi,

I recently installed some minc tools on a new MacBook Pro using  
andrew's installers. These create a /usr/local/bic directory instead  
of the "traditional" /usr/local/mni. I installed bicpl (1.4.3), mnc  
(1.4), display, register, mniXautoreg (0.99.3) and Getopt-Tabular  
(0.3). Everything seems to work fine except mritotal (the first  
mniautoreg thing I tried). I get the following perl error message:

Can't locate MNI/Startup.pm in @INC (@INC contains: /System/Library/ 
Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 / 
Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 / 
Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level / 
Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/ 
Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/ 
5.8.6 /Library/Perl/5.8.1 .) at /usr/local/bic/bin/mritotal line 57.
BEGIN failed--compilation aborted at /usr/local/bic/bin/mritotal line  
57.

Can someone explain what I need to fix? Given it is looking for /MNI/ 
Startup, I assume it is a path thing but don't have any idea where to  
look or fix.

Thanks for any comments.
Regards,

Roch Comeau
Rogue Research Inc.

From a.janke at gmail.com  Wed Sep 12 19:46:33 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 13 Sep 2007 09:46:33 +1000
Subject: [MINC-users] more minctracc questions!
In-Reply-To: <20070912125714.gu3q1512dwoocsss@webmail.utoronto.ca>
References: <20070912125714.gu3q1512dwoocsss@webmail.utoronto.ca>
Message-ID: <d747ed50709121646u562126dl5c52c5a3c93e3000@mail.gmail.com>

Hi,

the following is from 'man minctracc':

-w_translations <w_tx> <w_ty> <w_tz>: Optimization weight of
translation in x, y, z (default =  1.0  1.0 1.0).

-w_rotations  <w_rx> <w_ry> <w_rz>: Optimization weight of rotations
around x, y, z (default = 0.0174533
0.0174533 0.0174533).  Internally, the rotations are stored as
radians, although all user  input  is  in
degrees.  The value 0.0174533 makes one degree equivalent to 1 mm in
the optimization.

So to expand on this, these values are the inital amounts that will be
used in the optimiser for each iteration.  ie: translate 1.0mm in x, y
or z per iteration..  For rotation the amount given roughly translates
to the amount of rotation required for a movement of 1mm at the
surface of a "head shaped" object.

So yes, you will have to modify a bunch of parameters but it will
work!  As an initial quick hack, I suggest you scale your mouse heads
to roughly human size (use param2xfm and mincresample, or just
mincedit and change the step and start in the header) and get things
working.  Once this is good then scale all the values for the -w_
params and -step.

The simplex size is expressed in terms of -step so you should not have
to change this.


a


On 9/13/07, mojdeh.zamyadi at utoronto.ca <mojdeh.zamyadi at utoronto.ca> wrote:
> Hi all,
>
> Can someone please explain what exactly '-w_rotation' and
> 'w_translation' mean in minctracc? I know these are weight parameters
> that are used in the simplex optimization method that is used in
> minctracc, but I was wondering if anyone can give a more detailed
> description of these params.
>
> I am trying to register mouse embryos using minctracc. Since the
> parameters in minctracc has been optimized for human brain (right?!) I
> have to change them since mouse embryos are about 20 times smaller
> than human brain. The other thing is that, unlike brains, these
> embryos can be in very different orientations (eg. one can face left
> and the other one can be upside down and facing right!). Considering
> the scale and orientation, can someone suggest how I should optimize
> these params for registration of mouse embryos?
>
> Also, how are -step and -simplex values determined.
>
> Sorry for so many questions ;) and thanks in advance :)
>
> Mojdeh
>
>
> ###################################
> Mojdeh Zamyadi
> MSc Candidate
> Mouse Imaging Centre (MICe)
> Hospital for Sick Children
> Toronto Centre for Phenogenomics
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


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

From a.janke at gmail.com  Wed Sep 12 19:49:20 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 13 Sep 2007 09:49:20 +1000
Subject: [MINC-users] mritotal on OS X
In-Reply-To: <3B0C90CA-2D26-42B2-8710-1515E2B2593F@mac.com>
References: <3B0C90CA-2D26-42B2-8710-1515E2B2593F@mac.com>
Message-ID: <d747ed50709121649y235ab8dfs281e5ea5970194ec@mail.gmail.com>

Ah, welcome to the brave new world of minc2... :)

For all binary packages I build, I install minc2 in /usr/local/bic and
minc1 in /usr/local/mni

You need to install the mni_perllib package manually.  I have not yet
found a good way to install a perl package on OSX that will also work
in other places.  This is on packages.bic.mni.mcgill.ca/tgz  My
current approach is to just remove mni_perllib from any script that I
get my hands on and not use it in any future perl scripts given that
most of its functionality is now in base PERL libs.


a

On 9/13/07, Roch M. Comeau <rcomeau at mac.com> wrote:
> Hi,
>
> I recently installed some minc tools on a new MacBook Pro using
> andrew's installers. These create a /usr/local/bic directory instead
> of the "traditional" /usr/local/mni. I installed bicpl (1.4.3), mnc
> (1.4), display, register, mniXautoreg (0.99.3) and Getopt-Tabular
> (0.3). Everything seems to work fine except mritotal (the first
> mniautoreg thing I tried). I get the following perl error message:
>
> Can't locate MNI/Startup.pm in @INC (@INC contains: /System/Library/
> Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 /
> Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /
> Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level /
> Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/
> Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/
> 5.8.6 /Library/Perl/5.8.1 .) at /usr/local/bic/bin/mritotal line 57.
> BEGIN failed--compilation aborted at /usr/local/bic/bin/mritotal line
> 57.
>
> Can someone explain what I need to fix? Given it is looking for /MNI/
> Startup, I assume it is a path thing but don't have any idea where to
> look or fix.
>
> Thanks for any comments.
> Regards,
>
> Roch Comeau
> Rogue Research Inc.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


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

From a.janke at gmail.com  Thu Sep 13 02:42:19 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 13 Sep 2007 16:42:19 +1000
Subject: [MINC-users] Regional CBF differences
In-Reply-To: <LDECIOJNCEPJFCAHFLCCMEFDCAAA.john@absherneurology.com>
References: <mailman.3.1189008038.1162719.minc-users@bic.mni.mcgill.ca>
	<LDECIOJNCEPJFCAHFLCCMEFDCAAA.john@absherneurology.com>
Message-ID: <d747ed50709122342w1878dc47nec31e6713d49d02a@mail.gmail.com>

> I seek an automated way to determine the quantitative CBF PET changes on a
> region-by-region basis (rather than voxel by voxel).  I have 2 "baseline
> blood pressure" scans and 2 "low-blood-pressure" scans per subject.  I want
> to know how much blood pressure declined/changed in the thalamus, the
> caudate, the cingulate gyrus, and all other "standard" brain regions, like
> those defined by the Talairach atlas.
>
> I'm hoping there's an automated way to calculate these regional CBF
> differences.  I can use mincmath (Baseline1 - LowBP1, Baseline2-LowBP1,
> etc.) to run all 4 possible subtractions for each of the 4 subjects, then
> average these differnece images, again using mincmath.  However, I still
> need some way to analyze the voxels in the difference images (one per
> subject).  I'd like to do the whole brain, and print a table showing these
> average differences, by region, by subject.

OK, so do you have a masked model brain that you plan to use? (be this
the MNI model space -- icbm_152, or some other atlas with defined
areas?)

If so then I would suggest that you used a combination of mincmath (or
minccalc) as you are with mincstats using one of the masks from the
atlas you have chosen.

ie:  (where the caudate is labelled as 10 in an atlas called atlas.mnc

   mincstats -mask atlas.mnc -mask_binvalue 10 subtr-image.mnc

this will print out the mean, median, stdev, sum, etc etc of the local
region that is defined by your mask.


a

From mojdeh.zamyadi at utoronto.ca  Thu Sep 13 11:54:30 2007
From: mojdeh.zamyadi at utoronto.ca (mojdeh.zamyadi@utoronto.ca)
Date: Thu, 13 Sep 2007 11:54:30 -0400
Subject: [MINC-users] more minctracc questions!
Message-ID: <20070913115430.r6m1hf952sn48ogs@webmail.utoronto.ca>

Hi Andrew,

Thanks a lot for the hints! I just have some more questions:

I probably don't know that much about the Simplex optimization method!  
But, my initial understanding was that these weights scale the axis in  
the search space (so that the search space looks more like concentric  
circles rather than ellipses that are elongated in one direction! ...  
because in case of ellipses the algorithm may never find the min/max  
or may converge very slowly), does what I say make any sense?!! But  
after doing some experiments with different param values, I thought I  
have to set the rotation weight higher and the translation weight much  
lower in case I have embryos in completely different orientations (in  
this way the algorithm searches for a transformation with more  
rotation and not that much translation!!) again! does it make ANY  
sense?! ... So, for example one set of params that I used and got some  
result was :
-w_rotation 0.5 0.5 0.5  -w_translation 0.01 0.01 0.01 !!!!!
(I am saying SOME result, bc/ in some cases  all I was getting after  
finding the tform by minctracc and resampling the source volume, was  
either a zero volume, half of an embryo or one that was in totally  
different orientation with the target volume! ... although not  
properly registered using these params either, at least the source and  
target embryos look to be in same coordinate sys and in almost same  
orientation!)

Also, do you know if the optimization method used optimized one  
parameter (tx, ty, tz, rx, ry, rz) at a time?

I really appreciate any help and advice :)
Thanks again,

Mojdeh


From lnygard at yahoo.com  Fri Sep 14 15:48:19 2007
From: lnygard at yahoo.com (Lars Nygard)
Date: Fri, 14 Sep 2007 12:48:19 -0700 (PDT)
Subject: [MINC-users] Tag file
Message-ID: <578386.74790.qm@web50204.mail.re2.yahoo.com>

Hi everybody,
Im trying to load some points into register with a .tag file. 
I tried to use the same text as the output but Im getting an
error:
input_tag_points(): invalid header file.

Anybody knows how I can load my points into register??

thanks,
lars




      
_________________________________________________________
Alt i ?n. F? Yahoo! Mail med adressekartotek, kalender og
notisblokk. http://no.mail.yahoo.com


From a.janke at gmail.com  Sat Sep 15 17:02:07 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 16 Sep 2007 07:02:07 +1000
Subject: [MINC-users] Tag file
In-Reply-To: <578386.74790.qm@web50204.mail.re2.yahoo.com>
References: <578386.74790.qm@web50204.mail.re2.yahoo.com>
Message-ID: <d747ed50709151402p2207463bhd823ddf1273192ad@mail.gmail.com>

On 9/15/07, Lars Nygard <lnygard at yahoo.com> wrote:
> Hi everybody,
> Im trying to load some points into register with a .tag file.
> I tried to use the same text as the output but Im getting an
> error:
> input_tag_points(): invalid header file.
>
> Anybody knows how I can load my points into register??

Lars,

Do you mean that you have created your own tag file and want to load
this into register or is a tag file that "should work" and doesnt?

If you edited it, did you perhaps edit it on a windows machine and now
you have a DOS format text file?


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

From a.janke at gmail.com  Sat Sep 15 17:10:31 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 16 Sep 2007 07:10:31 +1000
Subject: [MINC-users] more minctracc questions!
In-Reply-To: <20070913115430.r6m1hf952sn48ogs@webmail.utoronto.ca>
References: <20070913115430.r6m1hf952sn48ogs@webmail.utoronto.ca>
Message-ID: <d747ed50709151410w6ec83256vfbe3b117f05b6bd6@mail.gmail.com>

> But, my initial understanding was that these weights scale the axis in
> the search space

Correct.  Well in effect they set the amount by which the algorithm
will "step" in each axis to begin with. As the algoritm converges,
these step sizes will get smaller.

> after doing some experiments with different param values, I thought I
> have to set the rotation weight higher and the translation weight much
> lower in case I have embryos in completely different orientations (in
> this way the algorithm searches for a transformation with more
> rotation and not that much translation!!) again! does it make ANY
> sense?! ...

Yes, perfect sense, the only problem that you will strike is that a
Euler angle decomposition of a rotation space (what minctracc uses) is
not smooth for large rotations (above 45deg or so) so you may have
trouble getting it to converge. There is some code in there for a
quaternion decomposition of rotation space but it is largely untested.
A quaternion decomposition of a rotation space is smooth for large R.

> Also, do you know if the optimization method used optimized one
> parameter (tx, ty, tz, rx, ry, rz) at a time?

they are all optimised simultaneously. Although of course at some
level in the code, they all occur at a finite level...

My suggestion if you have large initial rotations would be to stary
minctracc with smaller rotation weights and instead have a number of
starting transformations that involve various combinations of the
large rotations that you are getting as per FLIRT in FSL.


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

From a.janke at gmail.com  Sat Sep 15 17:34:10 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 16 Sep 2007 07:34:10 +1000
Subject: [MINC-users] Bug reports?
In-Reply-To: <46DFEBD4.3020505@hst.aau.dk>
References: <46DFB841.3090901@hst.aau.dk>
	<d747ed50709060409r1b78e29dq1ae873cbbc106477@mail.gmail.com>
	<46DFEBD4.3020505@hst.aau.dk>
Message-ID: <d747ed50709151434i190cb27bwd493ecf62badeb2@mail.gmail.com>

Hi Simon,

I cant reproduce this on 1.5.1 on netcdf 3.6.1 perhaps the problem is
related to netcdf 3.6.2?  I tried compiling against this and still no
crash though.

a

On 9/6/07, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
> Hi Andrew,
>
> Well, not much on MINC-core in there.
>
> Creating test.mnc with
>  > minccalc -expr "0" icbm_avg_152_t1_tal_lin.mnc test.mnc
> will give you a volume where mincstats crashes.
>
> My version is here
> http://www.hst.aau.dk/~se/andrew/test.mnc.gz
> (compressed nicely when there is only zeros in there :-) )
>
> Simon
>
> Andrew Janke wrote:
> > Hi Simon,
> >
> > I did set this up a while ago:
> >
> >    http://bugs.bic.mni.mcgill.ca/
> >
> > There is a project in there called MINC-core but it wasnt used much!
> > In the meantime, can you make you test.mnc available that breaks
> > mincstats?
> >
> > ta
> >
> > a
> >
> >
> > On 9/6/07, Simon Fristed Eskildsen <se at hst.aau.dk> wrote:
> >> Hi,
> >>
> >> Is someone maintaining a list of bugs in the minc tools?
> >> I occasionally come across minor bugs in various tools. Today, I noticed
> >> a discrepancy between version 1.4 and 1.5.1 of mincstats.
> >>
> >> Running mincstats on a zero-filled volume:
> >>
> >>  > mincstats test.mnc
> >> Segmentation fault
> >>  > mincstats -version
> >> program: 1.5.1
> >> libminc: 1.5.1
> >> netcdf : "3.6.2" of Jun 19 2007 10:38:40 $
> >>
> >> ]$ mincstats -version
> >> program: 1.4
> >> libminc: 1.4
> >> netcdf : 3.5.1 of Oct  5 2004 10:28:35 $
> >> ]$ mincstats test.mnc
> >> File:              test.mnc
> >> Mask file:         (null)
> >> Total voxels:      7109137
> >> ...snip...
> >>
> >> Things like this should be tracked I guess.


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

From lnygard at yahoo.com  Sat Sep 15 17:40:38 2007
From: lnygard at yahoo.com (Lars Nygard)
Date: Sat, 15 Sep 2007 14:40:38 -0700 (PDT)
Subject: [MINC-users] Tag file
Message-ID: <506520.81481.qm@web50201.mail.re2.yahoo.com>

>> If you edited it, did you perhaps edit it on a windows machine and now
>>you have a DOS format text file?
Yes Im running cygwin so when I edit files I use wordpad. 
Ive calculated some landmarks that I want to load
in register but I get an error. Ive managed to surround it by manually 
entering the coordinates but it would be easier to load the file.
regards,
lars

----- Original Message ----
From: Andrew Janke <a.janke at gmail.com>
To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
Sent: Saturday, September 15, 2007 2:02:07 PM
Subject: Re: [MINC-users] Tag file

On 9/15/07, Lars Nygard <lnygard at yahoo.com> wrote:
> Hi everybody,
> Im trying to load some points into register with a .tag file.
> I tried to use the same text as the output but Im getting an
> error:
> input_tag_points(): invalid header file.
>
> Anybody knows how I can load my points into register??

Lars,

Do you mean that you have created your own tag file and want to load
this into register or is a tag file that "should work" and doesnt?

If you edited it, did you perhaps edit it on a windows machine and now
you have a DOS format text file?


-- 
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://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users





      
_________________________________________________________
Alt i ?n. F? Yahoo! Mail med adressekartotek, kalender og
notisblokk. http://no.mail.yahoo.com


From a.janke at gmail.com  Sat Sep 15 17:50:25 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 16 Sep 2007 07:50:25 +1000
Subject: [MINC-users] Tag file
In-Reply-To: <506520.81481.qm@web50201.mail.re2.yahoo.com>
References: <506520.81481.qm@web50201.mail.re2.yahoo.com>
Message-ID: <d747ed50709151450n7180f99dqc7e16a3e28462a85@mail.gmail.com>

On 9/16/07, Lars Nygard <lnygard at yahoo.com> wrote:
> >> If you edited it, did you perhaps edit it on a windows machine and now
> >>you have a DOS format text file?
> Yes Im running cygwin so when I edit files I use wordpad.
> Ive calculated some landmarks that I want to load
> in register but I get an error. Ive managed to surround it by manually
> entering the coordinates but it would be easier to load the file.

Okie doke,

You will have to convert the file back to unix format.  Use something like this:

   $ tr -d \r < tagfile.tag > fixed_tags.tag

If you are editing these files routinely under windows I would suggest
using something like cream:

   http://cream.sourceforge.net/

It is a (very) user friendly version of vim that wont
"DOS'erise/Windows'erise" your text files.



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

From a.janke at gmail.com  Sat Sep 15 19:56:06 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 16 Sep 2007 09:56:06 +1000
Subject: [MINC-users] MINC 2.0.13
Message-ID: <d747ed50709151656p7ce0bf9aq10140b9ee830b049@mail.gmail.com>

Hi all,

Thanks to some work by Claude and others, we now have a 2.0.13 release
of MINC2.

http://packages.bic.mni.mcgill.ca/tgz/minc-2.0.13.tar.gz

I would be willing to say that this is our first stable release of
MINC2 (or at least more stable than previous versions!) There are a
few small fixes that are needed with mni_perllib and classify that I
will release shortly but beyond that all would appear good.  A few of
use (myself included) have been running this version of MINC2 for some
time now with no significant problems beyond what has been fixed in
this release.

There are a number of fixes in this release, and a new tool.  Here are
the NEWS and Changelog files:

==NEWS==
* Fixed a few small build errors for make check
* Changes to ensure there is a clean ITK minc build
* added xfmflip
* Fixed buffering and chunking for fast internal file compression
* updated nii2mnc and mnc2nii with the latest version of niftilib

==Changelog==
2007-09-13  Andrew L Janke <a.janke at gmail.com>
    * Added a few more free's for memory thanks to Claude

2007-08-24  Andrew L Janke <a.janke at gmail.com>
    * added xfmflip and man page
    * fixed a bug in the build of minccalc
    * updated nifti library for nii2mnc

2007-08-08 Claude Lepage <claude at bic.mni.mcgill.ca>
    * Increased size of MI_MAX_VAR_BUFFER_SIZE and fix chunking
    for internal file compression using hdf5
    * Modified mincconvert to use default chunking

2007-05-18  Andrew L Janke <a.janke at gmail.com>
    * Fixed up small problems with build process
    * replaced csh scripts with sh. (checks fail if no tcsh)
    * added libsrc2 to the INCLUDES. why this was not in before beats me

2006-09-01  Jonathan Harlap <jharlap at bic.mni.mcgill.ca>
    * conversion/Acr_nema - Fixed a bug causing dump_acr_nema to skip
    all elements with element number 0x0010

Once a few others out there have built this successfully I will
release Binary packages to suit.


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

From claude at bic.mni.mcgill.ca  Sat Sep 15 21:38:39 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Sat, 15 Sep 2007 21:38:39 -0400 (EDT)
Subject: [MINC-users] MINC 2.0.13
Message-ID: <200709160138.l8G1cdvR11123384@yorick.bic.mni.mcgill.ca>

Hi,

Here is my strongly suggested way of using minc2.

Set your shell environment to include (in csh):
     setenv MINC_FORCE_V2 1
     setenv MINC_COMPRESS 4

You can place those commands in your .cshrc or .bashrc (for sh
users).

This will make minc2 behave as I think it should behave: always
produce minc2 output, but seamlessly read minc1 or minc2. No need
to specify -2 on some of the tools, nor do you have to convert
your original images from minc1 to minc2. 

The second flag activates internal compression. The compression
ratio is as good as gzip and compression is very fast too that it
should always be used.

bye

Claude

From alex at bic.mni.mcgill.ca  Sat Sep 15 22:37:44 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sat, 15 Sep 2007 22:37:44 -0400
Subject: [MINC-users] MINC 2.0.13
In-Reply-To: <200709160138.l8G1cdvR11123384@yorick.bic.mni.mcgill.ca>
References: <200709160138.l8G1cdvR11123384@yorick.bic.mni.mcgill.ca>
Message-ID: <e758a6650709151937p26f572f6k3c31906ad6fbda66@mail.gmail.com>

This sounds reasonable to me - any reason why these wouldn't be
MINC2's own defaults, as opposed to having to be set by the user with
(obscure?) environment vars?

-- A

On 9/15/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> Hi,
>
> Here is my strongly suggested way of using minc2.
>
> Set your shell environment to include (in csh):
>      setenv MINC_FORCE_V2 1
>      setenv MINC_COMPRESS 4
>
> You can place those commands in your .cshrc or .bashrc (for sh
> users).
>
> This will make minc2 behave as I think it should behave: always
> produce minc2 output, but seamlessly read minc1 or minc2. No need
> to specify -2 on some of the tools, nor do you have to convert
> your original images from minc1 to minc2.
>
> The second flag activates internal compression. The compression
> ratio is as good as gzip and compression is very fast too that it
> should always be used.
>
> bye
>
> Claude
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Sun Sep 16 07:35:00 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 16 Sep 2007 21:35:00 +1000
Subject: [MINC-users] MINC 2.0.13
In-Reply-To: <e758a6650709151937p26f572f6k3c31906ad6fbda66@mail.gmail.com>
References: <200709160138.l8G1cdvR11123384@yorick.bic.mni.mcgill.ca>
	<e758a6650709151937p26f572f6k3c31906ad6fbda66@mail.gmail.com>
Message-ID: <d747ed50709160435q5aa11b3ag4d24eda3a2a1dd65@mail.gmail.com>

On 9/16/07, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
> This sounds reasonable to me - any reason why these wouldn't be
> MINC2's own defaults, as opposed to having to be set by the user with
> (obscure?) environment vars?

My plan was that these sorts of things would become default in minc
2.1.  There is no set release date for this yet as I hoping for a bit
more uptake of MINC 2.X first so that things can be tested well first.

Remember it took us 10 years to release MINC 1.0


a

From walkerlin at mail.nih.gov  Mon Sep 17 11:00:34 2007
From: walkerlin at mail.nih.gov (Walker, Lindsay (NIH/NICHD) [V])
Date: Mon, 17 Sep 2007 11:00:34 -0400
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <C190860B1ADC834399CE250C583BE5460118CB88@NIHCESMLBX7.nih.gov>
Message-ID: <C190860B1ADC834399CE250C583BE5460118CBBC@NIHCESMLBX7.nih.gov>

I just wanted to follow up on this earlier thread.  Is there anything we
can do to fix the mnc2nii -analyze orientation problem?

Thanks.

Lindsay Walker.

-----Original Message-----
From: Walker, Lindsay (NIH/NICHD) [V] 
Sent: Monday, September 10, 2007 11:33 AM
To: MINC users mailing list
Subject: Re: [MINC-users] conversion to analyze problem

Andrew,

I can answer some of these questions.  Yes, I am using the -analyze
flag, as I need to have my data in analyze format for a software
pipeline that I use.

In fact, mnc2nii converts the data correctly to nifti format (no issues
with orientation), but when I add the -analyze flag it flips the x-axis.

This axis is flipped when viewed in mipav, medx and fslview - so it is
not just one software package that is handling the data incorrectly.

The version of mnc2nii that I am using is:

mnc2nii -version
program: 1.5.1
libminc: 1.5.1
netcdf : "3.6.2"

Lindsay.

-----Original Message-----
From: Andrew Janke [mailto:a.janke at gmail.com] 
Sent: Sunday, September 09, 2007 7:52 AM
To: MINC users mailing list
Subject: Re: [MINC-users] conversion to analyze problem

> Although I am sympathetic to systemic problems and possible
> ambiguities of the MINC <-> ANALYZE format conversions, I am as yet
> not convinced that we are not looking at a bug; nor that the behaviour
> of mnc2nii/nii2mnc can/should not be improved to "work" for users in
> 95% of the cases instead of 5% (if that). Reasons being:

Okie doke...

> 1. I am yet to encounter the first case where flipping was not
> necessary (and I have done my fair share - probably more - of these
> types of conversions)

OK.  (has not been my experience?  I will check with the XNAT guys and
see what their experience is).

> 2. If I take a MINC volume (without funky directions cosines and etc),
> run mnc2nii (-analyze) followed by nii2mnc, the x-axis comes out
> flipped.

oh?  not so for me?  Although I questions why you are adding the
-analyze flag. This will cause mnc2nii to write an old style (non
oriented) analyze file as opposed to a Nifti 2-file format which I
suspect is what you want.  My test:

   $ mincreshape -dimrange xspace=0,100 \
      icbm_avg_152_t1_tal_lin.mnc /tmp/out.mnc

   $ mnc2nii out.mnc out.hdr
   $ nii2mnc out.hdr two.mnc

   $ register out.mnc two.mnc

Beyond image scaling issues, this is fine?  What versions are you
running?  myself:

gordon:tmp$ nii2mnc -version
program: 2.0.09
libminc: 2.0.09
netcdf : 3.6.1 of Mar  5 2007 07:16:16 $

> 3. In the case that Lindsay reports, at least 3 different analyze
> viewers agree that the x-axis is flipped (which I understand not to be
> an issue of viewer/radiological/neurological convention, as evidenced
> by a physical marker in the image).

Is this when using a -analyze flag?

> So notwithstanding MINC's conceptual superiority w/respect to
> coordinate space handling and etc, it still makes no sense to me that
> this conversion appears to not *ever* work correctly, nor that the
> conversion on 'simple' files is not bijective when using the
> conversion tools provided by MINC itself. Something just smells wrong
> here...

Myself I prefer to code to the spec and then add kludges later on for
specific cases if needs be.  Meaning I dont think there would be a
problem to write a quick and dirty conversion (shell) script called
mnc2fsl for example.

> Where does one actually find the formal specifications of
> ANALYZE/NIFTi? For ANALYZE I keep stumbling on the same pdf describing
> the ANALYZE 7.5 file format, but that is less than informative.

The old analyze spec used to be on the Mayo site. But I just went
looking for it an found nothing.  There is always the old .h file that
went with it.  As for nifti, the best site is the sourceforge page.

   http://niftilib.sourceforge.net/

In any case, if what you describe above really is a bug I am more than
happy to fix it.


-- 
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://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

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


From claude at bic.mni.mcgill.ca  Mon Sep 17 14:32:08 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Mon, 17 Sep 2007 14:32:08 -0400 (EDT)
Subject: [MINC-users] MINC 2.0.13
Message-ID: <200709171832.l8HIW8Qf11301437@yorick.bic.mni.mcgill.ca>

Hi,

> I would be willing to say that this is our first stable release of
> MINC2 (or at least more stable than previous versions!) There are a
> few small fixes that are needed with mni_perllib and classify that I
> will release shortly but beyond that all would appear good.  A few of
> use (myself included) have been running this version of MINC2 for some
> time now with no significant problems beyond what has been fixed in
> this release.

As promised by Andrew, here are the updated auxiliary packages for minc2:

http://packages.bic.mni.mcgill.ca/tgz/classify-1.0.07.tar.gz
http://packages.bic.mni.mcgill.ca/tgz/mni_perllib-0.08.tar.gz

No change in behaviour in those packages from their previous versions, 
except to correctly "enable" minc2.

bye

Claude

From dnesbitt at pet.ubc.ca  Mon Sep 17 15:16:42 2007
From: dnesbitt at pet.ubc.ca (Dan Nesbitt)
Date: Mon, 17 Sep 2007 12:16:42 -0700
Subject: [MINC-users] EMMA for MINC 2.x
Message-ID: <46EED29A.7060907@pet.ubc.ca>

I was wondering if anyone is working on porting EMMA to MINC 2.x?

It looks like from the source code that EMMA uses some NetCDF 
definitions and library calls that would require some effort to port to 
MINC 2.x (w/HDF5).

Thanks,
Dan

-- 
Dan Nesbitt, P.Eng
Software Engineer
Pacific Parkinson's Research Centre
University of British Columbia


From alex at bic.mni.mcgill.ca  Mon Sep 17 17:11:15 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Mon, 17 Sep 2007 17:11:15 -0400
Subject: [MINC-users] conversion to analyze problem
In-Reply-To: <C190860B1ADC834399CE250C583BE5460118CBBC@NIHCESMLBX7.nih.gov>
References: <C190860B1ADC834399CE250C583BE5460118CB88@NIHCESMLBX7.nih.gov>
	<C190860B1ADC834399CE250C583BE5460118CBBC@NIHCESMLBX7.nih.gov>
Message-ID: <e758a6650709171411pc3eb89ct5f1832a3741671a1@mail.gmail.com>

I have been somewhat stumped, as when I wrote my message last week I
did a number of minc-analyze-minc conversions and found the x-axis to
be flipped in that process. But then after Andrew's message I ran some
more tests, and now I'm not sure if I was in a twilight zone myself or
Andrew managed to change reality somehow - but I have not been able to
reproduce that  anymore :-( At this moment, any 'mnc2nii -analyze;
nii2mnc' loop i run appears to be internally consistent (not flip),
and i have no clue how I managed to get it to flip before.

Be that as it may, having looked at what people write on L/R sidedness
and how various tools treat it really is a sordid mess, as evidenced
by at least two web pages

   http://www.grahamwideman.com/gw/brain/orientation/orientterms.htm
   http://eeg.sourceforge.net/mri_orientation_notes.html

Since there does not seem to a 'right' way to represent orientaton in
ANALYZE, establishing whether or not 'mnc2nii -analyze'  does the
"right" thing is muddy territory. But if there is no standard, then
perhaps 'mnc2nii -analyze' should something more sensible and follow
the same (non-)standard that the tools that Lindsay refers to (MIPAV,
MEDx, FSLview) apparently follow - at least they appear to agree
amongst themselves.

But I'm afraid that none of this may be terribly helpful to you, so -
as much as I dislike it - I would suggest you to work around the
problem. I see a couple of options:

- teach your code to read NIFTI-1 (or MINC ;-) instead of ANALYZE
- flip the ANALYZE images that come out of 'mnc2nii -analyze'
- flip the MINC images before you feed them to mnc2nii

As a side note, I would suggest you to start using the latest version
of MINC and the associated conversion tools (2.0.13 just came out).

-- Alex


On 9/17/07, Walker, Lindsay (NIH/NICHD) [V] <walkerlin at mail.nih.gov> wrote:
> I just wanted to follow up on this earlier thread.  Is there anything we
> can do to fix the mnc2nii -analyze orientation problem?
>
> Thanks.
>
> Lindsay Walker.
>
> -----Original Message-----
> From: Walker, Lindsay (NIH/NICHD) [V]
> Sent: Monday, September 10, 2007 11:33 AM
> To: MINC users mailing list
> Subject: Re: [MINC-users] conversion to analyze problem
>
> Andrew,
>
> I can answer some of these questions.  Yes, I am using the -analyze
> flag, as I need to have my data in analyze format for a software
> pipeline that I use.
>
> In fact, mnc2nii converts the data correctly to nifti format (no issues
> with orientation), but when I add the -analyze flag it flips the x-axis.
>
> This axis is flipped when viewed in mipav, medx and fslview - so it is
> not just one software package that is handling the data incorrectly.
>
> The version of mnc2nii that I am using is:
>
> mnc2nii -version
> program: 1.5.1
> libminc: 1.5.1
> netcdf : "3.6.2"
>
> Lindsay.
>
> -----Original Message-----
> From: Andrew Janke [mailto:a.janke at gmail.com]
> Sent: Sunday, September 09, 2007 7:52 AM
> To: MINC users mailing list
> Subject: Re: [MINC-users] conversion to analyze problem
>
> > Although I am sympathetic to systemic problems and possible
> > ambiguities of the MINC <-> ANALYZE format conversions, I am as yet
> > not convinced that we are not looking at a bug; nor that the behaviour
> > of mnc2nii/nii2mnc can/should not be improved to "work" for users in
> > 95% of the cases instead of 5% (if that). Reasons being:
>
> Okie doke...
>
> > 1. I am yet to encounter the first case where flipping was not
> > necessary (and I have done my fair share - probably more - of these
> > types of conversions)
>
> OK.  (has not been my experience?  I will check with the XNAT guys and
> see what their experience is).
>
> > 2. If I take a MINC volume (without funky directions cosines and etc),
> > run mnc2nii (-analyze) followed by nii2mnc, the x-axis comes out
> > flipped.
>
> oh?  not so for me?  Although I questions why you are adding the
> -analyze flag. This will cause mnc2nii to write an old style (non
> oriented) analyze file as opposed to a Nifti 2-file format which I
> suspect is what you want.  My test:
>
>    $ mincreshape -dimrange xspace=0,100 \
>       icbm_avg_152_t1_tal_lin.mnc /tmp/out.mnc
>
>    $ mnc2nii out.mnc out.hdr
>    $ nii2mnc out.hdr two.mnc
>
>    $ register out.mnc two.mnc
>
> Beyond image scaling issues, this is fine?  What versions are you
> running?  myself:
>
> gordon:tmp$ nii2mnc -version
> program: 2.0.09
> libminc: 2.0.09
> netcdf : 3.6.1 of Mar  5 2007 07:16:16 $
>
> > 3. In the case that Lindsay reports, at least 3 different analyze
> > viewers agree that the x-axis is flipped (which I understand not to be
> > an issue of viewer/radiological/neurological convention, as evidenced
> > by a physical marker in the image).
>
> Is this when using a -analyze flag?
>
> > So notwithstanding MINC's conceptual superiority w/respect to
> > coordinate space handling and etc, it still makes no sense to me that
> > this conversion appears to not *ever* work correctly, nor that the
> > conversion on 'simple' files is not bijective when using the
> > conversion tools provided by MINC itself. Something just smells wrong
> > here...
>
> Myself I prefer to code to the spec and then add kludges later on for
> specific cases if needs be.  Meaning I dont think there would be a
> problem to write a quick and dirty conversion (shell) script called
> mnc2fsl for example.
>
> > Where does one actually find the formal specifications of
> > ANALYZE/NIFTi? For ANALYZE I keep stumbling on the same pdf describing
> > the ANALYZE 7.5 file format, but that is less than informative.
>
> The old analyze spec used to be on the Mayo site. But I just went
> looking for it an found nothing.  There is always the old .h file that
> went with it.  As for nifti, the best site is the sourceforge page.
>
>    http://niftilib.sourceforge.net/
>
> In any case, if what you describe above really is a bug I am more than
> happy to fix it.
>
>
> --
> 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://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From sean at rogue-research.com  Tue Sep 18 14:58:07 2007
From: sean at rogue-research.com (Sean McBride)
Date: Tue, 18 Sep 2007 14:58:07 -0400
Subject: [MINC-users] MINC 2.0.13
In-Reply-To: <d747ed50709151656p7ce0bf9aq10140b9ee830b049@mail.gmail.com>
References: <d747ed50709151656p7ce0bf9aq10140b9ee830b049@mail.gmail.com>
Message-ID: <20070918185807.236230475@smtp1.sympatico.ca>

On 9/16/07 9:56 AM, Andrew Janke said:

>Thanks to some work by Claude and others, we now have a 2.0.13 release
>of MINC2.
>
>http://packages.bic.mni.mcgill.ca/tgz/minc-2.0.13.tar.gz
>
>I would be willing to say that this is our first stable release of
>MINC2

Great!

Perhaps updating
<http://www.bic.mni.mcgill.ca/software/minc/>

is in order? :)

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




From alex at bic.mni.mcgill.ca  Tue Sep 18 20:09:22 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Tue, 18 Sep 2007 20:09:22 -0400
Subject: [MINC-users] MINC 2.0.13
In-Reply-To: <d747ed50709151656p7ce0bf9aq10140b9ee830b049@mail.gmail.com>
References: <d747ed50709151656p7ce0bf9aq10140b9ee830b049@mail.gmail.com>
Message-ID: <e758a6650709181709x5f04493cm50edefea91806c3f@mail.gmail.com>

Anybody tried to build this package yet? It does not seem to work out
of the box:

% ./configure --prefix=/usr/local/bic
% make
depbase=`echo conversion/nifti1/mnc2nii.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
        gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
-I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema     -g
-O2 -MT conversion/nifti1/mnc2nii.o -MD -MP -MF $depbase.Tpo -c -o
conversion/nifti1/mnc2nii.o conversion/nifti1/mnc2nii.c &&\
        mv -f $depbase.Tpo $depbase.Po
conversion/nifti1/mnc2nii.c:1:19: minc2.h: No such file or directory
make[2]: *** [conversion/nifti1/mnc2nii.o] Error 1
make[2]: Leaving directory `/usr/local/src/minc-2.0.13'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/minc-2.0.13'
make: *** [all] Error 2

$ find . -name minc2.h
./libsrc2/minc2.h

Looks like there is a problem with the -I list. It's including
./libsrc, but not ./libsrc2 where minc2.h seems to live.

-- A

On 9/15/07, Andrew Janke <a.janke at gmail.com> wrote:
> Hi all,
>
> Thanks to some work by Claude and others, we now have a 2.0.13 release
> of MINC2.
>
> http://packages.bic.mni.mcgill.ca/tgz/minc-2.0.13.tar.gz
>
> I would be willing to say that this is our first stable release of
> MINC2 (or at least more stable than previous versions!) There are a
> few small fixes that are needed with mni_perllib and classify that I
> will release shortly but beyond that all would appear good.  A few of
> use (myself included) have been running this version of MINC2 for some
> time now with no significant problems beyond what has been fixed in
> this release.
>
> There are a number of fixes in this release, and a new tool.  Here are
> the NEWS and Changelog files:
>
> ==NEWS==
> * Fixed a few small build errors for make check
> * Changes to ensure there is a clean ITK minc build
> * added xfmflip
> * Fixed buffering and chunking for fast internal file compression
> * updated nii2mnc and mnc2nii with the latest version of niftilib
>
> ==Changelog==
> 2007-09-13  Andrew L Janke <a.janke at gmail.com>
>     * Added a few more free's for memory thanks to Claude
>
> 2007-08-24  Andrew L Janke <a.janke at gmail.com>
>     * added xfmflip and man page
>     * fixed a bug in the build of minccalc
>     * updated nifti library for nii2mnc
>
> 2007-08-08 Claude Lepage <claude at bic.mni.mcgill.ca>
>     * Increased size of MI_MAX_VAR_BUFFER_SIZE and fix chunking
>     for internal file compression using hdf5
>     * Modified mincconvert to use default chunking
>
> 2007-05-18  Andrew L Janke <a.janke at gmail.com>
>     * Fixed up small problems with build process
>     * replaced csh scripts with sh. (checks fail if no tcsh)
>     * added libsrc2 to the INCLUDES. why this was not in before beats me
>
> 2006-09-01  Jonathan Harlap <jharlap at bic.mni.mcgill.ca>
>     * conversion/Acr_nema - Fixed a bug causing dump_acr_nema to skip
>     all elements with element number 0x0010
>
> Once a few others out there have built this successfully I will
> release Binary packages to suit.
>
>
> --
> 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://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From claude at bic.mni.mcgill.ca  Tue Sep 18 20:23:00 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Tue, 18 Sep 2007 20:23:00 -0400 (EDT)
Subject: [MINC-users] MINC 2.0.13
References: <d747ed50709151656p7ce0bf9aq10140b9ee830b049@mail.gmail.com>
Message-ID: <200709190023.l8J0N0w111489905@yorick.bic.mni.mcgill.ca>

Alex, 

I guess that if you are using minc-2.0.13, you should specify --with-minc2
in your ./configure line.

In fact, I use:
  ./configure --with-minc2 --enable-shared=no --enable-static=yes --enable-acr-nema --enable-minc2

Can you try this out? You can omit shared/static flags if you want.

Claude

> Anybody tried to build this package yet? It does not seem to work out
> of the box:
> 
> % ./configure --prefix=/usr/local/bic
> % make
> depbase=`echo conversion/nifti1/mnc2nii.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
>         gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
> -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema     -g
> -O2 -MT conversion/nifti1/mnc2nii.o -MD -MP -MF $depbase.Tpo -c -o
> conversion/nifti1/mnc2nii.o conversion/nifti1/mnc2nii.c &&\
>         mv -f $depbase.Tpo $depbase.Po
> conversion/nifti1/mnc2nii.c:1:19: minc2.h: No such file or directory
> make[2]: *** [conversion/nifti1/mnc2nii.o] Error 1
> make[2]: Leaving directory `/usr/local/src/minc-2.0.13'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/local/src/minc-2.0.13'
> make: *** [all] Error 2
> 
> $ find . -name minc2.h
> ./libsrc2/minc2.h
> 
> Looks like there is a problem with the -I list. It's including
> ./libsrc, but not ./libsrc2 where minc2.h seems to live.



From alex at bic.mni.mcgill.ca  Tue Sep 18 21:40:08 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Tue, 18 Sep 2007 21:40:08 -0400
Subject: [MINC-users] MINC 2.0.13
In-Reply-To: <200709190023.l8J0N0w111489905@yorick.bic.mni.mcgill.ca>
References: <d747ed50709151656p7ce0bf9aq10140b9ee830b049@mail.gmail.com>
	<200709190023.l8J0N0w111489905@yorick.bic.mni.mcgill.ca>
Message-ID: <e758a6650709181840x566038d2xe18ac5a6d4a20c95@mail.gmail.com>

OK, well. I'm going through this pretending to be a naive user, which
hope will be instructive.

Specifying --with-minc2 does not appear to do anything. Specifying
--enable-minc2 ends up with:

  configure: error: cannot find required library hdf5

So fine, I need hdf5, I sort of knew that ;)

Note: why would I need to specify --enable-minc2 when  am trying to
build minc2? That seems counterintuitive, to put it mildly. Especially
since it won't build without specifying that option, I would call this
a bug.

Anyways, continuing on, let's hunt for hdf5. On a debian system,
'apt-cache libhdf5' tells me there are 3 different versions (serial,
lam, and mpich). Which one do i choose? Let's choose 'serial' (seems
the least threatening). Still:

  configure: error: cannot find required library hdf5

# ls -al /usr/lib/libhdf5*
lrwxrwxrwx  1 root root      22 Sep 18 21:06
/usr/lib/libhdf5-1.6.2.so.0 -> libhdf5-1.6.2.so.0.0.0
-rw-r--r--  1 root root 1089000 May 21  2004 /usr/lib/libhdf5-1.6.2.so.0.0.0
lrwxrwxrwx  1 root root      26 Sep 18 21:06
/usr/lib/libhdf5_cpp-1.6.2.so.0 ->libhdf5_cpp-1.6.2.so.0.0.0
-rw-r--r--  1 root root  228196 May 21  2004 /usr/lib/libhdf5_cpp-1.6.2.so.0.0.0

OK, so I guess minc just doesn't like this version of hdf5?

Fine. Let's remove the deb package and install from the 1.6.1 package
from packages.bic.mni.mcgill.ca then.

Ah, now it configures and compiles. So minc2 requires hdf5-1.6.1?

My main question is: where can I find instructions on how to build and
install minc2? The README states:

"For building and installation instructions, refer to the files
INSTALL.minc and INSTALL." INSTALL exists but only talks about generic
installation procedures. there is no file called INSTALL.minc.

So I still have no clue where to find installation instructions, and
google or the wiki doesn't help me. This should be improved...

In any case, an hour later I have less hair, but appear to have a
working installation of MINC2.

-- A

On 9/18/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> Alex,
>
> I guess that if you are using minc-2.0.13, you should specify --with-minc2
> in your ./configure line.
>
> In fact, I use:
>   ./configure --with-minc2 --enable-shared=no --enable-static=yes --enable-acr-nema --enable-minc2
>
> Can you try this out? You can omit shared/static flags if you want.
>
> Claude
>
> > Anybody tried to build this package yet? It does not seem to work out
> > of the box:
> >
> > % ./configure --prefix=/usr/local/bic
> > % make
> > depbase=`echo conversion/nifti1/mnc2nii.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> >         gcc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
> > -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema     -g
> > -O2 -MT conversion/nifti1/mnc2nii.o -MD -MP -MF $depbase.Tpo -c -o
> > conversion/nifti1/mnc2nii.o conversion/nifti1/mnc2nii.c &&\
> >         mv -f $depbase.Tpo $depbase.Po
> > conversion/nifti1/mnc2nii.c:1:19: minc2.h: No such file or directory
> > make[2]: *** [conversion/nifti1/mnc2nii.o] Error 1
> > make[2]: Leaving directory `/usr/local/src/minc-2.0.13'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/usr/local/src/minc-2.0.13'
> > make: *** [all] Error 2
> >
> > $ find . -name minc2.h
> > ./libsrc2/minc2.h
> >
> > Looks like there is a problem with the -I list. It's including
> > ./libsrc, but not ./libsrc2 where minc2.h seems to live.
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From steve at sumost.ca  Tue Sep 18 23:15:21 2007
From: steve at sumost.ca (Steve M. Robbins)
Date: Tue, 18 Sep 2007 22:15:21 -0500
Subject: [MINC-users] MINC 2.0.13
Message-ID: <20070919031520.GF6592@sumost.ca>

On Sun, Sep 16, 2007 at 09:56:06AM +1000, Andrew Janke wrote:
> Hi all,
> 
> Thanks to some work by Claude and others, we now have a 2.0.13 release
> of MINC2.
> 
> http://packages.bic.mni.mcgill.ca/tgz/minc-2.0.13.tar.gz
> 
> I would be willing to say that this is our first stable release of
> MINC2 (or at least more stable than previous versions!) 

That's good news.  I'd like to package this version for Debian, either
alongside the current Debian minc package (version 1.5) or replacing
it.

The library versioning, however, remains a problem.  Packagers such as
Debian prefer to ship shared libraries.  For this to work
successfully, the software must correctly version the shared libraries.
Since you're using libtool, you need only follow the rules outlined
in http://www.gnu.org/software/libtool/manual.html#Versioning,
specifically section 6.3.

It would be helpful if the MINC maintainers would commit to following
this procedure.  Is this possible?

Thanks,
-Steve

From claude at bic.mni.mcgill.ca  Wed Sep 19 14:11:37 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Wed, 19 Sep 2007 14:11:37 -0400 (EDT)
Subject: [MINC-users] Bug reports?
Message-ID: <200709191811.l8JIBbB111705711@yorick.bic.mni.mcgill.ca>

Hi Simon and Andrew,

Surprise! I found an example of a zero volume (minc2) that causes a seg fault
with mincstats -world_only. However, I couldn't reproduce it with Simon's zero
volume. I'm looking into it right now.

Claude

From a.janke at gmail.com  Wed Sep 26 21:13:58 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 27 Sep 2007 11:13:58 +1000
Subject: [MINC-users] Bug reports?
In-Reply-To: <200709191811.l8JIBbB111705711@yorick.bic.mni.mcgill.ca>
References: <200709191811.l8JIBbB111705711@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50709261813y1837f747i5f1dfa8c037098a1@mail.gmail.com>

This bug is now squashed in CVS for MINC2 thanks to Claude.

Expect it in the next release.


a

On 9/20/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> Hi Simon and Andrew,
>
> Surprise! I found an example of a zero volume (minc2) that causes a seg fault
> with mincstats -world_only. However, I couldn't reproduce it with Simon's zero
> volume. I'm looking into it right now.
>
> Claude
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


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

From vikingy at gmail.com  Thu Sep 27 01:35:33 2007
From: vikingy at gmail.com (lv bin)
Date: Thu, 27 Sep 2007 13:35:33 +0800
Subject: [MINC-users] correct the non-uniformity of 10 subjects to one
	scale
In-Reply-To: <d747ed50708281005u6887c134n60cb61377036138f@mail.gmail.com>
References: <897106.14690.qm@web50107.mail.re2.yahoo.com>
	<d747ed50708281005u6887c134n60cb61377036138f@mail.gmail.com>
Message-ID: <93e2f0200709262235k5843d284n368f669aa62cdb9@mail.gmail.com>

Hi Janke,

     I also want to normalise the intensities among various subjects(such as
22 subjects),but I didn't find any introduction about how to use inormalize
from the web. I guess if I want to normalise all the subjects into the same
scale, should I use like that:
inormalize subj2.mnc subj2_inc.mnc    -mode subj1.mnc
inormalize subj3.mnc subj3_inc.mnc    -mode subj1.mnc
..........
inormalize subj22.mnc subj22_inc.mnc    -mode subj1.mnc
       is that right?

Any help is appreciated,
Thanks,

                                         bin lv


2007/8/29, Andrew Janke <a.janke at gmail.com>:
>
> On 8/23/07, xingfeng lee <spmlxf at yahoo.com> wrote:
> >  I have 10 subjects, suj1,subj2,..,subj10. I want to do nu_correct for
> these subjects.
> >  How can I do these subjects as a group (correct the non-uniformity of
> all subjects to one scale) ? Is it the same as i do it individually using:
> nu_correct subj1.mnc subj1_correct_output.mnc ?
>
>
> nu_correct works on images individually.  If you want to normalise
> intensities between various minc files then you want inormalize.
>
>
> --
> 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://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From ed.gronenschild at mi.unimaas.nl  Thu Sep 27 05:58:49 2007
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Thu, 27 Sep 2007 11:58:49 +0200
Subject: [MINC-users] Details about cortical surface object file
Message-ID: <99FAB133-85BF-43F8-AF8B-1109FB5A3D5D@mi.unimaas.nl>

Hi,

I would like to import the output file (extension .obj) of  
cortical_surface
into a private Mac OS X application. Is there a description of this file
and how to read and use it. Of course, I could go through the source
files of Display, but that would take me a lot of time.

Regards,
Ed

From se at hst.aau.dk  Thu Sep 27 06:52:06 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 27 Sep 2007 12:52:06 +0200
Subject: [MINC-users] Details about cortical surface object file
In-Reply-To: <99FAB133-85BF-43F8-AF8B-1109FB5A3D5D@mi.unimaas.nl>
References: <99FAB133-85BF-43F8-AF8B-1109FB5A3D5D@mi.unimaas.nl>
Message-ID: <46FB8B56.8080908@hst.aau.dk>

Hi Ed,
The layout of an .obj (MNI style) file is:

Vertex header (Ex. "P 1.0 1.0 1.0 100 1 180098")
Vertex coordinates
Vertex normals
Polygon header (Ex. "359544 2")
Vertex/triangle colours
Polygon indices (defines the start of each polygon in the vertex indices 
below)
Vertex indices (defines each polygon)

Here is a simple cube in triangle polygon format with red and blue 
vertex coloring:

P 0.3 0.3 0.4 10 1 8
0 0 0
0 0 100
0 100 0
0 100 100
100 0 0
100 0 100
100 100 0
100 100 100

-0.666667 -0.333333 -0.666667
-0.333333 -0.666667 0.666667
-0.408248 0.816497 -0.408248
-0.816497 0.408248 0.408248
0.408248 -0.816497 -0.408248
0.816497 -0.408248 0.408248
0.666667 0.333333 -0.666667
0.333333 0.666667 0.666667

12 2
0.0 0.0 1.0 1
0.0 0.0 1.0 1
0.0 0.0 1.0 1
0.0 0.0 1.0 1
1.0 0.0 0.0 1
1.0 0.0 0.0 1
1.0 0.0 0.0 1
1.0 0.0 0.0 1

3 6 9 12 15 18 21 24 27 30 33 36

0 1 3 0 3 2 2 3 7 2 7 6 6 7 5 6 5 4 4 5 1 4 1 0 1 5 7 1 7 3 0 2 6 0 6 4

See also http://wiki.bic.mni.mcgill.ca/index.php/ObjectFiles
The description there lacks the color information though.

Simon

Ed Gronenschild wrote:
> Hi,
> 
> I would like to import the output file (extension .obj) of  
> cortical_surface
> into a private Mac OS X application. Is there a description of this file
> and how to read and use it. Of course, I could go through the source
> files of Display, but that would take me a lot of time.
> 
> Regards,
> Ed
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From jason at bic.mni.mcgill.ca  Thu Sep 27 09:38:45 2007
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Thu, 27 Sep 2007 09:38:45 -0400
Subject: [MINC-users] Details about cortical surface object file
In-Reply-To: <46FB8B56.8080908@hst.aau.dk>
References: <99FAB133-85BF-43F8-AF8B-1109FB5A3D5D@mi.unimaas.nl>
Message-ID: <46FBB265.1070302@bic.mni.mcgill.ca>

It's also quite easy to use the bicpl C functions to read an obj file. 
Take a look at the bicInventor library for one example. Lastly we also 
have a number of converters - so if you can already read an inventor or 
VTK format file, for example, you can just convert the obj file to that 
format.

Jason

Simon Fristed Eskildsen wrote:
> Hi Ed,
> The layout of an .obj (MNI style) file is:
>
> Vertex header (Ex. "P 1.0 1.0 1.0 100 1 180098")
> Vertex coordinates
> Vertex normals
> Polygon header (Ex. "359544 2")
> Vertex/triangle colours
> Polygon indices (defines the start of each polygon in the vertex 
> indices below)
> Vertex indices (defines each polygon)
>
> Here is a simple cube in triangle polygon format with red and blue 
> vertex coloring:
>
> P 0.3 0.3 0.4 10 1 8
> 0 0 0
> 0 0 100
> 0 100 0
> 0 100 100
> 100 0 0
> 100 0 100
> 100 100 0
> 100 100 100
>
> -0.666667 -0.333333 -0.666667
> -0.333333 -0.666667 0.666667
> -0.408248 0.816497 -0.408248
> -0.816497 0.408248 0.408248
> 0.408248 -0.816497 -0.408248
> 0.816497 -0.408248 0.408248
> 0.666667 0.333333 -0.666667
> 0.333333 0.666667 0.666667
>
> 12 2
> 0.0 0.0 1.0 1
> 0.0 0.0 1.0 1
> 0.0 0.0 1.0 1
> 0.0 0.0 1.0 1
> 1.0 0.0 0.0 1
> 1.0 0.0 0.0 1
> 1.0 0.0 0.0 1
> 1.0 0.0 0.0 1
>
> 3 6 9 12 15 18 21 24 27 30 33 36
>
> 0 1 3 0 3 2 2 3 7 2 7 6 6 7 5 6 5 4 4 5 1 4 1 0 1 5 7 1 7 3 0 2 6 0 6 4
>
> See also http://wiki.bic.mni.mcgill.ca/index.php/ObjectFiles
> The description there lacks the color information though.
>
> Simon
>
> Ed Gronenschild wrote:
>> Hi,
>>
>> I would like to import the output file (extension .obj) of  
>> cortical_surface
>> into a private Mac OS X application. Is there a description of this file
>> and how to read and use it. Of course, I could go through the source
>> files of Display, but that would take me a lot of time.
>>
>> Regards,
>> Ed
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> ------------------------------------------------------------------------
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>