3dmask_tool : different solutions using HEAD and BRIK and values 256 and 257 appearing

AFNI Message Board
1

Hi,

So i have 28 binarized maps (got using 3dcalc) and i want to find the intersection. I run the following command and have 2 questions regarding it:

3dmask_tool -input bin_rest_binarized*+orig.HEAD -prefix mask_inter \ -frac 1.0"

  1. What is the difference between giving the input as bin_rest_binarized*+orig.HEAD and bin_rest_binarized*+orig.BRIK (i get very different intersections when i switch one for the other. (With head i get almost 9000 voxels with value 1 whereas with BRIK i get just 188))

  2. I checked that all my bin_rest_binarized* are binary but in my mask_inter(output mask) i also see some values equal to 256 and 257 in both BRIK and HEAD (I am not sure where these two values come from)

Thanks
Prateek Sasan

2

Hi, Prateek-

That is odd behavior, and I don’t think either of those should be happening…

Firstly, what is the output of:


afni -ver

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.

–pt

3

Hi,

Thanks for the reply. I deleted the files and ran the code again. Now the result i get using BRIK.gz and HEAD are the same but i still get 256 and 257 as values. Here are the results of codes you told me to run (I am running it on OSC owens server):

afni -ver

Precompiled binary linux_openmp_64: Sep 2 2020 (Version AFNI_20.2.16 ‘Aulus Vitellius’)

ls bin_rest_binarized*+orig.HEAD | wc -l

28

ls bin_rest_binarized*+orig.BRIK.gz | wc -l

28

This is my code (I ran it from R):

name of file

binarize_name ← paste(“bin_rest_binarized”, sub_code, “_”, les_code, sep = “”)

code for 3dcalc

system2(“3dcalc”, args = paste0("-a ", bin_name, " -expr ‘notzero(a)’ -prefix ", binarize_name))

#code for 3dmask_tool
system2(“3dmask_tool”, args = paste0(“-input bin_rest_binarized*+orig.HEAD -prefix mask_inter
-frac 1.0”))

system2(“3dmask_tool”, args = paste0(“-input bin_rest_binarized*+orig.BRIK.gz -prefix mask_inter_brik
-frac 1.0”))

The data is 91 * 109 * 91 and this is the values i see

 0           1       256      257

654657 9402 9404 229166

Thanks
Prateek Sasan

4

I downloaded afni on windows (wsl) using the steps given on the afni website and i still see 256 and 257. This is the comment i get.

3dmask_tool -input bin_rest_binarized*+orig.HEAD -prefix mask_inter -frac 1.0
++ processing 28 input dataset(s), NN=2…
++ padding all datasets by 0 (for dilations)
++ frac 1 over 28 volumes gives min count 28
++ voxel limits: 238386 clipped, 183 survived, 664060 were zero
++ writing result mask_inter…

But there is a very big difference. When running on OSC server i get the following results as statistics :

 0            1      256    257

655015 9466 9514 228634

whereas on afni on my computer i get :

 0            1     256    257

902285 178 162 4

This is with the same files.

5

Hmm, would you be able to upload these files so I can take a look at them and see what is happening firsthand? I will PM you instructions.

–pt

6

Hi Parateek,

To be positive, what are the exact commands you are running to get this text output?

0 1 256 257
654657 9402 9404 229166

Also, can we be sure of the dataset? What is the output of these commands?

echo bin_rest_binarized*+orig.HEAD | wc
echo bin_rest_binarized*+orig.BRIK | wc
echo bin_rest_binarized*+orig.BRIK.gz | wc

As Paul noted, the output should be binary 0/1.

Were you able to upload this data?

Thanks,

  • rick
7

Hi,

Thanks. i figured out both of the problems. The 256/257 is a problem with readafni function in R. using 3dbrickstat i get 0 and 1. The other problem i was facing was regarding different results for HEAD and BRIK, that was again due to running with R. In one of them i accidently put the code in 2 lines which introduced a \n operator and that made the difference

Sorry for the confusion.

Thanks,
Prateek Sasan

8

Hi, Prateek-

OK, glad you figured those things out.

I guess I didn’t catch that you were using a readafni function in R specifically. Even later on in the thread, it seemed like you were just running regular command line functions through an R script.

In the future, it would probably help solve issues more quickly if you mention that kind of execution method (esp. non-command line usage, and using other I/O programs that are outside the software). We would probably rather have “too many” details, than too few.

thanks,
pt