Mon 07 Oct 2013 08:03:48 PM UTC, comment #7:
I fixed surf not rendering NaNs as transparent, and also did the same for mesh (edgecolor) in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/c3aadd228c37). The fix will be part of the next stable release 3.8 which should come out within 1-2 months.
|
Wed 29 Feb 2012 05:49:50 PM UTC, comment #6:
That's my assessment as well. As I understand the Matlab documentation it should take the FaceColor from the LL vertex. It should be pretty easy to do a test for NaN and just skip rendering the entire face. We'll see where Michael thinks the code fix belongs.
|
Wed 29 Feb 2012 04:20:45 PM UTC, comment #5:
I compared Matlab to Octave without NaNs, and they behave consistently.
When the FaceColor = 'flat' the LL corner color is used. So I think Matlab is doing the right thing. I don't see how to fix the Gnuplot result without changing Gnuplot itself.
In any event, the FLTK tookit is also doing the wrong thing (NaN = black).
I suggest we fix the fltk toolkit (gl-render.cc ?) and leave gnuplot as it is.
I'm not familiar with this code, so I've cc'd Michael Goffioul.
Michael, can you look at this or give us some pointers?
|
Wed 29 Feb 2012 01:59:21 PM UTC, comment #4:
After some more thought, I'm not sure Matlab is doing the right thing. The cdata corresponds to the color at the corners of the mesh. When FaceColor = "flat", the average of the RBG values of the vertices are used to determine the color of each rectangle in the mesh. If one vertex has a NaN, shouldn't four mesh elements be empty / missing?
When run in Octave and using the gnuplot backend, replacing the NaN with Inf produces the result I'd expect for NaN.
|
Wed 29 Feb 2012 01:02:07 PM UTC, comment #3:
The surface's properties under Matlab are
I don't think anything too complicated is needed. My understanding is that the NaN value should be equivalent to "none".
For gnuplot, I think the NaNs can be intereprted as missing values. See the thread below (I haven't looked to see if this works for gnuplot)
http://objectmix.com/graphics/139704-management-not-number-fields.html
Two solutions are mentioned.
I'm not sure if this will work for us. The second solution implied the "using" specifier can fix this problem, but I don't undertand how.
|
Tue 28 Feb 2012 01:00:18 AM UTC, comment #2:
Ben, I'm adding you to the CC list for this ancient bug report. The behavior is still present on a recent tip. For convenience, I'm attaching the reporter's example as an m-file.
How do we specify transparency as a color value? Or does this really mean we need to implement alpha(), alim(), and alphamap() which sounds like a big project.
(file #25197)
|
Mon 31 Jan 2011 10:42:35 AM UTC, comment #1:
This seems to have not included my Test Case.
The surf (and surface, and pcolor) functions do not handle NaN values the same as Matlab.
The following commands:
> c = [1 1.5 -1 0.2 2; 2 1.8 1.2 0.4 -0.8;1.6 NaN 0.7 2 -2;-1.1 1.5 0.1 -0.7 0];
> [nr, nc] = size(c);
> [x, y] = meshgrid (1:nc, 1:nr);
> surf(x,y,zeros(size(x)),c)
produces octave_surf_nan_bug.png in octave and matlab_surf_nan_bug.png in Matlab; i.e. octave treats NaNs as zero. You can issue:
> surf(zeros(size(c))+(c-c),c)
in octave, which produces octave_surf_bug_2.png; (the "+(c-c)" places matching NaNs in the zeroes matrix) but some of the surrounding cells are also left blank in that case.
|
Fri 28 Jan 2011 01:54:18 PM UTC, original submission:
Test Case:
|