Overlay Values are Outside the Range of Possible Values

We’re currently having an issue where beta coefficients in the visual display overlay in AFNI show values that are outside the listed range of values. For example, the stated range in the AFNI display is -1.28 to 2.07, while the listed value for selected voxel is shown as 23.68 (see attached images), well outside the range of possible values listed. We only see this after using adwarp to normalize images. The data in original space to not have this problem. Below is an excerpt of the code we are using:

adwarp -resam Li -apar ${Sub}Anat_al+tlrc -dpar Decon_MISTA+orig’[11]’ -prefix RespADur

Attached to this post are two screenshots, one called Original and one called Normalized, with boxes to highlight the overlay values.

Has anyone run into this issue before? We’re unsure why this is happening.



Check the output of

3dBrickStat -min -max mydset
3dBrickStat -min -max -slow mydset

Also what does 3dinfo report on the min and max. If these are different from the last “slow” command, you may want to run

3drefit -redo_bstat mydset

With the same dataset as the underlay, you can also right-click on the image viewer and see the “bg” value for the voxel value. That will remove the effect of interpolating the overlay dataset to the underlay. 3dmaskdump can be used to get the value at the command line.


I’m also having the same problem. I used @auto_tlrc to convert the anatomical data to standard space and then I used adwarp to convert the functional data to the standard space based on the transformation applied to the anatomical data. Afterwards GLM is applied to the functional data and correlation maps are created with respect to stimulus. When I overlay correlation results onto the anatomical data, the values are much higher than the range of the values. If I overlay the correlation maps on itself or onto the functional data in standard space, I see what I was expecting to see and the values are in the range. I also check the results with the commands 3dBrickStat and 3dInfo as suggested in the previous messages and the max min values are the same. I would appreciate if you could help me solving this interpolation problem and visualize the results on the anatomical data. Attached you can see the GUI screenshots with the data overlayed on the anatomical data and on itself.

That is strange. Would you mind uploading the datasets involved here so we can check it out. I’ll PM you with instructions.

Hi Daniel,

Thank you very much. Yes I can send you the data if you can provide me the details. I appreciate your help.

Best regards,
Gokce Sarar

You should have message in your private message inbox from me with instructions. On the upper right of this webpage, you should find a “Private Messages” button that’s clickable. I’ll try to send it again in case it got lost.

I took a quick look at your data, and I didn’t really see anything too unexpected. It may be that you are surprised by the behavior of the interpolation of the overlay when the underlay dataset has a different grid. There is some user control for this in the “Define Datamode” menu. Then select the Olay resampling and the Stats resampling methods. With NN (nearest neighbor) interpolation, you should get the same values as with the original grid, if the underlay has a finer grid. The other methods will create smoother images.

Hi Daniel,

Thank you for your reply. So when you overlayed them onto the anatomical data, didn’t it give you very high overlay values, which are much higher than what is seen when overlayed to the functional data?

Hi Daniel,

I checked the data and the Datamode is as you described as you can see attached. And this is happening with different subjects too, so it is not specific to one data. I would appreciate your help.

I’ve been looking at your data again, and I still don’t see that issue of the data values shown in the Overlay panel for the overlay being much larger than the range of the dataset. One thing that is system specific - the values shown in the lower right do sometimes have a lag that may not get updated if the image can not be computed fast enough. Try moving the crosshairs with the arrow keys or clicking in the slider.

Hi Daniel,

Thank you very much for your help. I tried that one too, but it remains with the high values, but I couldn’t figure out why you can’t see that effect. The only thing I’m able to do is putting functional data as underlay. When you say system specific, should I update my software version?


I don’t know where the problem is, but you can certainly try upgrading. Also see whether you see these same strange values on the command line for particular coordinates with 3dmaskdump.

I will try 3dmaskdump, thank you very much.