bugGNU Octave - Bugs: bug #32275, "surf" function...

 
 

bug #32275: "surf" function incorrectly handles NaN in colour data

Submitted by:  D Walker <staccato123>
Submitted on:  Fri 28 Jan 2011 01:54:18 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedAssigned to: None
Originator Name: D WalkerOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

Rik <rik5>
Project Administrator
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.

Rik <rik5>
Project Administrator
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?

Ben Abbott <bpabbott>
Project Member
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.

Ben Abbott <bpabbott>
Project Member
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.

Ben Abbott <bpabbott>
Project Member
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)

Rik <rik5>
Project Administrator
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.

D Walker <staccato123>
Fri 28 Jan 2011 01:54:18 PM UTC, original submission:

Test Case:

D Walker <staccato123>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #25197:  nan_surf.m added by rik5 (159B - text/x-octave)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bpabbott
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by rik5
  • -unavailable- added by staccato123 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 07 Oct 2013 08:03:48 PM UTCrik5StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Wed 29 Feb 2012 04:20:45 PM UTCbpabbottStatusNone=>Confirmed
      Release3.2.3=>dev
      Carbon-Copy-=>Added -unavailable-
    Tue 28 Feb 2012 01:00:18 AM UTCrik5Attached File-=>Added nan_surf.m, #25197
      Carbon-Copy-=>Added bpabbott
    Fri 28 Jan 2011 01:54:18 PM UTCstaccato123Attached File-=>Added octave_surf_bug_2.png, #22545
      Attached File-=>Added octave_surf_nan_bug.png, #22546
      Attached File-=>Added matlab_surf_nan_bug.png, #22547

    Back to the top


    Powered by Savane 3.1-cleanup1