It is the custom among MRI manufacturers to store image in short (16 bit integer) format. This custom arises from a few sources:

- the raw MRI data has more than 8 bits of accuracy (12..16 is typical), so an 8 bit grayscale format (typical for photos) would not be enough to capture the dynamic range of the instrumentation
- but storing as a 32 bit float (the way the images are actually calculated) takes more disk space
- the binary format of floats was not standardized at the time MRI scanners were introduced, unlike the binary format of integers

3dcalc, for example, converts all inputs to doubles (64 bit floats) for internal calculations. However, it writes the output dataset in the same binary format that the input was in, unless the "-datum" option is given.

AFNI datasets can contain scaling factors that basically say "this sub-brick is stored as a short, but before using it, scale it to a float by the factor XXX".
Programs like 3dDeconvolve write their results in this scaled-short format. The reason is primarily historical. It probably would be relatively easy to modify all these programs to give the option to save directly as float-valued datasets. Disk space is more plentiful and cheaper now, and the IEEE-794 standard for the binary representation of floats is now almost universal. Personally, I would prefer never to have to deal with byte- or short-valued datasets ever again. But I doubt I'll get that luxury.

bob cox