Hi Bruce,
On 26. Jun 2006, at 16:15 Uhr, Bruce Fischl wrote:
it should - consider it a bug.
On a related note, is there an easy way to convince mri_info to just
spit out the type (UCHAR FLOAT etc.) so I can easily script whether the
conform step is necessary or not (instead of making the temporary file
-> grep gymnastics ;)).
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.
Ah, I just use "-iis 1 -ijs 1 -iks 1" to fake the right resolution (I
do scan at .5 mm isotropic), that way I get nice large dislayes volumes
in tkmedit/tkregister2. With the large displays it is very easy to do
the manual rotations to get the AC-PC line horizontal and adjust
rotations around the other two axis. I will try "-cm" if that also
gives a "full size" display in the visualizers, I will switch.
Just checked it, tkmedit silently drops every other slice (at least in
the display), so this will not be very satisfactory for the three
manual steps (cleaning the brainmask, distributing shiploads of control
points, and getting the wm.mgz into good shape). So unfortunatelly, I
will have to stick to cheating about the resolution :(.
Ahoi & thanks
Sebastian
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
--
Sebastian Moeller
Tel.: 04 21 - 2 18 - 78 38 oder 96 91
Fax.: 04 21 - 2 18 - 90 04
GSM: 01 62 - 3 25 45 59
[EMAIL PROTECTED]
AG Kreiter / FB 2
Institut fuer Hirnforschung III
Abteilung Theoretische Neurobiologie
Universitaet Bremen
Biogarten
Hochschulring 16a
Postfach 33 04 40
28359 Bremen
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
