[vtk-developers] Rendering scalar data with NaNs

[David Thompson]

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