Volumes with extremely large values cannot be displayed properly

[denisri]

---

Author Name: Leprince, Yann (@ylep)
Original Redmine Issue: 13588, https://bioproj.extra.cea.fr/redmine/issues/13588
Original Date: 2015-10-20
Original Assignee: Riviere, Denis

---

Volumes with extremely large values (on the order of @1e37@, near @FLT_MAX@) cannot be displayed properly in Anatomist.

How to reproduce this bug:

1. Download https://bioproj.extra.cea.fr/redmine/attachments/download/17167/distCSF.nii.gz
2. Open @distCSF.nii.gz@ in an axial window in Anatomist
3. Go to the Palette panel, try setting the bounds to reasonable values (e.g. [-10, 10])
4. The Min and Max cursors are ineffective (the resulting value is always 0 and the display does not change).

The cause of this bug is that the bounds of the color map are handled internally as relative to the range [min, max] of values of the image. If max – min is too large, the scaling factor goes to zero, so the color map bounds cannot be represented. Fixing that bug is not trivial, here are a few possible solutions, in decreasing order of quality:

1. rewriting the color map handling code to work with absolute values rather than relative values;
2. keeping the same code, changing @float@ to @double@, but the issue would remain with double volumes and DBL_MAX values;
3. truncating the values of volumes on loading, replacing values outside of a known-safe range (e.g. [-1e10, 1e10]) by NaN or Inf.

I personally think that we should rule out solution 3, because altering the images’ contents can confuse the users.

[denisri]

---

Original Redmine Comment
Author Name: Riviere, Denis (@denisri)
Original Date: 2015-10-20T14:15:45Z

---

Actually I used solution 2 to fix #13582.
What do you mean for solution 1 ? I don't know how to actually avoid dealing with max-min since we have to address the whole range of values with images containing both FLT_MAX and -FLT_MAX (or around).
Solution 3 would not be a good solution, since there is no definition of a "safe range" and we might actually want to use somewhat large values sometimes. (it remains me that we actually truncate NaN values when loading to avoid nan in colormap bounds and divisions by zero but it was not a good solution either)

Right now solution 2 would be enough I think: we are not using so huge double values, and using double allows to safely represent max-min for all float values.

[denisri]

---

Original Redmine Comment
Author Name: Riviere, Denis (@denisri)
Original Date: 2015-10-20T16:02:30Z

---

Hm, in the case of your example image, solution 2 cannot work actually: even double precision cannot represent a difference between (-10+3e38)/3e38 and (+10+3e38)/3e38: both relative numbers are set to 1., and are actually equal.
So I understand better your suggestion 1.
The problem is that all colormap settings are represented by relative values (float, actually) in anatomist, and cannot in any way handle such "small" intervals. Solving this issue would require to completely refactor the palette implementation, and probably involve changes in API. And its use in several kinds of objects (volumes, textures etc) would still remain tricky.