casting nii to int16 in preprocessfmri.m

[tommysprague]

For nii's where intensity values are high, this seems to be a reasonable step. However, when the intensity values are small (e.g., <= 400 over entire brain), this step aggressively compresses the dynamic range of the image, especially in the time dimension. My resulting .nii's after processing end up with 5-20 unique values over time for any given voxel.

Perhaps it's possible to add a check somewhere as to whether the cast to int16 would compress the data based on its range?

[kendrickkay]

Ah, yeah, these are tricky but important issues. What would be ideal? A robust check and then if it fails, should the code just error out? What line number is the culprit? And I wonder: something like diff(prctile(...[1 99])) < 100, or something like that? An issue is spatial heterogeneity... so maybe a brain mask first and then that check?

…

On Mar 6, 2017, at 1:52 PM, Tommy Sprague ***@***.***> wrote: For nii's where intensity values are high, this seems to be a reasonable step. However, when the intensity values are small (e.g., <= 400 over entire brain), this step aggressively compresses the dynamic range of the image, especially in the time dimension. My resulting .nii's after processing end up with 5-20 unique values over time for any given voxel. Perhaps it's possible to add a check somewhere as to whether the cast to int16 would compress the data based on its range? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACmhkiaikjZBayVe7U-_h09IBMCDe--Xks5rjGP3gaJpZM4MUnNt>.

[tommysprague]

I was thinking the easiest way would be to scale the input image to match the range of int16 data format before casting - if done across an entire session, I don't think this would cause clipping, etc.

And I actually didn't track it down to a line number - I just noticed that time series plotted from the output nii's result in a small number of discrete values, so it's whenever the int16 conversion from nifti float/single-precision happens.

I can send you some example files if you like.

[kendrickkay]

Hmm... we would have to be careful about how this is done.. Maybe take all of the loaded EPI data (multiple runs), then find the min and max, and then decide whether the range was too low, and then if so, scale by a single positive real number to fill 1/2 of the max value in int16 ? A less error prone route is to error out and tell the user to fix it. Another route is to make this step yet another flag. Also, I didn't know anyone else out there was using preprocessfmri - are you using it for something?

…

On Mar 6, 2017, at 3:29 PM, Tommy Sprague ***@***.***> wrote: I was thinking the easiest way would be to scale the input image to match the range of int16 data format before casting - if done across an entire session, I don't think this would cause clipping, etc. And I actually didn't track it down to a line number - I just noticed that time series plotted from the output nii's result in a small number of discrete values, so it's whenever the int16 conversion from nifti float/single-precision happens. I can send you some example files if you like. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACmhkoBcfvbwDiuBGPGtOl5ccRKeockWks5rjHqggaJpZM4MUnNt>.

[tommysprague]

Yes - a few labs at NYU use a wrapper over it (Winawer lab, & parts of Curtis lab) for preprocessing.

And the first option sounds sensical if there's an agreed-upon minimum time-series precision (8 bits?). I can't imagine a scalar value difference inducing any large problems, but I'm likely overlooking something.