Dear Freesurfers,
I came across a possible issue during the automatic labeling of V1 using the Hinds method (http://surfer.nmr.mgh.harvard.edu/fswiki/BrodmannAreaMaps). If you use the command "recon-all -s subjid -label_v1", as far as I can see, mainly the shell script "predict_v1.sh" in $FREESURFER_HOME/bin is executed.
Apart from the fact whether you have a FreeSurfer version in which the command runs smoothly or whether you have to use a workaround combining different FreeSurfer versions described by Krish Singh (http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg20363.html), you should be careful with the automatically generated thresholded label files "lh.v1.predict.label" and "rh.v1.predict.label".
Note already here that the basic output of the analysis (rh.v1.prob.label/lh.v1.prob.label) is not affected by this. It is only relevant when you use the thresholding function "threshold_labelfile_at_0p8", which is included in "predict_v1.sh" or has been cited separately by Krish Singh in an e-mail post (http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg20367.html).
(1) The first problem people might run into is not pernicious and probably depends on the exact shell version you are using. I had a problem with the following line in threshold_labelfile_at_0p8 (didn't run in tcsh OR bash):
numlab=`wc -l /tmp/tmpthreshout | sed "s/ .*$//"`
It is supposed to compute the number of vertices, which is printed on the second line of the label file. Since the command does not succeed with current shell versions, the second line remains empty and if you load the label, it is shown not at all or in a distorted fashion. An easy replacement that should work is:
numlab=`wc -l < /tmp/tmpthreshout`
(2) The second problem gives you wrong results randomly in at least some cases (haven't tested the generality). The line:
cat $infile | sed "/^#/d;/^[0-9]*$/d;/.* 0\.[0-7].*$/d" \ > /tmp/tmpthreshout
throws out lines with probability values (which are in the last column) below 0.8 with the sed part "/.* 0\.[0-7].*$/d". Unfortunately, the regular expression also picks up coordinate values in other columns that might start with 0.x, so you end up with fewer vertices than you should have. In most cases, it won't severely affect your results, because not many vertices are thrown out in this way. But it's an error and might also be different for the different hemispheres. (In one case, I had 20-30 dropouts only in the left hemisphere.)
A replacement for the line of code would be, e.g.:
cat $infile | sed "/^#/d;/^[0-9]*$/d;/.* 0\.[0-7]0{5}$/d" \ > /tmp/tmpthreshout
Or you use something more sophisticated on columns (awk?).
Maybe someone could confirm the bug. It would be nice if it could be changed in future versions.
Obviously, there is also no effect for the GUI thresholding function. So if you do all your thresholding manually from the "prob" file, that's fine.
Best regards,
Axel Kohler