[vtk-developers] Rendering scalar data with NaNs

[Moreland, Kenneth]

I think we are in agreement.  The implementation I sent out is basically perspective 1 below.  The interpolation is basically filling the moiety-NaN polygon completely with the NaN color.  The only contention is that one pixel right on the vertex with a real value.  You say po-tay-toe; I say po-taa-toe; let's call the whole thing off.

As for your use case of a new 2D texture map lookup, I don't think this effects it much.  I didn't actually modify the mapper at all.  I modified the painter that by default handles color mapping.  If you want to customize the color mapping, you just swap out your own painter.  These changes don't effect that at all.

-Ken


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

Ken,

> I agree that the color interpolation is bad, but I venomously
> disagree that it makes the patch inappropriate for point data.

Fortunately for me, I have developed an immunity to your venom. :-)

> It really just states that color interpolation is erroneous in
> general.

No argument there. At least for linear, component-wise RGB
interpolation.

> For the case where texture mapping is used, I feel that the behavior
> is correct (or at least as correct as can be). ...
> 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?

They don't make more sense, but I think there are 2 possible methods
that might result in better visual representations from a cognitive
perspective.

1. One strategy would be: a cell with NaN at any vertex should be
drawn colored entirely with the NaN color. The idea is that, as you
say, no interpolation is possible. The distinction I would make is
that when you are interpolating point values, you are defining a new
field on each cell computed by interpolating all of the vertex values
of that cell; you are not rendering the underlying point data. The
derived field should be undefined over the entire cell where something
bad happens because the interpolant is a function of *all* the cell's
values plus the coordinates to evaluate the interpolant at.

2. If an illustrator wanted to show that a vertex surrounded by NaNs
had a finite value, he would either draw a glyph at the vertex or make
a region of the surrounding mesh take on the vertex's value. You can
get an effect much like the latter by partitioning the cell and
rendering it much the way an isovolume operation would be performed.
Edges with NaN at one end and a finite value at another would be split
in half. Edge midpoints would be connected to form surfaces/volumes
with a discontinuity in the derived scalar field. The concept is again
as above: you are defining a new interpolating function -- it should
be chosen to convey as much information as is feasible. While the
slivers in the test code appear acceptable, on a real 2D or 3D mesh
where NaNs surround a vertex in all directions it would be very hard
to pick out the single pixel of color. This effect would provide a
version much easier to read than the single pixel case -- which I
suspect would also suffer from flickering problems as vertices
approach pixel centers/edges. And unlike drawing glyphs and finite
values, the isovolume-alike approach makes more sense when >1 vertices
of a cell have finite values.

> I can't say for sure whether this change will conflict with some hue/
> saturation map because I cannot fathom the use case...

Here's my use case: measurements are made on a sensor over time. The
hue gets mapped to the most recent sensed value. One minus the
saturation gets mapped to the the (normalized) time since the last
measurement.

> ... 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. ...

But could they share code? Could a slightly more generic change to the
mapper (where it accepts an externally-provided texture map and a rule
for mapping vtkDataArray entries to texture coordinates) provide both
features without twice as much code?

        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/20100824/b23c3c60/attachment.html>