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