History of AFNI updates  

|
May 23, 2018 11:26AM
So it seems I was a bit dense about this in the first
place. If particular runs are being converted, then
once in a while some number exceeds 2^15 - 1 in
the short data (i.e. evaluation as unsigned short is
required).

But then you have the mix of types to deal with, since
Dimon was only applying -ushort2float when needed.

I have just checked in a -ushort2float option to Dimon,
so you can have it always applied if you want it.

However, now you have a choice:
a. When detected (you have to look), make all data float
for the given subject.

b. In general, make all data float for all subjects.
This is more consistent, but uses much more disk space.

c. Perform some additional computation to force data to
be less than 2^15. This requires care for appropriateness.
Dividing by 2 is a possibility. You lose the big of resolution,
but it should be a stable operation, e.g.

3dcalc -a dset_float+orig -expr a/2 -datum short -nscale -prefix dset_short

Anyway, the -ushort2float option for Dimon will be available
after the next build, which will hopefully be tonight.

- rick
Subject Author Posted

Dimon call outputting one run as float, rather than short

henrybrice May 02, 2018 09:31AM

Re: Dimon call outputting one run as float, rather than short

rick reynolds May 03, 2018 02:37PM

Re: Dimon call outputting one run as float, rather than short

henrybrice May 06, 2018 03:16AM

Re: Dimon call outputting one run as float, rather than short

rick reynolds May 08, 2018 09:51AM

Re: Dimon call outputting one run as float, rather than short

henrybrice May 08, 2018 11:08AM

Re: Dimon call outputting one run as float, rather than short

rick reynolds May 14, 2018 10:48AM

Re: Dimon call outputting one run as float, rather than short

rick reynolds May 23, 2018 11:26AM