That is odd behavior, and I don’t think either of those should be happening…
Firstly, what is the output of:
in order to know your AFNI version?
Re. #1: there should be no difference between specifying a file via it’s HEAD or BRIK file. Can you verify that the lists are really the same with the wildcarding? For example,
ls bin_rest_binarized*+orig.HEAD | wc -l
ls bin_rest_binarized*+orig.BRIK | wc -l
… both return the same number (that is, the number of files found by the shell)? And/or that
ls -1 bin_rest_binarized*+orig.HEAD
ls -1 bin_rest_binarized*+orig.BRIK
really look like the same list of files? One thing that might happen is something the BRIK file output is gzipped, so the file name for that part is *.BRIK.gz, and that would show up differently between your two wildcardings. However, from the behavior you describe, it seems that maybe somehow an extra *BRIK file is getting in with that list?
Re. #2: I think the output file (mask_inter*) should be binary, regardless of input values. So, you shouldn’t have values of 256 and 257 under any scenario.
Ummm, looking at other potential causes issues: are you overwriting files as you output? I would try moving the existing output files to a temporary directory, and then try these:
3dmask_tool -input bin_rest_binarized*+orig.HEAD -prefix mask_inter_h -frac 1.0
3dmask_tool -input bin_rest_binarized*+orig.BRIK -prefix mask_inter_b -frac 1.0
If none of those attempts point to a root cause, I’m curious what the 3dcalc command you were using is?
Let us know how that goes.