<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'>Dave,<BR>
<BR>
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.<BR>
<BR>
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).<BR>
<BR>
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?<BR>
<BR>
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.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 8/23/10 5:45 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'>> I’ve recently run into an issue with rendering fields with NaN <BR>
> values in it.... I propose making the changes in the attached <BR>
> patches (created with git-format-patch). First, a NanColor was <BR>
> added to vtkLookupTable (as a 4-tuple RGBA) and added to <BR>
> vtkColorTransferFunction (as a 3-tuple RGB) so that these respective <BR>
> lookup tables would return a specific color for NaN. Next, <BR>
> vtkScalarsToColorsPainter was modified to use a 2D texture map that <BR>
> uses the second dimensions to distinguish between real and NaN <BR>
> values. I also added a test for rendering these NaN values along <BR>
> with the other non-finite –INF and INF values.<BR>
><BR>
> Does anyone object to these changes, or do they seem reasonable to <BR>
> put into VTK?<BR>
Hi Ken,<BR>
<BR>
For cell data, the patch seems really useful. For point data I'm less <BR>
sure. For example, the attached images show first your test and second <BR>
what happens when 2 neighboring cells both have NaNs. Without the <BR>
texture map, color interpolation looks bad (bars 1, 3). With the <BR>
texture map, the valid values between NaNs appear as a single pixel <BR>
(bars 2, 4). Perhaps a filter with a feature similar to vertex <BR>
splitting in vtkPolyDataNormals is in order? It could modify polydata <BR>
as required to insert extra vertices along edges with a single NaN, so <BR>
that the rendered output would only display NaN in about half of each <BR>
cell.<BR>
<BR>
Also, I've long wanted a way to specify a multidimensional texture map <BR>
with hue mapped to one axis and saturation to another. Will this <BR>
change prevent it? If so, would you mind moving the NanColor handling <BR>
in the mapper to a subclass?<BR>
<BR>
Thanks,<BR>
David<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>