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