From sylvain at bic.mni.mcgill.ca  Tue Jun  1 09:43:47 2010
From: sylvain at bic.mni.mcgill.ca (Sylvain Milot)
Date: Tue, 1 Jun 2010 09:43:47 -0400 (EDT)
Subject: [MINC-users] MRI simulations. (fwd)
Message-ID: <Pine.LNX.4.64.1006010942190.27941@mustardseed.bic.mni.mcgill.ca>


A minc-users question, anyone ?

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

---------- Forwarded message ----------
Date: Tue, 1 Jun 2010 11:50:34 +0200
From: FIDEL ALFARO ALMAGRO <falfaro13 at alumno.uned.es>
To: bicadmin at bic.mni.mcgill.ca
Subject: MRI simulations.

To whom it may concern,

Good morning. My name is Fidel, and I am a Spanish computer scientist
doing a PhD in Artificial Vision. At the moment, I am trying to reproduce
some algorithms regarding the segmentation of brain tumors and I want to
use some of the brain models you give in your web
http://mouldy.bic.mni.mcgill.ca/brainweb/anatomic_normal_20.html.

I am trying to create a brain atlas using your brain models, but I have a
problem: I want to download the T1 simulation of a brain model and I want
to use it as a template, using the 'CRISP' model to know the tissue
classification of each pixel. Nevertheless, the T1 simulation and the
crisp model have different dimensions ( [181,256,256] & [362,434,362] ),
being this way impossible to "adjust" one to the other, as the axis have
not the same proportion.

Why are you creating the simulations this way? Do you have T1 simulation
with the same dimensions as the rest of the brain tissue models? Do you
know an easy way to adjust the T1 simulation to the rest of the files.

Thanks in advance for your hard and useful work!

Fidel Alfaro.

From burt.crepeault at crulrg.ulaval.ca  Tue Jun  1 16:17:29 2010
From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=)
Date: Tue, 1 Jun 2010 16:17:29 -0400
Subject: [MINC-users] N3 - Changes since v 1.10.1
Message-ID: <AANLkTikTKmKsf0yHm4GoXNn73-9OvQ31Gaq-mJbs_ZM3@mail.gmail.com>

Hi all,

Our lab recently upgraded N3 from 1.10.1 to 1.11.0. Applying nu_correct to
same images yields different results and we are trying to assess the extent
and meaning of those changes.

The 1.11.0 changelog says:

2009-06-15  Claude Lepage  <claude at bic.mni.mcgill.ca>
    * Remove downsampling in evaluation of field (computers are fast
          now, so be more accurate by sampling at full resolution)
    * Correct the field in the region outside the mask to make
          sure the mask varies smoothly away from the brain (important
          with the previous changes)
    * New program for the far-field correction

2009-05-08  Claude Lepage  <claude at bic.mni.mcgill.ca>
    * Make nu_estimate_np_and_em.in invariant to voxel steps (via
          spline_smooth in EBTKS - must use EBTKS 1.6.2 or above)
    * Free memory after usage

2008-06-10  Andrew L Janke <a.janke at gmail.com>
    * updated README, merged CHANGES and WHATSNEW into NEWS
    * src/NUcorrect/nu_estimate_np_and_EM: added code to check on
      (deprecated) use of the EM section and thus spit a warning
    * epm-header.in: removed netcdf dependency


Also, the help output from both version has one additional option in version
1.11.0:

-lambda <value>   regularization coefficient for splines [default: 1.0e-7]

I suppose these changes have been tried, tested and documented somewhere.
Can someone point me in the right direction so I can have a better idea of
what we are dealing with?


Burt.

From claude at bic.mni.mcgill.ca  Tue Jun  1 17:23:17 2010
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Tue, 1 Jun 2010 17:23:17 -0400
Subject: [MINC-users] N3 - Changes since v 1.10.1
In-Reply-To: <AANLkTikTKmKsf0yHm4GoXNn73-9OvQ31Gaq-mJbs_ZM3@mail.gmail.com>
Message-ID: <201006012123.o51LNHvN027840@grumio.bic.mni.mcgill.ca>

Hi Burt,

These are my changes. Of course, you will not obtain the same results as before,
because the previous code had a major bug.

If I can summarize somehow briefly:

N3 tries to minimize:

         E/N + Lambda*J

where E is the fitting term (cubic spline to image),
      N is the number of sampling points
      Lambda is a damping coefficient
      J is a stabilization term (matrix of derivatives)
You can read the original paper by Sled for my details.

In implementations prior to 1.11.0, the normalization by N was missing.
So instead of the average error per sampling point E/N, it was the total
error E. Another way of viewing the problem is that the effective damping
coefficient was Lambda*N instead of Lambda. So the amount of effective
damping would vary with number of sampling points (voxel sizes), thus the
old N3 was NOT voxel size invariant. For example, running old N3 on the
same image at 1mm or 0.5mm voxels would give totally different answers.
Fortunately, the old N3 scripts were calibrated to have a reasonable
damping Lambda in stereotaxic MNI space at 1mm voxels. Aside from that,
results would be unpredictable. Still, there was too much damping in 
the old N3. Lambda=1.0e-7 might be a little be too small. Perhaps 1.0e-6
would be better. The damping corresponding to the behaviour of the old
N3 would be approximately Lambda=5*1.0e-5.

In a second round of improvements, I modified the way in which the correction
field was evaluated outside the mask. Before, it would extrapolate the cubic
splines, which would cause problem at small spline distances like 25mm. Why?
Another complicated story. N3 computes a correction field in volume space 
inside the mask only. To extrapolate outside the mask, old N3 would set the
correction field to 1 everywhere outside the mask, with the real correction
inside the mask, then respline the extended correction field in/out the mask
and save the spline coefficients in compact form (.imp file). The drawback
with this approach is the lack of continuity in the correction field at the 
mask border. The end result is that the extended correction field is erroneous
around the perimeter of the mask, which happens to be in the cortex. This 
problem is amplified for 3-Tesla scans. In the new N3, I extend the correction 
field outside the mask by solving a Laplacian field, without modifying the 
correction field inside the mask.

Overall, the new N3 will make a substantial difference for 3T scans and
scans not at 1mm voxels (animal scans, for example).

I think this is it for the changes. Quite complicated indeed. I hope this
description helps you. If you have specific questions, don't hesitate to 
post them here.

Claude

> Our lab recently upgraded N3 from 1.10.1 to 1.11.0. Applying nu_correct to
> same images yields different results and we are trying to assess the extent
> and meaning of those changes.
>
> The 1.11.0 changelog says:
>
> 2009-06-15  Claude Lepage  <claude at bic.mni.mcgill.ca>
>     * Remove downsampling in evaluation of field (computers are fast
>           now, so be more accurate by sampling at full resolution)
>     * Correct the field in the region outside the mask to make
>           sure the mask varies smoothly away from the brain (important
>           with the previous changes)
>     * New program for the far-field correction
>
> 2009-05-08  Claude Lepage  <claude at bic.mni.mcgill.ca>
>     * Make nu_estimate_np_and_em.in invariant to voxel steps (via
>           spline_smooth in EBTKS - must use EBTKS 1.6.2 or above)
>     * Free memory after usage
>
> 2008-06-10  Andrew L Janke <a.janke at gmail.com>
>     * updated README, merged CHANGES and WHATSNEW into NEWS
>     * src/NUcorrect/nu_estimate_np_and_EM: added code to check on
>       (deprecated) use of the EM section and thus spit a warning
>     * epm-header.in: removed netcdf dependency
>
>
> Also, the help output from both version has one additional option in version
> 1.11.0:
>
> -lambda <value>   regularization coefficient for splines [default: 1.0e-7]
>
> I suppose these changes have been tried, tested and documented somewhere.
> Can someone point me in the right direction so I can have a better idea of
> what we are dealing with?
>
>
> Burt.

From alex at bic.mni.mcgill.ca  Tue Jun  1 21:39:52 2010
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Tue, 1 Jun 2010 21:39:52 -0400
Subject: [MINC-users] MRI simulations. (fwd)
In-Reply-To: <Pine.LNX.4.64.1006010942190.27941@mustardseed.bic.mni.mcgill.ca>
References: <Pine.LNX.4.64.1006010942190.27941@mustardseed.bic.mni.mcgill.ca>
Message-ID: <AANLkTilGb6BNIXZcRNDTUS6AyVze1riHXkRUnVXNnpVP@mail.gmail.com>

Hello Fidel,

The reason why the simulation model has higher resolution than the
resulting simulated MRI, is to allow the simulations to contain
partial volume effects - as you would encounter in an actual MRI. In
other words, this was done to increase the realism of the simulations.

However, the images live in the same space, meaning that the world
coordinate spaces of the model and the simulation line up. This in
turn means that you can simply resample the model to the sampling
space of the simulaton (or vice versa) using something like:

   mincresample -nearest -like <T1.mnc> <crisp.mnc> <crisp_like_T1.mnc>

Note that when resampling a label (discrete) volume you will need to
use nearest neighbor "interpolation" (-nearest), otherwise you will be
left with non-integer label values. A better way to do this is to use
resample_labels which goes about it somewhat more intelligently and
will result in a less voxellated resampled label volume.

-- Alex

> Date: Tue, 1 Jun 2010 11:50:34 +0200
> From: FIDEL ALFARO ALMAGRO <falfaro13 at alumno.uned.es>
> To: bicadmin at bic.mni.mcgill.ca
> Subject: MRI simulations.
>
> To whom it may concern,
>
> Good morning. My name is Fidel, and I am a Spanish computer scientist
> doing a PhD in Artificial Vision. At the moment, I am trying to reproduce
> some algorithms regarding the segmentation of brain tumors and I want to
> use some of the brain models you give in your web
> http://mouldy.bic.mni.mcgill.ca/brainweb/anatomic_normal_20.html.
>
> I am trying to create a brain atlas using your brain models, but I have a
> problem: I want to download the T1 simulation of a brain model and I want
> to use it as a template, using the 'CRISP' model to know the tissue
> classification of each pixel. Nevertheless, the T1 simulation and the
> crisp model have different dimensions ( [181,256,256] & [362,434,362] ),
> being this way impossible to "adjust" one to the other, as the axis have
> not the same proportion.
>
> Why are you creating the simulations this way? Do you have T1 simulation
> with the same dimensions as the rest of the brain tissue models? Do you
> know an easy way to adjust the T1 simulation to the rest of the files.
>
> Thanks in advance for your hard and useful work!
>
> Fidel Alfaro.

From francois.hebert007 at gmail.com  Fri Jun  4 17:29:38 2010
From: francois.hebert007 at gmail.com (francois hebert)
Date: Fri, 4 Jun 2010 17:29:38 -0400
Subject: [MINC-users] xfm2param
Message-ID: <AANLkTimU5gC1roZYYD4exWEo8fEhACBegQh-Jm-pgkOY@mail.gmail.com>

Hi All,

I met a problem with xfm2param.
I had this transformation

Transform_Type = Linear;
Linear_Transform =
 -0.999861 -0.01228965 -0.01125913 0
 0.01405692 -0.9847437 -0.1734425 0
 -0.008955808 -0.1735767 0.9847796 0;

when I give this transformation to xfm2param I had this answer:

WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
Cannot convert R to radians!  -0.999861   -0.012290   -0.011259
   0.014057   -0.984744   -0.173442
  -0.008956   -0.173577    0.984780
after parameter extraction
-center         0.00000    0.00000    0.00000
-translation    0.00000    0.00000    0.00000
-rotation       0.00000    0.00000    0.00000
-scale          1.00000    1.00000    1.00000
-shear          0.00000    0.00000    0.00000

Where the problem is coming from?

Thanks,

Francois

From lasse at hst.aau.dk  Mon Jun  7 06:25:47 2010
From: lasse at hst.aau.dk (Lasse Riis Oestergaard)
Date: Mon, 7 Jun 2010 12:25:47 +0200 (CEST)
Subject: [MINC-users] Ubuntu Lynx Packages
In-Reply-To: <552294984.412592.1275906090911.JavaMail.root@zimbra-store01.hst.aau.dk>
Message-ID: <1725313104.412879.1275906347027.JavaMail.root@zimbra-store01.hst.aau.dk>

Hi Andrew

Will you upload a 32-bit version?

Best
Lasse

-- 
Lasse Riis ?stergaard, PhD
Associate Professor
Dept. of Health Science and Technology, Aalborg University
Fredrik Bajers Vej 7D, DK-9220 Aalborg
Tel: +45 9940 8743 Mobile: +45 2142 8200

----- "Luis Concha" <lconcha at gmail.com> wrote:

> Hello Andrew.
> 
> Thanks for posting the ubuntu-lucid packages. Is there any chance
> there will
> be the equivalent 32-bit versions?
> 
> Thanks
> 
> Luis Concha
> 
> 
> 
> From: Andrew Janke <a.janke at gmail.com>
> 
> > Subject: [MINC-users] Ubuntu Lynx Packages
> > To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
> > Message-ID:
> >       
> <AANLkTimDyCJXA-bU6wzLptcR66skAQ-71BZ69TyPOSik at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi all,
> >
> > I am currently uploading packages for ubuntu lynx here:
> >
> >   http://packages.bic.mni.mcgill.ca/ubuntu-lucid/
> >
> > This has required some changes to EBTKS for a build against gcc 4.3
> > and a few other things. It is currently missing brain-view as there
> is
> > some qt3/4 build config issue that I am yet to hunt down. Let me
> know
> > if something breaks with them for you.
> >
> >
> > --
> > Andrew Janke
> > (a.janke at gmail.com || http://a.janke.googlepages.com/)
> > Canberra->Australia    +61 (402) 700 883
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From a.janke at gmail.com  Mon Jun  7 07:38:01 2010
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 7 Jun 2010 21:38:01 +1000
Subject: [MINC-users] xfm2param
In-Reply-To: <AANLkTimU5gC1roZYYD4exWEo8fEhACBegQh-Jm-pgkOY@mail.gmail.com>
References: <AANLkTimU5gC1roZYYD4exWEo8fEhACBegQh-Jm-pgkOY@mail.gmail.com>
Message-ID: <AANLkTinjklAmKLf_A76iYYKRurqjaV2sshU-kKrTpuba@mail.gmail.com>

Hi Francois,

This behaviour is considered normal as the xfm you have passed in
cannot be resolved as a set of rotations less than 90 degrees.
xfm2param can only handle such matrix decompositions and thus spat the
error.

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


On Sat, Jun 5, 2010 at 07:29, francois hebert
<francois.hebert007 at gmail.com> wrote:
> Hi All,
>
> I met a problem with xfm2param.
> I had this transformation
>
> Transform_Type = Linear;
> Linear_Transform =
> ?-0.999861 -0.01228965 -0.01125913 0
> ?0.01405692 -0.9847437 -0.1734425 0
> ?-0.008955808 -0.1735767 0.9847796 0;
>
> when I give this transformation to xfm2param I had this answer:
>
> WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
> Cannot convert R to radians! ?-0.999861 ? -0.012290 ? -0.011259
> ? 0.014057 ? -0.984744 ? -0.173442
> ?-0.008956 ? -0.173577 ? ?0.984780
> after parameter extraction
> -center ? ? ? ? 0.00000 ? ?0.00000 ? ?0.00000
> -translation ? ?0.00000 ? ?0.00000 ? ?0.00000
> -rotation ? ? ? 0.00000 ? ?0.00000 ? ?0.00000
> -scale ? ? ? ? ?1.00000 ? ?1.00000 ? ?1.00000
> -shear ? ? ? ? ?0.00000 ? ?0.00000 ? ?0.00000
>
> Where the problem is coming from?
>
> Thanks,
>
> Francois
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From francois.hebert007 at gmail.com  Mon Jun  7 13:46:44 2010
From: francois.hebert007 at gmail.com (francois hebert)
Date: Mon, 7 Jun 2010 13:46:44 -0400
Subject: [MINC-users] xfm2param
In-Reply-To: <AANLkTinjklAmKLf_A76iYYKRurqjaV2sshU-kKrTpuba@mail.gmail.com>
References: <AANLkTimU5gC1roZYYD4exWEo8fEhACBegQh-Jm-pgkOY@mail.gmail.com>
	<AANLkTinjklAmKLf_A76iYYKRurqjaV2sshU-kKrTpuba@mail.gmail.com>
Message-ID: <AANLkTik6sU2wZ-ciEkR9rRvkU5afBbMNBZ7LvWzHhx2o@mail.gmail.com>

Hi Andrew,

thank you for the help.

Best reagrds,

Francois

2010/6/7 Andrew Janke <a.janke at gmail.com>

> Hi Francois,
>
> This behaviour is considered normal as the xfm you have passed in
> cannot be resolved as a set of rotations less than 90 degrees.
> xfm2param can only handle such matrix decompositions and thus spat the
> error.
>
> --
> Andrew Janke
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
>
>
> On Sat, Jun 5, 2010 at 07:29, francois hebert
> <francois.hebert007 at gmail.com> wrote:
> > Hi All,
> >
> > I met a problem with xfm2param.
> > I had this transformation
> >
> > Transform_Type = Linear;
> > Linear_Transform =
> >  -0.999861 -0.01228965 -0.01125913 0
> >  0.01405692 -0.9847437 -0.1734425 0
> >  -0.008955808 -0.1735767 0.9847796 0;
> >
> > when I give this transformation to xfm2param I had this answer:
> >
> > WARNING: (rotmat_to_ang.c:187) step one: rz not in the range -pi/2..pi/2
> > Cannot convert R to radians!  -0.999861   -0.012290   -0.011259
> >   0.014057   -0.984744   -0.173442
> >  -0.008956   -0.173577    0.984780
> > after parameter extraction
> > -center         0.00000    0.00000    0.00000
> > -translation    0.00000    0.00000    0.00000
> > -rotation       0.00000    0.00000    0.00000
> > -scale          1.00000    1.00000    1.00000
> > -shear          0.00000    0.00000    0.00000
> >
> > Where the problem is coming from?
> >
> > Thanks,
> >
> > Francois
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From yonas.t at gmail.com  Mon Jun 21 18:24:21 2010
From: yonas.t at gmail.com (Yonas T.)
Date: Mon, 21 Jun 2010 15:24:21 -0700
Subject: [MINC-users] Reading minc format DTI data
Message-ID: <AANLkTim7iqF9DlNdBEZht87ewlVHghWRF1hsW36Wy4s7@mail.gmail.com>

Hi all,

I am trying to read DTI data that is stored in minc file format (minc 1.0 I
am told). I am using PC and found this win32 binary distribution at:
http://packages.bic.mni.mcgill.ca/win32/

mincinfo gives

C:\Mywork>mincinfo dti.mnc
file: dti.mnc
image: signed__ short 0 to 4095
image dimensions: time zspace yspace xspace
    dimension name         length         step        start
    --------------                   ------            ----           -----
    time                            109         11.1            0
    zspace                        63           -2      69.2799
    yspace                       128           -2      189.266
    xspace                       128           -2          128

and using the commands

mincinfo -attvalue acquisition:bvalues dti.mnc > b_values.txt
mincinfo -attvalue acquisition:direction_x dti.mnc > grad_x.txt,
mincinfo -attvalue acquisition:direction_y dti.mnc > grad_y.txt,
mincinfo -attvalue acquisition:direction_z dti.mnc > grad_z.txt

I have found out that, my file contains b-values = 0,0,...0 10 of them,
followed by 3000, 3000,...,3000 (99 of them), gradient directions of
(0,0,0),...10 times followed by 99 entries of (x,y,z). This made me believe
my dti file contains, 109 volumes out of which 10 are b0 volumes and the
remaining 99 are DW volumes. So far so good.

Now, I would like to read ONLY the image part (no header information) and
save it as raw file so that I can read it in matlab; as my code for the
analysis of DTI is developed in matlab. Before even reading the image part,
this is what I thought: whatever routine I use to read the image, the result
raw file must have size of 109x63x128x128xsizeOfDataType bytes. So if I use
short (sizeOfDataType=2) datatype for reading, I would expect,
109x63x128x128x2 = 225,017,856 bytes. Similarly, if I use float I would
expect exactly twice size.

Here is what I found however:

minctoraw -normalize dti.mnc > ImageData.raw
Result: ImageData.raw file with size = 227,288,499 bytes  (about 216MB)

minctoraw -normalize -short dti.mnc > ImageData_Short.raw
Result: ImageData_Short.raw file with size = 227,288,499 bytes  (about
216MB)

mincextract dti.mnc > ImageDataWithExtract.raw
Result: ImageDataWithExtract.raw file with size = 2,141,244,230 bytes
(about 2GB)

mincextract -normalize -short dti.mnc > ImageDataWithExtract_Short.raw
Result: ImageDataWithExtract_Short.raw file with size = 225,473,844 bytes
(about 215MB)

So my questions,

1. As you can see from the result, I am baffled by these strangely different
results when using minctoraw versus mincextract calls. Worse, none of these
file sizes matches what I expected. That is the file size is LARGER than
what I expected (mincextract -normalize -short dti.mnc >
ImageDataWithExtract_Short.raw gives 225,473,844 bytes although I expected
225,017,856 bytes). Any idea, please?

2. I also found emma matlab toolbox that can read minc format images. Going
through line by line of the reading routines, I can see that this tool does
nothing but uses mincextract to read the minc file to a temporary file and
then takes the first N bytes (where N is the expected size) from the
temporary file and returns. That is although the temporary file is bigger,
what emma does is simply discard the extra bytes. My questions here is: does
this emma knows the extra bytes are at the end of the raw file read? Is
there any documentation for this?

3. Does the result of mincinfo seem meaningful? I am a bit surprised by "image:
signed__ short 0 to 4095" because I would think unsigned short would make
more sense to say range 0 - 4095.

Any ideas please? Or any better way to read minc format image to save it as
raw file?

Thank you for your help.

From vladimir.fonov at gmail.com  Mon Jun 21 18:46:54 2010
From: vladimir.fonov at gmail.com (Vladimir FONOV)
Date: Mon, 21 Jun 2010 18:46:54 -0400
Subject: [MINC-users] Reading minc format DTI data
In-Reply-To: <AANLkTim7iqF9DlNdBEZht87ewlVHghWRF1hsW36Wy4s7@mail.gmail.com>
References: <AANLkTim7iqF9DlNdBEZht87ewlVHghWRF1hsW36Wy4s7@mail.gmail.com>
Message-ID: <4C1FEBDE.3050700@gmail.com>

Hello,

Yonas T. wrote:
> Here is what I found however:
> 
> minctoraw -normalize dti.mnc > ImageData.raw
> Result: ImageData.raw file with size = 227,288,499 bytes  (about 216MB)
> 
> minctoraw -normalize -short dti.mnc > ImageData_Short.raw
> Result: ImageData_Short.raw file with size = 227,288,499 bytes  (about
> 216MB)
> 
> mincextract dti.mnc > ImageDataWithExtract.raw
> Result: ImageDataWithExtract.raw file with size = 2,141,244,230 bytes
> (about 2GB)
> 
> mincextract -normalize -short dti.mnc > ImageDataWithExtract_Short.raw
> Result: ImageDataWithExtract_Short.raw file with size = 225,473,844 bytes
> (about 215MB)

my experiment:

 > mincinfo test_dti.mnc
file: test_dti.mnc
image: signed__ short 0 to 4095
image dimensions: time zspace yspace xspace
     dimension name         length         step        start
     --------------         ------         ----        -----
     time                       32            1            0
     zspace                     40          1.2      -16.894
     yspace                    128     -1.21875      80.1687
     xspace                    128     -1.21875      77.9898

32*40*128*128*4=83886080

 > minctoraw -normalize -float test_dti.mnc > test1.raw
 > mincextract -float test_dti.mnc > test2.raw
 > ls -l test1.raw test2.raw
-rw-r--r-- 1 vfonov pet 83886080 Jun 21 18:41 test1.raw
-rw-r--r-- 1 vfonov pet 83886080 Jun 21 18:41 test2.raw

 > cmp  test1.raw test2.raw

(no messages, meaning files are identical)


> So my questions,
> 
> 1. As you can see from the result, I am baffled by these strangely different
> results when using minctoraw versus mincextract calls. Worse, none of these
> file sizes matches what I expected. That is the file size is LARGER than
> what I expected (mincextract -normalize -short dti.mnc >
> ImageDataWithExtract_Short.raw gives 225,473,844 bytes although I expected
> 225,017,856 bytes). Any idea, please?
> 
> 2. I also found emma matlab toolbox that can read minc format images. Going
> through line by line of the reading routines, I can see that this tool does
> nothing but uses mincextract to read the minc file to a temporary file and
> then takes the first N bytes (where N is the expected size) from the
> temporary file and returns. That is although the temporary file is bigger,
> what emma does is simply discard the extra bytes. My questions here is: does
> this emma knows the extra bytes are at the end of the raw file read? Is
> there any documentation for this?

As far as I know emma is unsupported now.


> 
> 3. Does the result of mincinfo seem meaningful? I am a bit surprised by "image:
> signed__ short 0 to 4095" because I would think unsigned short would make
> more sense to say range 0 - 4095.

2**12=4096 - so scanner have got 12bit ADC I suppose ?


> Any ideas please? Or any better way to read minc format image to save it as
> raw file?

You can try to use niak: http://code.google.com/p/niak/ , it uses 
mincextract internally as well.


-- 
Best regards,
  Vladimir S. FONOV ~ v.s.fonov  <at> ilmarin.info

From a.janke at gmail.com  Mon Jun 21 20:21:17 2010
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 22 Jun 2010 10:21:17 +1000
Subject: [MINC-users] i386 and amd64 ubuntu lucid packages
Message-ID: <AANLkTikX2RtG1Kh-IE6sv2xn9mq9PI4WHMC45K23Ed1G@mail.gmail.com>

Are now available here:

   http://packages.bic.mni.mcgill.ca/ubuntu-lucid/


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

From rupert.brooks at gmail.com  Mon Jun 21 22:12:50 2010
From: rupert.brooks at gmail.com (Rupert Brooks)
Date: Mon, 21 Jun 2010 22:12:50 -0400
Subject: [MINC-users] Reading minc format DTI data
In-Reply-To: <4C1FEBDE.3050700@gmail.com>
References: <AANLkTim7iqF9DlNdBEZht87ewlVHghWRF1hsW36Wy4s7@mail.gmail.com>
	<4C1FEBDE.3050700@gmail.com>
Message-ID: <AANLkTilUf6dz9E0aDy5JCkd-F-yYrgbS3Rfzk5RNC9N_@mail.gmail.com>

Hi,

I've seen a vaguely similar problem at some point in the past.  If i
remember, it was because the windows versions did not correctly do
binary writing - so some bytes actually expanded to two when written
to the disk.  Theres a similar problem with windows reading where the
file appears mysteriously truncated due to attempting to read the
CTRL-Z.   When opening files in C++ on windows, you have to be careful
to pass the binary flags exactly right or it does some kind of ascii
conversion.  I think C worked similarly.  I never remember the details
and get bitten by this problem about once a year :-P

The easiest fix would be to perform the extraction on a linux or mac
system i would guess.  Vlad - im supposing you did your experiment on
a linux box?

At some point in the distant past, i created native windows binaries
as well.   They are posted on my web site (see
www.rupertbrooks.ca/code.html).  It might be worth trying them as
well, although i kind of doubt they will work any differently than
what you tried.  If you do try them, please let me know the result,
i'll attach it to the notes about them for what its worth.

If you really cant get access to a linux system, you could try a
cygwin build instead of a native Win32 build.  It might overcome the
problem.

Good luck,
Rupert
--------------------------------------------------------------
Rupert Brooks
rupert.brooks at gmail.com




On Mon, Jun 21, 2010 at 18:46, Vladimir FONOV <vladimir.fonov at gmail.com> wrote:
> Hello,
>
> Yonas T. wrote:
>>
>> Here is what I found however:
>>
>> minctoraw -normalize dti.mnc > ImageData.raw
>> Result: ImageData.raw file with size = 227,288,499 bytes ?(about 216MB)
>>
>> minctoraw -normalize -short dti.mnc > ImageData_Short.raw
>> Result: ImageData_Short.raw file with size = 227,288,499 bytes ?(about
>> 216MB)
>>
>> mincextract dti.mnc > ImageDataWithExtract.raw
>> Result: ImageDataWithExtract.raw file with size = 2,141,244,230 bytes
>> (about 2GB)
>>
>> mincextract -normalize -short dti.mnc > ImageDataWithExtract_Short.raw
>> Result: ImageDataWithExtract_Short.raw file with size = 225,473,844 bytes
>> (about 215MB)
>
> my experiment:
>
>> mincinfo test_dti.mnc
> file: test_dti.mnc
> image: signed__ short 0 to 4095
> image dimensions: time zspace yspace xspace
> ? ?dimension name ? ? ? ? length ? ? ? ? step ? ? ? ?start
> ? ?-------------- ? ? ? ? ------ ? ? ? ? ---- ? ? ? ?-----
> ? ?time ? ? ? ? ? ? ? ? ? ? ? 32 ? ? ? ? ? ?1 ? ? ? ? ? ?0
> ? ?zspace ? ? ? ? ? ? ? ? ? ? 40 ? ? ? ? ?1.2 ? ? ?-16.894
> ? ?yspace ? ? ? ? ? ? ? ? ? ?128 ? ? -1.21875 ? ? ?80.1687
> ? ?xspace ? ? ? ? ? ? ? ? ? ?128 ? ? -1.21875 ? ? ?77.9898
>
> 32*40*128*128*4=83886080
>
>> minctoraw -normalize -float test_dti.mnc > test1.raw
>> mincextract -float test_dti.mnc > test2.raw
>> ls -l test1.raw test2.raw
> -rw-r--r-- 1 vfonov pet 83886080 Jun 21 18:41 test1.raw
> -rw-r--r-- 1 vfonov pet 83886080 Jun 21 18:41 test2.raw
>
>> cmp ?test1.raw test2.raw
>
> (no messages, meaning files are identical)
>
>
>> So my questions,
>>
>> 1. As you can see from the result, I am baffled by these strangely
>> different
>> results when using minctoraw versus mincextract calls. Worse, none of
>> these
>> file sizes matches what I expected. That is the file size is LARGER than
>> what I expected (mincextract -normalize -short dti.mnc >
>> ImageDataWithExtract_Short.raw gives 225,473,844 bytes although I expected
>> 225,017,856 bytes). Any idea, please?
>>
>> 2. I also found emma matlab toolbox that can read minc format images.
>> Going
>> through line by line of the reading routines, I can see that this tool
>> does
>> nothing but uses mincextract to read the minc file to a temporary file and
>> then takes the first N bytes (where N is the expected size) from the
>> temporary file and returns. That is although the temporary file is bigger,
>> what emma does is simply discard the extra bytes. My questions here is:
>> does
>> this emma knows the extra bytes are at the end of the raw file read? Is
>> there any documentation for this?
>
> As far as I know emma is unsupported now.
>
>
>>
>> 3. Does the result of mincinfo seem meaningful? I am a bit surprised by
>> "image:
>> signed__ short 0 to 4095" because I would think unsigned short would make
>> more sense to say range 0 - 4095.
>
> 2**12=4096 - so scanner have got 12bit ADC I suppose ?
>
>
>> Any ideas please? Or any better way to read minc format image to save it
>> as
>> raw file?
>
> You can try to use niak: http://code.google.com/p/niak/ , it uses
> mincextract internally as well.
>
>
> --
> Best regards,
> ?Vladimir S. FONOV ~ v.s.fonov ?<at> ilmarin.info
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From vladimir.fonov at gmail.com  Mon Jun 21 22:29:28 2010
From: vladimir.fonov at gmail.com (Vladimir S. Fonov)
Date: Mon, 21 Jun 2010 22:29:28 -0400
Subject: [MINC-users] Reading minc format DTI data
In-Reply-To: <AANLkTilUf6dz9E0aDy5JCkd-F-yYrgbS3Rfzk5RNC9N_@mail.gmail.com>
References: <AANLkTim7iqF9DlNdBEZht87ewlVHghWRF1hsW36Wy4s7@mail.gmail.com>	<4C1FEBDE.3050700@gmail.com>
	<AANLkTilUf6dz9E0aDy5JCkd-F-yYrgbS3Rfzk5RNC9N_@mail.gmail.com>
Message-ID: <4C202008.40904@gmail.com>

Hello,

Rupert Brooks wrote:
> The easiest fix would be to perform the extraction on a linux or mac
> system i would guess.  Vlad - im supposing you did your experiment on
> a linux box?
Yes.

> If you really cant get access to a linux system, you could try a
> cygwin build instead of a native Win32 build.  It might overcome the
> problem.
You might also try to convert minc to nifti with mnc2nii .

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

From a.janke at gmail.com  Tue Jun 22 06:17:09 2010
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 22 Jun 2010 20:17:09 +1000
Subject: [MINC-users] Reading minc format DTI data
In-Reply-To: <AANLkTim7iqF9DlNdBEZht87ewlVHghWRF1hsW36Wy4s7@mail.gmail.com>
References: <AANLkTim7iqF9DlNdBEZht87ewlVHghWRF1hsW36Wy4s7@mail.gmail.com>
Message-ID: <AANLkTinRhWvshC2kYyGGWz6E9wLNDHtzJxjJ4Gnvv7g7@mail.gmail.com>

Hi Yonas,

On Tue, Jun 22, 2010 at 08:24, Yonas T. <yonas.t at gmail.com> wrote:
> I am trying to read DTI data that is stored in minc file format (minc 1.0 I
> am told). I am using PC and found this win32 binary distribution at:
> http://packages.bic.mni.mcgill.ca/win32/

Erk! for one, these binaries are very old, but might suffice for what
you are doing.

> ? ?time ? ? ? ? ? ? ? ? ? ? ? ? ? ?109 ? ? ? ? 11.1 ? ? ? ? ? ?0
> ? ?zspace ? ? ? ? ? ? ? ? ? ? ? ?63 ? ? ? ? ? -2 ? ? ?69.2799
> ? ?yspace ? ? ? ? ? ? ? ? ? ? ? 128 ? ? ? ? ? -2 ? ? ?189.266
> ? ?xspace ? ? ? ? ? ? ? ? ? ? ? 128 ? ? ? ? ? -2 ? ? ? ? ?128

> Now, I would like to read ONLY the image part (no header information) and
> save it as raw file so that I can read it in matlab; as my code for the
> analysis of DTI is developed in matlab.


> Here is what I found however:
> minctoraw -normalize dti.mnc > ImageData.raw
> Result: ImageData.raw file with size = 227,288,499 bytes ?(about 216MB)

To add to what others have said here, what version of windows are you
using? I have found binary redirects and pipes of large files to be
somewhat hit and miss under XP at least. Under cygwin things seem to
work better though. I have no idea why this is as I very rarely use
windows for such things.

> 2. I also found emma matlab toolbox that can read minc format images

I would suggest (as Vlad said) to use NIAK:

   http://code.google.com/p/niak/

Unlike EMMA it is under active development.

> 3. Does the result of mincinfo seem meaningful? I am a bit surprised by "image:
> signed__ short 0 to 4095" because I would think unsigned short would make
> more sense to say range 0 - 4095.

This is normal for a image from a scanner, the image is saved in a 16
bit filetype but most ADC's in scanners are only accurate to about 12
bits so the output is truncated. DICOM also stores 12 bit imaging data
in this format.


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

From vladimir.fonov at gmail.com  Tue Jun 22 11:21:34 2010
From: vladimir.fonov at gmail.com (Vladimir Fonov)
Date: Tue, 22 Jun 2010 11:21:34 -0400
Subject: [MINC-users] i386 and amd64 ubuntu lucid packages
In-Reply-To: <AANLkTikX2RtG1Kh-IE6sv2xn9mq9PI4WHMC45K23Ed1G@mail.gmail.com>
References: <AANLkTikX2RtG1Kh-IE6sv2xn9mq9PI4WHMC45K23Ed1G@mail.gmail.com>
Message-ID: <AANLkTilTBNO7xU3kdbkThxrgWByh1kHVzZLCoay3ZChr@mail.gmail.com>

Hello,

On Mon, Jun 21, 2010 at 8:21 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Are now available here:
>
> ? http://packages.bic.mni.mcgill.ca/ubuntu-lucid/


It looks like something is broken, I added
deb http://packages.bic.mni.mcgill.ca/ubuntu-lucid ./
to my /etc/apt/sources.list , did apt-get update. And now if I do
apt-cache search minc
it finds libminc2-1, libminc-dev and minc-tools from the standard distribution
and also mincbundle

But if i try to do apt-get install mincbundle  I am getting following error:
The following packages have unmet dependencies:
  mincbundle: Depends: minc but it is not installable
              Depends: glim-image but it is not installable
              Depends: mincblob but it is not installable
              Depends: mincdti but it is not installable
              Depends: mincfft but it is not installable
              Depends: mincmorph but it is not installable
              Depends: mincregress but it is not installable
              Depends: mincsample but it is not installable
              Depends: mrisim but it is not installable
              Depends: volperf but it is not installable
              Depends: volregrid but it is not installable
              Depends: mni-autoreg but it is not installable
              Depends: mni-models-average305-lin but it is not installable
              Depends: mni-models-colin27-lin but it is not installable
              Depends: mni-models-icbm152-lin but it is not installable
              Depends: mni-models-icbm152-nl-2009 but it is not installable
              Depends: bicpl but it is not installable
              Depends: postf but it is not installable
              Depends: display but it is not installable
              Depends: register but it is not installable
              Depends: ray-trace but it is not installable
              Depends: ebtks but it is not installable
              Depends: classify but it is not installable
              Depends: inormalize but it is not installable
              Depends: n3 but it is not installable
              Depends: arguments but it is not installable
              Depends: oobicpl but it is not installable
              Depends: bicinventor but it is not installable
E: Broken packages

P.S. Running 64bit Ubuntu 10.04

-- 
Best regards,
 Vladimir S. Fonov ~ v.s.fonov <@> ilmarin.info

From a.janke at gmail.com  Tue Jun 22 11:58:16 2010
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 23 Jun 2010 01:58:16 +1000
Subject: [MINC-users] i386 and amd64 ubuntu lucid packages
In-Reply-To: <AANLkTilTBNO7xU3kdbkThxrgWByh1kHVzZLCoay3ZChr@mail.gmail.com>
References: <AANLkTikX2RtG1Kh-IE6sv2xn9mq9PI4WHMC45K23Ed1G@mail.gmail.com> 
	<AANLkTilTBNO7xU3kdbkThxrgWByh1kHVzZLCoay3ZChr@mail.gmail.com>
Message-ID: <AANLkTimXCoPohYBwXNNtHUOOXfdKcXJo4c_RC-8r-B0P@mail.gmail.com>

> It looks like something is broken, I added
> deb http://packages.bic.mni.mcgill.ca/ubuntu-lucid ./

Try again now,

I forgot to rebuild the release file with both the i386 and amd64 versions.


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

From vladimir.fonov at gmail.com  Tue Jun 22 13:30:37 2010
From: vladimir.fonov at gmail.com (Vladimir Fonov)
Date: Tue, 22 Jun 2010 13:30:37 -0400
Subject: [MINC-users] i386 and amd64 ubuntu lucid packages
In-Reply-To: <AANLkTimXCoPohYBwXNNtHUOOXfdKcXJo4c_RC-8r-B0P@mail.gmail.com>
References: <AANLkTikX2RtG1Kh-IE6sv2xn9mq9PI4WHMC45K23Ed1G@mail.gmail.com>
	<AANLkTilTBNO7xU3kdbkThxrgWByh1kHVzZLCoay3ZChr@mail.gmail.com>
	<AANLkTimXCoPohYBwXNNtHUOOXfdKcXJo4c_RC-8r-B0P@mail.gmail.com>
Message-ID: <AANLkTilt-gKyBx_EHruoImYqERqMBqVKV8x0B5txTD7z@mail.gmail.com>

Hello,

On Tue, Jun 22, 2010 at 11:58 AM, Andrew Janke <a.janke at gmail.com> wrote:
>> It looks like something is broken, I added
>> deb http://packages.bic.mni.mcgill.ca/ubuntu-lucid ./
>
> Try again now,
>
> I forgot to rebuild the release file with both the i386 and amd64 versions.

Now it seem to install fine. Also, when I install it - Ubuntu removes
minc-tools from standard repository.

-- 
Best regards,
 Vladimir S. Fonov ~ v.s.fonov <@> ilmarin.info

From mishkind at gmail.com  Tue Jun 22 14:04:01 2010
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Tue, 22 Jun 2010 14:04:01 -0400
Subject: [MINC-users] mritoself xcorr memory problem
Message-ID: <AANLkTikJqiyiyyqlTDESKrRWSxCOIPkTgy53SqxHCgQE@mail.gmail.com>

Hi,
I have found that every now and then when I run mritoself with the
xcorr option it will take up as much memory as it can find and never
complete.

I've managed to narrow the problem down to a data type problem,
specifically if my source image is of type long.
In this case, mritoself, or more precisely volume_stats according to
top, will just eat up all 8GB of my memory.

This fails:
mritoself brain.mnc.gz head.mnc.gz out.xfm -clobber -xcorr

where mincinfo brain.mnc.gz gives:
file: brain.mnc.gz
image: signed__ long -2147483648 to 2147483647
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     60            3          -48
    yspace                    256     0.976562     -100.586
    xspace                    256     0.976562     -124.023

Whereas if I do this, then it works:
mincresample brain.mnc.gz -short short.mnc
mincinfo short.mnc
file: short.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     60            3          -48
    yspace                    256     0.976562     -100.586
    xspace                    256     0.976562     -124.023

mritoself short.mnc head.mnc.gz out.xfm -clobber -xcorr


I've managed to find a fix for my problem but perhaps someone with a
bit more knowledge of what is going on can fix this bug (or feature
depending on what you wnt to call it).

mishkin

fyi:

opus[~]$ uname -a
Linux opus 2.6.24-24-generic #1 SMP Tue Aug 18 16:22:17 UTC 2009
x86_64 GNU/Linux

opus[~]$ mritoself -version
mritoself 0.99.3 built from:
Package mni_autoreg 0.99.3, compiled by ladmin at ccr-twodogs
(x86_64-unknown-linux-gnu) on Wed Feb 11 10:46:24 EST 2009

opus[~]$ mincinfo -version
program: 2.0.17
libminc: 2.0.17
netcdf : "3.6.2" of Feb  8 2008 15:52:05 $
HDF5   : 1.6.5

From a.janke at gmail.com  Wed Jun 30 22:45:26 2010
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 1 Jul 2010 12:45:26 +1000
Subject: [MINC-users] mritoself xcorr memory problem
In-Reply-To: <AANLkTikJqiyiyyqlTDESKrRWSxCOIPkTgy53SqxHCgQE@mail.gmail.com>
References: <AANLkTikJqiyiyyqlTDESKrRWSxCOIPkTgy53SqxHCgQE@mail.gmail.com>
Message-ID: <AANLkTil6dF2BjGb8HrlMvQACO3E5FbIHFL1Awt0tqP-Y@mail.gmail.com>

Hi mishkin

This memory issue is known to happen with the current mincmorph + hdf
combination.  It is due to a combination of chunking sizes and file
size.

You will find that it is not due to filetype but the size of the file
itself.  This is of course assuming the problem is what I think it is.

This problem is fixed in mincmorph 2.1 which is due for release either
this week or early next week.

Andrew.

On 2010-06-23, Mishkin Derakhshan <mishkind at gmail.com> wrote:
> Hi,
> I have found that every now and then when I run mritoself with the
> xcorr option it will take up as much memory as it can find and never
> complete.
>
> I've managed to narrow the problem down to a data type problem,
> specifically if my source image is of type long.
> In this case, mritoself, or more precisely volume_stats according to
> top, will just eat up all 8GB of my memory.
>
> This fails:
> mritoself brain.mnc.gz head.mnc.gz out.xfm -clobber -xcorr
>
> where mincinfo brain.mnc.gz gives:
> file: brain.mnc.gz
> image: signed__ long -2147483648 to 2147483647
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start
>     --------------         ------         ----        -----
>     zspace                     60            3          -48
>     yspace                    256     0.976562     -100.586
>     xspace                    256     0.976562     -124.023
>
> Whereas if I do this, then it works:
> mincresample brain.mnc.gz -short short.mnc
> mincinfo short.mnc
> file: short.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start
>     --------------         ------         ----        -----
>     zspace                     60            3          -48
>     yspace                    256     0.976562     -100.586
>     xspace                    256     0.976562     -124.023
>
> mritoself short.mnc head.mnc.gz out.xfm -clobber -xcorr
>
>
> I've managed to find a fix for my problem but perhaps someone with a
> bit more knowledge of what is going on can fix this bug (or feature
> depending on what you wnt to call it).
>
> mishkin
>
> fyi:
>
> opus[~]$ uname -a
> Linux opus 2.6.24-24-generic #1 SMP Tue Aug 18 16:22:17 UTC 2009
> x86_64 GNU/Linux
>
> opus[~]$ mritoself -version
> mritoself 0.99.3 built from:
> Package mni_autoreg 0.99.3, compiled by ladmin at ccr-twodogs
> (x86_64-unknown-linux-gnu) on Wed Feb 11 10:46:24 EST 2009
>
> opus[~]$ mincinfo -version
> program: 2.0.17
> libminc: 2.0.17
> netcdf : "3.6.2" of Feb  8 2008 15:52:05 $
> HDF5   : 1.6.5
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Wed Jun 30 22:46:45 2010
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 1 Jul 2010 12:46:45 +1000
Subject: [MINC-users] mritoself xcorr memory problem
In-Reply-To: <AANLkTil6dF2BjGb8HrlMvQACO3E5FbIHFL1Awt0tqP-Y@mail.gmail.com>
References: <AANLkTikJqiyiyyqlTDESKrRWSxCOIPkTgy53SqxHCgQE@mail.gmail.com>
	<AANLkTil6dF2BjGb8HrlMvQACO3E5FbIHFL1Awt0tqP-Y@mail.gmail.com>
Message-ID: <AANLkTimDXJLkgtlWhkLXi9R4U3lnE_Q6Iz37RiQRNm6M@mail.gmail.com>

Whoops, make that

   Minc + hdf

Andrew (who needs to be more carefull when using nokias predictive text...)

On 2010-07-01, Andrew Janke <a.janke at gmail.com> wrote:
> Hi mishkin
>
> This memory issue is known to happen with the current mincmorph + hdf
> combination.  It is due to a combination of chunking sizes and file
> size.
>
> You will find that it is not due to filetype but the size of the file
> itself.  This is of course assuming the problem is what I think it is.
>
> This problem is fixed in mincmorph 2.1 which is due for release either
> this week or early next week.
>
> Andrew.
>
> On 2010-06-23, Mishkin Derakhshan <mishkind at gmail.com> wrote:
>> Hi,
>> I have found that every now and then when I run mritoself with the
>> xcorr option it will take up as much memory as it can find and never
>> complete.
>>
>> I've managed to narrow the problem down to a data type problem,
>> specifically if my source image is of type long.
>> In this case, mritoself, or more precisely volume_stats according to
>> top, will just eat up all 8GB of my memory.
>>
>> This fails:
>> mritoself brain.mnc.gz head.mnc.gz out.xfm -clobber -xcorr
>>
>> where mincinfo brain.mnc.gz gives:
>> file: brain.mnc.gz
>> image: signed__ long -2147483648 to 2147483647
>> image dimensions: zspace yspace xspace
>>     dimension name         length         step        start
>>     --------------         ------         ----        -----
>>     zspace                     60            3          -48
>>     yspace                    256     0.976562     -100.586
>>     xspace                    256     0.976562     -124.023
>>
>> Whereas if I do this, then it works:
>> mincresample brain.mnc.gz -short short.mnc
>> mincinfo short.mnc
>> file: short.mnc
>> image: signed__ short -32768 to 32767
>> image dimensions: zspace yspace xspace
>>     dimension name         length         step        start
>>     --------------         ------         ----        -----
>>     zspace                     60            3          -48
>>     yspace                    256     0.976562     -100.586
>>     xspace                    256     0.976562     -124.023
>>
>> mritoself short.mnc head.mnc.gz out.xfm -clobber -xcorr
>>
>>
>> I've managed to find a fix for my problem but perhaps someone with a
>> bit more knowledge of what is going on can fix this bug (or feature
>> depending on what you wnt to call it).
>>
>> mishkin
>>
>> fyi:
>>
>> opus[~]$ uname -a
>> Linux opus 2.6.24-24-generic #1 SMP Tue Aug 18 16:22:17 UTC 2009
>> x86_64 GNU/Linux
>>
>> opus[~]$ mritoself -version
>> mritoself 0.99.3 built from:
>> Package mni_autoreg 0.99.3, compiled by ladmin at ccr-twodogs
>> (x86_64-unknown-linux-gnu) on Wed Feb 11 10:46:24 EST 2009
>>
>> opus[~]$ mincinfo -version
>> program: 2.0.17
>> libminc: 2.0.17
>> netcdf : "3.6.2" of Feb  8 2008 15:52:05 $
>> HDF5   : 1.6.5
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>