A bug in Above/BelowRangeColor mapping?

Hi,

I think the behavior of UseBelowRangeColor in Parview 5.5 is wrong. As an example, I load a surface into Paraview, rescale the color range to point data (elevation in this case), and enable the ‘Use Below Range Color’ checkbox. What you see is that parts of the surface are colored with black (fig. paraview_wrong.png), although they are in fact within the automatically computed value range. So they should get the usual color from the lookup table.

It is also simple to achieve when point data is constant. If you then enable the Below Range Color, then the entire model is black (although clearly the data is within the preset bounds).

Looks like it could be a simple <= vs < bug in the bounds checks. Any ideas?

Thanks!


Marcin,
Thanks for reporting these two bugs.

  1. Although I couldn’t easily replicate it, I believe you have fund bug number 15442, written up here: https://gitlab.kitware.com/paraview/paraview/issues/15441. I bumped up the priority slightly.

  2. I think this is related to 1) above, but is distinct enough I decided to write it up. It is here: https://gitlab.kitware.com/paraview/paraview/issues/18607.

Thanks again,

Alan

Hi, Walter,

Thanks for looking at this. Sorry, I should have attached the data set. Here comes. The problem seems to be that the ‘out of brange’ colors also cover values that do fall within the specified range. So the data range is probably fine, it’s just there effectively is an overlap between ‘out of range’ and ‘within range’.

Marcin

bug.vtk (1.1 MB)

What you are seeing is a result of limited floating-point precision when mapping data values to the texture coordinates used to do the actually coloring on graphics hardware. Data values equal to or slightly larger than the bottom range are being mapped just past the boundary between the in-range and and below-range color. This mapping is done by a combination of math in ParaView and linear interpolation hardware in the graphics layer, so the solution is not going to be super easy to get right everywhere. It will likely take more than just changing a comparison or introducing a fudge factor. I’ll spend some time looking at the issue for ParaView 5.7.

Cory, do we need to write up a new bug report, or are mine sufficient?

Thanks a lot, Cory! I guess my intuition was overly simplistic :wink: Let me know if you need help testing the fix - I’ll be happy to contribute.

No, the existing bug reports are sufficient.