Avoiding integer overflow in pixel values

[maneeshrj]

Casting to uint8 will cause integer overflow if the pixel value is beyond the display range, e.g. a value of 257 will overflow to 1. The convention (e.g. in MATLAB, matplotlib) seems to be that values above the display range will be displayed as 255 and values below the display range will be displayed as 0, so to match this behavior in stackview, the casting should be done after clipping the pixel value to the range [0,255].

If the way it's implemented now is intentional, feel free to ignore this, but I figured it's probably a bug.

[haesleinhuepf]

Hi @maneeshrj

interesting, thanka for this suggestion! Could you please provide a scenario / example code / example image where I could see the impact of this code modification?

Thanks!

Best,
Robert

[maneeshrj]

Hi Robert,

For my own work I'm trying to view brain MRI data, specifically quantitative susceptibility maps (QSM). For the display range we tend to use something like [-0.2, 0.2], but due to pathology (e.g. hemorrhages in the brain), we can get very high values beyond the display max. Automatically scaling the display range will result in poor contrast in the rest of the brain. However, setting the display range to [-0.2, 0.2] causes those high values to appear incorrect due to the overflow bug.

Here's an example of what a hemorrhage looks like with the current code vs with the bug fix.

As it is now, the values in the hemorrhage are misleading. They look very low but are actually very high. I noticed this behavior because until now I've been using matplotlib and MATLAB imshow, and with the same display range, they both display the hemorrhage as white. Hope that helps, and thanks for your time!

[maneeshrj]

Sorry I didn't realize that any further commits I made to my fork would show up in this pull request, I've reverted that commit.