From Michel.Audette at medizin.uni-leipzig.de  Wed Aug  1 05:24:03 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 1 Aug 2007 11:24:03 +0200
Subject: [MINC-users] rawtominc & nu_correct difficulties
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de><ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>

Dear folks, 

subsequent to yesterday's discussion, I'm trying to run nu_correct on a volume converted from tiff to raw to minc, as the volume has significant intensity inhomogeneity, but there is apparently something that I've neglected to do in the conversion. See below, where I've used some of Vladimir Fonov's parameters.  

maudette at icaw164201:~/data/ENTdata> cat HumanS16885_Stack.gray | rawtominc -clobber -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned -zyx HumanS16885_Stack2.mnc 340 366 489
maudette at icaw164201:~/data/ENTdata> nu_correct  HumanS16885_Stack2.mnc HumanS16885_Stack2_nuc.mnc
nu_estimate_np_and_em: crashed while running volume_stats (termination status=11)
nu_correct: crashed while running nu_estimate_np_and_em (termination status=65280)

Can anyone spot the missing parameter? The program nu_correct otherwise runs fine on other MINC volumes, which have been converted from DICOM. 

Cheers, 

Michel

Michel Audette, Ph.D.
Innovation Center Computer Assisted Surgery (ICCAS)
Philipp-Rosenthal-Strasse 55
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Audette, Michel
Sent: Tue 7/31/2007 6:17 PM
To: MINC users mailing list; vladimir.fonov at gmail.com
Subject: Re: [MINC-users] rawtominc difficulties
 
Hi Vladimir, 

thanks to you too for the tip. 

Cheers, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Vladimir FONOV
Sent: Tue 7/31/2007 6:00 PM
To: MINC users mailing list
Subject: Re: [MINC-users] rawtominc difficulties
 
Hello,

On 7/31/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> when I try to perform a rawtominc, with any slice number larger than 1, I get rawtominc: Premature end of file.
> See below:
>
> maudette at icaw164201:~/data/ENTdata> rawtominc -clobber HumanS16885_Stack.mnc 489 366 1 -input HumanS16885_Stack.raw
> maudette at icaw164201:~/data/ENTdata> rawtominc -clobber HumanS16885_Stack.mnc 489 366 2 -input HumanS16885_Stack.raw
> rawtominc: Premature end of file.
> Can anyone suggest how to proceed? Is there a way of checking that my raw file was properly converted from tiff, to begin with?
>
You can check the size of the file , for example. If there are no
headers, it should be
X*Y*Z bytes long .

Also, when i was using rawtominc i was explicitly specifying some things:
rawtominc -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned
-zyx  ....



-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT1153254.txt
Url: http://www.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20070801/bdb4b2d7/ATT1153254-0001.txt

From a.janke at gmail.com  Wed Aug  1 06:31:29 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 1 Aug 2007 20:31:29 +1000
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>

Hi Michel,

nu_correct is very picky about ranges within data. Is the data
perchance all squashed into a few bits of precision?

I also seem to remember that it prefers unsigned short data from some
reason but I could be wrong on that.  Given that the ranges are going
to be rescaled anyhow, I would run it through something like mincnorm
with an output range of 0 - 100 to ensure that you have no restriction
of range effects.

send me a reply if you dont have a copy of mincnorm.


a

On 8/1/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> Dear folks,
>
> subsequent to yesterday's discussion, I'm trying to run nu_correct on a volume converted from tiff to raw to minc, as the volume has significant intensity inhomogeneity, but there is apparently something that I've neglected to do in the conversion. See below, where I've used some of Vladimir Fonov's parameters.
>
> maudette at icaw164201:~/data/ENTdata> cat HumanS16885_Stack.gray | rawtominc -clobber -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned -zyx HumanS16885_Stack2.mnc 340 366 489
> maudette at icaw164201:~/data/ENTdata> nu_correct  HumanS16885_Stack2.mnc HumanS16885_Stack2_nuc.mnc
> nu_estimate_np_and_em: crashed while running volume_stats (termination status=11)
> nu_correct: crashed while running nu_estimate_np_and_em (termination status=65280)
>
> Can anyone spot the missing parameter? The program nu_correct otherwise runs fine on other MINC volumes, which have been converted from DICOM.

From vladimir.fonov at gmail.com  Wed Aug  1 08:39:15 2007
From: vladimir.fonov at gmail.com (Vladimir FONOV)
Date: Wed, 1 Aug 2007 08:39:15 -0400
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>
Message-ID: <ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com>

Hello ,

> On 8/1/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> > Dear folks,
> >
> > subsequent to yesterday's discussion, I'm trying to run nu_correct on a volume converted from tiff to raw to minc, as the volume has significant intensity inhomogeneity, but there is apparently something that I've neglected to do in the conversion. See below, where I've used some of Vladimir Fonov's parameters.
> >
> > maudette at icaw164201:~/data/ENTdata> cat HumanS16885_Stack.gray | rawtominc -clobber -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned -zyx HumanS16885_Stack2.mnc 340 366 489
> > maudette at icaw164201:~/data/ENTdata> nu_correct  HumanS16885_Stack2.mnc HumanS16885_Stack2_nuc.mnc
> > nu_estimate_np_and_em: crashed while running volume_stats (termination status=11)
> > nu_correct: crashed while running nu_estimate_np_and_em (termination status=65280)
> >

Maybe you have to specify real coordinates:

rawtominc ........ -xstart <X> -ystart <Y> -zstart <Z> -xstep <...>
-ystep <...> -zstep <...>

-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com

From Michel.Audette at medizin.uni-leipzig.de  Wed Aug  1 11:29:40 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 1 Aug 2007 17:29:40 +0200
Subject: [MINC-users] rawtominc & nu_correct difficulties
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de><ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de><d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>
	<ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>

Dear Vladimir, 

your suggestion seemed to do the trick, in terms of allowing nu_correct to process the image. However, it seems as though the correction underestimates what is actually a pretty severe nonuniformity. 

I can forward to anyone my minc volume, in case someone has an idea what to tweak. 

Thanks to Andrew, for your suggestion too. I was about to try that next. Do you think that the byte-vs-short issue is responsible for this underestimation?

Cheers, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Vladimir FONOV
Sent: Wed 8/1/2007 2:39 PM
To: MINC users mailing list
Subject: Re: [MINC-users] rawtominc & nu_correct difficulties
 
Hello ,

> On 8/1/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> > Dear folks,
> >
> > subsequent to yesterday's discussion, I'm trying to run nu_correct on a volume converted from tiff to raw to minc, as the volume has significant intensity inhomogeneity, but there is apparently something that I've neglected to do in the conversion. See below, where I've used some of Vladimir Fonov's parameters.
> >
> > maudette at icaw164201:~/data/ENTdata> cat HumanS16885_Stack.gray | rawtominc -clobber -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned -zyx HumanS16885_Stack2.mnc 340 366 489
> > maudette at icaw164201:~/data/ENTdata> nu_correct  HumanS16885_Stack2.mnc HumanS16885_Stack2_nuc.mnc
> > nu_estimate_np_and_em: crashed while running volume_stats (termination status=11)
> > nu_correct: crashed while running nu_estimate_np_and_em (termination status=65280)
> >

Maybe you have to specify real coordinates:

rawtominc ........ -xstart <X> -ystart <Y> -zstart <Z> -xstep <...>
-ystep <...> -zstep <...>

-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users




From a.janke at gmail.com  Wed Aug  1 11:38:42 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 2 Aug 2007 01:38:42 +1000
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>
	<ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708010838u24671911k51679008539ced52@mail.gmail.com>

> I can forward to anyone my minc volume, in case someone has an idea what to tweak.
>
> Thanks to Andrew, for your suggestion too. I was about to try that next. Do you think that the byte-vs-short issue is responsible for this underestimation?

It it possible as N3 works by minimising the entropy of a histogram.
It uses a fairly sensitive method to do this so perhaps you are just
getting a restriction of range effect in the calculation of the
entropy of the histogram.

It is always worth a try!

Be sure to adjust the distance parameter if you think there is more
than just base B0 problems in there.  For example for 3T data we
generally reduce the distance to 50-70mm as opposed to the default.



a

From Michel.Audette at medizin.uni-leipzig.de  Wed Aug  1 11:47:08 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 1 Aug 2007 17:47:08 +0200
Subject: [MINC-users] rawtominc & nu_correct difficulties
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de><ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de><d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com><ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010838u24671911k51679008539ced52@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de>

The distance issue looks very relevant. This is a very small, high-res volume, with 0.078mm isotropic spacing, so that the longest axis is 38.2mm. Let me try that distance parameter then...

Thanks again, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Wed 8/1/2007 5:38 PM
To: MINC users mailing list
Subject: Re: [MINC-users] rawtominc & nu_correct difficulties
 
> I can forward to anyone my minc volume, in case someone has an idea what to tweak.
>
> Thanks to Andrew, for your suggestion too. I was about to try that next. Do you think that the byte-vs-short issue is responsible for this underestimation?

It it possible as N3 works by minimising the entropy of a histogram.
It uses a fairly sensitive method to do this so perhaps you are just
getting a restriction of range effect in the calculation of the
entropy of the histogram.

It is always worth a try!

Be sure to adjust the distance parameter if you think there is more
than just base B0 problems in there.  For example for 3T data we
generally reduce the distance to 50-70mm as opposed to the default.



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


From vladimir.fonov at gmail.com  Wed Aug  1 11:51:25 2007
From: vladimir.fonov at gmail.com (Vladimir FONOV)
Date: Wed, 1 Aug 2007 11:51:25 -0400
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>
	<ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <ea3878950708010851v641ddd0ev89d44e6bfdb0c155@mail.gmail.com>

Hello,

On 8/1/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> Dear Vladimir,
>
> your suggestion seemed to do the trick, in terms of allowing nu_correct to process the image. However, it seems as though the correction underestimates what is actually a pretty severe nonuniformity.
>
> I can forward to anyone my minc volume, in case someone has an idea what to tweak.
>
> Thanks to Andrew, for your suggestion too. I was about to try that next. Do you think that the byte-vs-short issue is responsible for this underestimation?

You can try to convert your volume to float, for doing calculations
and see if it affects anything. Also, here people came up with
'optimized' parameters for nu_correct -iter 100 -stop 0.0001 -fwhm 0.1

also, make sure that you are using latest version of N3 ( 1.10.1) i
remember that there were some issues with older versions.

-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com

From a.janke at gmail.com  Wed Aug  1 11:52:23 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 2 Aug 2007 01:52:23 +1000
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455D8@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950707310900v6c0108b4qb9449fdc08c731e0@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>
	<ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010838u24671911k51679008539ced52@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708010852m4524af85nac388f6d49e095ce@mail.gmail.com>

The distance parameter is related to field strength.  It should be set
to the distance over which you would expect a typical signal
fluctuation.  This typically amounts to one wavelength.

a

On 8/2/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> The distance issue looks very relevant. This is a very small, high-res volume, with 0.078mm isotropic spacing, so that the longest axis is 38.2mm. Let me try that distance parameter then...
>
> Thanks again,
>
> Michel
>
>
> -----Original Message-----
> From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
> Sent: Wed 8/1/2007 5:38 PM
> To: MINC users mailing list
> Subject: Re: [MINC-users] rawtominc & nu_correct difficulties
>
> > I can forward to anyone my minc volume, in case someone has an idea what to tweak.
> >
> > Thanks to Andrew, for your suggestion too. I was about to try that next. Do you think that the byte-vs-short issue is responsible for this underestimation?
>
> It it possible as N3 works by minimising the entropy of a histogram.
> It uses a fairly sensitive method to do this so perhaps you are just
> getting a restriction of range effect in the calculation of the
> entropy of the histogram.
>
> It is always worth a try!
>
> Be sure to adjust the distance parameter if you think there is more
> than just base B0 problems in there.  For example for 3T data we
> generally reduce the distance to 50-70mm as opposed to the default.
>
>
>
> a
> _______________________________________________
> 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
>
>


-- 
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 Aug  2 08:39:42 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 2 Aug 2007 22:39:42 +1000
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6901145601@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com>
	<ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010838u24671911k51679008539ced52@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010852m4524af85nac388f6d49e095ce@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145601@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708020539t7e381519n33daac2fa4fcdab0@mail.gmail.com>

> looking at the data, it appears that much of the inhomogeneity is concentrated at the sides. Moreover, I only know the resolution of the image, and don't have any info about the field strength involved. Would it be appropriate to estimate the distance based on the span the locally bright area? Currently, despite converting to short, there doesn't seem to be an effect.
>
> Andrew and Vladimir, I am including an image for your perusal.
>
> All that I know about the scan is this:
>
> Human S16885
> Homo sapiens - Human
> Inner and middle ear
> Headfile available.
> 40 mm fov
> 78.125 um isotropic voxels.
> Description - Scan is at a high resolution and has great contast.
> Segmentations available
> Reconstructions available
> QuickTime Movies available

Hi again Michel,

First I would reccomend that you only correct within mask that does
not include the white border. N3 uses histogram sharpening and I
suspect that the histogram will be swamped with a very large "white"
or high value peak.

Also with the white border saturated I suspect that it would throw the
correction off anyhow given that there is no inhomogeneity information
left in there.

As for the distance, from a look at the data I would start with a
distance of about 1/2 - 1/3 of the width of the image given what
appears to be wavelength in the picture.  Of course you would be far
better of to know thie field strength! :)



a

From Michel.Audette at medizin.uni-leipzig.de  Thu Aug  2 08:49:29 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 2 Aug 2007 14:49:29 +0200
Subject: [MINC-users] rawtominc & nu_correct difficulties
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E69011455E1@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E69011455E7@MRZS152229.medizin.uni-leipzig.de><d747ed50708010331x159b1f30v88d51ff291718c0@mail.gmail.com><ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de><d747ed50708010838u24671911k51679008539ced52@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de><d747ed50708010852m4524af85nac388f6d49e095ce@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145601@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708020539t7e381519n33daac2fa4fcdab0@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145602@MRZS152229.medizin.uni-leipzig.de>

Hi Andrew, 

thanks so much for this. I don't have your experience with the so-called beast. That's definitely a good start. 

Cheers, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Thu 8/2/2007 2:39 PM
To: Audette, Michel
Cc: MINC users mailing list
Subject: Re: [MINC-users] rawtominc & nu_correct difficulties
 
> looking at the data, it appears that much of the inhomogeneity is concentrated at the sides. Moreover, I only know the resolution of the image, and don't have any info about the field strength involved. Would it be appropriate to estimate the distance based on the span the locally bright area? Currently, despite converting to short, there doesn't seem to be an effect.
>
> Andrew and Vladimir, I am including an image for your perusal.
>
> All that I know about the scan is this:
>
> Human S16885
> Homo sapiens - Human
> Inner and middle ear
> Headfile available.
> 40 mm fov
> 78.125 um isotropic voxels.
> Description - Scan is at a high resolution and has great contast.
> Segmentations available
> Reconstructions available
> QuickTime Movies available

Hi again Michel,

First I would reccomend that you only correct within mask that does
not include the white border. N3 uses histogram sharpening and I
suspect that the histogram will be swamped with a very large "white"
or high value peak.

Also with the white border saturated I suspect that it would throw the
correction off anyhow given that there is no inhomogeneity information
left in there.

As for the distance, from a look at the data I would start with a
distance of about 1/2 - 1/3 of the width of the image given what
appears to be wavelength in the picture.  Of course you would be far
better of to know thie field strength! :)



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


From Michel.Audette at medizin.uni-leipzig.de  Thu Aug  2 11:53:52 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 2 Aug 2007 17:53:52 +0200
Subject: [MINC-users] rawtominc & nu_correct difficulties
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de><ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de><d747ed50708010838u24671911k51679008539ced52@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de><d747ed50708010852m4524af85nac388f6d49e095ce@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145601@MRZS152229.medizin.uni-leipzig.de><d747ed50708020539t7e381519n33daac2fa4fcdab0@mail.gmail.com><ea3878950708020552n79d1e68cjd36b44d57fbf33da@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145603@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950708020845s2d8fcd34o165b0427610c092f@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145606@MRZS152229.medizin.uni-leipzig.de>

Dear Vladimir, 

these results are indeed impressive. I'm working on applying it to HumanS16885.mnc right now. 

I'll be happy if I can duplicate this. 

What I'm getting with a mask, prior to trying your method, seems to heavily distort the bright area near the strong intensity changes in the dark portions. 

Cheers, 

Michel

-----Original Message-----
From: Vladimir FONOV [mailto:vladimir.fonov at gmail.com]
Sent: Thu 8/2/2007 5:45 PM
To: Audette, Michel
Cc: Andrew Janke
Subject: Re: [MINC-users] rawtominc & nu_correct difficulties
 
Hello,

On 8/2/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi Vladimir,
>
> thanks for the suggestion. The data is 3D MR microscopy. http://cbaweb2.med.unc.edu/henson_mrm/pages/Scans_Primates.html
>
I tried playing with Human13959, got some success:

rawtominc -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned
-zyx -xstep 1 -ystep 1 -zstep 1 -xstart 0 -ystart 0 -zstart 0 -clob
-oshort Human13959_Stack.mnc 176 187 256  < Human13959_Stack.gray

minccalc -expression '255-A[0]' Human13959_Stack.mnc Human13959_Stack_inv.mnc

nu_correct -clob Human13959_Stack_inv.mnc Human13959_Stack_inv_nuc.mnc
-iter 100 -stop 0.0001 -fwhm 0.1

 minccalc -expression 'clamp(255-A[0],0,255)'
Human13959_Stack_inv_nuc.mnc Human13959_Stack_nuc.mnc -clob

see attached images.

P.S. note that I used step size of 1mm instead of 0.025um as indicated
in the dataset

-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com



From Michel.Audette at medizin.uni-leipzig.de  Thu Aug  2 12:25:51 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Thu, 2 Aug 2007 18:25:51 +0200
Subject: [MINC-users] rawtominc & nu_correct difficulties
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de><ea3878950708010539v6110b029g71e652bb9c84178a@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F6@MRZS152229.medizin.uni-leipzig.de><d747ed50708010838u24671911k51679008539ced52@mail.gmail.com><160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de><d747ed50708010852m4524af85nac388f6d49e095ce@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145601@MRZS152229.medizin.uni-leipzig.de><d747ed50708020539t7e381519n33daac2fa4fcdab0@mail.gmail.com><ea3878950708020552n79d1e68cjd36b44d57fbf33da@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145603@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950708020845s2d8fcd34o165b0427610c092f@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145608@MRZS152229.medizin.uni-leipzig.de>

Hi again Vladimir, 

it worked! This result is as good as anyone can expect. Can you explain to me the significance of the parameters, and why exactly it worked? 

Actually, I may have to go back and redo it with the actual voxel spacing, because the non-rigid registration with patient data, which comes afterward, must be applied to anatomical meshing... but everything scales accordingly, right? 

Cheers, 

Michel


-----Original Message-----
From: Vladimir FONOV [mailto:vladimir.fonov at gmail.com]
Sent: Thu 8/2/2007 5:45 PM
To: Audette, Michel
Cc: Andrew Janke
Subject: Re: [MINC-users] rawtominc & nu_correct difficulties
 
Hello,

On 8/2/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> Hi Vladimir,
>
> thanks for the suggestion. The data is 3D MR microscopy. http://cbaweb2.med.unc.edu/henson_mrm/pages/Scans_Primates.html
>
I tried playing with Human13959, got some success:

rawtominc -byte -range 0 255 -orange 0 255 -real_range 0 255 -unsigned
-zyx -xstep 1 -ystep 1 -zstep 1 -xstart 0 -ystart 0 -zstart 0 -clob
-oshort Human13959_Stack.mnc 176 187 256  < Human13959_Stack.gray

minccalc -expression '255-A[0]' Human13959_Stack.mnc Human13959_Stack_inv.mnc

nu_correct -clob Human13959_Stack_inv.mnc Human13959_Stack_inv_nuc.mnc
-iter 100 -stop 0.0001 -fwhm 0.1

 minccalc -expression 'clamp(255-A[0],0,255)'
Human13959_Stack_inv_nuc.mnc Human13959_Stack_nuc.mnc -clob

see attached images.

P.S. note that I used step size of 1mm instead of 0.025um as indicated
in the dataset

-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com



From a.janke at gmail.com  Thu Aug  2 20:13:42 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 3 Aug 2007 10:13:42 +1000
Subject: [MINC-users] rawtominc & nu_correct difficulties
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6901145608@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010838u24671911k51679008539ced52@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E69011455F7@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708010852m4524af85nac388f6d49e095ce@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145601@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708020539t7e381519n33daac2fa4fcdab0@mail.gmail.com>
	<ea3878950708020552n79d1e68cjd36b44d57fbf33da@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145603@MRZS152229.medizin.uni-leipzig.de>
	<ea3878950708020845s2d8fcd34o165b0427610c092f@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145608@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708021713m24fa3452sd475ce55190edb47@mail.gmail.com>

> it worked! This result is as good as anyone can expect. Can you explain to me the significance of the parameters, and why exactly it worked?

One of the at times amusing things about some of the addon MINC tools
(minctracc and nu_correct in particular) is that they were very much
optimised for "head sized" data. It is a common trick to make data
"head sized" to make things work at times.

You can make it work on "small data" but there are a number of
parameters that must be adjusted.  For example in minctracc you MUST
adjust -w_rotations for example.  I shall leave that one as an
exercise for the reader. :)

> Actually, I may have to go back and redo it with the actual voxel spacing, because the non-rigid registration with patient data, which comes afterward, must be applied to anatomical meshing... but everything scales accordingly, right?

in minctracc, yes almost everything does.  For nonlinear you should be
OK so long as you set the step correctly.


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

From spmlxf at yahoo.com  Mon Aug  6 11:06:35 2007
From: spmlxf at yahoo.com (xingfeng lee)
Date: Mon, 6 Aug 2007 08:06:35 -0700 (PDT)
Subject: [MINC-users] I can install MINC-1.0,
	but there is a problem when install MINC2 or Display/Register
Message-ID: <547363.65988.qm@web50106.mail.re2.yahoo.com>

Dear MINC experts,
 
 I have installed netCDF (netcdf-3.6.1), and i have not problem to install minc-1.0  ( it can find netcdf package... found in $(ROOT)/../netcdf-3.6.1), but when i installed MINC-2.0.12 or Register/Display I met this error:
 
 ./configure
 .......
 checking if g77 supports -c -o file.o... yes
 checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking how to hardcode library paths into programs... immediate
 checking for library m... yes
 checking for library netcdf... no
 configure: error: cannot find required library netcdf
 
 Can anyone help to figure out the problem?  My Linux is Fedora Core 3.
 
 Thanks in advance.
 
       
---------------------------------
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel and lay it on us.

From a.janke at gmail.com  Mon Aug  6 11:32:10 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 7 Aug 2007 01:32:10 +1000
Subject: [MINC-users] I can install MINC-1.0,
	but there is a problem when install MINC2 or Display/Register
In-Reply-To: <547363.65988.qm@web50106.mail.re2.yahoo.com>
References: <547363.65988.qm@web50106.mail.re2.yahoo.com>
Message-ID: <d747ed50708060832v7a40bbdet6f559278682c192f@mail.gmail.com>

>  I have installed netCDF (netcdf-3.6.1), and i have not problem to install minc-1.0  ( it can find netcdf package... found in $(ROOT)/../netcdf-3.6.1), but when i installed MINC-2.0.12 or Register/Display I met this error:
>
>  ./configure
>  .......
>  checking if g77 supports -c -o file.o... yes
>  checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes
>  checking dynamic linker characteristics... GNU/Linux ld.so
>  checking how to hardcode library paths into programs... immediate
>  checking for library m... yes
>  checking for library netcdf... no
>  configure: error: cannot find required library netcdf

Hi Xingfeng,

What does config.log say around where this error happens?  I have
struck linkage problems with netcdf on some machines where -lpthread
is missing.

Are you using the --enable-minc2 flags to configure?  (to add in hdf5 support).

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

From Michel.Audette at medizin.uni-leipzig.de  Wed Aug 15 12:46:43 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Wed, 15 Aug 2007 18:46:43 +0200
Subject: [MINC-users] registering two tag files to get an xfm file
Message-ID: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>

Hi everyone, 

I have two tag files consisting of the same anatomical landmarks
identified in two volumes, one from high res MR from individual A
(0.078mm isotropic resolution), and another, fairly high res CT from
individual B (0.2mm in x and y, 0.3mm in z), both scans of the middle
left ear. Is there a tag file registration command that will produce an
xfm file, that I can subsequently refine with Animal over the two
volumes? Any suggestions as to how to tweak Animal for this?

Thanks for your kind support. 

Cheers, 

Michel


Michel Audette, Ph.D. 
Innovation Center Computer Assisted Surgery (ICCAS) 
Philipp-Rosenthal-Strasse 55
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09


From spmlxf at yahoo.com  Tue Aug  7 12:26:51 2007
From: spmlxf at yahoo.com (xingfeng lee)
Date: Tue, 7 Aug 2007 09:26:51 -0700 (PDT)
Subject: [MINC-users] Register installation problem
Message-ID: <201912.32991.qm@web50107.mail.re2.yahoo.com>

                    Dear MINC experts,
 I run into a problem when i installed Register1.3.5:
  ./configure --with-build-path=/usr/local/minctools/netcdf-3.6.1:/usr/local/minctools/bicpl-1.4.3/
 checking for glBegin in -lGL... yes
 checking GL/glu.h usability... yes
 checking GL/glu.h presence... yes
 checking for GL/glu.h... yes
 checking for gluLookAt in -lGLU... yes
 checking GL/glut.h usability... no
 checking GL/glut.h presence... no
 checking for GL/glut.h... no
 configure: error: cannot find required header
 
 
 When i installed Register-1.3.6, the  configuration works, but when i  
 make check
 it does not, the error messages are in the following:
 
 
 make[2]: Entering directory `/usr/local/minctools/Register-1.3.6'
 gcc  -g -O2  -L/usr/local/minctools/netcdf-3.6.1/lib -o register -L/usr/X11R6/lib dummy.o Functionality/initialize/initialize.o Functionality/slices/colour_map.o Functionality/slices/cursor.o Functionality/slices/create_slice.o Functionality/slices/initialize_slice.o Functionality/slices/resample.o Functionality/slices/save_image.o Functionality/slices/set_volume.o Functionality/slices/slices.o Functionality/slices/updates.o Functionality/tags/objects.o Functionality/tags/save_and_load.o Functionality/tags/tag_points.o Functionality/tags/tag_transform.o Functionality/update/update_window.o UI_calls_F/UI_calls_F.o User_interface/main/main.o User_interface/main/initialize.o User_interface/colour_popup/colour_selection.o User_interface/delete_tags_popup/delete_tags.o User_interface/event_callbacks/save_image.o User_interface/event_callbacks/slice_events.o User_interface/event_callbacks/tag_events.o User_interface/event_callbacks/utilities.o
 User_interface/event_callbacks/window_events.o User_interface/event_handling/event_callbacks.o User_interface/event_handling/event_loop.o User_interface/event_handling/event_viewports.o User_interface/event_handling/global_events.o User_interface/event_handling/window_events.o User_interface/filter_popup/filter_selection.o User_interface/input/load.o User_interface/input/load_popup.o User_interface/layout/colours.o User_interface/layout/layout.o User_interface/print_popup/print.o User_interface/quit_popup/quit.o User_interface/resampling/resample.o User_interface/slices/slices.o User_interface/transform_popup/xform_selection.o User_interface/value_readout/update.o User_interface/widget_instances/colour_bar.o User_interface/widget_instances/initialize.o User_interface/widget_instances/main_menu_callbacks.o User_interface/widget_instances/merged_interface.o User_interface/widget_instances/meter.o User_interface/widget_instances/position_widgets.o
 User_interface/widget_instances/tag_points.o User_interface/widget_instances/volume_interface.o User_interface/widgets/buttons.o User_interface/widgets/sliders.o User_interface/widgets/text_entry.o User_interface/widgets/utilities.o User_interface/widgets/widgets.o User_interface/windows/lookup.o User_interface/windows/popup.o User_interface/windows/update.o User_interface/windows/xsect.o Graphics/libbicgl.a -lGL -L/usr/X11R6/lib -lX11 -lm -lGLU -lGL -L/usr/X11R6/lib -lX11  -lm  -lbicpl -lvolume_io -lminc -lnetcdf -lm -lm
 Functionality/slices/resample.o(.text+0x30): In function `resample_the_volume':
 /usr/local/minctools/Register-1.3.6/Functionality/slices/resample.c:39: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
 /usr/local/lib/libminc.a(netcdf_convenience.o)(.text+0x4eb): In function `miexpand_file':
 : warning: the use of `tempnam' is dangerous, better use `mkstemp'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x36): In function `WS_initialize':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:151: undefined reference to `glutInit'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x4f): In function `flip_screen_y':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:919: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x64): In function `delete_GLUT_window':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:342: undefined reference to `glutDestroyWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xf6): In function `WS_get_window_position':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:609: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x105):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:610: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x113):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:610: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x139): In function `WS_get_window_size':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:618: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x14a):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:619: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x180): In function `glut_set_colour_entry':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:628: undefined reference to `glutSetColor'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x1d2): In function `reestablish_colour_map_in_new_window':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:351: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x1f1):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:355: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x303): In function `lookup_font':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:691: undefined reference to `glutBitmap8By13'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x39a): In function `WS_draw_text':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:728: undefined reference to `glutBitmapCharacter'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x424): In function `WS_get_text_length':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:754: undefined reference to `glutBitmapWidth'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x45c): In function `WS_get_screen_size':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:763: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x46d):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:764: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x596): In function `get_keyboard_modifiers':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:898: undefined reference to `glutGetModifiers'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x5c4): In function `flip_window_y':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:913: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x5e0): In function `display_function':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:931: undefined reference to `glutGetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x637):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:944: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x67b): In function `resize_function':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:962: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x689):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:963: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x943): In function `create_GLUT_window':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:205: undefined reference to `glutInitWindowPosition'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x965):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:210: undefined reference to `glutInitWindowSize'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x96d):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:212: undefined reference to `glutInitDisplayMode'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x979):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:219: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x99a):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:227: undefined reference to `glutInitDisplayMode'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x9a8):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:253: undefined reference to `glutCreateWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x9c0):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:261: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x9ce):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:262: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x9dc):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:263: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x9e3):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:268: undefined reference to `glutPopWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x9ef):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1066: undefined reference to `glutDisplayFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x9fb):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1067: undefined reference to `glutReshapeFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa07):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1072: undefined reference to `glutKeyboardFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa13):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1073: undefined reference to `glutSpecialFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa1f):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1074: undefined reference to `glutMouseFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa2b):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1075: undefined reference to `glutMotionFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa37):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1076: undefined reference to `glutPassiveMotionFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa43):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1077: undefined reference to `glutEntryFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa65):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:279: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa73):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:279: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xb1e):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:310: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xb52):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:197: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xb8b): In function `WS_set_colour_map_state':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:497: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xb97):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:499: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xbae):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:500: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xbc1):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:503: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xbd0):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:504: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xbde):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:505: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xbed):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:506: more undefined references to `glutGet' follow
 Graphics/libbicgl.a(glut_windows.o)(.text+0xc88): In function `WS_set_colour_map_state':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:534: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xcb9):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:534: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xcdb): In function `WS_set_double_buffer_state':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:441: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xce7):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:443: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xcfe):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:444: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xd11):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:447: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xd20):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:448: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xd2e):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:449: undefined reference to `glutGet'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xd3d):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:450: more undefined references to `glutGet' follow
 Graphics/libbicgl.a(glut_windows.o)(.text+0xdd8): In function `WS_set_double_buffer_state':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:480: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xe09):/usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:480: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xe62): In function `WS_create_window':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:416: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x1065): In function `WS_add_idle_function':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1151: undefined reference to `glutIdleFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x77): In function `WS_set_window_title':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:543: undefined reference to `glutSetWindowTitle'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xa1): In function `get_current_event_window':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:556: undefined reference to `glutGetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xbd): In function `WS_set_bitplanes':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:568: undefined reference to `glutSetWindow'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x2e9): In function `WS_swap_buffers':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:661: undefined reference to `glutSwapBuffers'
 Graphics/libbicgl.a(glut_windows.o)(.text+0xfa0): In function `WS_add_timer_function':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1127: undefined reference to `glutTimerFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x113a): In function `WS_remove_idle_function':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1180: undefined reference to `glutIdleFunc'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x1145): In function `WS_event_loop':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1185: undefined reference to `glutMainLoop'
 Graphics/libbicgl.a(glut_windows.o)(.text+0x1151): In function `WS_set_update_flag':
 /usr/local/minctools/Register-1.3.6/Graphics/GLUT_windows/glut_windows.c:1191: undefined reference to `glutPostRedisplay'
 Graphics/libbicgl.a(glut_windows.o)(.data+0x4): undefined reference to `glutBitmapHelvetica10'
 Graphics/libbicgl.a(glut_windows.o)(.data+0xc): undefined reference to `glutBitmapHelvetica12'
 Graphics/libbicgl.a(glut_windows.o)(.data+0x14): undefined reference to `glutBitmap8By13'
 Graphics/libbicgl.a(glut_windows.o)(.data+0x1c): undefined reference to `glutBitmap9By15'
 Graphics/libbicgl.a(glut_windows.o)(.data+0x24): undefined reference to `glutBitmapHelvetica18'
 Graphics/libbicgl.a(glut_windows.o)(.data+0x2c): undefined reference to `glutBitmapTimesRoman24'
 Graphics/libbicgl.a(glut_windows.o)(.data+0x34): undefined reference to `glutBitmapTimesRoman10'
 collect2: ld a retourn? 1 code d'?tat d'ex?cution
 make[2]: *** [register] Erreur 1
 make[2]: Leaving directory `/usr/local/minctools/Register-1.3.6'
 make[1]: *** [all-recursive] Erreur 1
 make[1]: Leaving directory `/usr/local/minctools/Register-1.3.6'
 make: *** [all] Erreur 2
 
 
 could anyone help? Display has the same problem to install.
 Thanks in advance.
 All the best
 
 
 
       
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
 Play Sims Stories at Yahoo! Games. 

From Michel.Audette at medizin.uni-leipzig.de  Wed Aug 15 12:37:13 2007
From: Michel.Audette at medizin.uni-leipzig.de (Michel.Audette@medizin.uni-leipzig.de)
Date: Wed, 15 Aug 2007 18:37:13 +0200
Subject: [MINC-users] registering two tag files to get an xfm file
References: <160E3DD4FB702C4CB860C65186686E69011455D7@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145639@MRZS152229.medizin.uni-leipzig.de>

<160E3DD4FB702C4CB860C65186686E69011455D8 at MRZS152229.medizin.uni-leipzig.de> <46AF54DF.9090902 at bic.mni.mcgill.ca>
From: "Audette, Michel" <Michel.Audette at medizin.uni-leipzig.de>
To: <minc-users at bic.mni.mcgill.ca>

Hi everyone, 

I have two tag files consisting of the same anatomical landmarks identified in two volumes, one from high res MR from individual A (0.078mm isotropic resolution), and another, fairly high res CT from individual B (0.2mm in x and y, 0.3mm in z), both scans of the middle left ear. Is there a tag file registration command that will produce an xfm file, that I can subsequently refine with Animal over the two volumes? Any suggestions as to how to tweak Animal for this?

Thanks for your kind support. 

Cheers, 

Michel


Michel Audette, Ph.D. 
Innovation Center Computer Assisted Surgery (ICCAS) 
Philipp-Rosenthal-Strasse 55
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09


From vladimir.fonov at gmail.com  Wed Aug 15 22:21:48 2007
From: vladimir.fonov at gmail.com (Vladimir FONOV)
Date: Wed, 15 Aug 2007 22:21:48 -0400
Subject: [MINC-users] registering two tag files to get an xfm file
In-Reply-To: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <ea3878950708151921m5080c398t5b398b8c6061fc34@mail.gmail.com>

Hello Michel,


On 8/15/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> I have two tag files consisting of the same anatomical landmarks
> identified in two volumes, one from high res MR from individual A
> (0.078mm isotropic resolution), and another, fairly high res CT from
> individual B (0.2mm in x and y, 0.3mm in z), both scans of the middle
> left ear. Is there a tag file registration command that will produce an
> xfm file, that I can subsequently refine with Animal over the two
> volumes? Any suggestions as to how to tweak Animal for this?

There is a tagtoxfm program which calculates transformation based on
the tag points. But it expects a single tag file with two sets of tags
(register produces this file when you load two volumes).

For animal , you can specify this xfm file as a parameter to minctracc
: -transformation <our xfm file>


-- 
Best regards,
 Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com

From se at hst.aau.dk  Thu Aug 16 04:01:51 2007
From: se at hst.aau.dk (Simon Fristed Eskildsen)
Date: Thu, 16 Aug 2007 10:01:51 +0200
Subject: [MINC-users] Register installation problem
In-Reply-To: <201912.32991.qm@web50107.mail.re2.yahoo.com>
References: <201912.32991.qm@web50107.mail.re2.yahoo.com>
Message-ID: <46C4046F.5070806@hst.aau.dk>

Hi Xingfeng,

xingfeng lee wrote:
>                     Dear MINC experts,
>  I run into a problem when i installed Register1.3.5:
>   ./configure --with-build-path=/usr/local/minctools/netcdf-3.6.1:/usr/local/minctools/bicpl-1.4.3/
>  checking for glBegin in -lGL... yes
>  checking GL/glu.h usability... yes
>  checking GL/glu.h presence... yes
>  checking for GL/glu.h... yes
>  checking for gluLookAt in -lGLU... yes
>  checking GL/glut.h usability... no
>  checking GL/glut.h presence... no
>  checking for GL/glut.h... no
>  configure: error: cannot find required header

You need to install glut. Display and register uses opengl libraries, 
which is implemented by glut (OpenGL Utility Toolkit). If you use a 
debian-style OS

apt-get install freeglut-devel

should do it. And if you do you might as well use the deb packages for 
the minc tools, http://packages.bic.mni.mcgill.ca/deb/ , instead of 
compiling yourself.

Otherwise: http://freeglut.sourceforge.net/

Simon

From ed.gronenschild at mi.unimaas.nl  Thu Aug 16 10:25:37 2007
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Thu, 16 Aug 2007 16:25:37 +0200
Subject: [MINC-users] Problem with mritotal
Message-ID: <9553F704-A571-4D5A-A795-A27CE32D1B23@mi.unimaas.nl>

Hi,

Currently we are acquiring MRI volumes on a 3T machine. After
conversion to minc format I used the command 'insect' to preprocess
the scans. I noticed that for some scans this resulted in too small
brains which, in addition, were also not correctly orientated in
stereotaxic orientation. Most probably 'mritotal' is not able to
derive a correct (linear) transformation. To check this I artificially
multiplied the pixel size in X and Z by a factor 1.2 in the conversion
to minc format (so without changing the voxel data). This resulted in
a correctly sized and orientated volume.

Is there some limitation in mritotal or a bug?

Info: Mac OSX 10.4.10 and MINC software version for OSX 10.3

Kind regards,
Ed


From claude at bic.mni.mcgill.ca  Thu Aug 16 23:19:26 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Thu, 16 Aug 2007 23:19:26 -0400 (EDT)
Subject: [MINC-users] Problem with mritotal
Message-ID: <200708170319.l7H3JQwS4950265@yorick.bic.mni.mcgill.ca>

Hello Ed,

> Currently we are acquiring MRI volumes on a 3T machine. After
> conversion to minc format I used the command 'insect' to preprocess
> the scans. I noticed that for some scans this resulted in too small
> brains which, in addition, were also not correctly orientated in
> stereotaxic orientation. Most probably 'mritotal' is not able to
> derive a correct (linear) transformation. To check this I artificially
> multiplied the pixel size in X and Z by a factor 1.2 in the conversion
> to minc format (so without changing the voxel data). This resulted in
> a correctly sized and orientated volume.
> 
> Is there some limitation in mritotal or a bug?

I will attempt to answer your questions. Hopefully, perhaps Andrew
can fill-in some more details.

The MNI tools were developed and tuned for a 1.5T scanner. We are
starting to process scans from 3T scanners, with limitations. The
non-uniformities are much stronger on a 3T scanner and I found
that a -distance 25 to 50 must be given to nu_correct for better
results. This is not optimal, but it is better than the default
distance of 200 (or is it still 60 in some older versions?). It's
worth trying.

At the Brain-Imaging Centre (BIC) of the MNI, I came up with a
replacement script for mritotal. Based on experience, linear
registration is more reliable and robust when the source and
the target are masked (keep only brain tissues). This will avoid
neck cropping issues (autocrop option) for scans with the full
neck. Non-uniformities must also be corrected in native space 
prior to registration (in particular for 3T). 

These new tools are used internally at the BIC and haven't been
officially packaged. Andrew, what do you think? 

Yours,

Claude Lepage


From Michel.Audette at medizin.uni-leipzig.de  Fri Aug 17 06:25:42 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 17 Aug 2007 12:25:42 +0200
Subject: [MINC-users] minctracc error after initialization from
	register-based xfm
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>

Dear all, 

I am attempting a nonlinear registration between 2 volumes, where the extent of one volume is significantly less than that of the other (a high res MR of the inner ear of individual A, 0.078mm resolution, and a fairly high res CT of individual B, 0.2mm in x and y, 0.3mm in z), after reasonably successful rigid registration from 5 homologous pairs via the register program. I get the following error: 

maudette at icaw164201:~/work/earData> minctracc -transformation HumanS16885_etzoldCT.xfm HumanS16885_Stack_nuc_xyz.mnc etzold_emma_12792115_003002_mri_xyz.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc
WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
Cannot convert R to radians!  -0.717591    0.045836   -0.694954
   0.408952   -0.779968   -0.473716
  -0.563756   -0.624138    0.540954
Error in minctracc in file minctracc.c, line 536
Could not initialize transformation parameters

Does this ring a bell with anyone? [etzold_emma_12792115_003002_mri_xyz.mnc is in fact a CT volume converted from Dicom, not mr data...]

Thanks for your kind support. 

Cheers, 

Michel


Michel Audette, Ph.D. 
Innovation Center Computer Assisted Surgery (ICCAS) 
Philipp-Rosenthal-Strasse 55
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09


P.S: 
Other info: 
maudette at icaw164201:~/work/earData> minctracc -version
The program <minctracc> was built from:
Package mni_autoreg 0.98u, compiled by root at icaw164201 (x86_64-unknown-linux-gnu) on Thu Mar 16 13:13:40 CET 2006

Also, one volume has cosine info:  
       int zspace ;
                zspace:varid = "MINC standard variable" ;
                zspace:vartype = "dimension____" ;
                zspace:version = "MINC Version    1.0" ;
                zspace:comments = "Z increases from patient inferior to superior" ;
                zspace:spacing = "regular__" ;
                zspace:alignment = "centre" ;
                zspace:step = 0.299075200106658 ;
                zspace:start = -67.2154025304974 ;
                zspace:direction_cosines = 0., -0.0784590962903196, 0.99691733368886 ;
        int yspace ;
                yspace:varid = "MINC standard variable" ;
                yspace:vartype = "dimension____" ;
                yspace:version = "MINC Version    1.0" ;
                yspace:comments = "Y increases from patient posterior to anterior" ;
                yspace:spacing = "regular__" ;
                yspace:alignment = "centre" ;
                yspace:step = -0.1953125 ;
                yspace:start = 193.094103137385 ;
                yspace:direction_cosines = 0., 0.99691733368886, 0.0784590962903196 ;
        int xspace ;
                xspace:varid = "MINC standard variable" ;
                xspace:vartype = "dimension____" ;
                xspace:version = "MINC Version    1.0" ;
                xspace:comments = "X increases from patient left to right" ;
                xspace:spacing = "regular__" ;
                xspace:alignment = "centre" ;
                xspace:step = -0.1953125 ;
                xspace:start = 26.80468775 ;
                xspace:direction_cosines = 1., 0., 0. ;

The other not: 

        double xspace ;
                xspace:varid = "MINC standard variable" ;
                xspace:vartype = "dimension____" ;
                xspace:version = "MINC Version    1.0" ;
                xspace:comments = "X increases from patient left to right" ;
                xspace:spacing = "regular__" ;
                xspace:alignment = "centre" ;
                xspace:step = 0.078125 ;
                xspace:start = 0. ;
        double yspace ;
                yspace:varid = "MINC standard variable" ;
                yspace:vartype = "dimension____" ;
                yspace:version = "MINC Version    1.0" ;
                yspace:comments = "Y increases from patient posterior to anterior" ;
                yspace:spacing = "regular__" ;
                yspace:alignment = "centre" ;
                yspace:step = 0.078125 ;
                yspace:start = 0. ;
        double zspace ;
                zspace:varid = "MINC standard variable" ;
                zspace:vartype = "dimension____" ;
                zspace:version = "MINC Version    1.0" ;
                zspace:comments = "Z increases from patient inferior to superior" ;
                zspace:spacing = "regular__" ;
                zspace:alignment = "centre" ;
                zspace:step = 0.078125 ;
                zspace:start = 0. ;




From a.janke at gmail.com  Fri Aug 17 07:03:58 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 17 Aug 2007 21:03:58 +1000
Subject: [MINC-users] minctracc error after initialization from
	register-based xfm
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com>

On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> maudette at icaw164201:~/work/earData> minctracc -transformation HumanS16885_etzoldCT.xfm HumanS16885_Stack_nuc_xyz.mnc etzold_emma_12792115_003002_mri_xyz.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc
> WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
> Cannot convert R to radians!  -0.717591    0.045836   -0.694954
>    0.408952   -0.779968   -0.473716
>   -0.563756   -0.624138    0.540954
> Error in minctracc in file minctracc.c, line 536
> Could not initialize transformation parameters

Hi Michel,

What does:

   xfm2param HumanS16885_etzoldCT.xfm

return?  I suspect a rotation larger than pi/2.

There is no way around this in minctracc given how it optimises
rotations (Euler Angles). But there is a way!

First resample your source file using the xfm in question:

   mincresample ....  -transformation HumanS16885_etzoldCT.xfm \
      HumanS16885_Stack_nuc_xyz.mnc grimpflegroob.mnc

Then do your nonlinear part of the registration starting with an identity xfm

   minctracc -identity HumanS16885_Stack_nuc_xyz.mnc \
      grimpflegroob.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc \
      nonlinear.xfm

Once you then have your xfm, concatenate the two and resample. Of
course things are not best they can be given that you are working from
resampled data, but at least you only resample once for your final
image.


a

From Michel.Audette at medizin.uni-leipzig.de  Fri Aug 17 07:11:12 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 17 Aug 2007 13:11:12 +0200
Subject: [MINC-users] minctracc error after initialization
	fromregister-based xfm
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145643@MRZS152229.medizin.uni-leipzig.de>

Hi Andrew, 

thanks for your mail. I had a feeling that you'd respond quickly, and you didn't disappoint me!

xfm2param HumanS16885_etzoldCT.xfm gives me the same choking response that I get with minctracc. 

Do we care what sampling orientation to give mincresample? I'll go with -use_input_sampling unless you suggest otherwise... 

Cheers, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Fri 8/17/2007 1:03 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minctracc error after initialization fromregister-based xfm
 
On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> maudette at icaw164201:~/work/earData> minctracc -transformation HumanS16885_etzoldCT.xfm HumanS16885_Stack_nuc_xyz.mnc etzold_emma_12792115_003002_mri_xyz.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc
> WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
> Cannot convert R to radians!  -0.717591    0.045836   -0.694954
>    0.408952   -0.779968   -0.473716
>   -0.563756   -0.624138    0.540954
> Error in minctracc in file minctracc.c, line 536
> Could not initialize transformation parameters

Hi Michel,

What does:

   xfm2param HumanS16885_etzoldCT.xfm

return?  I suspect a rotation larger than pi/2.

There is no way around this in minctracc given how it optimises
rotations (Euler Angles). But there is a way!

First resample your source file using the xfm in question:

   mincresample ....  -transformation HumanS16885_etzoldCT.xfm \
      HumanS16885_Stack_nuc_xyz.mnc grimpflegroob.mnc

Then do your nonlinear part of the registration starting with an identity xfm

   minctracc -identity HumanS16885_Stack_nuc_xyz.mnc \
      grimpflegroob.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc \
      nonlinear.xfm

Once you then have your xfm, concatenate the two and resample. Of
course things are not best they can be given that you are working from
resampled data, but at least you only resample once for your final
image.


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


From Michel.Audette at medizin.uni-leipzig.de  Fri Aug 17 07:14:03 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 17 Aug 2007 13:14:03 +0200
Subject: [MINC-users] minctracc error after initialization
	fromregister-based xfm
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145644@MRZS152229.medizin.uni-leipzig.de>

Make that -tfm_input_sampling (the default). 

Michel

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Fri 8/17/2007 1:03 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minctracc error after initialization fromregister-based xfm
 
On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> maudette at icaw164201:~/work/earData> minctracc -transformation HumanS16885_etzoldCT.xfm HumanS16885_Stack_nuc_xyz.mnc etzold_emma_12792115_003002_mri_xyz.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc
> WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
> Cannot convert R to radians!  -0.717591    0.045836   -0.694954
>    0.408952   -0.779968   -0.473716
>   -0.563756   -0.624138    0.540954
> Error in minctracc in file minctracc.c, line 536
> Could not initialize transformation parameters

Hi Michel,

What does:

   xfm2param HumanS16885_etzoldCT.xfm

return?  I suspect a rotation larger than pi/2.

There is no way around this in minctracc given how it optimises
rotations (Euler Angles). But there is a way!

First resample your source file using the xfm in question:

   mincresample ....  -transformation HumanS16885_etzoldCT.xfm \
      HumanS16885_Stack_nuc_xyz.mnc grimpflegroob.mnc

Then do your nonlinear part of the registration starting with an identity xfm

   minctracc -identity HumanS16885_Stack_nuc_xyz.mnc \
      grimpflegroob.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc \
      nonlinear.xfm

Once you then have your xfm, concatenate the two and resample. Of
course things are not best they can be given that you are working from
resampled data, but at least you only resample once for your final
image.


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


From a.janke at gmail.com  Fri Aug 17 07:25:17 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 17 Aug 2007 21:25:17 +1000
Subject: [MINC-users] Problem with mritotal
In-Reply-To: <200708170319.l7H3JQwS4950265@yorick.bic.mni.mcgill.ca>
References: <200708170319.l7H3JQwS4950265@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50708170425q70c795cdn2b8ee99d4a9fe230@mail.gmail.com>

On 8/17/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:

> > Currently we are acquiring MRI volumes on a 3T machine. After
> > conversion to minc format I used the command 'insect' to preprocess
> > the scans. I noticed that for some scans this resulted in too small
> > brains which, in addition, were also not correctly orientated in
> > stereotaxic orientation. Most probably 'mritotal' is not able to
> > derive a correct (linear) transformation. To check this I artificially
> > multiplied the pixel size in X and Z by a factor 1.2 in the conversion
> > to minc format (so without changing the voxel data). This resulted in
> > a correctly sized and orientated volume.

Ed, I what does xfm2param return for your final xfm? If it doesnt have
a scale of 0.8 or so in both X and Y I would suspect that you have an
error in your conversion to MINC or that you are scanning people with
small heads.

As Claude said, the MNI tools are (inadvertently) best at 1.5T data of
about "adult head" size. This is not to say that they will not work on
other sized data, just that this is how they have been most tested.

> These new tools are used internally at the BIC and haven't been
> officially packaged. Andrew, what do you think?

By all means I think that bestlinreg.pl is ready for prime time.  My
plan was to include it (and nlpfit) in the next release of mni-autoreg
if that is OK by you. For now you can always put it on packages for
others to have a go with it.  You can always use the scripts directory
for now.


a

From a.janke at gmail.com  Fri Aug 17 07:40:09 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 17 Aug 2007 21:40:09 +1000
Subject: [MINC-users] minctracc error after initialization
	fromregister-based xfm
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6901145643@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145643@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708170440n602d0dc7x64d2ef0c00562f9e@mail.gmail.com>

On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:

> xfm2param HumanS16885_etzoldCT.xfm gives me the same choking response that I get with minctracc.

Have a hack with this little perl script I wrote a yonk ago as a drop
in replacement for xfm2param that can handle up to 180deg rotations.

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

> Do we care what sampling orientation to give mincresample? I'll go with -use_input_sampling unless you suggest otherwise...

I would guess that given that large transformation that
-tfm_input_sampling would be the best bet as per your next email.

-use_input_sampling is sometimes easier to use given that it will give
you an idea of where your data has gone/rotated to. Given that you
have a rotation of more than 90deg in there I would suspect that your
data is doing some amusing flips and contortions.  These can also be
due to wierd direction cosines but they looked OK in your headers that
you posted before.


a

From Michel.Audette at medizin.uni-leipzig.de  Fri Aug 17 07:55:20 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 17 Aug 2007 13:55:20 +0200
Subject: [MINC-users] minctracc error after
	initializationfromregister-based xfm
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de><d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145643@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170440n602d0dc7x64d2ef0c00562f9e@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145645@MRZS152229.medizin.uni-leipzig.de>

Hi again, 

It may be a left ear vs right ear thing, but I was pretty sure up to now that they were both left ear... But it could be that what I am seeing in the patient data is mirror-imaged compared to what I am think I am seeing. 

In fact, I meant to also use a free-form transformation, as opposed to affine nonrigid. I don't have much experience with animal, so I've a bit of reading to do...

Thanks again for your help. 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Fri 8/17/2007 1:40 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minctracc error after initializationfromregister-based xfm
 
On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:

> xfm2param HumanS16885_etzoldCT.xfm gives me the same choking response that I get with minctracc.

Have a hack with this little perl script I wrote a yonk ago as a drop
in replacement for xfm2param that can handle up to 180deg rotations.

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

> Do we care what sampling orientation to give mincresample? I'll go with -use_input_sampling unless you suggest otherwise...

I would guess that given that large transformation that
-tfm_input_sampling would be the best bet as per your next email.

-use_input_sampling is sometimes easier to use given that it will give
you an idea of where your data has gone/rotated to. Given that you
have a rotation of more than 90deg in there I would suspect that your
data is doing some amusing flips and contortions.  These can also be
due to wierd direction cosines but they looked OK in your headers that
you posted before.


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


From a.janke at gmail.com  Fri Aug 17 08:02:29 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 17 Aug 2007 22:02:29 +1000
Subject: [MINC-users] minctracc error after
	initializationfromregister-based xfm
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6901145645@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145643@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170440n602d0dc7x64d2ef0c00562f9e@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145645@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708170502x9731d3ayd93bee6116f5d9f2@mail.gmail.com>

On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> It may be a left ear vs right ear thing, but I was pretty sure up to now that they were both left ear... But it could be that what I am seeing in the patient data is mirror-imaged compared to what I am think I am seeing.

You are correct, a flip in an xfm wil also cause such problems..

As for a kickstart into ANIMAL, try this script:

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

It is a fairly compact perl script that wraps up the nonlinear fitting
part of minctracc for you.



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

From Michel.Audette at medizin.uni-leipzig.de  Fri Aug 17 08:18:03 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 17 Aug 2007 14:18:03 +0200
Subject: [MINC-users] minctracc error
	afterinitializationfromregister-based xfm
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de><d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145643@MRZS152229.medizin.uni-leipzig.de><d747ed50708170440n602d0dc7x64d2ef0c00562f9e@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145645@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170502x9731d3ayd93bee6116f5d9f2@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145648@MRZS152229.medizin.uni-leipzig.de>

Hi Andrew, 

looks great! Thanks for the kind and prompt response. I wish all electronic user groups were like this one. :-)

Cheers,

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Fri 8/17/2007 2:02 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minctracc error afterinitializationfromregister-based xfm
 
On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> It may be a left ear vs right ear thing, but I was pretty sure up to now that they were both left ear... But it could be that what I am seeing in the patient data is mirror-imaged compared to what I am think I am seeing.

You are correct, a flip in an xfm wil also cause such problems..

As for a kickstart into ANIMAL, try this script:

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

It is a fairly compact perl script that wraps up the nonlinear fitting
part of minctracc for you.



-- 
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 Michel.Audette at medizin.uni-leipzig.de  Fri Aug 17 08:47:25 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 17 Aug 2007 14:47:25 +0200
Subject: [MINC-users] minctracc
	errorafterinitializationfromregister-based xfm
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de><d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145643@MRZS152229.medizin.uni-leipzig.de><d747ed50708170440n602d0dc7x64d2ef0c00562f9e@mail.gmail.com><160E3DD4FB702C4CB860C65186686E6901145645@MRZS152229.medizin.uni-leipzig.de><d747ed50708170502x9731d3ayd93bee6116f5d9f2@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E6901145648@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <160E3DD4FB702C4CB860C65186686E690114564B@MRZS152229.medizin.uni-leipzig.de>

Hi again, 

I noticed that the words in my subject line are becoming clumped together with sucessive emails. I wonder if this is a consequence of my living in Germany... :-)

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Audette, Michel
Sent: Fri 8/17/2007 2:18 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minctracc errorafterinitializationfromregister-based xfm
 
Hi Andrew, 

looks great! Thanks for the kind and prompt response. I wish all electronic user groups were like this one. :-)

Cheers,

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Fri 8/17/2007 2:02 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minctracc error afterinitializationfromregister-based xfm
 
On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> It may be a left ear vs right ear thing, but I was pretty sure up to now that they were both left ear... But it could be that what I am seeing in the patient data is mirror-imaged compared to what I am think I am seeing.

You are correct, a flip in an xfm wil also cause such problems..

As for a kickstart into ANIMAL, try this script:

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

It is a fairly compact perl script that wraps up the nonlinear fitting
part of minctracc for you.



-- 
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 alex at bic.mni.mcgill.ca  Fri Aug 17 08:50:57 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Fri, 17 Aug 2007 08:50:57 -0400
Subject: [MINC-users] Problem with mritotal
In-Reply-To: <d747ed50708170425q70c795cdn2b8ee99d4a9fe230@mail.gmail.com>
References: <200708170319.l7H3JQwS4950265@yorick.bic.mni.mcgill.ca>
	<d747ed50708170425q70c795cdn2b8ee99d4a9fe230@mail.gmail.com>
Message-ID: <e758a6650708170550p312dfe78h390f8f3c6fa7d4d6@mail.gmail.com>

> By all means I think that bestlinreg.pl is ready for prime time.  My
> plan was to include it (and nlpfit) in the next release of mni-autoreg
> if that is OK by you. For now you can always put it on packages for
> others to have a go with it.  You can always use the scripts directory
> for now.

I have some questions: is bestlinreg still "best" without all the
other things that CIVET does to make it best? And will it replace
mritotal? If so, where are the data/paper supporting that it is really
better than mritotal?

Note that I am not suggesting that we do not make it available, but I
don't think we should have two tools to do exactly the same thing; nor
should we replace a very widely used and 'standard' tool like mritotal
with something without telling the world exactly why and how it is
better.

Secondly - and this may be moot if it will replace mritotal: can we
PLEASE change the name of bestlinreg.pl, or any best* tool for that
matter, before making them publicly available?!

-- Alex

From ed.gronenschild at mi.unimaas.nl  Fri Aug 17 09:53:44 2007
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Fri, 17 Aug 2007 15:53:44 +0200
Subject: [MINC-users] Problem with mritotal
In-Reply-To: <mailman.2400.1187349926.7670.minc-users@bic.mni.mcgill.ca>
References: <mailman.2400.1187349926.7670.minc-users@bic.mni.mcgill.ca>
Message-ID: <39D31BB8-E5FC-431E-8142-D69EEA2FC224@mi.unimaas.nl>

Andrew (and Claude),

Here are the requested results of xfm2param.
For the original data (voxel size is 1.0 * 1.0 * 1.0 mm^3):
-center         0.00000    0.00000    0.00000
-translation  -70.45679  142.58327  101.26605
-rotation     -14.28202    6.44659   -0.85951
-scale          0.85468    0.87173    0.87334
-shear          0.00000    0.00000    0.00000

Total scale factor = 0.65068

For the data with the voxel size set to 1.2 * 1.0 * 1.2 mm^3:
-center         0.00000    0.00000    0.00000
-translation  -99.12584  188.75531   93.02094
-rotation     -24.77424    0.41362   -1.06088
-scale          0.90102    0.94179    0.95061
-shear         -0.00000   -0.00000    0.00000

Total scale factor = 0.80666
Converted to the original voxel size this would be 1.16159.

Notice also the difference in rotation angles!!

The head size of the offendig scans is the same as that of the
successfully processed scans: width left->right = 130 mm and
width AP = 172 mm. So, that cannot be the error source. I think
that Claude may be right to use a mask in order to have a more
robust registration. The fact that the position of the head in the
field of view changes from scan to scan (especially in the Z
direction) could that be a reason for the bad performance?

By the way: the non-uniformities in our 3T scans are almost absent,
qualitatively I don't see much differences between the original and
N3-corrected scans.

Ed

On 17 Aug 2007, at 13:25, minc-users-request at bic.mni.mcgill.ca wrote:

> Message: 6
> Date: Fri, 17 Aug 2007 21:25:17 +1000
> From: "Andrew Janke" <a.janke at gmail.com>
> Subject: Re: [MINC-users] Problem with mritotal
> To: "MINC users mailing list" <minc-users at bic.mni.mcgill.ca>
> Message-ID:
> 	<d747ed50708170425q70c795cdn2b8ee99d4a9fe230 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 8/17/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
>
>>> Currently we are acquiring MRI volumes on a 3T machine. After
>>> conversion to minc format I used the command 'insect' to preprocess
>>> the scans. I noticed that for some scans this resulted in too small
>>> brains which, in addition, were also not correctly orientated in
>>> stereotaxic orientation. Most probably 'mritotal' is not able to
>>> derive a correct (linear) transformation. To check this I  
>>> artificially
>>> multiplied the pixel size in X and Z by a factor 1.2 in the  
>>> conversion
>>> to minc format (so without changing the voxel data). This  
>>> resulted in
>>> a correctly sized and orientated volume.
>
> Ed, I what does xfm2param return for your final xfm? If it doesnt have
> a scale of 0.8 or so in both X and Y I would suspect that you have an
> error in your conversion to MINC or that you are scanning people with
> small heads.
>
> As Claude said, the MNI tools are (inadvertently) best at 1.5T data of
> about "adult head" size. This is not to say that they will not work on
> other sized data, just that this is how they have been most tested.
>
>> These new tools are used internally at the BIC and haven't been
>> officially packaged. Andrew, what do you think?
>
> By all means I think that bestlinreg.pl is ready for prime time.  My
> plan was to include it (and nlpfit) in the next release of mni-autoreg
> if that is OK by you. For now you can always put it on packages for
> others to have a go with it.  You can always use the scripts directory
> for now.
>
>
> a
>


From Michel.Audette at medizin.uni-leipzig.de  Fri Aug 17 11:59:10 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Fri, 17 Aug 2007 17:59:10 +0200
Subject: [MINC-users] minctracc error after initialization
	fromregister-based xfm: one last question
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de><160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com>
Message-ID: <160E3DD4FB702C4CB860C65186686E690114564E@MRZS152229.medizin.uni-leipzig.de>

Hi again, 

and sorry to be a pest. This conversation came up a little while back, on another project of mine, and is relevant to my discussion of today. It has to do with which parameters to tweak on minctracc, if one is not working with 1mm resolution MR, but something significantly more high-res. In my case 0.08mm and 0.2-0.3mm for the two volumes, with one volume only covering a small part of the second. 

Also, starting from a pretty good estimation: a rigidly registered resampled source volume, based on a transformation obtained via register. 

Is it -step value that gets tweaked, or -w_translations, for smaller volumes? 

Also, since the orientation alignment is pretty good, does this have implications for -w_rotations? 

Thanks for your consideration. 

Cheers, 

Michel


-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca on behalf of Andrew Janke
Sent: Fri 8/17/2007 1:03 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minctracc error after initialization fromregister-based xfm
 
On 8/17/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
> maudette at icaw164201:~/work/earData> minctracc -transformation HumanS16885_etzoldCT.xfm HumanS16885_Stack_nuc_xyz.mnc etzold_emma_12792115_003002_mri_xyz.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc
> WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
> Cannot convert R to radians!  -0.717591    0.045836   -0.694954
>    0.408952   -0.779968   -0.473716
>   -0.563756   -0.624138    0.540954
> Error in minctracc in file minctracc.c, line 536
> Could not initialize transformation parameters

Hi Michel,

What does:

   xfm2param HumanS16885_etzoldCT.xfm

return?  I suspect a rotation larger than pi/2.

There is no way around this in minctracc given how it optimises
rotations (Euler Angles). But there is a way!

First resample your source file using the xfm in question:

   mincresample ....  -transformation HumanS16885_etzoldCT.xfm \
      HumanS16885_Stack_nuc_xyz.mnc grimpflegroob.mnc

Then do your nonlinear part of the registration starting with an identity xfm

   minctracc -identity HumanS16885_Stack_nuc_xyz.mnc \
      grimpflegroob.mnc HumanS16885_Stack_nuc_xyz_nonlin.mnc \
      nonlinear.xfm

Once you then have your xfm, concatenate the two and resample. Of
course things are not best they can be given that you are working from
resampled data, but at least you only resample once for your final
image.


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


From claude at bic.mni.mcgill.ca  Fri Aug 17 12:15:33 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Fri, 17 Aug 2007 12:15:33 -0400 (EDT)
Subject: [MINC-users] Problem with mritotal
References: <200708170319.l7H3JQwS4950265@yorick.bic.mni.mcgill.ca>
Message-ID: <200708171615.l7HGFXrN4864919@yorick.bic.mni.mcgill.ca>

Hi,

Some notes about the history of bestlinreg.pl:

- I created this script as a simplified version of mritotal for linear registration
  using a brain mask, in the same way that nlpfit was created for non-linear
  registration -- because it was too difficult to modify the do-it-all script
  mritotal. Remember that mritotal can do both linear and non-linear registration. 
- bestlinreg.pl basically reproduces the same fitting steps as mritotal - including
  blurring as in mritotal.
- unlike mritotal, bestlinreg.pl does not have a config file (good or bad???)
- bestlinreg.pl can be used without masking, if desired
- Following Louis' suggestion, I tried linear registration without blurring (and
  also without the gradient image), but the results were not convincing - too many
  failures.

>From the thousands of scans processed with bestlinreg.pl, I can report very few
failures. This was not the case for mritotal where often the subject's head ended
up being fully inside the skull of the model (hence the smaller head).

To the question if mritotal should no longer be used, my answer is if the code
is too "monstruous" to be maintainable, then the answer is use simpler scripts that
perform the same tasks but that can be modified and maintained easily. Modularity,
simple tasks... the key to structured programming. (Sorry if I offended anyone.)

As for releasing bestlinreg.pl, I'll leave it in Andrew's hands to decide if it
should be part of the next release of mni_autoreg. I think it should.

Claude


From a.janke at gmail.com  Sat Aug 18 23:59:47 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 19 Aug 2007 13:59:47 +1000
Subject: [MINC-users] minctracc error after initialization
	fromregister-based xfm: one last question
In-Reply-To: <160E3DD4FB702C4CB860C65186686E690114564E@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E69015F1CA8@MRZS152229.medizin.uni-leipzig.de>
	<160E3DD4FB702C4CB860C65186686E6901145642@MRZS152229.medizin.uni-leipzig.de>
	<d747ed50708170403w62565d4ew303baa71583b4d56@mail.gmail.com>
	<160E3DD4FB702C4CB860C65186686E690114564E@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708182059n3e4c9f38q7081c1a5bedabfa2@mail.gmail.com>

On 8/18/07, Audette, Michel <Michel.Audette at medizin.uni-leipzig.de> wrote:
>
> It has to do with which parameters to tweak on minctracc, if one is not working with 1mm resolution MR, but something significantly more high-res. In my case 0.08mm and 0.2-0.3mm for the two volumes, with one volume only covering a small part of the second.
>
> Also, starting from a pretty good estimation: a rigidly registered resampled source volume, based on a transformation obtained via register.
>
> Is it -step value that gets tweaked, or -w_translations, for smaller volumes?

Usually all three.  I was hoping that Mallar (a post-doc of louis) has
had a lot of experience here.

But yes, certainly the step should be modified.  The -w_translations
and so on are scaled by the step so these should be OK. But you will
usually have to modify the -w_rotations parameter. If you use
minctracc -help you will see that it is set to a number that seems to
have no bearing in reality.  in fact it does... :)  the number used
works along the premise that a rotation of x degrees about the COM of
a "head sized object" should amount to a shift of 1mm at the surface
of the "head sized object".  Thus the number does have a meaning, just
not an obvious one.


a

From spmlxf at yahoo.com  Wed Aug 22 11:23:35 2007
From: spmlxf at yahoo.com (xingfeng lee)
Date: Wed, 22 Aug 2007 08:23:35 -0700 (PDT)
Subject: [MINC-users] correct the non-uniformity of 10 subjects to one scale
Message-ID: <897106.14690.qm@web50107.mail.re2.yahoo.com>

                     Dear Experts,
 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 ?  
 Thanks in advance,
 
 
 
       
---------------------------------
Shape Yahoo! in your own image.  Join our Network Research Panel today!

From sean at rogue-research.com  Thu Aug 23 11:55:57 2007
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 23 Aug 2007 11:55:57 -0400
Subject: [MINC-users] Best route to install MINC tools on virgin Intel Mac?
Message-ID: <20070823155557.1439751803@smtp1.sympatico.ca>

Hi all,

I just got a brand new Intel Mac and want to install all the MINC tools,
including Register and Display.  What is the best route to take?  Build
from source?  Use installer packages?  If the latter, can someone
provide URLs?

Thanks a lot,

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




From penhunelab at gmail.com  Thu Aug 23 12:45:48 2007
From: penhunelab at gmail.com (Penhune Lab)
Date: Thu, 23 Aug 2007 12:45:48 -0400
Subject: [MINC-users] Best route to install MINC tools on virgin Intel
	Mac?
In-Reply-To: <20070823155557.1439751803@smtp1.sympatico.ca>
References: <20070823155557.1439751803@smtp1.sympatico.ca>
Message-ID: <c983d2410708230945n7f3d074bme2f4f88057d097ad@mail.gmail.com>

my advice is use minc1, i never had luck with minc2; there were problems
with the compression routines IIRC when installing mri2tal. Everything
else installed fine.
packages.bic.mni.mcgill.ca is a good start. They have a lot of
pre-compiled packages there; although i compiled everything myself,
but it's very time-consuming and frustrating...



Alejandro


On 8/23/07, Sean McBride <sean at rogue-research.com> wrote:
>
> Hi all,
>
> I just got a brand new Intel Mac and want to install all the MINC tools,
> including Register and Display.  What is the best route to take?  Build
> from source?  Use installer packages?  If the latter, can someone
> provide URLs?
>
> Thanks a lot,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Laboratory for Motor Learning and Neural Plasticity
Directed by Dr. Virginia Penhune
Department of Psychology, Concordia University
SP-A 244, 7141 Sherbrooke St. W
Montreal, QC  H4B 1R6  Canada
(514)848-2424 ext. 7567
http://psychology.concordia.ca/fac/penhune/winindex.html

From a.janke at gmail.com  Thu Aug 23 13:00:00 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 24 Aug 2007 03:00:00 +1000
Subject: [MINC-users] Best route to install MINC tools on virgin Intel
	Mac?
In-Reply-To: <20070823155557.1439751803@smtp1.sympatico.ca>
References: <20070823155557.1439751803@smtp1.sympatico.ca>
Message-ID: <d747ed50708230959s7ecbbebdu84343e9e12a60a06@mail.gmail.com>

> I just got a brand new Intel Mac and want to install all the MINC tools,
> including Register and Display.  What is the best route to take?  Build
> from source?  Use installer packages?  If the latter, can someone
> provide URLs?

Hi Sean,

Last time I got my hands on a Intel Mac I made this lot:

   http://packages.bic.mni.mcgill.ca/osx-10.4-intel-beta/

They are all minc1 based.  Of course you are more than welcome to
build them all from source too! :)



-- 
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  Thu Aug 23 13:32:53 2007
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Thu, 23 Aug 2007 13:32:53 -0400 (EDT)
Subject: [MINC-users] Best route to install MINC tools on virgin Intel
	Mac?
References: <20070823155557.1439751803@smtp1.sympatico.ca>
Message-ID: <200708231732.l7NHWr2a6049459@yorick.bic.mni.mcgill.ca>

Let's go, Andrew. Release that new minc2 with my fixes for internal compression.
See, people are asking for it. 

Claude

From a.janke at gmail.com  Thu Aug 23 13:46:34 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 24 Aug 2007 03:46:34 +1000
Subject: [MINC-users] Best route to install MINC tools on virgin Intel
	Mac?
In-Reply-To: <200708231732.l7NHWr2a6049459@yorick.bic.mni.mcgill.ca>
References: <20070823155557.1439751803@smtp1.sympatico.ca>
	<200708231732.l7NHWr2a6049459@yorick.bic.mni.mcgill.ca>
Message-ID: <d747ed50708231046k279999fcv445cb945dcbc038f@mail.gmail.com>

On 8/24/07, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> Let's go, Andrew. Release that new minc2 with my fixes for internal compression.
> See, people are asking for it.

In good time.. :)  My current build is still running through testing
on the older P4 and P3 Mac architectures and Cygwin.


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

From sean at rogue-research.com  Thu Aug 23 14:41:31 2007
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 23 Aug 2007 14:41:31 -0400
Subject: [MINC-users] Best route to install MINC tools on virgin Intel
 Mac?
In-Reply-To: <d747ed50708230959s7ecbbebdu84343e9e12a60a06@mail.gmail.com>
References: <20070823155557.1439751803@smtp1.sympatico.ca>
	<d747ed50708230959s7ecbbebdu84343e9e12a60a06@mail.gmail.com>
Message-ID: <20070823184131.1985556501@smtp1.sympatico.ca>

On 8/24/07 3:00 AM, Andrew Janke said:

>Last time I got my hands on a Intel Mac I made this lot:
>
>   http://packages.bic.mni.mcgill.ca/osx-10.4-intel-beta/
>
>They are all minc1 based.

I thought I remembered you doing so, but could not find this linked
anywhere.  Thanks!

I installed the following:
  bicpl-1.4.3.pkg
  display-1.4.2.pkg
  minc-1.4.pkg
  mniXautoreg-0.99.3.pkg
  register-1.3.6.pkg

But when I try to run Display from X11.app it says:

dyld: Library not loaded: /sw/lib/libnetpbm.10.dylib
  Referenced from: /usr/local/bic/bin/Display
  Reason: image not found

It seems fink is required, correct?  Are there other dependencies?

Thanks,

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




From Michel.Audette at medizin.uni-leipzig.de  Mon Aug 27 08:07:00 2007
From: Michel.Audette at medizin.uni-leipzig.de (Audette, Michel)
Date: Mon, 27 Aug 2007 14:07:00 +0200
Subject: [MINC-users] minctracc with mutual information and spline-based
	transformation
Message-ID: <160E3DD4FB702C4CB860C65186686E6901145675@MRZS152229.medizin.uni-leipzig.de>

Hi all, 

I had some correspondence with a fellow Minc user, and he indicated to me that mutual information-based variant of minctracc does not work well with a spline-based freeform interpolation, due to insufficiency of data for the local histogram that determines the local spline. Has anyone used minctracc in this way (in a manner similar to Daniel Ruickert), rather than the usual Animal correlation method? 

Can anyone report their experience of using it in this manner? I have data that are dissimilar to each other, so I'm thinking that mutual information might be a useful avenue. 

Secondly, I'm thinking of weighting a registration method for critical tissues, using a mask computed from each patient's scan. Can anyone comment about the feasibility, with either Animal or Mutual information, of using a mask that correlates with these, or perhaps tweaking the algorithm to weight critical tissues more strongly?

Best regards, 

Michel

Michel Audette, Ph.D. 
Innovation Center Computer Assisted Surgery (ICCAS) 
Philipp-Rosenthal-Strasse 55
Leipzig, Germany
Phone: ++49 (0) 341 / 97 - 1 20 13
Fax: ++49 (0) 341 / 97 - 1 20 09

 


From penhunelab at gmail.com  Mon Aug 27 09:36:21 2007
From: penhunelab at gmail.com (Penhune Lab)
Date: Mon, 27 Aug 2007 09:36:21 -0400
Subject: [MINC-users] Best route to install MINC tools on virgin Intel
	Mac?
In-Reply-To: <20070823184131.1985556501@smtp1.sympatico.ca>
References: <20070823155557.1439751803@smtp1.sympatico.ca>
	<d747ed50708230959s7ecbbebdu84343e9e12a60a06@mail.gmail.com>
	<20070823184131.1985556501@smtp1.sympatico.ca>
Message-ID: <c983d2410708270636y280c973akd72e2954979bd73b@mail.gmail.com>

yes, you need fink. i dont remember what for though, netcdf? glut? both?

On 8/23/07, Sean McBride <sean at rogue-research.com> wrote:
>
> On 8/24/07 3:00 AM, Andrew Janke said:
>
> >Last time I got my hands on a Intel Mac I made this lot:
> >
> >   http://packages.bic.mni.mcgill.ca/osx-10.4-intel-beta/
> >
> >They are all minc1 based.
>
> I thought I remembered you doing so, but could not find this linked
> anywhere.  Thanks!
>
> I installed the following:
>   bicpl-1.4.3.pkg
>   display-1.4.2.pkg
>   minc-1.4.pkg
>   mniXautoreg-0.99.3.pkg
>   register-1.3.6.pkg
>
> But when I try to run Display from X11.app it says:
>
> dyld: Library not loaded: /sw/lib/libnetpbm.10.dylib
>   Referenced from: /usr/local/bic/bin/Display
>   Reason: image not found
>
> It seems fink is required, correct?  Are there other dependencies?
>
> Thanks,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Laboratory for Motor Learning and Neural Plasticity
Directed by Dr. Virginia Penhune
Department of Psychology, Concordia University
SP-A 244, 7141 Sherbrooke St. W
Montreal, QC  H4B 1R6  Canada
(514)848-2424 ext. 7567
http://psychology.concordia.ca/fac/penhune/winindex.html

From a.janke at gmail.com  Mon Aug 27 19:13:27 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 28 Aug 2007 09:13:27 +1000
Subject: [MINC-users] Best route to install MINC tools on virgin Intel
	Mac?
In-Reply-To: <c983d2410708270636y280c973akd72e2954979bd73b@mail.gmail.com>
References: <20070823155557.1439751803@smtp1.sympatico.ca>
	<d747ed50708230959s7ecbbebdu84343e9e12a60a06@mail.gmail.com>
	<20070823184131.1985556501@smtp1.sympatico.ca>
	<c983d2410708270636y280c973akd72e2954979bd73b@mail.gmail.com>
Message-ID: <d747ed50708271613i312bfb9q817b799113448b7b@mail.gmail.com>

On 8/27/07, Penhune Lab <penhunelab at gmail.com> wrote:
> yes, you need fink. i dont remember what for though, netcdf? glut? both?

netpbm => Fink   (for bicpl and thus register/Display)
glut => OSX version although the fink version can be compiled against
if you go from source but then Command-Q or Command-Tab switching will
not work.

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

From a.janke at gmail.com  Mon Aug 27 20:04:09 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 28 Aug 2007 10:04:09 +1000
Subject: [MINC-users] minctracc with mutual information and spline-based
	transformation
In-Reply-To: <160E3DD4FB702C4CB860C65186686E6901145675@MRZS152229.medizin.uni-leipzig.de>
References: <160E3DD4FB702C4CB860C65186686E6901145675@MRZS152229.medizin.uni-leipzig.de>
Message-ID: <d747ed50708271704h7809b92ckdf517e89f8e08008@mail.gmail.com>

> I had some correspondence with a fellow Minc user, and he indicated to me that mutual information-based variant of minctracc does not work well with a spline-based freeform interpolation, due to insufficiency of data for the local histogram that determines the local spline. Has anyone used minctracc in this way (in a manner similar to Daniel Ruickert), rather than the usual Animal correlation method?

Spline-based in minctracc?  minctracc uses a linear-elastic model
(with local smoothing after each iteration) for nonlinear fitting.
But I presume you mean using mutual information for the nonlinear
fitting.

In any case, yes people have used mi for the nonlinear fits and the
best answer I can give is that it is more hit and miss that using the
correlation co-efficient.  Note that this does not mean that it doesnt
work or that it will work in you case.. :)  now that was very specific
wasn't it? :)

Mind you the use of mutual information has not been incorporated in
the released versions of minctracc so you would have to dig in the
code (in minctracc/Main/minctracc.c -- get_nonlinear_objective()) The
methods that are coded in for nonlinear are:

   xcorr, diff, label, chamfer, corrcoeff and sqdiff

You use them as such:

   minctracc -nonlinear xcorr source.mnc target.mnc xfm.mnc

> Secondly, I'm thinking of weighting a registration method for critical tissues, using a mask computed from each patient's scan. Can anyone comment about the feasibility, with either Animal or Mutual information, of using a mask that correlates with these, or perhaps tweaking the algorithm to weight critical tissues more strongly?

This has been discussed at length at the BIC between various people
and everyone agrees that it should be done.. just no-one has done it
(nicely) yet. To do it you would just turn the -weight argument
variable into a volume.

You can of course achieve this in a script as a quick hack by a bit of
judicious masking (with a weighted mask) before fitting and a bit of
blurring of edges.

Good luck!  Let me know if you need more help with the guts of the
code of minctracc.


a

From thomas_mansi at yahoo.fr  Tue Aug 28 08:20:22 2007
From: thomas_mansi at yahoo.fr (Thomas Mansi)
Date: Tue, 28 Aug 2007 14:20:22 +0200
Subject: [MINC-users] mrisim for cardiac MRI simulation
Message-ID: <46D41306.1090903@yahoo.fr>

Dear minc users,

In our lab we are interested in simulating cardiac cine-MRI from 
artificial phantoms. We have downloaded and installed MRISim and played 
a little bit with it but we were wondering if there exist configuration 
files for the coil, sequence and tissue parameters already tuned for 
such an application.

Does anyone know if it is possible to use MRISim to perform these kind 
of simulations? Preliminary results were promising but we are missing 
some parameters.

Many thanks in advance for your precious help,

Best regards,
Thomas


From a.janke at gmail.com  Tue Aug 28 13:05:38 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 29 Aug 2007 03:05:38 +1000
Subject: [MINC-users] correct the non-uniformity of 10 subjects to one
	scale
In-Reply-To: <897106.14690.qm@web50107.mail.re2.yahoo.com>
References: <897106.14690.qm@web50107.mail.re2.yahoo.com>
Message-ID: <d747ed50708281005u6887c134n60cb61377036138f@mail.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

From a.janke at gmail.com  Tue Aug 28 22:25:05 2007
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 29 Aug 2007 12:25:05 +1000
Subject: [MINC-users] mrisim for cardiac MRI simulation
In-Reply-To: <46D41306.1090903@yahoo.fr>
References: <46D41306.1090903@yahoo.fr>
Message-ID: <d747ed50708281925oa7ad44cpf48c708530503dae@mail.gmail.com>

> In our lab we are interested in simulating cardiac cine-MRI from
> artificial phantoms. We have downloaded and installed MRISim and played
> a little bit with it but we were wondering if there exist configuration
> files for the coil, sequence and tissue parameters already tuned for
> such an application.

Not that I know of.  Your best contact within the BIC for this would
be Bruce Pike.

> Does anyone know if it is possible to use MRISim to perform these kind
> of simulations? Preliminary results were promising but we are missing
> some parameters.

I don't see why it would not be possible but I suspect you will have
to write a bit more code for the physics (and distortions) of surface
coils, I don't remember such things being in mrisim.

I hate to do it, but there is also the competition in terms of
simulation, (POSSUM -
http://www.fmrib.ox.ac.uk/analysis/research/possum). It at least is
under active development as I understand. POSSUM has a lot more
functionality in terms of distortion simulation which will be needed
to model surface coil artifacts and signal drop-off.

Last I heard Ivana Drobnjak was looking after POSSUM.

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

From thomas_mansi at yahoo.fr  Wed Aug 29 08:37:12 2007
From: thomas_mansi at yahoo.fr (Thomas Mansi)
Date: Wed, 29 Aug 2007 14:37:12 +0200
Subject: [MINC-users] mrisim for cardiac MRI simulation
In-Reply-To: <d747ed50708281925oa7ad44cpf48c708530503dae@mail.gmail.com>
References: <46D41306.1090903@yahoo.fr>
	<d747ed50708281925oa7ad44cpf48c708530503dae@mail.gmail.com>
Message-ID: <46D56878.1090006@yahoo.fr>

Hello Andrew,

Many thanks for your quick answer. We keep looking at the possibilities 
offered by mrisim and, as the same time, we will test POSSUM as you 
suggested. By reading the introduction to the software it seems they 
implement motion artefacts among other distortions, which is very 
interesting for our application!

Many thanks again for your help,
Regards

Thomas



Andrew Janke wrote:
>> In our lab we are interested in simulating cardiac cine-MRI from
>> artificial phantoms. We have downloaded and installed MRISim and played
>> a little bit with it but we were wondering if there exist configuration
>> files for the coil, sequence and tissue parameters already tuned for
>> such an application.
>>     
>
> Not that I know of.  Your best contact within the BIC for this would
> be Bruce Pike.
>
>   
>> Does anyone know if it is possible to use MRISim to perform these kind
>> of simulations? Preliminary results were promising but we are missing
>> some parameters.
>>     
>
> I don't see why it would not be possible but I suspect you will have
> to write a bit more code for the physics (and distortions) of surface
> coils, I don't remember such things being in mrisim.
>
> I hate to do it, but there is also the competition in terms of
> simulation, (POSSUM -
> http://www.fmrib.ox.ac.uk/analysis/research/possum). It at least is
> under active development as I understand. POSSUM has a lot more
> functionality in terms of distortion simulation which will be needed
> to model surface coil artifacts and signal drop-off.
>
> Last I heard Ivana Drobnjak was looking after POSSUM.
>
>   

From roch at rogue-research.com  Wed Aug 29 16:14:20 2007
From: roch at rogue-research.com (Roch M. Comeau)
Date: Wed, 29 Aug 2007 16:14:20 -0400
Subject: [MINC-users]  rawtominc & nu_correct difficulties
Message-ID: <2658FC17-EB68-4FE2-A598-D22F7EE7F023@rogue-research.com>

Hi Michel,

I noticed your posts to MINC users and see a new address. It may be  
old I suppose, but its been a while since we spoke. How's life in  
Germany?

Cheers,

Roch

Roch M. Comeau, Ph.D.
Rogue Research Inc.
4398 St-Laurent, Suite 206
Montreal, QC, Canada, H2W 1Z5
Phone:(514)284-3888
Fax: (514)284-6750
roch at rogue-research.com
www.rogue-research.com




From john at absherneurology.com  Fri Aug 31 09:51:22 2007
From: john at absherneurology.com (John Absher)
Date: Fri, 31 Aug 2007 09:51:22 -0400
Subject: [MINC-users] Regional CBF differences
In-Reply-To: <mailman.1.1188489624.1074796.minc-users@bic.mni.mcgill.ca>
Message-ID: <LDECIOJNCEPJFCAHFLCCEEDNCAAA.john@absherneurology.com>

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.

Thanks,
John Absher

-----Original Message-----
From: minc-users-bounces at bic.mni.mcgill.ca
[mailto:minc-users-bounces at bic.mni.mcgill.ca]On Behalf Of
minc-users-request at bic.mni.mcgill.ca
Sent: Thursday, August 30, 2007 12:00 PM
To: minc-users at bic.mni.mcgill.ca
Subject: MINC-users Digest, Vol 25, Issue 19


Send MINC-users mailing list submissions to
	minc-users at bic.mni.mcgill.ca

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
or, via email, send a message with subject or body 'help' to
	minc-users-request at bic.mni.mcgill.ca

You can reach the person managing the list at
	minc-users-owner at bic.mni.mcgill.ca

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MINC-users digest..."


Today's Topics:

   1.  rawtominc & nu_correct difficulties (Roch M. Comeau)


----------------------------------------------------------------------

Message: 1
Date: Wed, 29 Aug 2007 16:14:20 -0400
From: "Roch M. Comeau" <roch at rogue-research.com>
Subject: [MINC-users]  rawtominc & nu_correct difficulties
To: minc-users at bic.mni.mcgill.ca
Message-ID: <2658FC17-EB68-4FE2-A598-D22F7EE7F023 at rogue-research.com>
Content-Type: text/plain;	charset=US-ASCII;	delsp=yes;	format=flowed

Hi Michel,

I noticed your posts to MINC users and see a new address. It may be
old I suppose, but its been a while since we spoke. How's life in
Germany?

Cheers,

Roch

Roch M. Comeau, Ph.D.
Rogue Research Inc.
4398 St-Laurent, Suite 206
Montreal, QC, Canada, H2W 1Z5
Phone:(514)284-3888
Fax: (514)284-6750
roch at rogue-research.com
www.rogue-research.com





------------------------------

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


End of MINC-users Digest, Vol 25, Issue 19
******************************************