<HTML>
<HEAD>
<TITLE>Re: [vtk-developers] Rendering scalar data with NaNs</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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.<BR>
<BR>
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.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 8/23/10 7:18 PM, "David Thompson" <<a href="dcthomp@sandia.gov">dcthomp@sandia.gov</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Ken,<BR>
<BR>
> I agree that the color interpolation is bad, but I venomously <BR>
> disagree that it makes the patch inappropriate for point data.<BR>
<BR>
Fortunately for me, I have developed an immunity to your venom. :-)<BR>
<BR>
> It really just states that color interpolation is erroneous in <BR>
> general.<BR>
<BR>
No argument there. At least for linear, component-wise RGB <BR>
interpolation.<BR>
<BR>
> For the case where texture mapping is used, I feel that the behavior <BR>
> is correct (or at least as correct as can be). ...<BR>
> the main point is to make explicit that there is a NaN by assigning <BR>
> it a specific color. Without the change you get results that are <BR>
> incorrect by any metric with no indication that something is wrong. <BR>
> The fact is that NaNs in point data happen. Do you have some other <BR>
> interpolation behavior that makes sense?<BR>
<BR>
They don't make more sense, but I think there are 2 possible methods <BR>
that might result in better visual representations from a cognitive <BR>
perspective.<BR>
<BR>
1. One strategy would be: a cell with NaN at any vertex should be <BR>
drawn colored entirely with the NaN color. The idea is that, as you <BR>
say, no interpolation is possible. The distinction I would make is <BR>
that when you are interpolating point values, you are defining a new <BR>
field on each cell computed by interpolating all of the vertex values <BR>
of that cell; you are not rendering the underlying point data. The <BR>
derived field should be undefined over the entire cell where something <BR>
bad happens because the interpolant is a function of *all* the cell's <BR>
values plus the coordinates to evaluate the interpolant at.<BR>
<BR>
2. If an illustrator wanted to show that a vertex surrounded by NaNs <BR>
had a finite value, he would either draw a glyph at the vertex or make <BR>
a region of the surrounding mesh take on the vertex's value. You can <BR>
get an effect much like the latter by partitioning the cell and <BR>
rendering it much the way an isovolume operation would be performed. <BR>
Edges with NaN at one end and a finite value at another would be split <BR>
in half. Edge midpoints would be connected to form surfaces/volumes <BR>
with a discontinuity in the derived scalar field. The concept is again <BR>
as above: you are defining a new interpolating function -- it should <BR>
be chosen to convey as much information as is feasible. While the <BR>
slivers in the test code appear acceptable, on a real 2D or 3D mesh <BR>
where NaNs surround a vertex in all directions it would be very hard <BR>
to pick out the single pixel of color. This effect would provide a <BR>
version much easier to read than the single pixel case -- which I <BR>
suspect would also suffer from flickering problems as vertices <BR>
approach pixel centers/edges. And unlike drawing glyphs and finite <BR>
values, the isovolume-alike approach makes more sense when >1 vertices <BR>
of a cell have finite values.<BR>
<BR>
> I can’t say for sure whether this change will conflict with some hue/<BR>
> saturation map because I cannot fathom the use case...<BR>
<BR>
Here's my use case: measurements are made on a sensor over time. The <BR>
hue gets mapped to the most recent sensed value. One minus the <BR>
saturation gets mapped to the the (normalized) time since the last <BR>
measurement.<BR>
<BR>
> ... but I suspect that yes they will conflict, sort of. I don’t see <BR>
> any way to share the NaN dimension with either hue or saturation. ...<BR>
<BR>
But could they share code? Could a slightly more generic change to the <BR>
mapper (where it accepts an externally-provided texture map and a rule <BR>
for mapping vtkDataArray entries to texture coordinates) provide both <BR>
features without twice as much code?<BR>
<BR>
David<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'><BR>
**** Kenneth Moreland<BR>
*** Sandia National Laboratories<BR>
*********** <BR>
*** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
** *** ** phone: (505) 844-8919<BR>
*** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>