that's not enough?

On Thu, 25 Mar 2004, Tamara Knutsen wrote:

this is all i find:

[whatever:ben1] (nmr-std-env) mri_segment usage: mri_segment <input volume> <output volume>

thanks!

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu http://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

yes i was wondering more about the options pertaining to manually editing and normalization (because normalization before this step is disastrous for our monkey volumes).

is there anyway to know which flags exist and/or are working?

thanks, tamara

On Thu, 25 Mar 2004, Bruce Fischl wrote:

sorry. What are you looking for? Is it failing? There are a lot of options in it (as usual), and the truth is I can't remember which of them still work. We almost never give it any options, except -keep, which reads in the the output volume (assuming it exists), and retains all manual edits that are found in it. This is useful, for example, if you decide to rerun the intensity normalization after you have manually edited a volume.

Bruce

On Thu, 25 Mar 2004, Tamara Knutsen wrote:

...

this is all i find:

[whatever:ben1] (nmr-std-env) mri_segment usage: mri_segment <input volume> <output volume>

thanks!

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu http://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Hi All,

This thread brings up a more general point. It starts from the idea that probably (just my guess) many people were surprised to find out that the "-u" argument would yield more information about mri_segment.

Let me make the strong assertion that well-behaved code should spit out in the short version of feedback/documentation the method for getting the long version. As in, when you just type in mri_segment, you should get back a simple usage file that includes the flag you would need to supply in order to get more usage information.

How would a user know to try -u? It is only listed in the output you get when you supply the flag.

In fact, I just tried it: the -u flag does not give the output Brian posted when most users give it. It only works if you have access to the development environment.

Furthermore, this is in the context of there being many standards for how to evince extra online help from the various utilities used as part of FreeSurfer and FS-FAST.

In some cases, the flag is "-help" in others it is "--help" and in others, apparently, it is "-u". When it is one, it is not the other - for instance neither 'help' flag works with mri_segment.

Of course I realize that much of this is historical - different standards at different times, when various utilities were written. Perhaps one is the chosen standard now.

Any one person having to check and re-work all ~832 utilities, well, would be quite annoyed. Especially because it is a mindless task. But, could we utilize how mindless it is, and pawn it off in chunks to do in spare moments to a fairly large net of developers at the Center? 5 programs a week times 10 programmers would mean roughly 1 minute per day, and yet the task would be done this summer. And of course it could be much faster than that. The task, again, would be standardizing all programs to give full info when one flag (say "-help") is supplied, and making the simple usage prompt reflect this fact.

The payoff is all users would be able to get the information below immediately, rather than after 5 emails to the whole list, and in many cases would be able to answer their own questions.

Sorry for the rant, here. I hope it was useful, and the suggestion can be implemented.

Thanks!

-ned t. sahin

Brian T. Quinn wrote:

try the -u option for the following:

    -slope <float s>  set the curvature slope (both n and p)
    -pslope <float p> set the curvature pslope (default=1.0)
    -nslope <float n> set the curvature nslope (default=1.0)
    -debug_voxel <int x y z> set voxel for debugging
    -auto             automatically detect class statistics (default)
    -noauto           don't automatically detect class statistics
    -log              log to ./segment.dat
    -keep             keep wm edits. maintains all values of 0 and 255
    -ghi, -gray_hi <int h> set the gray matter high limit 

(default=100.000) -wlo, -wm_low <int l> set the white matter low limit (default=90.000) -whi, -wm_hi <int h> set the white matter high limit (default=125.000) -nseg <int n> thicken the n largest thin strands (default=20) -thicken toggle thickening step (default=ON) -fillbg toggle filling of the basal ganglia (default=OFF) -fillv toggle filling of the ventricles (default=OFF) -b <float s> set blur sigma (default=0.25) -n <int i> set # iterations of border classification (default=1) -t <int t> set limit to thin strands in mm (default=4) -v verbose -p <float p> set % threshold (default=0.80) -x <filename> extract options from filename -w <int w> set wsize (default=11) -u usage

good luck,

brian t. quinn

On Thu, 25 Mar 2004, Tamara Knutsen wrote:

...

this is all i find:

[whatever:ben1] (nmr-std-env) mri_segment usage: mri_segment <input volume> <output volume>

thanks!

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu http://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

---

Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu http://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Thanks Bruce! This would be really useful!!

I hope the work can be distributed.

For the fs-fast ones I could write a script that could patch/addend some of them automatically, and deliver code for review by the team (Doug) - but as you mentioned when those help files are there they are pretty standardized. Obviously i don't have access to fs code.

Thanks!

-ned

Bruce Fischl wrote:

Hi Ned et al.,

in this particular case, I had actually forgotten. Also, it's only fair to say that in general Doug is *much* better than I am about this, and that we have different standards (mine are usually -u and -?, and Doug's are -help I think). I'm happy to make a start on this and support the -help option in all of our stuff.

cheers, Bruce

On Thu, 25 Mar 2004, Ned T. Sahin wrote:

...

Hi All,

This thread brings up a more general point. It starts from the idea that probably (just my guess) many people were surprised to find out that the "-u" argument would yield more information about mri_segment.

Let me make the strong assertion that well-behaved code should spit out in the short version of feedback/documentation the method for getting the long version. As in, when you just type in mri_segment, you should get back a simple usage file that includes the flag you would need to supply in order to get more usage information.

How would a user know to try -u? It is only listed in the output you get when you supply the flag.

In fact, I just tried it: the -u flag does not give the output Brian posted when most users give it. It only works if you have access to the development environment.

Furthermore, this is in the context of there being many standards for how to evince extra online help from the various utilities used as part of FreeSurfer and FS-FAST.

In some cases, the flag is "-help" in others it is "--help" and in others, apparently, it is "-u". When it is one, it is not the other - for instance neither 'help' flag works with mri_segment.

Of course I realize that much of this is historical - different standards at different times, when various utilities were written. Perhaps one is the chosen standard now.

Any one person having to check and re-work all ~832 utilities, well, would be quite annoyed. Especially because it is a mindless task. But, could we utilize how mindless it is, and pawn it off in chunks to do in spare moments to a fairly large net of developers at the Center? 5 programs a week times 10 programmers would mean roughly 1 minute per day, and yet the task would be done this summer. And of course it could be much faster than that. The task, again, would be standardizing all programs to give full info when one flag (say "-help") is supplied, and making the simple usage prompt reflect this fact.

The payoff is all users would be able to get the information below immediately, rather than after 5 emails to the whole list, and in many cases would be able to answer their own questions.

Sorry for the rant, here. I hope it was useful, and the suggestion can be implemented.

______________________ Ned T. Sahin, M.S. _______________________________________________________________________ Harvard Psychology | MGH Martinos Neuroimaging Center Cognition, Brain & Behavior | Martinos Scholar PhD Candidate | Student & Post-Doc Rep. to Faculty _________________________________|_____________________________________ fMRI and MEG neuroimaging of human language morphosyntax _______________________________________________________________________ sahin@fas.harvard.edu | sahin@alum.mit.edu | c +1 617-331-8401