I've run into a problem where it seems that precision is being lost during several standard preprocessing steps. If a run a script that uses the following series of commands,

3dDespike -ignore 4 -prefix ds+orig run+orig
3dDetrend -prefix dsdt -polort 1 'ds[36..153]'
3dmerge -1blur_fwhm 4 -doall -prefix dsdtsm4 dsdt+orig

(despike, detrend, and the spatially smooth a dataset), the resulting BRIK ranges from a minimum value of -134 to a maximum value of 168. There are apparently no floating point scale factors being applied, so there are effectively only approximately 300 discrete states that a voxel could be in. Thus I am now down to around 8 bits of precision.

My questions are these: is this the official behavior of AFNI, or am I doing something wrong? Can AFNI rescale my data automatically to use the full 15-bits of precision, so that the range [-134, 168] could be represented using 16-bit integers and a floating point factor? Is this what '3dcalc -fscale' does? If so, how can I get preprocessing programs to apply 'fscale' before truncation occurs?

As a temporary solution, I can convert the raw+orig dataset to float using 3dcalc before I do any preprocessing, and use 32-bits of precision for all calculations, but this doubles space requirements.

A graph comparing the timecourse of a single voxel computed with floating point precision at all steps (blue) vs. short precision (green) is attached. It looks like using the short precision is losing variance that might affect my later analyses.

Thanks very much,
David Weiss