Hi everyone. I’m trying to do a conjunction analysis and I have some question about viewing the results.
First, I ran a conjunction analysis,
3dcalc -a zeffortSVcho_age+tlrc’[1]’ -b zprobSVcho_age+tlrc’[1]’ -expr ‘step(a-3.28)+2*step(b-3.28)’ -prefix conj_SVcho_ep
and then I opened the conjunction map in the afni viewer. This is my understanding of how to view the results: the voxels where both tasks are above the threshold of 3.28 should have a value of 3 in this conjunction map. So, to view only these voxels I should set the slider somewhere between 2 and 3.
However, when I set the threshold to 2.2, I noticed that the voxels with a value of 2 are still displayed. When I moved the threshold to 2.8, the voxels with a value of 2 disappear. More exploration showed that the voxels labeled 2 were disappearing above 2.5. The problem also extends to the cluster table. If I view the table of results, the cluster algorithm includes voxels with a value of 2 even when the threshold is set to something between 2.01 and 2.49.
I was concerned this was specific to the machine I was working on (AFNI version 16.3.14, compiled on Dec. 7, 2016), so I moved to a different machine. On that machine (AFNI version 16.3.09, compiled on Nov. 16, 2016), the voxels with a 2 were no longer displayed between 2.01 and 2.49 in the viewer, but the problem in the cluster table remains.
Any idea why there are these inconsistencies in viewing are occurring? What should I do to see the true results of the conjunction analysis?
I expect the underlay dataset is a higher resolution,
and the overlay is being interpolated. For a simple
test, change the underlay dataset to be the same
as the overlay dataset.
First thought – check the Alpha setting for functional overlays. This is the variable
AFNI_FUNC_ALPHA which is set in your ~/.afnirc file (or perhaps in your shell login file).
You can check this setting inside AFNI – where it counts – by looking at the color overlay “pbar” underneath the OLay label at the top of the Define Overlay control panel. If that pbar shades left-to-right from color to white-ish, then Alpha is turned on.
You can control the Alpha setting interactively in the GUI by right-clicking on the label at the top of the threshold slider. That should popup a menu with various items, including a sub-menu for Alpha. If that is anything but Off, set it to Off.
What does Alpha do? Instead of hard thresholding, which is what you want here, it “soft thresholds” – voxels where the Thr value is below the threshold setting are faded out in color, and the Alpha setting determines how that works (linearly or quadratically). If Alpha is on, then voxel clusters above threshold are also outlined in black. These ideas came from some paper I read http://www.sciencedirect.com/science/article/pii/S089662731200428X (see Fig 3).
Another way to disable Alpha temporarily is to use Clusterize.
When I set the overlay and underlay to the same data set, it fixes the problems I was having with the viewer displaying voxels with a value of 2 while the threshold was set to a value above 2.
However, when I view the cluster report, it still includes voxels of 2 in the cluster report. I’ve uploaded the file to the afni server as suggested by ptaylor - file name KendraSeaman.
I don’t think we have alpha on. There is no AFNI_FUNC_ALPHA set in the .afnirc file. Within the AFNI viewer the color overlay “pbar” is solid (no left-right white-color gradient).
I uploaded a copy of the file (KendraSeaman.tar) to the AFNI server as suggested in an earlier response.
Also, thanks for the reference. I’ll check it out!
At this point, I can only suggest packaging up the files (underlay and overlay) that aren’t working nicely together, and sending them to us. This link should work for that purpose.
Thanks Rick. I’m not sure how that happened! I found the original header file, replaced in the folder, and re-uploaded it to the afni server. I also included the anatomical scan I have been using as an underlay, as requested by Bob.
The latter two look like a dataset, but the HEAD file is a copy of the BRIK file and so useless. I have deleted the upload with your name on it. Can you check to make sure the HEAD file has a different file size than the BRIK file, and that 3dinfo works when run on the HEAD file? Once that’s verified, you can package them up and upload them again.
There should be a file upload KendraSeaman2.tar that has a conj_svcho_ep+tlrc head/brik file that are different sizes. It should also include the anatomical scan - aveanatss1mm+tlrc.
I may have uploaded the wrong directory earlier today. Sorry for the confusion on my end.
I’ve got the corrected data and am looking at it now.
I think what you are seeing is due to the intersection of 2 functions in AFNI.
[ol]
[li] The overlay is at a lower resolution than the underlay, so it is resampled to match to underlay grid for display.
[/li][li] The default resampling method is Linear interpolation.
[/li][/ol]
Your overlay data isn’t some value that is more-or-less continuous in space (such as a beta weight or t-statistic), where linear interpolation makes sense. It is a discrete value, and so interpolation between 2 and 3 to get (say) 2.5 makes no sense.
You can turn off this linear interpolation. Click on Define Datamode and you will see two controls, OLay Resam mode and Stat Resam mode. Change both of these to NN and your overlay image will suddenly go from smooth to blocky.
This switch of texture, from smooth to blocky, is very visible if you zoom in on the region of interest, but it is apparent even with no zooming.
How did I find this? I did something “tricky” or “hidden” in the AFNI GUI, that few people know about. I put the Overlay in as the Underlay temporarily (using the “U]” key into the image viewer). Then I opened the Disp control in the viewer, and chose RowGraphs to be 1. This shows a graph of the data in the underlay image underneath the row where the image crosshairs are. It was obvious then that some intermediate values were being created by interpolation.
The problem has been solved. It had to do with differences in the implementation of thresholding in the clustering code and in the main AFNI GUI. The fix is explained below, in an excerpt from README.environment (as I edited it yesterday). However, you’ll have to wait until we re-compile the binaries. I hope to remember to do that tonight, but my aging brain doesn’t remember things as well as it once did
Variable: AFNI_OLD_SHORT_THRESH
When thresholding a dataset with a sub-brick that is stored as shorts (16 bit
integers), the AFNI GUI uses floats, but the 3dmerge and Clusterize functions
use shorts. The difference is that the user-supplied threshold in the latter
case is rounded to the nearest short. Thus, a threshold of 2.2 would become
2, and then a value of 2 would pass the ‘greater than or equal to threshold’
test – which is probably not what the user meant. Again, this would happen
in 3dmerge and Clusterize, but NOT in the AFNI GUI without Clusterize.
This inconsistency has been fixed, and both sets of places now threshold
using floats. However, IF you want to stick with the old method for some
un-imaginable reason, you need to set this variable to YES.
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.
