3dBrickStat -non-zero / -positive

Hello,

I have a 3D volume with minimal value of non-zero voxels being 3.69779e-32.
When I run


3dBrickStat -min -non-zero myvolume.nii.gz

I obtain 0 as minimal value. Same if I run:


3dBrickStat -min -positive myvolume.nii.gz

Interestingly, if I binarize my volume first (any non-zero voxel changed to 1), and then use this new binary volume as a mask:


3dBrickStat -min -positive -mask myvolume_binarized.nii.gz myvolume.nii.gz

then I obtain the expected minimal value of 3.69779e-32.

Do you know why this happens? Is there a way to obtain the minimal value without having to create a binary mask?

Thanks,
Giuseppe

Hi, Giuseppe-

What is your AFNI version number? That is, the output of:


afni -ver

?

–pt

I have tested this on my laptop [Precompiled binary macos_10.12_local: Jun 6 2022 (Version AFNI_22.1.13 ‘Antoninus Pius’)] and on my workstation [Precompiled binary linux_centos_7_64: Feb 18 2022 (Version AFNI_22.0.11 ‘Hadrian’)].

Thank you!

Giuseppe

OK. I am unsure (a fix about something else in 3dBrickstat had been made a little while ago, based on whether one had a mask or not; but that looks separate).

I am not sure about this, so will email you for the dset specifically, if that is OK? I am curious what the datum type of it is, as well as whether a scaling factor is involved… But rather than continually prodding with questions, I’ll just try to take a look.

I will note that you are checking numbers at the knife-edge of double precision here… I am tempted to say some computational shenanigans might almost be expected. I have never seen an MRI dataset require this level of precision, and so am a bit curious about that. But indeed, I am happy to look into the present issue for more clarity.

–pt

Actually, reading more carefully here, I see that your versions of AFNI each pre-date the 3dBrickStat fix that went in on Sept 1, 2022.

Testing your dataset on my computer with each of the old and new versions of 3dBrickStat, I see that the above bug fix (related to masking or not) fixes this issue. Therefore, AFNI versions >= 22.2.10 should not have this problem.

Thanks for checking about it, but can you update your AFNI binaries on those systems:


@update.afni.binaries -d

?

–pt

Yes, updating AFNI to the latest version solved the issue.

Thank you very much!

Giuseppe