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
Hi Sebastian,
why do you want to run mri_normalize on non-conformed volumes? It wasn't really built for it.
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
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
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
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
yeah, sorry, that's on our list of things to fix.
I just added a --conform to mri_info so that it will return "yes" or "no" (also --type). Will be live in dev tomorrow. Nick: does the dev build go on the web every day?
Bruce
On Mon, 26 Jun 2006, Sebastian Moeller wrote:
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
Hi Bruce,
On 26. Jun 2006, at 16:49 Uhr, Bruce Fischl wrote:
yeah, sorry, that's on our list of things to fix.
This will make a great tool even greater, thnanks. Then again, for the smaller monkey brains the "fake the resolution to be 1mm isotropic" does the trick nicely, once you know it, that is ;).
I just added a --conform to mri_info so that it will return "yes" or "no" (also --type). Will be live in dev tomorrow. Nick: does the dev build go on the web every day?
Waoh, how cool, thanks a million. Just a nit, mri_normalize uses "-u" to get to the help while other fs tools use either "-h" or gnuish "--help", maybe you might want to consider to consolidate to one uniform command line switch? But I digress...
ahoi Sebastian
Bruce
On Mon, 26 Jun 2006, Sebastian Moeller wrote:
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
yeah, I know. That's Doug vs. me (you can always tell the difference based on whether the help is useful (Doug) or not (me)).
sorry, Bruce On Mon, 26 Jun 2006, Sebastian Moeller wrote:
Hi Bruce,
On 26. Jun 2006, at 16:49 Uhr, Bruce Fischl wrote:
yeah, sorry, that's on our list of things to fix.
This will make a great tool even greater, thnanks. Then again, for the smaller monkey brains the "fake the resolution to be 1mm isotropic" does the trick nicely, once you know it, that is ;).
I just added a --conform to mri_info so that it will return "yes" or "no" (also --type). Will be live in dev tomorrow. Nick: does the dev build go on the web every day?
Waoh, how cool, thanks a million. Just a nit, mri_normalize uses "-u" to get to the help while other fs tools use either "-h" or gnuish "--help", maybe you might want to consider to consolidate to one uniform command line switch? But I digress...
ahoi Sebastian
Bruce
On Mon, 26 Jun 2006, Sebastian Moeller wrote:
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
Hey all,
I was wondering if anyone knows the format for the Talairach.bnd file? Specifically what I am looking for is what the matrix at the bottom actually represents. I am going to use them in a script to actually trim the brain so I need a way to compute the 6 planes that make up the box around the brain.
-Eric
The dev build is not posted on the web anymore, rather, bug fixes and tested minor enhancements get folded into the stable build and released periodically (so far, it seems about every six weeks).
A new stable release (v3.0.4) will be forthcoming, and I'll make sure that the --conform flag of mri_info gets included.
On Mon, 2006-06-26 at 10:49 -0400, Bruce Fischl wrote:
yeah, sorry, that's on our list of things to fix.
I just added a --conform to mri_info so that it will return "yes" or "no" (also --type). Will be live in dev tomorrow. Nick: does the dev build go on the web every day?
Bruce
On Mon, 26 Jun 2006, Sebastian Moeller wrote:
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
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Nick, hi Bruce,
On 29. Jun 2006, at 00:39 Uhr, Nick Schmansky wrote:
The dev build is not posted on the web anymore, rather, bug fixes and tested minor enhancements get folded into the stable build and released periodically (so far, it seems about every six weeks).
Which, I might add, is really great. Then again, if you want me to test anything I'd be happy to do so.
A new stable release (v3.0.4) will be forthcoming, and I'll make sure that the --conform flag of mri_info gets included.
Great.
Ahoi & thanks for all the fish, ermh, the nice tools & the great support Sebastian
On Mon, 2006-06-26 at 10:49 -0400, Bruce Fischl wrote:
yeah, sorry, that's on our list of things to fix.
I just added a --conform to mri_info so that it will return "yes" or "no" (also --type). Will be live in dev tomorrow. Nick: does the dev build go on the web every day?
Bruce
On Mon, 26 Jun 2006, Sebastian Moeller wrote:
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
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
our pleasure (most of the time)
On Thu, 29 Jun 2006, Sebastian Moeller wrote:
Hi Nick, hi Bruce,
On 29. Jun 2006, at 00:39 Uhr, Nick Schmansky wrote:
The dev build is not posted on the web anymore, rather, bug fixes and tested minor enhancements get folded into the stable build and released periodically (so far, it seems about every six weeks).
Which, I might add, is really great. Then again, if you want me to test anything I'd be happy to do so.
A new stable release (v3.0.4) will be forthcoming, and I'll make sure that the --conform flag of mri_info gets included.
Great.
Ahoi & thanks for all the fish, ermh, the nice tools & the great support Sebastian
On Mon, 2006-06-26 at 10:49 -0400, Bruce Fischl wrote:
yeah, sorry, that's on our list of things to fix.
I just added a --conform to mri_info so that it will return "yes" or "no" (also --type). Will be live in dev tomorrow. Nick: does the dev build go on the web every day?
Bruce
On Mon, 26 Jun 2006, Sebastian Moeller wrote:
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
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Faden, Eric (NIH/NIMH) [F] -
Nick Schmansky -
Sebastian Moeller