[vtk-developers] Rendering scalar data with NaNs

[Moreland, Kenneth]

Dave,

I agree that the color interpolation is bad, but I venomously disagree that it makes the patch inappropriate for point data.  It really just states that color interpolation is erroneous in general.  This happens whenever you have a large change in colors.  For example, if you have the rainbow color map and have a polygon with point values at both the low and high ends, the colors will get interpolated through violet rather than green  That's one of the main reasons for using a texture map for color mapping in the first place.

For the case where texture mapping is used, I feel that the behavior is correct (or at least as correct as can be).  In your example, those green slivers are exactly what I intended to happen.  The value is defined right on that point but NaN everywhere else (because when you interpolate to NaN you get Nan).

I admit that "correct" is a little fuzzy here because the interpolation is ill defined.  But the main point is to make explicit that there is a NaN by assigning it a specific color.  Without the change you get results that are incorrect by any metric with no indication that something is wrong.  The fact is that NaNs in point data happen.  Do you have some other interpolation behavior that makes sense?

I can't say for sure whether this change will conflict with some hue/saturation map because I cannot fathom the use case, but I suspect that yes they will conflict, sort of.  I don't see any way to share the NaN dimension with either hue or saturation.  However, if you are making a texture referenced by hue/saturation, then clearly somewhere else you are mapping scalar values to hue and saturation.  In that case, make sure that when you do this map that you don't get NaN values for hue or saturation.  Since you are making a special texture map anyway, these are two distinct cases and you don't have to worry about it.

-Ken


On 8/23/10 5:45 PM, "David Thompson" <dcthomp at sandia.gov> wrote:

> I've recently run into an issue with rendering fields with NaN
> values in it.... I propose making the changes in the attached
> patches (created with git-format-patch).  First, a NanColor was
> added to vtkLookupTable (as a 4-tuple RGBA) and added to
> vtkColorTransferFunction (as a 3-tuple RGB) so that these respective
> lookup tables would return a specific color for NaN.  Next,
> vtkScalarsToColorsPainter was modified to use a 2D texture map that
> uses the second dimensions to distinguish between real and NaN
> values.  I also added a test for rendering these NaN values along
> with the other non-finite -INF and INF values.
>
> Does anyone object to these changes, or do they seem reasonable to
> put into VTK?
Hi Ken,

For cell data, the patch seems really useful. For point data I'm less
sure. For example, the attached images show first your test and second
what happens when 2 neighboring cells both have NaNs. Without the
texture map, color interpolation looks bad (bars 1, 3). With the
texture map, the valid values between NaNs appear as a single pixel
(bars 2, 4). Perhaps a filter with a feature similar to vertex
splitting in vtkPolyDataNormals is in order? It could modify polydata
as required to insert extra vertices along edges with a single NaN, so
that the rendered output would only display NaN in about half of each
cell.

Also, I've long wanted a way to specify a multidimensional texture map
with hue mapped to one axis and saturation to another. Will this
change prevent it? If so, would you mind moving the NanColor handling
in the mapper to a subclass?

        Thanks,
        David




   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100823/76a0166c/attachment.html>