Hi, Giuseppe-

Have you just updated your AFNI recently, and from a fairly old version? On May 24, 2019, we updated the default autorange (but you can still control it!) to be as follows:

5) User can set [an environment variable] AFNI_AUTORANGE_PERC to have the autoRange computed as
    percentile point (from 2-99) of the nonzero absolute values in the OLay
    brick. However, this doesn't work with warp-on-demand datasets now, so
    it is confusing. Therefore, the default setting of this is 0, which
    leaves the autoRange to be the maximum absolute value.

Note that autorange applies to the *overlay*, not the threshold (though sometimes those are the same data). Indeed, we used to set the upper colorbar value at the max value in the overlay dataset, but we found in virtually all floating point dset cases (e.g., anatomical overlays, effect estimates, stats, etc.) there were a small number of unrepresentatively high values that stretched the colorbar misleadingly. So we created an environment variable AFNI_AUTORANGE_PERC that you can set in your ~/.afnirc file to define a percentile within the overlay dset to set the autorange; default is 95 (percent). Its description in the list of env vars (https://afni.nimh.nih.gov/pub/dist/doc/htmldoc/educational/readme_env_vars.html) is:

If this variable is set to a value P between 2 and 99 (inclusive),
then it indicates that the functional overlay 'autoRange' value
will be set the P-th percentile point on the cumulative histogram
of the absolute values of the nonzero entries in the Overlay
dataset sub-brick being viewed. To be less confusing, if P=95
(for example), then the nonzero absolute values are tabulated
into histogram bins from smallest (percentile=0) to largest
(percentile=100), and the value at the 95th percentile will
be chosen -- so that only 5 percent of the values in the
dataset are larger than this autoRange value. The reason for
doing this is to avoid allowing a few large values to distort
the overlay color scale.

Thresholding is typically off by default (or actually a super-tiny value, I think, for OpenGL-related reasons, but essentially 0).

Note that if you have integer-valued dsets like ROI maps that have the INT_CMAP attribute on (to select an ROI-appropriate colorbar by default), then the max value will/should be the number of colorbands for that colormap.

Does that all seem consistent with what you have on your computer?

--pt