it should - consider it a bug. Have you tried mri_convert -cm (conform
to min)? That will make it 8 bit and isotropic, but at the highest linear
resolution it finds. I think that's what people here use when they're doing
monkey recons.
Bruce
On Mon, 26 Jun 2006, Sebastian Moeller wrote:
Hi Bruce,
On 26. Jun 2006, at 02:30 Uhr, Bruce Fischl wrote:
Hi Sebastian,
why do you want to run mri_normalize on non-conformed volumes? It wasn't
really built for it.
Well I have monkey data, which I feed into freesurfer, so only few of
the automatic step actually work for me. Therefore I do call all the relevant
programs/scripts by hand. Until now I used freesurfers skull-strip (which
feeds on the fully conformed T1 volume)
Now, to be able to use fsl's BET, I spatially conforme the input just
after making sure that its orientation is right (this is the rawavg.mgz
volume, of type float). And to give BET something to feed from I would rather
not lower rawavg.mgz's resolution to 8bit just yet, given that the scans have
11bit resolution. I do admit that those 3bit probably are in the noise though
;).
So all I am reporting here, is that mri_normalize's "-conform"
argument does not go the full mile, but only seems to consider the spatial
part of conforming (which is not obvious from the output of "mri_normalize
-u", I thought interpolation would also cover the process of 32 to 8 bit
conversion).
Ahoi
Sebastian
Bruce
On Sun, 25 Jun 2006, Sebastian Moeller wrote:
Hi List,
as the subject line says I am having problems running mri_normalize (on
suse 9.3 x86_64, freesurfer centos4 x86_64 3.0.2 release). When feeding in
slightly unconformed volumes (like 1mm isotropic 256 by 256 by 256 of type
3 (float)) mri_normalize's "-conform" argument fails (fully unconformed
volumes are no problem). The error message boils down to
MRInormGentlyFindControlPoints: unsupported src format 3" followed by
"MRI3dGentleNormalize failure! mri_ctrl=Null".
I just work around this by running a full mri_convert --conform on my
input file before running mri_normalize. Just a nit, specifying "-v" some
where else than at the end of the commandline easily produces segmentation
faults (probably because -v is "overloaded" to also expect Gx Gy Gz
arguments? the help is a bit terse)
Ahoi
Sebastian
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
