From thor4ooo at gmail.com  Tue Sep  5 12:45:45 2006
From: thor4ooo at gmail.com (Thorarin Bjarnason)
Date: Tue, 5 Sep 2006 10:45:45 -0600
Subject: [MINC-users] N3 crashes when processing a volume on MacOSx
Message-ID: <9354d5230609050945yeef57c8wfd1b60c2059e37a7@mail.gmail.com>

Hello All,

I recently got minc tools running on Mac OS X 10.4.7 < with effort ;-)
>. I am interested in running N3. I have no trouble taking one file
from a dicom set and processing it <by converting it to mnc and
running nu_correct>. Processing an entire volume is not working as
well, unfortunately. Everything appears to be running fine until the
end <I think> where nu_correct crashes. My work flow is as follows:

I convert dicom to mnc using:
dcm2mnc * .

I go to the mnc output dir and use the following command:
nu_correct -fwhm 0.15 -distance 50 -stop 0.0001 -iterations 1000
InputFile.mnc test.mnc

and the computer works away for a while with the following output:
Processing:..............Done
Not implemented yet in cache_volume_range_has_changed()
Not implemented yet in cache_volume_range_has_changed()
Processing:..............Done
      ... etc ...
Not implemented yet in cache_volume_range_has_changed()
Not implemented yet in cache_volume_range_has_changed()
Number of iterations: 138
CV of field change: 9.77015e-05
Transforming slices:..................................................Done
Not implemented yet in cache_volume_range_has_changed()
Not implemented yet in cache_volume_range_has_changed()
Transforming slices:..................................................Done
Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
different step coordinates (zspace)
nu_evaluate: crashed while running mincmath (termination status=256)
nu_correct: crashed while running nu_evaluate (termination status=256)

A test.imp file was created. I tried changing some of the imput
parameters when I call the nu_correct function, but I get the same
error.

Does anyone know how I can fix this error?

Kind Regards,

-- 

Thorarin Bjarnason, BEng, MASc
www.imaginginformatics.ca

From sylvain at bic.mni.mcgill.ca  Tue Sep  5 14:58:51 2006
From: sylvain at bic.mni.mcgill.ca (Sylvain MILOT)
Date: Tue, 5 Sep 2006 14:58:51 -0400
Subject: [MINC-users] N3 crashes when processing a volume on MacOSx
In-Reply-To: <9354d5230609050945yeef57c8wfd1b60c2059e37a7@mail.gmail.com>
Message-ID: <Pine.SGI.4.44.0609051453560.153031-100000@shadow.bic.mni.mcgill.ca>



Hello,

I haven't used nu_correct in a long while but one thing caught my eye:

Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> different step coordinates (zspace)
> nu_evaluate: crashed while running mincmath (termination status=256)

mincmath requires that all its input data have the same shape and
same coordinate sampling.

try nu_correct -keeptmp ... to troubleshoot.

hoe this helps,

Sylvain

On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:

> Hello All,
>
> I recently got minc tools running on Mac OS X 10.4.7 < with effort ;-)
> >. I am interested in running N3. I have no trouble taking one file
> from a dicom set and processing it <by converting it to mnc and
> running nu_correct>. Processing an entire volume is not working as
> well, unfortunately. Everything appears to be running fine until the
> end <I think> where nu_correct crashes. My work flow is as follows:
>
> I convert dicom to mnc using:
> dcm2mnc * .
>
> I go to the mnc output dir and use the following command:
> nu_correct -fwhm 0.15 -distance 50 -stop 0.0001 -iterations 1000
> InputFile.mnc test.mnc
>
> and the computer works away for a while with the following output:
> Processing:..............Done
> Not implemented yet in cache_volume_range_has_changed()
> Not implemented yet in cache_volume_range_has_changed()
> Processing:..............Done
>       ... etc ...
> Not implemented yet in cache_volume_range_has_changed()
> Not implemented yet in cache_volume_range_has_changed()
> Number of iterations: 138
> CV of field change: 9.77015e-05
> Transforming slices:..................................................Done
> Not implemented yet in cache_volume_range_has_changed()
> Not implemented yet in cache_volume_range_has_changed()
> Transforming slices:..................................................Done
> Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> different step coordinates (zspace)
> nu_evaluate: crashed while running mincmath (termination status=256)
> nu_correct: crashed while running nu_evaluate (termination status=256)
>
> A test.imp file was created. I tried changing some of the imput
> parameters when I call the nu_correct function, but I get the same
> error.
>
> Does anyone know how I can fix this error?
>
> Kind Regards,
>
> --
>
> Thorarin Bjarnason, BEng, MASc
> www.imaginginformatics.ca
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

---
Sylvain Milot (sylvain at bic.mni.mcgill.ca)
              (trinity at bic.mni.mcgill.ca)
Brain Imaging Centre
Montreal Neurological Institute
Webster 2B, Room 208
Montreal, Qc., Canada, H3A 2B4
Phone  : (514) 398-4965, Fax: 398-8948
Mobile : (514) 712-1768
Office : 527 Av Des Pins O., Room 204
         Montreal, Qc., H2W 1S4



From thor4ooo at gmail.com  Tue Sep  5 16:11:55 2006
From: thor4ooo at gmail.com (Thorarin Bjarnason)
Date: Tue, 5 Sep 2006 14:11:55 -0600
Subject: [MINC-users] N3 crashes when processing a volume on MacOSx
In-Reply-To: <Pine.SGI.4.44.0609051453560.153031-100000@shadow.bic.mni.mcgill.ca>
References: <9354d5230609050945yeef57c8wfd1b60c2059e37a7@mail.gmail.com>
	<Pine.SGI.4.44.0609051453560.153031-100000@shadow.bic.mni.mcgill.ca>
Message-ID: <9354d5230609051311n28b77926h4811bb0f21ef1abd@mail.gmail.com>

Hello:

Thank you for your help.

I guess I did not tell the whole story <by accident, of course>.

The problem might originate from converting dcm2mnc. When I ran this
command to convert the dicom volume I had a warning:

> dcm2mnc * .
Checking file types...
File Img000.dcm appears to be DICOM (CD/Export).
Parsing 50 files     |<--------------------------------------------------->|
Sorting 50 files...   Done sorting files.
Processing files, one series at a time...
-Parsing series info |<--------------------------------------------------->|
WARNING: calculated slice width (2.9271522383) disagrees with file's
slice width (3.0000000000)
-Creating minc file  |<--------------------------------------------------->|
Done processing files.

So perhaps this warning caused an error later on. I have a work around though:

] dcm2mnc * .
] mnc2nii InputFile.mnc Temp1.nii
] nii2mnc Temp1.nii Temp2.mnc
] nu_correct -options Temp2.mnc OutputFile.mnc

nu_correct ran to completion this time. Can anyone comment as to
whether this workflow is OK?

Have a nice day,
Thor

On 9/5/06, Sylvain MILOT <sylvain at bic.mni.mcgill.ca> wrote:
>
>
> Hello,
>
> I haven't used nu_correct in a long while but one thing caught my eye:
>
> Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > different step coordinates (zspace)
> > nu_evaluate: crashed while running mincmath (termination status=256)
>
> mincmath requires that all its input data have the same shape and
> same coordinate sampling.
>
> try nu_correct -keeptmp ... to troubleshoot.
>
> hoe this helps,
>
> Sylvain
>
> On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:
>
> > Hello All,
> >
> > I recently got minc tools running on Mac OS X 10.4.7 < with effort ;-)
> > >. I am interested in running N3. I have no trouble taking one file
> > from a dicom set and processing it <by converting it to mnc and
> > running nu_correct>. Processing an entire volume is not working as
> > well, unfortunately. Everything appears to be running fine until the
> > end <I think> where nu_correct crashes. My work flow is as follows:
> >
> > I convert dicom to mnc using:
> > dcm2mnc * .
> >
> > I go to the mnc output dir and use the following command:
> > nu_correct -fwhm 0.15 -distance 50 -stop 0.0001 -iterations 1000
> > InputFile.mnc test.mnc
> >
> > and the computer works away for a while with the following output:
> > Processing:..............Done
> > Not implemented yet in cache_volume_range_has_changed()
> > Not implemented yet in cache_volume_range_has_changed()
> > Processing:..............Done
> >       ... etc ...
> > Not implemented yet in cache_volume_range_has_changed()
> > Not implemented yet in cache_volume_range_has_changed()
> > Number of iterations: 138
> > CV of field change: 9.77015e-05
> > Transforming slices:..................................................Done
> > Not implemented yet in cache_volume_range_has_changed()
> > Not implemented yet in cache_volume_range_has_changed()
> > Transforming slices:..................................................Done
> > Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > different step coordinates (zspace)
> > nu_evaluate: crashed while running mincmath (termination status=256)
> > nu_correct: crashed while running nu_evaluate (termination status=256)
> >
> > A test.imp file was created. I tried changing some of the imput
> > parameters when I call the nu_correct function, but I get the same
> > error.
> >
> > Does anyone know how I can fix this error?
> >
> > Kind Regards,
> >
> > --
> >
> > Thorarin Bjarnason, BEng, MASc
> > www.imaginginformatics.ca
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
> ---
> Sylvain Milot (sylvain at bic.mni.mcgill.ca)
>               (trinity at bic.mni.mcgill.ca)
> Brain Imaging Centre
> Montreal Neurological Institute
> Webster 2B, Room 208
> Montreal, Qc., Canada, H3A 2B4
> Phone  : (514) 398-4965, Fax: 398-8948
> Mobile : (514) 712-1768
> Office : 527 Av Des Pins O., Room 204
>          Montreal, Qc., H2W 1S4
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 

Thorarin Bjarnason, BEng, MASc
www.imaginginformatics.ca

From sylvain at bic.mni.mcgill.ca  Tue Sep  5 16:37:51 2006
From: sylvain at bic.mni.mcgill.ca (Sylvain MILOT)
Date: Tue, 5 Sep 2006 16:37:51 -0400
Subject: [MINC-users] N3 crashes when processing a volume on MacOSx
In-Reply-To: <9354d5230609051311n28b77926h4811bb0f21ef1abd@mail.gmail.com>
Message-ID: <Pine.SGI.4.44.0609051632530.153031-100000@shadow.bic.mni.mcgill.ca>


Hello,

seems like an overkill - I would guess that dcm2mnc fails to set some
step/start values and that mnc2nii/nii2mnc uses some defaults values which
may not be correct - but for nu_correct's sake, I dont think it matters.

What does mincinfo reveal on both volumes?

 On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:

> Hello:
>
> Thank you for your help.
>
> I guess I did not tell the whole story <by accident, of course>.
>
> The problem might originate from converting dcm2mnc. When I ran this
> command to convert the dicom volume I had a warning:
>
> > dcm2mnc * .
> Checking file types...
> File Img000.dcm appears to be DICOM (CD/Export).
> Parsing 50 files     |<--------------------------------------------------->|
> Sorting 50 files...   Done sorting files.
> Processing files, one series at a time...
> -Parsing series info |<--------------------------------------------------->|
> WARNING: calculated slice width (2.9271522383) disagrees with file's
> slice width (3.0000000000)
> -Creating minc file  |<--------------------------------------------------->|
> Done processing files.
>
> So perhaps this warning caused an error later on. I have a work around though:
>
> ] dcm2mnc * .
> ] mnc2nii InputFile.mnc Temp1.nii
> ] nii2mnc Temp1.nii Temp2.mnc
> ] nu_correct -options Temp2.mnc OutputFile.mnc
>
> nu_correct ran to completion this time. Can anyone comment as to
> whether this workflow is OK?
>
> Have a nice day,
> Thor
>
> On 9/5/06, Sylvain MILOT <sylvain at bic.mni.mcgill.ca> wrote:
> >
> >
> > Hello,
> >
> > I haven't used nu_correct in a long while but one thing caught my eye:
> >
> > Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > > different step coordinates (zspace)
> > > nu_evaluate: crashed while running mincmath (termination status=256)
> >
> > mincmath requires that all its input data have the same shape and
> > same coordinate sampling.
> >
> > try nu_correct -keeptmp ... to troubleshoot.
> >
> > hoe this helps,
> >
> > Sylvain
> >
> > On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:
> >
> > > Hello All,
> > >
> > > I recently got minc tools running on Mac OS X 10.4.7 < with effort ;-)
> > > >. I am interested in running N3. I have no trouble taking one file
> > > from a dicom set and processing it <by converting it to mnc and
> > > running nu_correct>. Processing an entire volume is not working as
> > > well, unfortunately. Everything appears to be running fine until the
> > > end <I think> where nu_correct crashes. My work flow is as follows:
> > >
> > > I convert dicom to mnc using:
> > > dcm2mnc * .
> > >
> > > I go to the mnc output dir and use the following command:
> > > nu_correct -fwhm 0.15 -distance 50 -stop 0.0001 -iterations 1000
> > > InputFile.mnc test.mnc
> > >
> > > and the computer works away for a while with the following output:
> > > Processing:..............Done
> > > Not implemented yet in cache_volume_range_has_changed()
> > > Not implemented yet in cache_volume_range_has_changed()
> > > Processing:..............Done
> > >       ... etc ...
> > > Not implemented yet in cache_volume_range_has_changed()
> > > Not implemented yet in cache_volume_range_has_changed()
> > > Number of iterations: 138
> > > CV of field change: 9.77015e-05
> > > Transforming slices:..................................................Done
> > > Not implemented yet in cache_volume_range_has_changed()
> > > Not implemented yet in cache_volume_range_has_changed()
> > > Transforming slices:..................................................Done
> > > Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > > different step coordinates (zspace)
> > > nu_evaluate: crashed while running mincmath (termination status=256)
> > > nu_correct: crashed while running nu_evaluate (termination status=256)
> > >
> > > A test.imp file was created. I tried changing some of the imput
> > > parameters when I call the nu_correct function, but I get the same
> > > error.
> > >
> > > Does anyone know how I can fix this error?
> > >
> > > Kind Regards,
> > >
> > > --
> > >
> > > Thorarin Bjarnason, BEng, MASc
> > > www.imaginginformatics.ca
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> >
> > ---
> > Sylvain Milot (sylvain at bic.mni.mcgill.ca)
> >               (trinity at bic.mni.mcgill.ca)
> > Brain Imaging Centre
> > Montreal Neurological Institute
> > Webster 2B, Room 208
> > Montreal, Qc., Canada, H3A 2B4
> > Phone  : (514) 398-4965, Fax: 398-8948
> > Mobile : (514) 712-1768
> > Office : 527 Av Des Pins O., Room 204
> >          Montreal, Qc., H2W 1S4
> >
> >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
> --
>
> Thorarin Bjarnason, BEng, MASc
> www.imaginginformatics.ca
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

---
Sylvain Milot (sylvain at bic.mni.mcgill.ca)
              (trinity at bic.mni.mcgill.ca)
Brain Imaging Centre
Montreal Neurological Institute
Webster 2B, Room 208
Montreal, Qc., Canada, H3A 2B4
Phone  : (514) 398-4965, Fax: 398-8948
Mobile : (514) 712-1768
Office : 527 Av Des Pins O., Room 204
         Montreal, Qc., H2W 1S4



From thor4ooo at gmail.com  Tue Sep  5 17:56:52 2006
From: thor4ooo at gmail.com (Thorarin Bjarnason)
Date: Tue, 5 Sep 2006 15:56:52 -0600
Subject: [MINC-users] N3 crashes when processing a volume on MacOSx
In-Reply-To: <Pine.SGI.4.44.0609051632530.153031-100000@shadow.bic.mni.mcgill.ca>
References: <9354d5230609051311n28b77926h4811bb0f21ef1abd@mail.gmail.com>
	<Pine.SGI.4.44.0609051632530.153031-100000@shadow.bic.mni.mcgill.ca>
Message-ID: <9354d5230609051456m63649ffbpebb80d03d6d15c63@mail.gmail.com>

Hello Sylvain,

I get the following results <based on the scenario described earlier> :

] mincinfo -image_info InputFile.mnc
file: InputFile.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     50            3     -74.4609
    yspace                    256    -0.859375      108.378
    xspace                    256     -0.85938          115

] mincinfo -image_info OutputFile.mnc
file: OutputFile.mnc
image: signed__ float 0 to 1285.8984375
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     50            3     -74.4609
    yspace                    256     0.859375     -110.762
    xspace                    256      0.85938     -104.142


Should I be worried about a change from 'singed short' to 'signed float'?

Cheers,
Thor

On 9/5/06, Sylvain MILOT <sylvain at bic.mni.mcgill.ca> wrote:
>
> Hello,
>
> seems like an overkill - I would guess that dcm2mnc fails to set some
> step/start values and that mnc2nii/nii2mnc uses some defaults values which
> may not be correct - but for nu_correct's sake, I dont think it matters.
>
> What does mincinfo reveal on both volumes?
>
>  On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:
>
> > Hello:
> >
> > Thank you for your help.
> >
> > I guess I did not tell the whole story <by accident, of course>.
> >
> > The problem might originate from converting dcm2mnc. When I ran this
> > command to convert the dicom volume I had a warning:
> >
> > > dcm2mnc * .
> > Checking file types...
> > File Img000.dcm appears to be DICOM (CD/Export).
> > Parsing 50 files     |<--------------------------------------------------->|
> > Sorting 50 files...   Done sorting files.
> > Processing files, one series at a time...
> > -Parsing series info |<--------------------------------------------------->|
> > WARNING: calculated slice width (2.9271522383) disagrees with file's
> > slice width (3.0000000000)
> > -Creating minc file  |<--------------------------------------------------->|
> > Done processing files.
> >
> > So perhaps this warning caused an error later on. I have a work around though:
> >
> > ] dcm2mnc * .
> > ] mnc2nii InputFile.mnc Temp1.nii
> > ] nii2mnc Temp1.nii Temp2.mnc
> > ] nu_correct -options Temp2.mnc OutputFile.mnc
> >
> > nu_correct ran to completion this time. Can anyone comment as to
> > whether this workflow is OK?
> >
> > Have a nice day,
> > Thor
> >
> > On 9/5/06, Sylvain MILOT <sylvain at bic.mni.mcgill.ca> wrote:
> > >
> > >
> > > Hello,
> > >
> > > I haven't used nu_correct in a long while but one thing caught my eye:
> > >
> > > Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > > > different step coordinates (zspace)
> > > > nu_evaluate: crashed while running mincmath (termination status=256)
> > >
> > > mincmath requires that all its input data have the same shape and
> > > same coordinate sampling.
> > >
> > > try nu_correct -keeptmp ... to troubleshoot.
> > >
> > > hoe this helps,
> > >
> > > Sylvain
> > >
> > > On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:
> > >
> > > > Hello All,
> > > >
> > > > I recently got minc tools running on Mac OS X 10.4.7 < with effort ;-)
> > > > >. I am interested in running N3. I have no trouble taking one file
> > > > from a dicom set and processing it <by converting it to mnc and
> > > > running nu_correct>. Processing an entire volume is not working as
> > > > well, unfortunately. Everything appears to be running fine until the
> > > > end <I think> where nu_correct crashes. My work flow is as follows:
> > > >
> > > > I convert dicom to mnc using:
> > > > dcm2mnc * .
> > > >
> > > > I go to the mnc output dir and use the following command:
> > > > nu_correct -fwhm 0.15 -distance 50 -stop 0.0001 -iterations 1000
> > > > InputFile.mnc test.mnc
> > > >
> > > > and the computer works away for a while with the following output:
> > > > Processing:..............Done
> > > > Not implemented yet in cache_volume_range_has_changed()
> > > > Not implemented yet in cache_volume_range_has_changed()
> > > > Processing:..............Done
> > > >       ... etc ...
> > > > Not implemented yet in cache_volume_range_has_changed()
> > > > Not implemented yet in cache_volume_range_has_changed()
> > > > Number of iterations: 138
> > > > CV of field change: 9.77015e-05
> > > > Transforming slices:..................................................Done
> > > > Not implemented yet in cache_volume_range_has_changed()
> > > > Not implemented yet in cache_volume_range_has_changed()
> > > > Transforming slices:..................................................Done
> > > > Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > > > different step coordinates (zspace)
> > > > nu_evaluate: crashed while running mincmath (termination status=256)
> > > > nu_correct: crashed while running nu_evaluate (termination status=256)
> > > >
> > > > A test.imp file was created. I tried changing some of the imput
> > > > parameters when I call the nu_correct function, but I get the same
> > > > error.
> > > >
> > > > Does anyone know how I can fix this error?
> > > >
> > > > Kind Regards,
> > > >
> > > > --
> > > >
> > > > Thorarin Bjarnason, BEng, MASc
> > > > www.imaginginformatics.ca
> > > > _______________________________________________
> > > > MINC-users at bic.mni.mcgill.ca
> > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > > >
> > >
> > > ---
> > > Sylvain Milot (sylvain at bic.mni.mcgill.ca)
> > >               (trinity at bic.mni.mcgill.ca)
> > > Brain Imaging Centre
> > > Montreal Neurological Institute
> > > Webster 2B, Room 208
> > > Montreal, Qc., Canada, H3A 2B4
> > > Phone  : (514) 398-4965, Fax: 398-8948
> > > Mobile : (514) 712-1768
> > > Office : 527 Av Des Pins O., Room 204
> > >          Montreal, Qc., H2W 1S4
> > >
> > >
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> >
> >
> > --
> >
> > Thorarin Bjarnason, BEng, MASc
> > www.imaginginformatics.ca
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
> ---
> Sylvain Milot (sylvain at bic.mni.mcgill.ca)
>               (trinity at bic.mni.mcgill.ca)
> Brain Imaging Centre
> Montreal Neurological Institute
> Webster 2B, Room 208
> Montreal, Qc., Canada, H3A 2B4
> Phone  : (514) 398-4965, Fax: 398-8948
> Mobile : (514) 712-1768
> Office : 527 Av Des Pins O., Room 204
>          Montreal, Qc., H2W 1S4
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 

Thorarin Bjarnason, BEng, MASc
www.imaginginformatics.ca

From a.janke at gmail.com  Tue Sep  5 20:03:39 2006
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 5 Sep 2006 20:03:39 -0400
Subject: [MINC-users] N3 crashes when processing a volume on MacOSx
In-Reply-To: <9354d5230609051456m63649ffbpebb80d03d6d15c63@mail.gmail.com>
References: <9354d5230609051311n28b77926h4811bb0f21ef1abd@mail.gmail.com>
	<Pine.SGI.4.44.0609051632530.153031-100000@shadow.bic.mni.mcgill.ca>
	<9354d5230609051456m63649ffbpebb80d03d6d15c63@mail.gmail.com>
Message-ID: <d747ed50609051703j40075d52if6629798bf43b228@mail.gmail.com>

Thorarin,

The file type will not matter.  My guess is that one of the files has
something like an irregular step size in Z.  Use mincheader on the
Input file and I suspect in the zspace section you will see something
like spacing:irregular.

In this case dcm2mnc has become a tad confused during the conversion.
There is a simple fix.  If you think the step is correct just do this:

   minc_modify_header -sinsert zspace:spacing=regular  input.mnc


a

On 9/5/06, Thorarin Bjarnason <thor4ooo at gmail.com> wrote:
> Hello Sylvain,
>
> I get the following results <based on the scenario described earlier> :
>
> ] mincinfo -image_info InputFile.mnc
> file: InputFile.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                     50            3     -74.4609
>    yspace                    256    -0.859375      108.378
>    xspace                    256     -0.85938          115
>
> ] mincinfo -image_info OutputFile.mnc
> file: OutputFile.mnc
> image: signed__ float 0 to 1285.8984375
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                     50            3     -74.4609
>    yspace                    256     0.859375     -110.762
>    xspace                    256      0.85938     -104.142
>
>
> Should I be worried about a change from 'singed short' to 'signed float'?
>
> Cheers,
> Thor
>
> On 9/5/06, Sylvain MILOT <sylvain at bic.mni.mcgill.ca> wrote:
> >
> > Hello,
> >
> > seems like an overkill - I would guess that dcm2mnc fails to set some
> > step/start values and that mnc2nii/nii2mnc uses some defaults values which
> > may not be correct - but for nu_correct's sake, I dont think it matters.
> >
> > What does mincinfo reveal on both volumes?
> >
> >  On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:
> >
> > > Hello:
> > >
> > > Thank you for your help.
> > >
> > > I guess I did not tell the whole story <by accident, of course>.
> > >
> > > The problem might originate from converting dcm2mnc. When I ran this
> > > command to convert the dicom volume I had a warning:
> > >
> > > > dcm2mnc * .
> > > Checking file types...
> > > File Img000.dcm appears to be DICOM (CD/Export).
> > > Parsing 50 files     |<--------------------------------------------------->|
> > > Sorting 50 files...   Done sorting files.
> > > Processing files, one series at a time...
> > > -Parsing series info |<--------------------------------------------------->|
> > > WARNING: calculated slice width (2.9271522383) disagrees with file's
> > > slice width (3.0000000000)
> > > -Creating minc file  |<--------------------------------------------------->|
> > > Done processing files.
> > >
> > > So perhaps this warning caused an error later on. I have a work around though:
> > >
> > > ] dcm2mnc * .
> > > ] mnc2nii InputFile.mnc Temp1.nii
> > > ] nii2mnc Temp1.nii Temp2.mnc
> > > ] nu_correct -options Temp2.mnc OutputFile.mnc
> > >
> > > nu_correct ran to completion this time. Can anyone comment as to
> > > whether this workflow is OK?
> > >
> > > Have a nice day,
> > > Thor
> > >
> > > On 9/5/06, Sylvain MILOT <sylvain at bic.mni.mcgill.ca> wrote:
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I haven't used nu_correct in a long while but one thing caught my eye:
> > > >
> > > > Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > > > > different step coordinates (zspace)
> > > > > nu_evaluate: crashed while running mincmath (termination status=256)
> > > >
> > > > mincmath requires that all its input data have the same shape and
> > > > same coordinate sampling.
> > > >
> > > > try nu_correct -keeptmp ... to troubleshoot.
> > > >
> > > > hoe this helps,
> > > >
> > > > Sylvain
> > > >
> > > > On Tue, 5 Sep 2006, Thorarin Bjarnason wrote:
> > > >
> > > > > Hello All,
> > > > >
> > > > > I recently got minc tools running on Mac OS X 10.4.7 < with effort ;-)
> > > > > >. I am interested in running N3. I have no trouble taking one file
> > > > > from a dicom set and processing it <by converting it to mnc and
> > > > > running nu_correct>. Processing an entire volume is not working as
> > > > > well, unfortunately. Everything appears to be running fine until the
> > > > > end <I think> where nu_correct crashes. My work flow is as follows:
> > > > >
> > > > > I convert dicom to mnc using:
> > > > > dcm2mnc * .
> > > > >
> > > > > I go to the mnc output dir and use the following command:
> > > > > nu_correct -fwhm 0.15 -distance 50 -stop 0.0001 -iterations 1000
> > > > > InputFile.mnc test.mnc
> > > > >
> > > > > and the computer works away for a while with the following output:
> > > > > Processing:..............Done
> > > > > Not implemented yet in cache_volume_range_has_changed()
> > > > > Not implemented yet in cache_volume_range_has_changed()
> > > > > Processing:..............Done
> > > > >       ... etc ...
> > > > > Not implemented yet in cache_volume_range_has_changed()
> > > > > Not implemented yet in cache_volume_range_has_changed()
> > > > > Number of iterations: 138
> > > > > CV of field change: 9.77015e-05
> > > > > Transforming slices:..................................................Done
> > > > > Not implemented yet in cache_volume_range_has_changed()
> > > > > Not implemented yet in cache_volume_range_has_changed()
> > > > > Transforming slices:..................................................Done
> > > > > Files /var/tmp/nu_correct_7953//test_field.mnc and InputFile.mnc have
> > > > > different step coordinates (zspace)
> > > > > nu_evaluate: crashed while running mincmath (termination status=256)
> > > > > nu_correct: crashed while running nu_evaluate (termination status=256)
> > > > >
> > > > > A test.imp file was created. I tried changing some of the imput
> > > > > parameters when I call the nu_correct function, but I get the same
> > > > > error.
> > > > >
> > > > > Does anyone know how I can fix this error?
> > > > >
> > > > > Kind Regards,
> > > > >
> > > > > --
> > > > >
> > > > > Thorarin Bjarnason, BEng, MASc
> > > > > www.imaginginformatics.ca
> > > > > _______________________________________________
> > > > > MINC-users at bic.mni.mcgill.ca
> > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > > > >
> > > >
> > > > ---
> > > > Sylvain Milot (sylvain at bic.mni.mcgill.ca)
> > > >               (trinity at bic.mni.mcgill.ca)
> > > > Brain Imaging Centre
> > > > Montreal Neurological Institute
> > > > Webster 2B, Room 208
> > > > Montreal, Qc., Canada, H3A 2B4
> > > > Phone  : (514) 398-4965, Fax: 398-8948
> > > > Mobile : (514) 712-1768
> > > > Office : 527 Av Des Pins O., Room 204
> > > >          Montreal, Qc., H2W 1S4
> > > >
> > > >
> > > > _______________________________________________
> > > > MINC-users at bic.mni.mcgill.ca
> > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > > >
> > >
> > >
> > > --
> > >
> > > Thorarin Bjarnason, BEng, MASc
> > > www.imaginginformatics.ca
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> >
> > ---
> > Sylvain Milot (sylvain at bic.mni.mcgill.ca)
> >               (trinity at bic.mni.mcgill.ca)
> > Brain Imaging Centre
> > Montreal Neurological Institute
> > Webster 2B, Room 208
> > Montreal, Qc., Canada, H3A 2B4
> > Phone  : (514) 398-4965, Fax: 398-8948
> > Mobile : (514) 712-1768
> > Office : 527 Av Des Pins O., Room 204
> >          Montreal, Qc., H2W 1S4
> >
> >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
> --
>
> Thorarin Bjarnason, BEng, MASc
> www.imaginginformatics.ca
> _______________________________________________
> 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/)
Canada->Montreal                                   Cell: +1 (514) 924 2012

From thor4ooo at gmail.com  Wed Sep  6 12:27:32 2006
From: thor4ooo at gmail.com (Thorarin Bjarnason)
Date: Wed, 6 Sep 2006 10:27:32 -0600
Subject: [MINC-users] N3 crashes when processing a volume on MacOSx
In-Reply-To: <d747ed50609051703j40075d52if6629798bf43b228@mail.gmail.com>
References: <9354d5230609051311n28b77926h4811bb0f21ef1abd@mail.gmail.com>
	<Pine.SGI.4.44.0609051632530.153031-100000@shadow.bic.mni.mcgill.ca>
	<9354d5230609051456m63649ffbpebb80d03d6d15c63@mail.gmail.com>
	<d747ed50609051703j40075d52if6629798bf43b228@mail.gmail.com>
Message-ID: <9354d5230609060927k1a52b4bw6d9730bb952dd2d@mail.gmail.com>

Hello Andrew,

Your suggestion appears to work, with the following modification:
minc_modify_header -sinsert zspace:spacing=regular__ InputFile.mnc

I used 'regular__' because it was the text used for yspace and xspace.

Thanks for your help.

Have a nice day,
Thor

On 9/5/06, Andrew Janke <a.janke at gmail.com> wrote:
> Thorarin,
>
> The file type will not matter.  My guess is that one of the files has
> something like an irregular step size in Z.  Use mincheader on the
> Input file and I suspect in the zspace section you will see something
> like spacing:irregular.
>
> In this case dcm2mnc has become a tad confused during the conversion.
> There is a simple fix.  If you think the step is correct just do this:
>
>    minc_modify_header -sinsert zspace:spacing=regular  input.mnc
>
>
> a
>
>
> --
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canada->Montreal                                   Cell: +1 (514) 924 2012
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 

Thorarin Bjarnason, BEng, MASc
www.imaginginformatics.ca

From thor4ooo at gmail.com  Wed Sep  6 16:17:44 2006
From: thor4ooo at gmail.com (Thorarin Bjarnason)
Date: Wed, 6 Sep 2006 14:17:44 -0600
Subject: [MINC-users] mnc2nii. int vs uint vs float
Message-ID: <9354d5230609061317p54229503s6ac8beb4aea69472@mail.gmail.com>

Hello List,

I thought I would start another thread. Even though it is quite
possible that my ignorance of data types will soon become apparent.
;-)

I am trying to take my mnc files and create raw data consisting of
unsigned shorts. When I try to open the resulting raw data as unsigned
shorts; they do not look correct. If I open them as signed shorts, all
is fine.

Perhaps the following workflow will be more clear:
] cp InputFile.mnc InputFile2.mnc
] cp InputFile.mnc InputFile3.mnc
] mnc2nii -signed -short -dual InputFile.mnc
<various output>
  datatype = '4'
  datatype_name = 'INT16'
<various output>
] mnc2nii -unsigned -short -dual InputFile2.mnc
<various output>
  datatype = '512'
  datatype_name = 'UINT16'
<various output>
] mnc2nii -float -dual InputFile3.mnc
<various output>
  datatype = '16'
  datatype_name = 'FLOAT32'
<various output>
] diff InputFile3.img InputFile2.img
Binary files InputFile3.img and InputFile2.img differ
] diff InputFile3.img InputFile.img
Binary files InputFile3.img and InputFile.img differ
] diff InputFile2.img InputFile.img
]

In the case above, 'diff' found no difference between int16 and
uint16. Shouldn't there be a difference? Running 'mincheader' on the
input files provide a variable (in case it matters):
variables:
         short image(zspace, yspace, xspace) ;
                     image:signtype = "signed__" ;

Can anyone reproduce this? Should diff find a difference between int16
and uint16? In other words, are my unsigned integers in fact signed
when using mnc2nii?

Have a nice day,

-- 

Thorarin Bjarnason, BEng, MASc
www.imaginginformatics.ca

From sorench at gmail.com  Wed Sep  6 17:48:16 2006
From: sorench at gmail.com (Soren Christensen)
Date: Wed, 6 Sep 2006 14:48:16 -0700
Subject: [MINC-users] mnc2nii. int vs uint vs float
In-Reply-To: <9354d5230609061317p54229503s6ac8beb4aea69472@mail.gmail.com>
References: <9354d5230609061317p54229503s6ac8beb4aea69472@mail.gmail.com>
Message-ID: <d6e2d6550609061448v48486bffm3865ce76744199c8@mail.gmail.com>

Hi Thorain,
 I think that will depend on the values in your image. If you are within the
posetive range only of your signed integer datatype then the binary coding
does not differ from that of unsigned coding in the mentioned range.  This
will often be the case in images from the scanner. So in other words maybe
the reason is a limited range of your image?

Best regards
Soren



On 9/6/06, Thorarin Bjarnason <thor4ooo at gmail.com> wrote:
>
> Hello List,
>
> I thought I would start another thread. Even though it is quite
> possible that my ignorance of data types will soon become apparent.
> ;-)
>
> I am trying to take my mnc files and create raw data consisting of
> unsigned shorts. When I try to open the resulting raw data as unsigned
> shorts; they do not look correct. If I open them as signed shorts, all
> is fine.
>
> Perhaps the following workflow will be more clear:
> ] cp InputFile.mnc InputFile2.mnc
> ] cp InputFile.mnc InputFile3.mnc
> ] mnc2nii -signed -short -dual InputFile.mnc
> <various output>
> datatype = '4'
> datatype_name = 'INT16'
> <various output>
> ] mnc2nii -unsigned -short -dual InputFile2.mnc
> <various output>
> datatype = '512'
> datatype_name = 'UINT16'
> <various output>
> ] mnc2nii -float -dual InputFile3.mnc
> <various output>
> datatype = '16'
> datatype_name = 'FLOAT32'
> <various output>
> ] diff InputFile3.img InputFile2.img
> Binary files InputFile3.img and InputFile2.img differ
> ] diff InputFile3.img InputFile.img
> Binary files InputFile3.img and InputFile.img differ
> ] diff InputFile2.img InputFile.img
> ]
>
> In the case above, 'diff' found no difference between int16 and
> uint16. Shouldn't there be a difference? Running 'mincheader' on the
> input files provide a variable (in case it matters):
> variables:
>         short image(zspace, yspace, xspace) ;
>                     image:signtype = "signed__" ;
>
> Can anyone reproduce this? Should diff find a difference between int16
> and uint16? In other words, are my unsigned integers in fact signed
> when using mnc2nii?
>
> Have a nice day,
>
> --
>
> Thorarin Bjarnason, BEng, MASc
> www.imaginginformatics.ca
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From ed.gronenschild at mi.unimaas.nl  Thu Sep  7 08:44:19 2006
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Thu, 7 Sep 2006 14:44:19 +0200
Subject: [MINC-users] Conversion of volume
Message-ID: <A0485B5B-68EE-4114-BD34-280FFED7CE4E@mi.unimaas.nl>

Hello

I'm doing volumetric measurements of brain structures in
stacks which have been transformed linearly in stereotaxic
Talairach space (mritotal) en resampled in 1.00 mm cubic
voxels (mincresample). The native voxel size is 0.94 * 0.94
* 1.50 = 1.3254 mm^3). To derive the volume in native
space I do the following:

Let's define the native voxel size "voxel_size_native",
and the Talairach voxel size "voxel_size_tal". Furthermore,
the native volume is defined as "vol_native" and the volume
in Talairach as "vol_tal".

With xfm2param I derive the following transformation
parameters:

-center         0.00000    0.00000    0.00000
-translation -129.92584  111.43100   97.71683
-rotation      -7.68466   -1.81075   -0.82142
-scale          1.06879    1.11325    1.20931
-shear          0.00000   -0.00000   -0.00000

The scale factor ("scale_factor") is the product of the scale
factors in X,Y, and Z, so
scale_factor = 1.06879 * 1.11325 * 1.20931 = 1.43882.
By the way, this is equal to the determinant of the transformation
matrix.

The conversion from Talairach to native is then:

vol_native = vol_tal * voxel_size_native / voxel_size_tal /  
scale_factor,

or

vol_native = vol_tal * 1.3254 / 1.0 / 1.4388

		= vol_tal * 0.9211

Can you agree with me?

Regards,

Ed

From thor4ooo at gmail.com  Thu Sep  7 17:50:37 2006
From: thor4ooo at gmail.com (Thorarin Bjarnason)
Date: Thu, 7 Sep 2006 15:50:37 -0600
Subject: [MINC-users] mnc2nii. int vs uint vs float
In-Reply-To: <d6e2d6550609061448v48486bffm3865ce76744199c8@mail.gmail.com>
References: <9354d5230609061317p54229503s6ac8beb4aea69472@mail.gmail.com>
	<d6e2d6550609061448v48486bffm3865ce76744199c8@mail.gmail.com>
Message-ID: <9354d5230609071450o61baeeabvcdc4bb9ee08f3444@mail.gmail.com>

Fair enough, providing the case you described is true.

However, when I open the resulting img file (assuming it is raw) using
something like matlab, I have to specify that the binary data is
'int16' in order for the data to look correct when plotted, even
though I specified unsigned short as output for the mnc2nii
conversion. What is happening is that the -ve values are being mapped
to +ve values if I open the file as an uint. When I open the file as
int16, -ve values do exist.

I encourage someone else to try this and see if they reproduce the
trouble I am having. Make sure the mnc input is signed and run mnc2nii
as described below. Perhaps I'm doing something wrong.

On the flip-side. I am now using minctoraw with the flags -unsigned
-short and all is well.

Cheers,

On 9/6/06, Soren Christensen <sorench at gmail.com> wrote:
> Hi Thorain,
>  I think that will depend on the values in your image. If you are within the
> posetive range only of your signed integer datatype then the binary coding
> does not differ from that of unsigned coding in the mentioned range.  This
> will often be the case in images from the scanner. So in other words maybe
> the reason is a limited range of your image?
>
> Best regards
> Soren
>
>
>
> On 9/6/06, Thorarin Bjarnason <thor4ooo at gmail.com> wrote:
> >
> > Hello List,
> >
> > I thought I would start another thread. Even though it is quite
> > possible that my ignorance of data types will soon become apparent.
> > ;-)
> >
> > I am trying to take my mnc files and create raw data consisting of
> > unsigned shorts. When I try to open the resulting raw data as unsigned
> > shorts; they do not look correct. If I open them as signed shorts, all
> > is fine.
> >
> > Perhaps the following workflow will be more clear:
> > ] cp InputFile.mnc InputFile2.mnc
> > ] cp InputFile.mnc InputFile3.mnc
> > ] mnc2nii -signed -short -dual InputFile.mnc
> > <various output>
> > datatype = '4'
> > datatype_name = 'INT16'
> > <various output>
> > ] mnc2nii -unsigned -short -dual InputFile2.mnc
> > <various output>
> > datatype = '512'
> > datatype_name = 'UINT16'
> > <various output>
> > ] mnc2nii -float -dual InputFile3.mnc
> > <various output>
> > datatype = '16'
> > datatype_name = 'FLOAT32'
> > <various output>
> > ] diff InputFile3.img InputFile2.img
> > Binary files InputFile3.img and InputFile2.img differ
> > ] diff InputFile3.img InputFile.img
> > Binary files InputFile3.img and InputFile.img differ
> > ] diff InputFile2.img InputFile.img
> > ]
> >
> > In the case above, 'diff' found no difference between int16 and
> > uint16. Shouldn't there be a difference? Running 'mincheader' on the
> > input files provide a variable (in case it matters):
> > variables:
> >         short image(zspace, yspace, xspace) ;
> >                     image:signtype = "signed__" ;
> >
> > Can anyone reproduce this? Should diff find a difference between int16
> > and uint16? In other words, are my unsigned integers in fact signed
> > when using mnc2nii?
> >
> > Have a nice day,
> >
> > --
> >
> > Thorarin Bjarnason, BEng, MASc
> > www.imaginginformatics.ca
> > _______________________________________________
> > 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
>


-- 

Thorarin Bjarnason, BEng, MASc
www.imaginginformatics.ca

From yves.roy at UMontreal.CA  Thu Sep  7 16:20:24 2006
From: yves.roy at UMontreal.CA (yves.roy@UMontreal.CA)
Date: Thu, 07 Sep 2006 16:20:24 -0400
Subject: [MINC-users] [REPRIC] Multivariate neuroimaging analysis workshop
	Oct 5&6
Message-ID: <8A678742-256E-4B7C-84E5-219B8E767C65@UMontreal.CA>

Dear Colleagues

As most of you working in neuroimaging know very well, new methods for
data analysis are constantly being developed. Among these are
multivariate techniques which have wide applicability in many
circumstances.

In collaboration with the University of Montreal, we have arranged for a
two-day workshop devoted to one of these methods, partial least squares
(PLS), to be given by Randy McIntosh and Nancy Lobaugh, from the
University of Toronto, who have been leaders in this field for some
time. (see references, below)

The workshop is aimed at faculty, postdocs, and advanced graduate
students who have experience with neuroimaging and wish to enlarge their
knowledge of analysis techniques. Details about PLS analyses as they
pertain to PET and fMRI as well as ERP techniques will be discussed.

Background information will be presented on the first day to
ensure a sufficient base for attendees, but the assumption is that most
attendees have a rudimentary knowledge of matrix algebra, statistics,
neuroimaging.  The second day will be a hands-on computer lab using both
example data sets and data that participants bring.  Further details
concerning the format for data to be analyzed will be posted shortly.

Additional details

PLACE:
1st day: MNI, room 201 Webster pavillion, 3801 University St.
2nd day: Universit? de Montr?al, lab A-325, Marie-Victorin, 90 Vincent
d'Indy Ave.

DATES: October 5 & 6

COST: $100 per participant (further details on method of payment will be
forthcoming to those who register)

NOTE: places are limited because of the availability of computer
terminals. We may need to double up people from the same or related labs
on a single terminal if there are more participants than there are  
spaces.

IF YOU ARE INTERESTED: please register at the following web site:
http://www.rsmnq.ca/repric/en/pls_workshop.htm

Schedule
Day 1
900-1015    Multivariate Stats Review
1015-1045    Coffee
1045-1200    PLS Basics
1200-1330    Lunch
1330-1530    PLS for MRI
1530-1600    Coffee
1600-1730    PLS for ERP

Day 2
900-1015    PLS software
1015-1045    coffee
1045-1200    PLS apps - example data sets
1200-1330    Lunch
1330-1730    PLS appls - self directed

Hope to see you at the workshop

Robert Zatorre
*******************************************************

Readings:
McIntosh, AR, Bookstein, FL, Haxby, JV & Grady, CL, (1996). Spatial
pattern analysis of functional brain images using partial least squares.
NeuroImage, 3, 143-157.

Lobaugh NJ, West R, McIntosh AR (2001) Spatiotemporal analysis of
experimental differences in event-related potential data with partial
least squares. Psychophysiology 38:517-530

McIntosh, A.R., Rajah, M. N., and Lobaugh, N. J. (2003). Functional
Connectivity of Medial Temporal Lobe Relates to Learning and Awareness.
Journal of Neuroscience, 23(26), 6520-6528.



--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Robert J. Zatorre, Ph.D.
Montreal Neurological Institute
3801 University St.
Montreal, QC Canada H3A 2B4
phone: 1-514-398-8903
fax: 1-514-398-1338
e-mail: robert.zatorre at mcgill.ca
web site: www.zlab.mcgill.ca


From penhunelab at gmail.com  Mon Sep 11 18:57:30 2006
From: penhunelab at gmail.com (Penhune Lab)
Date: Mon, 11 Sep 2006 18:57:30 -0400
Subject: [MINC-users] minc blur (mni_autoreg)
Message-ID: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>

Hello everyone
Im trying to install mni_autoreg but im getting a problem when i try to
compile mincblur:

...
gradmag_volume.o: In function `build_vol_info':
/home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:330: undefined
reference to `MI2varinq'
/home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:335: undefined
reference to `MI2varinq'
gradmag_volume.o: In function `make_curvature_volumes':
/home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1275: undefined
reference to `MI2attput'
gradmag_volume.o: In function `make_gradmag_volumes':
/home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1127: undefined
reference to `MI2attput'
collect2: ld returned 1 exit status
make: *** [mincblur] Error 1


all those undefined references are part of minc_compat.c but i cant seem to
tell the compiler to use the minc_compat.o file that i created when
installing minc2

any ideas? has anyone else encountered this??

im using linux mandriva 2006
kernel 2.6

thank you very much for your time

-- 
Laboratory for Motor Learning and Neural Plasticity
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 Sep 11 19:41:47 2006
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 11 Sep 2006 19:41:47 -0400
Subject: [MINC-users] minc blur (mni_autoreg)
In-Reply-To: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
References: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
Message-ID: <d747ed50609111641u57faf3e2w92068d06a2abfdd1@mail.gmail.com>

Hi Virginia,

The simplest fix is to compile against MINC 1.4 (the latest stable
release). MINC 2.0 is still somewhat experimental if only because many
of the older packages have not been ported yet.


Andrew

On 9/11/06, Penhune Lab <penhunelab at gmail.com> wrote:
> Hello everyone
> Im trying to install mni_autoreg but im getting a problem when i try to
> compile mincblur:
>
> ...
> gradmag_volume.o: In function `build_vol_info':
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:330: undefined
> reference to `MI2varinq'
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:335: undefined
> reference to `MI2varinq'
> gradmag_volume.o: In function `make_curvature_volumes':
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1275: undefined
> reference to `MI2attput'
> gradmag_volume.o: In function `make_gradmag_volumes':
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1127: undefined
> reference to `MI2attput'
> collect2: ld returned 1 exit status
> make: *** [mincblur] Error 1
>
>
> all those undefined references are part of minc_compat.c but i cant seem to
> tell the compiler to use the minc_compat.o file that i created when
> installing minc2
>
> any ideas? has anyone else encountered this??
>
> im using linux mandriva 2006
> kernel 2.6
>
> thank you very much for your time
>
> --
> Laboratory for Motor Learning and Neural Plasticity
> 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
> _______________________________________________
> 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/)
Canada->Montreal                                   Cell: +1 (514) 924 2012

From jason at bic.mni.mcgill.ca  Mon Sep 11 19:52:15 2006
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Mon, 11 Sep 2006 19:52:15 -0400
Subject: [MINC-users] minc blur (mni_autoreg)
In-Reply-To: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
References: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
Message-ID: <E709CBB9-56ED-49FE-8665-12B83B49BCDA@bic.mni.mcgill.ca>

Did you compile minc2 with the ''--enable-minc2" command line option?  
By default minc2 does not compile the newer hdf5 support in (why this  
is the default I cannot fathom).

Jason

On 11-Sep-06, at 6:57 PM, Penhune Lab wrote:

> Hello everyone
> Im trying to install mni_autoreg but im getting a problem when i  
> try to
> compile mincblur:
>
> ...
> gradmag_volume.o: In function `build_vol_info':
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:330:  
> undefined
> reference to `MI2varinq'
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:335:  
> undefined
> reference to `MI2varinq'
> gradmag_volume.o: In function `make_curvature_volumes':
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1275:  
> undefined
> reference to `MI2attput'
> gradmag_volume.o: In function `make_gradmag_volumes':
> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1127:  
> undefined
> reference to `MI2attput'
> collect2: ld returned 1 exit status
> make: *** [mincblur] Error 1
>
>
> all those undefined references are part of minc_compat.c but i cant  
> seem to
> tell the compiler to use the minc_compat.o file that i created when
> installing minc2
>
> any ideas? has anyone else encountered this??
>
> im using linux mandriva 2006
> kernel 2.6
>
> thank you very much for your time
>
> -- 
> Laboratory for Motor Learning and Neural Plasticity
> 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
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From ed.gronenschild at mi.unimaas.nl  Tue Sep 12 05:37:12 2006
From: ed.gronenschild at mi.unimaas.nl (Ed Gronenschild)
Date: Tue, 12 Sep 2006 11:37:12 +0200
Subject: [MINC-users] Conversion of volume
In-Reply-To: <A0485B5B-68EE-4114-BD34-280FFED7CE4E@mi.unimaas.nl>
References: <A0485B5B-68EE-4114-BD34-280FFED7CE4E@mi.unimaas.nl>
Message-ID: <BD39CBC0-1670-4892-9AE1-6BF2F08E3FEA@mi.unimaas.nl>

Hello,

Since I didn't receive any response I tried to figure it out myself.
I think that I'm wrong about the proposed conversion. I guess
that it is much simpler:

vol_native = vol_tal / scale_factor
		= vol_tal / 1.4388
		= vol_tal * 0.6950

(see eg. Pruessner et al, J. Neurosci, 2001, 21(1), 194-200)

I hope that I can have some feedback now.

Ed

On 7 Sep 2006, at 14:44, Ed Gronenschild wrote:

> Hello
>
> I'm doing volumetric measurements of brain structures in
> stacks which have been transformed linearly in stereotaxic
> Talairach space (mritotal) en resampled in 1.00 mm cubic
> voxels (mincresample). The native voxel size is 0.94 * 0.94
> * 1.50 = 1.3254 mm^3). To derive the volume in native
> space I do the following:
>
> Let's define the native voxel size "voxel_size_native",
> and the Talairach voxel size "voxel_size_tal". Furthermore,
> the native volume is defined as "vol_native" and the volume
> in Talairach as "vol_tal".
>
> With xfm2param I derive the following transformation
> parameters:
>
> -center         0.00000    0.00000    0.00000
> -translation -129.92584  111.43100   97.71683
> -rotation      -7.68466   -1.81075   -0.82142
> -scale          1.06879    1.11325    1.20931
> -shear          0.00000   -0.00000   -0.00000
>
> The scale factor ("scale_factor") is the product of the scale
> factors in X,Y, and Z, so
> scale_factor = 1.06879 * 1.11325 * 1.20931 = 1.43882.
> By the way, this is equal to the determinant of the transformation
> matrix.
>
> The conversion from Talairach to native is then:
>
> vol_native = vol_tal * voxel_size_native / voxel_size_tal /  
> scale_factor,
>
> or
>
> vol_native = vol_tal * 1.3254 / 1.0 / 1.4388
>
> 		= vol_tal * 0.9211
>
> Can you agree with me?
>
> Regards,
>
> Ed


From penhunelab at gmail.com  Tue Sep 12 09:47:57 2006
From: penhunelab at gmail.com (Penhune Lab)
Date: Tue, 12 Sep 2006 09:47:57 -0400
Subject: [MINC-users] minc blur (mni_autoreg)
In-Reply-To: <E709CBB9-56ED-49FE-8665-12B83B49BCDA@bic.mni.mcgill.ca>
References: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
	<E709CBB9-56ED-49FE-8665-12B83B49BCDA@bic.mni.mcgill.ca>
Message-ID: <c983d2410609120647w2876fab5tb6c1d5a1ffbd41df@mail.gmail.com>

wow!! --enable-minc2 did the trick!!!
i wish i had asked this question before, i spent a week trying to fix that
before getting to the mailing list
i looked for that switch in the minc2 documentation (INSTALL and README) and
its not there, maybe i didn't look in the right place.

What i find strange is that everything compiled fine using --with-minc2.
register, xdisp and even most of mni_autoreg. only mincblur didn't compile

Andrew, when you say minc2 is still experimental, does it mean, we don't
support (recommend) it yet or does it mean, don't use it because the results
might be wrong?
I didn't know myself that minc2 was still experimental and that 1.4 was the
latest stable version; maybe that should be mentioned somewhere visible
(like in the filename?)

Thanks a lot for the help!

Sincerely,
Alejandro Endo


On 9/11/06, Jason Lerch <jason at bic.mni.mcgill.ca> wrote:
>
> Did you compile minc2 with the ''--enable-minc2" command line option?
> By default minc2 does not compile the newer hdf5 support in (why this
> is the default I cannot fathom).
>
> Jason
>
> On 11-Sep-06, at 6:57 PM, Penhune Lab wrote:
>
> > Hello everyone
> > Im trying to install mni_autoreg but im getting a problem when i
> > try to
> > compile mincblur:
> >
> > ...
> > gradmag_volume.o: In function `build_vol_info':
> > /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:330:
> > undefined
> > reference to `MI2varinq'
> > /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:335:
> > undefined
> > reference to `MI2varinq'
> > gradmag_volume.o: In function `make_curvature_volumes':
> > /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1275:
> > undefined
> > reference to `MI2attput'
> > gradmag_volume.o: In function `make_gradmag_volumes':
> > /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1127:
> > undefined
> > reference to `MI2attput'
> > collect2: ld returned 1 exit status
> > make: *** [mincblur] Error 1
> >
> >
> > all those undefined references are part of minc_compat.c but i cant
> > seem to
> > tell the compiler to use the minc_compat.o file that i created when
> > installing minc2
> >
> > any ideas? has anyone else encountered this??
> >
> > im using linux mandriva 2006
> > kernel 2.6
> >
> > thank you very much for your time
> >
> > --
> > Laboratory for Motor Learning and Neural Plasticity
> > 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
> > _______________________________________________
> > 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
>



-- 
Laboratory for Motor Learning and Neural Plasticity
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 jason at bic.mni.mcgill.ca  Tue Sep 12 09:50:06 2006
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Tue, 12 Sep 2006 09:50:06 -0400
Subject: [MINC-users] minc blur (mni_autoreg)
In-Reply-To: <c983d2410609120647w2876fab5tb6c1d5a1ffbd41df@mail.gmail.com>
References: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
	<E709CBB9-56ED-49FE-8665-12B83B49BCDA@bic.mni.mcgill.ca>
	<c983d2410609120647w2876fab5tb6c1d5a1ffbd41df@mail.gmail.com>
Message-ID: <50416A0B-C49C-46F9-B7AC-3D08B8B09557@bic.mni.mcgill.ca>


On 12-Sep-06, at 9:47 AM, Penhune Lab wrote:

> wow!! --enable-minc2 did the trick!!!
> i wish i had asked this question before, i spent a week trying to  
> fix that
> before getting to the mailing list
> i looked for that switch in the minc2 documentation (INSTALL and  
> README) and
> its not there, maybe i didn't look in the right place.
>
> What i find strange is that everything compiled fine using --with- 
> minc2.
> register, xdisp and even most of mni_autoreg. only mincblur didn't  
> compile
>
> Andrew, when you say minc2 is still experimental, does it mean, we  
> don't
> support (recommend) it yet or does it mean, don't use it because  
> the results
> might be wrong?

We've been using minc2 for a while now, and it is quite stable and  
has not produced incorrect results in a long while! So I would not  
worry about it being experimental anymore ...

Jason

> I didn't know myself that minc2 was still experimental and that 1.4  
> was the
> latest stable version; maybe that should be mentioned somewhere  
> visible
> (like in the filename?)
>
> Thanks a lot for the help!
>
> Sincerely,
> Alejandro Endo
>
>
> On 9/11/06, Jason Lerch <jason at bic.mni.mcgill.ca> wrote:
>>
>> Did you compile minc2 with the ''--enable-minc2" command line option?
>> By default minc2 does not compile the newer hdf5 support in (why this
>> is the default I cannot fathom).
>>
>> Jason
>>
>> On 11-Sep-06, at 6:57 PM, Penhune Lab wrote:
>>
>>> Hello everyone
>>> Im trying to install mni_autoreg but im getting a problem when i
>>> try to
>>> compile mincblur:
>>>
>>> ...
>>> gradmag_volume.o: In function `build_vol_info':
>>> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:330:
>>> undefined
>>> reference to `MI2varinq'
>>> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:335:
>>> undefined
>>> reference to `MI2varinq'
>>> gradmag_volume.o: In function `make_curvature_volumes':
>>> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1275:
>>> undefined
>>> reference to `MI2attput'
>>> gradmag_volume.o: In function `make_gradmag_volumes':
>>> /home/vp/fMRI/mni_autoreg-0.99.2/mincblur/gradmag_volume.c:1127:
>>> undefined
>>> reference to `MI2attput'
>>> collect2: ld returned 1 exit status
>>> make: *** [mincblur] Error 1
>>>
>>>
>>> all those undefined references are part of minc_compat.c but i cant
>>> seem to
>>> tell the compiler to use the minc_compat.o file that i created when
>>> installing minc2
>>>
>>> any ideas? has anyone else encountered this??
>>>
>>> im using linux mandriva 2006
>>> kernel 2.6
>>>
>>> thank you very much for your time
>>>
>>> --
>>> Laboratory for Motor Learning and Neural Plasticity
>>> 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
>>> _______________________________________________
>>> 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
>>
>
>
>
> -- 
> Laboratory for Motor Learning and Neural Plasticity
> 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
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From a.janke at gmail.com  Tue Sep 12 10:24:26 2006
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 12 Sep 2006 10:24:26 -0400
Subject: [MINC-users] minc blur (mni_autoreg)
In-Reply-To: <50416A0B-C49C-46F9-B7AC-3D08B8B09557@bic.mni.mcgill.ca>
References: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
	<E709CBB9-56ED-49FE-8665-12B83B49BCDA@bic.mni.mcgill.ca>
	<c983d2410609120647w2876fab5tb6c1d5a1ffbd41df@mail.gmail.com>
	<50416A0B-C49C-46F9-B7AC-3D08B8B09557@bic.mni.mcgill.ca>
Message-ID: <d747ed50609120724v6c01ffbtcdec7abfb6b5c1c8@mail.gmail.com>

On 9/12/06, Jason Lerch <jason at bic.mni.mcgill.ca> wrote:
> >
> > What i find strange is that everything compiled fine using --with-
> > minc2.
> > register, xdisp and even most of mni_autoreg. only mincblur didn't
> > compile
> >
> > Andrew, when you say minc2 is still experimental, does it mean, we
> > don't
> > support (recommend) it yet or does it mean, don't use it because
> > the results
> > might be wrong?
>
> We've been using minc2 for a while now, and it is quite stable and
> has not produced incorrect results in a long while! So I would not
> worry about it being experimental anymore ...

As Jason says, mnic2 itself is stable but there is still a lot work to
do on some of the accompanying packages as they rely upon a lot of
compatibility functions in MINC 2.0 that are harbingers from the MINC
1.x chain.

Problem is MINC isn't of much use by itself! :)


-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canada->Montreal                                   Cell: +1 (514) 924 2012

From jason at bic.mni.mcgill.ca  Tue Sep 12 10:51:53 2006
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Tue, 12 Sep 2006 10:51:53 -0400
Subject: [MINC-users] minc blur (mni_autoreg)
In-Reply-To: <d747ed50609120724v6c01ffbtcdec7abfb6b5c1c8@mail.gmail.com>
References: <c983d2410609111557k1534d1e5n1ddba61560f33626@mail.gmail.com>
	<E709CBB9-56ED-49FE-8665-12B83B49BCDA@bic.mni.mcgill.ca>
	<c983d2410609120647w2876fab5tb6c1d5a1ffbd41df@mail.gmail.com>
	<50416A0B-C49C-46F9-B7AC-3D08B8B09557@bic.mni.mcgill.ca>
	<d747ed50609120724v6c01ffbtcdec7abfb6b5c1c8@mail.gmail.com>
Message-ID: <DD670C2C-6711-49FB-A7A2-E1B1F02C26C6@bic.mni.mcgill.ca>


On 12-Sep-06, at 10:24 AM, Andrew Janke wrote:

> On 9/12/06, Jason Lerch <jason at bic.mni.mcgill.ca> wrote:
>>>
>>> What i find strange is that everything compiled fine using --with-
>>> minc2.
>>> register, xdisp and even most of mni_autoreg. only mincblur didn't
>>> compile
>>>
>>> Andrew, when you say minc2 is still experimental, does it mean, we
>>> don't
>>> support (recommend) it yet or does it mean, don't use it because
>>> the results
>>> might be wrong?
>>
>> We've been using minc2 for a while now, and it is quite stable and
>> has not produced incorrect results in a long while! So I would not
>> worry about it being experimental anymore ...
>
> As Jason says, mnic2 itself is stable but there is still a lot work to
> do on some of the accompanying packages as they rely upon a lot of
> compatibility functions in MINC 2.0 that are harbingers from the MINC
> 1.x chain.

Let me rephrase then - we've been using minc2 and most if not all of  
the associated tools (mni_autoreg, conglomerate, etc) compiled  
against the compatibility layer for a long while and have not had any  
incorrect results recently! Everything which compiles against minc1  
should work with minc2. If it does not that's clearly a bug to be fixed.

Jason

>
> Problem is MINC isn't of much use by itself! :)
>
>
> -- 
> Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canada->Montreal                                   Cell: +1 (514)  
> 924 2012
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From jason at bic.mni.mcgill.ca  Tue Sep 12 14:39:42 2006
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Tue, 12 Sep 2006 14:39:42 -0400
Subject: [MINC-users] Conversion of volume
In-Reply-To: <BD39CBC0-1670-4892-9AE1-6BF2F08E3FEA@mi.unimaas.nl>
References: <A0485B5B-68EE-4114-BD34-280FFED7CE4E@mi.unimaas.nl>
	<BD39CBC0-1670-4892-9AE1-6BF2F08E3FEA@mi.unimaas.nl>
Message-ID: <4506FEEE.6060704@bic.mni.mcgill.ca>

Ed Gronenschild wrote:

>Hello,
>
>Since I didn't receive any response I tried to figure it out myself.
>I think that I'm wrong about the proposed conversion. I guess
>that it is much simpler:
>
>vol_native = vol_tal / scale_factor
>		= vol_tal / 1.4388
>		= vol_tal * 0.6950
>
>(see eg. Pruessner et al, J. Neurosci, 2001, 21(1), 194-200)
>
>I hope that I can have some feedback now.
>  
>
This looks correct. A good sanity check, if you are unsure of 
conversions like this, is to invert the transform that takes the volume 
into stereotaxic space (using xfminvert), then resample the labels 
(using mincresample -nearest_neighbour) using the inverted transform, 
and then measuring the volume in native space. If it's close to your 
computed volume then you were right!

Jason

>Ed
>
>On 7 Sep 2006, at 14:44, Ed Gronenschild wrote:
>
>  
>
>>Hello
>>
>>I'm doing volumetric measurements of brain structures in
>>stacks which have been transformed linearly in stereotaxic
>>Talairach space (mritotal) en resampled in 1.00 mm cubic
>>voxels (mincresample). The native voxel size is 0.94 * 0.94
>>* 1.50 = 1.3254 mm^3). To derive the volume in native
>>space I do the following:
>>
>>Let's define the native voxel size "voxel_size_native",
>>and the Talairach voxel size "voxel_size_tal". Furthermore,
>>the native volume is defined as "vol_native" and the volume
>>in Talairach as "vol_tal".
>>
>>With xfm2param I derive the following transformation
>>parameters:
>>
>>-center         0.00000    0.00000    0.00000
>>-translation -129.92584  111.43100   97.71683
>>-rotation      -7.68466   -1.81075   -0.82142
>>-scale          1.06879    1.11325    1.20931
>>-shear          0.00000   -0.00000   -0.00000
>>
>>The scale factor ("scale_factor") is the product of the scale
>>factors in X,Y, and Z, so
>>scale_factor = 1.06879 * 1.11325 * 1.20931 = 1.43882.
>>By the way, this is equal to the determinant of the transformation
>>matrix.
>>
>>The conversion from Talairach to native is then:
>>
>>vol_native = vol_tal * voxel_size_native / voxel_size_tal /  
>>scale_factor,
>>
>>or
>>
>>vol_native = vol_tal * 1.3254 / 1.0 / 1.4388
>>
>>		= vol_tal * 0.9211
>>
>>Can you agree with me?
>>
>>Regards,
>>
>>Ed
>>    
>>
>
>_______________________________________________
>MINC-users at bic.mni.mcgill.ca
>http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>  
>


From o.winz at fz-juelich.de  Fri Sep 15 10:58:20 2006
From: o.winz at fz-juelich.de (Oliver Winz)
Date: Fri, 15 Sep 2006 16:58:20 +0200
Subject: [MINC-users] slice images to volume image, howto?
Message-ID: <450ABF8C.60300@fz-juelich.de>

hi everybody,

i have a question concerning slices to volume conversion.
i've downloaded the rat atlas from the loni ucla homepage, but unfortunately
the images are single slices only available in the GIF format.
then i start to convert the gif's to analyze using "medcon" and then 
converting to to minc using "ana2mnc".
now i'm able to display the slice using "Display" but i'm not able to 
concat in the right way using "mincconcat".

has anyone a idea to setup a volume from single slices?

greetings,

oliver




-- 
Oliver Winz, M.Sc.
Molecular Neuroimaging Group
Institute of Medicine
Research Centre Juelich
D-52425 Juelich
Germany
Phone: +49 2461 61-6493
Web: http://www.fz-juelich.de/ime/mni
Location: Building 15.9, Room 3010


From thor4ooo at gmail.com  Wed Sep 20 17:20:07 2006
From: thor4ooo at gmail.com (Thorarin Bjarnason)
Date: Wed, 20 Sep 2006 15:20:07 -0600
Subject: [MINC-users] using N3 - parameter values
Message-ID: <9354d5230609201420q70cfda5mcc7df2e220ce001e@mail.gmail.com>

Hello All,

How does one use N3? What flags do users generally set? When I run the
default, there are very little changes. Randomly setting flags seems
hardly scientific  :-).

I realize these questions are simple, but I'm having trouble finding
solutions on the web. Can anyone profide advice or point me towards
some documentation?

Cheers,

-- 

Thorarin Bjarnason, BEng, MASc
www.imaginginformatics.ca

From jason at bic.mni.mcgill.ca  Thu Sep 21 10:06:37 2006
From: jason at bic.mni.mcgill.ca (Jason Lerch)
Date: Thu, 21 Sep 2006 10:06:37 -0400
Subject: [MINC-users] using N3 - parameter values
In-Reply-To: <9354d5230609201420q70cfda5mcc7df2e220ce001e@mail.gmail.com>
References: <9354d5230609201420q70cfda5mcc7df2e220ce001e@mail.gmail.com>
Message-ID: <485C9626-D1B9-4134-86FA-5619EAAC2B09@bic.mni.mcgill.ca>


On 20-Sep-06, at 5:20 PM, Thorarin Bjarnason wrote:

> Hello All,
>
> How does one use N3? What flags do users generally set? When I run the
> default, there are very little changes. Randomly setting flags seems
> hardly scientific  :-).

The default should work on 1.5T images. The most important parameters  
for nu_correct to play with are:

-mask binary_mask.mnc -> limits the processing to a region of  
interest - usually a good idea.
-distance -> lowering the distance to less than the default of 200 is  
often a good way of removing stronger inhomogeneities.
-fwhm -> lowering the width of the deconvolution kernel can also  
increase accuracy.

Another good tool to know is imp2field. nu_correct outputs two files  
- the corrected minc file and the field that it found (and removed).  
To actually view the field you have to turn it into a minc file first  
- this is what imp2field does.

Hope this helps,

Jason

>
> I realize these questions are simple, but I'm having trouble finding
> solutions on the web. Can anyone profide advice or point me towards
> some documentation?
>
> Cheers,
>
> -- 
>
> Thorarin Bjarnason, BEng, MASc
> www.imaginginformatics.ca
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From forrest.bao at gmail.com  Wed Sep 27 21:41:49 2006
From: forrest.bao at gmail.com (Forrest S. Bao)
Date: Thu, 28 Sep 2006 09:41:49 +0800
Subject: [MINC-users] install autoreg_model error
Message-ID: <889df5f00609271841sa4f6e23v1dd86f73c1b9114a@mail.gmail.com>

Hi guys,

I tried to install the autoreg_model few days ago. But I see many errors
saying
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)

Due to this problem, the installation of autoreg_model failed.

How can I fix this problem and install it successfully?

Following is the shell record:

mri at MRI:~/fmri/mni_autoreg_model-1.03$ make install
    Creating directory /usr/local/mni/share/mni_autoreg
    I hope you have several dozen MB free there!
Using base filename average_305
Note that your input volume *must* be in Talairach space for this to work
** Making average_305_pad.mnc from average_305.mnc by resampling on 2mm grid
and  padding by 16mm
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:12:29]
/usr /local/mni/bin/mincresample -clobber average_305.mnc
average_305_pad.mnc -start -102.095 -142.51 -84.25 -step 2 2 2 -nelements
102 126 94
Transforming
slices:............................................................
..................................Done
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
** Building 16mm data for average_305
Making byte volume...
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:12:31]
/usr /local/mni/bin/mincreshape -clobber tmp_16_blur.mnc
average_305_16_blur.mnc -sta rt 18,8,8 -count 58,110,86
Copying
chunks:..........................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
Transforming
slices:..........................................................Do ne
** Building 8mm data for average_305
Making byte volume...
Transforming
slices:..............................................................................................Done
Making byte volume dx...Making byte volume dy...Making byte volume
dz...[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25
17:12:34] /usr/local/mni/bin/mincreshape -clobber tmp_8_blur.mnc
average_305_8_blur.mnc -start 13,8,8 -count 68,110,86
Copying
chunks:....................................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:12:34]
/usr/local/mni/bin/mincreshape -clobber tmp_8_dxyz.mnc
average_305_8_dxyz.mnc -start 13,8,8 -count 68,110,86
Copying
chunks:....................................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
Transforming
slices:....................................................................Done
** Making average_305_pad4.mnc from average_305.mnc by padding by 4mm
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:12:34]
/usr/local/mni/bin/mincreshape -clobber average_305.mnc average_305_pad4.mnc
-start -4,-4,-4 -count 164,228,180
Copying
chunks:....................................................................................................................................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
** Building 4mm data for average_305
Making byte volume...
Making byte volume dx...Making byte volume dy...Gradient volume:
..............................................................Making byte
volume dz...
Transforming
slices:....................................................................................................................................................................Done
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:12:47]
/usr/local/mni/bin/mincreshape -clobber tmp_4_blur.mnc
average_305_4_blur.mnc -start 9,9,9 -count 146,210,162
Copying
chunks:..................................................................................................................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:12:47]
/usr/local/mni/bin/mincreshape -clobber tmp_4_dxyz.mnc
average_305_4_dxyz.mnc -start 9,9,9 -count 146,210,162
Copying
chunks:..................................................................................................................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
Transforming
slices:..................................................................................................................................................Done
** Building 2mm data for average_305
Making byte volume...
Making byte volume dx...Making byte volume dy...Gradient volume:
..............................................................Making byte
volume dz...
Transforming
slices:....................................................................................................................................................................Done
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:13:00]
/usr/local/mni/bin/mincreshape -clobber tmp_2_blur.mnc
average_305_2_blur.mnc -start 7,7,7 -count 150,214,166
Copying
chunks:......................................................................................................................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
[autocrop] [mri at MRI:/usr/local/mni/share/mni_autoreg] [2006-09-25 17:13:00]
/usr/local/mni/bin/mincreshape -clobber tmp_2_dxyz.mnc
average_305_2_dxyz.mnc -start 7,7,7 -count 150,214,166
Copying
chunks:......................................................................................................................................................Done.
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
Transforming
slices:......................................................................................................................................................Done
[2]+  Done                    gedit Makefile
mri at MRI:~/fmri/mni_autoreg_model-1.03$ cd ..]
bash: cd: ..]: No such file or directory
mri at MRI:~/fmri/mni_autoreg_model-1.03$ cd ..
mri at MRI:~/fmri$ ls
AIR5.2.5                ebtks-1.6.1                minc-1.2
mni_n3-1.05.tar.gz
AIR5.2.5.tar.gz         ebtks-1.6.1.tar.gz         minc-1.2.tar.gz
mni_perllib-0.07
bicpl-1.4.3             emma-0.9.7-linux.tar.gz    minc-2.0.10
mni_perllib-0.07.tar.gz
bicpl-1.4.3.tar.gz      freeglut-2.4.0             minc-2.0.10.tar.gz
N3
classify-1.0.03         freeglut-2.4.0.tar.gz      mni_autoreg-0.99.2
netcdf-3.6.1
classify-1.0.03.tar.gz  Getopt-Tabular-0.3
mni_autoreg-0.99.2.tar.gz
netcdf-3.6.1.tar.gz
cobra_v031.tar.gz       Getopt-Tabular-0.3.tar.gz
mni_autoreg_model-1.03
PIPELINE.zip
Display-1.4.1           glut-3.6.tar.gz            mni_autoreg_model-
1.03.tar.gz         Register-1.3.6
Display-1.4.1.tar.gz    instruction.txt            mni-models_average305-
lin-1.0.tar.gz  Register-1.3.6.tar.gz
mri at MRI:~/fmri$ cd ..
mri at MRI:~$ ls
004.HDR                  010_RTIP.mnc     112-1.MNC
004.IMG                  011.HDR          112-2.MNC
004.MNC                  011.IMG
1.2.840.113619.2.134.1762897138.1708.1154955905.102
004_RTIP_MC.log          011.MNC
1.2.840.113619.2.134.1762897138.1708.1154955905.117
004_RTIP_MC.mnc          011_RTIP_MC.log  8-10
004_RTIP.mnc             011_RTIP_MC.mnc  a
005.HDR                  011_RTIP.mnc     b
005.IMG                  014.HDR          cobra-20030803-185544
005.MNC                  014.IMG          cobra-20030803-191004
005_RTIP_MC.log          014.MNC          cobra-20030803-191700
005_RTIP_MC.mnc          014_RTIP_MC.log  cobra-20030803-192529
005_RTIP.mnc             014_RTIP_MC.mnc  cobra-20030803-192817
0068_bold_signal_MC.log  014_RTIP.mnc     cobra-20030803-192953
0068_bold_signal_MC.mnc  015.HDR          cobra-20030803-193842
0068_bold_signal.mnc     015.IMG          Desktop
006.HDR                  015.MNC          Examples
006.IMG                  015_RTIP_MC.log  fmri
006.MNC                  015_RTIP_MC.mnc  fmri_bin
006_RTIP_MC.log          015_RTIP.mnc     fmri.tar.gz
006_RTIP_MC.mnc          017.HDR
freesurfer-Linux-centos4-stable-pub-v3.0.3-full.tar.gz
006_RTIP.mnc             017.IMG          huangliqiu_contrast
007.HDR                  017.MNC
huang_pi_chun_20051017_090041_12_mri_1x1x1_toRet.mnc
007.IMG                  017_RTIP_MC.log  INFO-1.MNC
007.MNC                  017_RTIP_MC.mnc  INFO-2.MNC
007_RTIP_MC.log          017_RTIP.mnc     lv06.mnc
007_RTIP_MC.mnc          018.HDR          lv07.mnc
007_RTIP.mnc             018.IMG          lv08.mnc
008.HDR                  018.MNC          lv09.mnc
008.IMG                  018_RTIP_MC.log  lv1t.mnc
008.MNC                  018_RTIP_MC.mnc  mni_autoreg-0.1l
008_RTIP_MC.log          018_RTIP.mnc     mni_autoreg-0.9.tar.tar
008_RTIP_MC.mnc          019.HDR          total_i.xfm
008_RTIP.mnc             019.IMG          total.xfm
009.HDR                  019.MNC          vfsCombinedEye2.m
009.IMG                  019_RTIP_MC.log  vfsCombinedEye.m
009.MNC                  019_RTIP_MC.mnc  xingfeng_matlab
009_RTIP_MC.log          019_RTIP.mnc     zhangzhiying
009_RTIP_MC.mnc          020.HDR
zhang_zhi_ying_f_31_20060813_130148_16_mri.mnc
009_RTIP.mnc             020.IMG
zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri.mnc
010.HDR                  020.MNC
zhang_zhi_ying_f_31_20060813_130148_21_mri.mnc
010.IMG                  020_RTIP_MC.log
zhang_zhi_ying_f_31_20060813_130148_3_mri.mnc
010.MNC                  020_RTIP_MC.mnc  zhenggang
010_RTIP_MC.log          020_RTIP.mnc
010_RTIP_MC.mnc          111.MNC
mri at MRI:~$ mritotal zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri.mnc
Usage: mritotal [options] input_volume output_transform
       mritotal -help

Incorrect number of arguments
mri at MRI:~$ mritotal zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri.mnc
111.xfm
Loading configuration file
/usr/local/mni/bin/../etc/mni_autoreg/mritotal.cfg
Loading protocol default (protocol file =
/usr/local/mni/bin/../etc/mni_autoreg/mritotal.default.cfg)
   source = zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri.mnc
    model = /usr/local/mni/bin/../share/mni_autoreg/average_305
transform = 111.xfm
 protocol = default:
    linear fit only
    subsample heuristically
    crop heuristically
    blur with 16 and 8 mm FHWM kernels
    pad/unpad correctly (encroach on original volume)
    default objective function = cross-correlation

Subsampling/cropping data:
[mritotal] [mri at MRI:/home/mri] [2006-09-25 17:14:21]
/usr/local/mni/bin/autocrop
zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri.mnc
/var/tmp/mritotal_5597//zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri_crop.mnc
-step -1.875024 -1.875 2 -extend 0,0 0,0 0,0
[autocrop] [mri at MRI:/home/mri] [2006-09-25 17:14:22]
/usr/local/mni/bin/mincresample
zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri.mnc
/var/tmp/mritotal_5597//zhang_zhi_ying_f_31_20060813_130148_1x1x1_mri_crop.mnc
-start 116.839072 97.947 -31.2595 -step -1.875024 -1.875 2 -nelements 129
128 54
Transforming
slices:......................................................Done
(from miopen): Can't write compressed file
ncredef: ncid -1: Not a netCDF id
ncattput: ncid -1: Not a netCDF id
ncclose: ncid -1: Not a netCDF id
autocrop: crashed while running minc_modify_header (termination status=768)
mritotal: crashed while running autocrop (termination status=768)


-- 
Forrest Sheng Bao
Dept. of Medical Imaging, Clinical School of Medical College
Nanjing University

Home Page: http://forrest.bao.googlepages.com
MSN: bsh1984 at hotmail.com
Yahoo! : forrestbao at yahoo.com.cn
Google : forrest.bao at gmail.com
AIM/ICQ: forrestbao
Skype: forrestbao

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

From misssophy at gmail.com  Thu Sep 28 16:35:38 2006
From: misssophy at gmail.com (=?ISO-8859-1?Q?Sofie_S=F8rensen?=)
Date: Thu, 28 Sep 2006 22:35:38 +0200
Subject: [MINC-users] Display cannot enlarge!!!
Message-ID: <a1bf1cda0609281335o56a1b638r1d5bad6163e8af46@mail.gmail.com>

Hi,

I'm running Display in Ubuntu 6.06. When running Display, I can only view in
a small window. When I enlarge the viewing, the pictures (3 slices)
disappear. It seems, that there is only allocated space in the view for a
certain picture size, and therefore, they disappear when completely
enlarged.

Can anyone explain to me, what is wrong? Is there some settings in the
program that can be changed?

I don't get any warnings!

Sofie Lykke S?rensen, student
Biomedical Engineering,
Aalborg University, Denmark

From lau at bic.mni.mcgill.ca  Thu Sep 28 17:50:45 2006
From: lau at bic.mni.mcgill.ca (Jonathan LAU)
Date: Thu, 28 Sep 2006 17:50:45 -0400
Subject: [MINC-users] Display cannot enlarge!!!
In-Reply-To: <a1bf1cda0609281335o56a1b638r1d5bad6163e8af46@mail.gmail.com>
References: <a1bf1cda0609281335o56a1b638r1d5bad6163e8af46@mail.gmail.com>
Message-ID: <eb9fb4b10609281450h3874e41dse314ce294a8bf576@mail.gmail.com>

Hi Sofie,

I have the same problem with Display on my laptop (also Ubuntu Dapper Drake)
-- are you also using a widescreen?
http://www.bic.mni.mcgill.ca/~lau/img/Display_clipping.jpg<http://www.bic.mni.mcgill.ca/%7Elau/img/Display_clipping.jpg>

I've posted about a similar problem with register, where the 3rd view clips
when maximized to full widescreen but the Display issue you raised is much
more severe.  For the record:
http://www.bic.mni.mcgill.ca/~lau/img/register_ws_noclip.jpg<http://www.bic.mni.mcgill.ca/%7Elau/img/register_ws_noclip.jpg>
http://www.bic.mni.mcgill.ca/~lau/img/register_ws_clip.jpg<http://www.bic.mni.mcgill.ca/%7Elau/img/register_ws_clip.jpg>

I'm afraid to look at the code, but may try to look at it one of these
days.  Anyone have any ideas?

cheers,
jon

On 9/28/06, Sofie S?rensen <misssophy at gmail.com> wrote:
>
> Hi,
>
> I'm running Display in Ubuntu 6.06. When running Display, I can only view
> in
> a small window. When I enlarge the viewing, the pictures (3 slices)
> disappear. It seems, that there is only allocated space in the view for a
> certain picture size, and therefore, they disappear when completely
> enlarged.
>
> Can anyone explain to me, what is wrong? Is there some settings in the
> program that can be changed?
>
> I don't get any warnings!
>
> Sofie Lykke S?rensen, student
> Biomedical Engineering,
> Aalborg University, Denmark
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From misssophy at gmail.com  Fri Sep 29 15:07:21 2006
From: misssophy at gmail.com (=?ISO-8859-1?Q?Sofie_S=F8rensen?=)
Date: Fri, 29 Sep 2006 21:07:21 +0200
Subject: [MINC-users] Display cannot enlarge!!!
Message-ID: <a1bf1cda0609291207x60beb7dbu2aab7de6d4496fe0@mail.gmail.com>

Thanks Jonathan!
It seems that we got the same problem.
I wont be able to go online for the next to weeks, but i'm still woking to
solve the problem, and will be happy to get new clews!

On 9/29/06, minc-users-request at bic.mni.mcgill.ca <
minc-users-request at bic.mni.mcgill.ca> wrote:
>
> 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. Display cannot enlarge!!! ( Sofie S?rensen )
>    2. Re: Display cannot enlarge!!! (Jonathan LAU)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 28 Sep 2006 22:35:38 +0200
> From: " Sofie S?rensen " <misssophy at gmail.com>
> Subject: [MINC-users] Display cannot enlarge!!!
> To: minc-users at bic.mni.mcgill.ca
> Message-ID:
>         <a1bf1cda0609281335o56a1b638r1d5bad6163e8af46 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> I'm running Display in Ubuntu 6.06. When running Display, I can only view
> in
> a small window. When I enlarge the viewing, the pictures (3 slices)
> disappear. It seems, that there is only allocated space in the view for a
> certain picture size, and therefore, they disappear when completely
> enlarged.
>
> Can anyone explain to me, what is wrong? Is there some settings in the
> program that can be changed?
>
> I don't get any warnings!
>
> Sofie Lykke S?rensen, student
> Biomedical Engineering,
> Aalborg University, Denmark
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 28 Sep 2006 17:50:45 -0400
> From: "Jonathan LAU" <lau at bic.mni.mcgill.ca>
> Subject: Re: [MINC-users] Display cannot enlarge!!!
> To: "MINC users mailing list" <minc-users at bic.mni.mcgill.ca>
> Message-ID:
>         <eb9fb4b10609281450h3874e41dse314ce294a8bf576 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Sofie,
>
> I have the same problem with Display on my laptop (also Ubuntu Dapper
> Drake)
> -- are you also using a widescreen?
> http://www.bic.mni.mcgill.ca/~lau/img/Display_clipping.jpg<
> http://www.bic.mni.mcgill.ca/%7Elau/img/Display_clipping.jpg>
>
> I've posted about a similar problem with register, where the 3rd view
> clips
> when maximized to full widescreen but the Display issue you raised is much
> more severe.  For the record:
> http://www.bic.mni.mcgill.ca/~lau/img/register_ws_noclip.jpg<
> http://www.bic.mni.mcgill.ca/%7Elau/img/register_ws_noclip.jpg>
> http://www.bic.mni.mcgill.ca/~lau/img/register_ws_clip.jpg<
> http://www.bic.mni.mcgill.ca/%7Elau/img/register_ws_clip.jpg>
>
> I'm afraid to look at the code, but may try to look at it one of these
> days.  Anyone have any ideas?
>
> cheers,
> jon
>
> On 9/28/06, Sofie S?rensen <misssophy at gmail.com> wrote:
> >
> > Hi,
> >
> > I'm running Display in Ubuntu 6.06. When running Display, I can only
> view
> > in
> > a small window. When I enlarge the viewing, the pictures (3 slices)
> > disappear. It seems, that there is only allocated space in the view for
> a
> > certain picture size, and therefore, they disappear when completely
> > enlarged.
> >
> > Can anyone explain to me, what is wrong? Is there some settings in the
> > program that can be changed?
> >
> > I don't get any warnings!
> >
> > Sofie Lykke S?rensen, student
> > Biomedical Engineering,
> > Aalborg University, Denmark
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
> ------------------------------
>
> _______________________________________________
> 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 14, Issue 7
> *****************************************
>