Ah, I see, that I can replicate. As Bruce says, use -ns 1 to keep it from doing a funny rescaling when converting from float to int.
doug
Wayne Su wrote:
Maybe my email is not clear. Try this to see what you get:
mri_convert aparc+aseg.mgz aparc+aseg1.mgz -odt float mri_convert aparc+aseg1.mgz aparc+aseg2.mgz -odt int mris_calc aparc+aseg2.mgz max
I tried 'mris_calc'. The output is in floating format. I have no way to avoid converting back to int format.
I am using Freesurfer version 5.
Wayne
On 05/10/10 2:33 PM, "Douglas N Greve" greve@nmr.mgh.harvard.edu wrote:
And when you run
mri_convert aparc+aseg.mgz aparc+aseg2.mgz -odt int
And
then
mris_calc aparc+aseg2.mgz max
you get that crazy number?
I've tried
this here with version 5 and cannot replicate. What version
are you
using?
doug
Wayne Su wrote:
Here is: mris_calc aparc+aseg.mgz max
Max@(index) [ 2035.000000 (7772808) ]
On 05/10/10 2:20 PM, "Douglas N Greve" greve@nmr.mgh.harvard.edu wrote:
btw, I mean the original
aparc+aseg.mgz, not the one created after you
made
changes
using those FSL commands.
doug
Douglas N Greve wrote:
And what do
you get when you run mris_calc on aparc+aseg.mgz?
Wayne
Su wrote:
Here is the output from mris_calc:
mris_calc aparc+aseg2.mgz max
Max@(index) [
2145516800.000000 (6400402) ]
Wayne
On 05/10/10
2:05
PM, "Douglas N Greve" greve@nmr.mgh.harvard.edu wrote:
I've never heard of DTI_TK Quick Look. Does it
actually read mgz files?
What value does it give for
aparc+aseg.mgz? Try loading the file into
matlab with the
FreeSurfer MRIread.m function and see what it gives for
the max. Or
just run
mris_calc aparc+aseg2.mgz max
doug
Wayne Su wrote:
Hi
Bruce,
I used
just mri_binarize, mri_mask and
mri_concat and all in mgz format. I
got a
32-bit floating point image with intensity range from 0~2031. Then I
used
the mri_convert to convert it to 32-bit
integer also both in mgz
format.
Here is the
message on the screen.
mri_convert aparc+aseg.mgz
aparc+aseg2.mgz -odt int
$Id: mri_convert.c,v 1.166.2.2
2010/08/10
19:11:50 greve Exp $
reading from
aparc+aseg.mgz...
TR=0.00,
TE=0.00, TI=0.00, flip
angle=0.00
i_ras = (-1, -1.77636e-15,
-1.88564e-15)
j_ras = (0, -4.3715e-16, -1) k_ras = (0,
1,
-3.72529e-09)
changing data type from
float to int (noscale = 0)...
MRIchangeType:
Building histogram
writing to
aparc+aseg2.mgz...
The intensity range of new
image is -214783648.00 ~ 214551xxx.00 showed
by
DTI_TK Quick
Look.
Wayne
On 05/10/10
1:30 PM, "Bruce Fischl" fischl@nmr.mgh.harvard.edu wrote:
> Hi >
Wayne,
> can you check to see whether it's > >
an FSL problem or a FreeSurfer one? If
> you don't use FSL do you >
still
> >
have the problem?
> cheers > >
Bruce
> On Tue, 5 Oct 2010, > >
Wayne
Su wrote:
> > > > >
Well, I tried to avoid FSL, and used only Freesurfer tool to do the
same
>> thing. I found there was the same issue when an image >>
with 32-bit
>> >>
float
>> point data type >>
converts to 32-bit integer. No problem for the
>> >>
convertion
>> from 32-bit float point to 8-bit unsigned >> >>
integer.
>> Wayne >> >> >> On 05/10/10 10:44 >>
AM, "Wayne
>> >>
Su" wsu@interchange.ubc.ca wrote:
>> >> >> >> >> >> >>> Hello Freesurfer Users, >>> >>> I am >>> >>>
feeling very bad when I am using mri_convert. There are two problems:
- When I converted a file in mgz format to nii.gz format, and did
some
>>> volume calculation (mask and addition) by using fslmaths >>>
from
>>> >>>
FSL, then
>>> converted back to >>>
mgz. If the image type is uchar, it works
>>> >>>
fine.
If the
>>> image type is int, the intensities changed. The Œ0¹ >>>
value
>>> >>>
is changed to
>>> Œ2.1e+09¹, >>>
others also in very large number (look like
>>> >>>
read
the data from
>>> wrong place). Here is the code I >>> >>>
used:
>>> ${FREESURFER_HOME}/bin/mri_convert >>> >>>
aparc+aseg.mgz
>>> aparc+aseg.nii.gz >>> -odt >>>
int
>>> >>>
${FSLDIR}/bin/fslmaths aparc+aseg
-mas right_vect_mask_inv -add
right_vect_mask aparc+aseg
>>> ${FREESURFER_HOME}/bin/mri_convert >>> >>>
aparc+aseg.nii.gz
>>> aparc+aseg.mgz >>> -odt >>>
int
>>> >>>
If no fslmaths calculation,
convert back to mgz right way, no
problem
found.
>>> 2. when the conform is used, some head >>> >>>
were rotated a little bit, but not
>>> for >>> others. I >>>
am wondering
>>> >>>
how to avoid the rotation?
>>> Regards, >>> >>> >>>
Wayne
>>> _______________________________________________ >>> >>> >>>
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
>>> >>>
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>> The information in this e-mail is intended only for the person to >>>
whom
>>> >>>
it
>>> is >>> addressed. >>>
If you believe this e-mail was sent to you in
>>> >>>
error and the
>>> e-mail >>> contains patient information, >>>
please
>>> >>>
contact the Partners Compliance
>>> HelpLine >>> at >>> >>> >>>
http://www.partners.org/complianceline . If the e-mail was sent to you
in
>>> error >>> but does not contain patient information, >>>
please
>>> >>>
contact the sender and
properly
>>> dispose of the e-mail. >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >>
> Freesurfer >
mailing
> >
list
Freesurfer@nmr.mgh.harvard.edu
> >
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> >
The information in this e-mail is intended only
for the person to whom it
is
> addressed. If you believe this >
e-mail was sent to you in error and
> >
the
> contains patient information, please contact the > >
Partners Compliance
> HelpLine > at > > >
http://www.partners.org/complianceline . If the e-mail was sent to you
in
> error > but does not contain patient information, >
please contact
> >
the sender and
properly
> dispose of the e-mail. > > > > > > >
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer