bugGNU Octave - Bugs: bug #34417, patch() does not process 'cdata'...

 
 

bug #34417: patch() does not process 'cdata' correctly

Submitter:  Rik <rik5>
Submitted:  Wed 28 Sep 2011 04:24:16 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  bpabbott
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 29 Aug 2013 11:49:12 PM UTC, comment #20: 

Re-visiting this bug report, I found that we got nearly everything right except for a typo in the input processing of 'agrs' instead of 'args'.  With that fix (http://hg.savannah.gnu.org/hgweb/octave/rev/1391dc953ae2) I'm closing this report.



Rik <rik5>
Group administrator
Fri 04 May 2012 05:19:15 PM UTC, comment #19: 

Arnaud, for help please use email.

help-octave Octave <help-octave@octave.org>

Ben Abbott <bpabbott>
Group Member
Fri 04 May 2012 05:15:17 PM UTC, comment #18: 

hello,

I get the same problem trying to convert some files using the patch function from matlab to octave :

"warning: "interp" not supported, using 1st entry of cdata"

Could you explain how to fix it ?

thanks

arnaud <arnaudnaud>
Fri 14 Oct 2011 10:44:22 PM UTC, comment #17: 

I found the problem (local to me). Now I get the same result as jwe.

I have a new example that works differently from ML.


x = [ 0 0; 1 1; 1 0 ];
y = [ 0 0; 0 1; 1 1 ];
c = zeros ([size(x),3]);
c(:,:,3) = 1;
h = patch (x, y, c);
facevertexcdata = get (h, 'facevertexcdata')


Matlab and Octave return the same facevertexcdata ...

facevertexcdata =
     0     0     1
     0     0     1
     0     0     1
     0     0     1
     0     0     1
     0     0     1


But gnuplot complains


multiplot> plot "-" binary format='%float64' record=3 using ($1):($2) title "" with filledcurve lc rgb "#000000" fillstyle transparent solid 0.000000lc rgb "#000080" fillstyle transparent solid 128.000000lc rgb "#800000" fillstyle transparent solid 0.000000lc rgb "#000000" fillstyle transparent solid 0.000000lc rgb "#000080" fillstyle transparent solid 128.000000lc rgb "#808080" fillstyle transparent solid 128.000000lc rgb "#000000" fillstyle transparent solid 1.000000 , "-" binary format='%float64' record=4 using ($1):($2) title "" with lines linewidth 0.500000 lt 1 lc rgb "#000000" , "-" binary format='%float64' record=3 using ($1):($2) title "" with filledcurve lc rgb "#000000" fillstyle transparent solid 0.000000lc rgb "#000080" fillstyle transparent solid 128.000000lc rgb "#800000" fillstyle transparent solid 0.000000lc rgb "#000000" fillstyle transparent solid 0.000000lc rgb "#000080" fillstyle transparent solid 128.000000lc rgb "#808080" fillstyle transparent solid 128.000000lc rgb "#000000" fillstyle transparent solid 1.000000 , "-" binary format='%float64' record=4 using ($1):($2) title "" with lines linewidth 0.500000 lt 1 lc rgb "#000000" ;
                                                                                                                                                                      ^
           line 0: duplicated or contradicting arguments in plot options


The FLTK backend produces the correct result.

Ben Abbott <bpabbott>
Group Member
Fri 14 Oct 2011 10:31:51 PM UTC, comment #16: 

John,

Before, I start digging deeper, those results were produced from the code below, correct?


x = [ 0 0; 1 1; 1 0 ];
y = [ 0 0; 0 1; 1 1 ];
h = patch (x, y, rand (size (x)));



Ben Abbott <bpabbott>
Group Member
Fri 14 Oct 2011 02:04:57 PM UTC, comment #15: 

With the current version of Octave on my system, and with fltk+opengl graphics, I see


xdata =

   0   0
   1   1
   1   0

octave:21> ydata = get (h, 'xdata')
ydata =

   0   0
   1   1
   1   0

octave:22> cdata = get (h, 'cdata')
cdata =

   0.71536   0.23336
   0.49571   0.26989
   0.57966   0.96610

octave:23> facevertexcdata = get (h, 'facevertexcdata')
facevertexcdata =

   0.71536
   0.23336
   0.49571
   0.26989
   0.57966
   0.96610


With gnuplot, I see


warning: "interp" not supported, using 1st entry of cdata
warning: "interp" not supported, using 1st entry of cdata
octave:4> xdata = get (h, 'xdata')
xdata =

   0   0
   1   1
   1   0

octave:5> ydata = get (h, 'xdata')
ydata =

   0   0
   1   1
   1   0

octave:6> cdata = get (h, 'cdata')
cdata =

   0.46766   0.70736
   0.27825   0.44173
   0.86237   0.72850

octave:7> facevertexcdata = get (h, 'facevertexcdata')
facevertexcdata =

   0.46766
   0.70736
   0.27825
   0.44173
   0.86237
   0.72850


John W. Eaton <jwe>
Group administrator
Thu 13 Oct 2011 11:56:06 PM UTC, comment #14: 

For the two patches in comment #12, the facevertexcdata is empty, for ML.

Same for Octave.

I ran the test below.


x = [ 0 0; 1 1; 1 0 ];
y = [ 0 0; 0 1; 1 1 ];
h = patch (x, y, rand (size (x)));
xdata = get (h, 'xdata')
ydata = get (h, 'xdata')
cdata = get (h, 'cdata')
facevertexcdata = get (h, 'facevertexcdata')


Matlab returned,


xdata =

     0     0
     1     1
     1     0

ydata =

     0     0
     1     1
     1     0

cdata =

    0.6096    0.4564
    0.5747    0.7138
    0.3260    0.8844

facevertexcdata =

    0.6096
    0.5747
    0.3260
    0.4564
    0.7138
    0.8844


Octave gives an error for me.


error: __patch__: A(I): index out of bounds; value 4 out of bound 3
error: called from:
error:   /Users/bpabbott/Development/mercurial/stable/scripts/plot/private/__patch__.m at line 79, column 7
error:   /Users/bpabbott/Development/mercurial/stable/scripts/plot/patch.m at line 50, column 20


Ben Abbott <bpabbott>
Group Member
Thu 13 Oct 2011 11:15:10 PM UTC, comment #13: 

What is the orientation of facevertexcdata in Matlab?

Does my change get the order of the elements right?  Maybe the transpose is not needed, just the (:)?

I was trying to fix a problem where x, y, and c are all matrices.  There was some size mismatch if I did not force facevertexcdata to be a column vector.  I thought that was how Matlab stores this property, but maybe I got the order of the elements wrong.

John W. Eaton <jwe>
Group administrator
Thu 13 Oct 2011 11:08:24 PM UTC, comment #12: 

Rik,

John just pushed a patch that looks to conflict with your original changeeset.

Yours ...

http://hg.savannah.gnu.org/hgweb/octave/rev/41c2f4633a62

John's ..

http://hg.savannah.gnu.org/hgweb/octave/rev/276bb0dd9d24

There have been other changes as well.

Presently, the code below does not produce the intended result.


figure (1)
clf
xdata = [2 2 0 2 5; 2 8 2 4 5; 8 8 2 4 8];
ydata = [4 4 4 2 0; 8 4 6 2 2; 4 0 4 0 0];
zdata = ones (3, 5);
patch (xdata, ydata, zdata, "b")
x = [ 0 0; 1 1; 1 0 ];
y = [ 0 0; 0 1; 1 1 ];
patch (x, y, "r");


Ben Abbott <bpabbott>
Group Member
Mon 10 Oct 2011 03:16:01 AM UTC, comment #11: 

Second patch works for me.

Rik <rik5>
Group administrator
Mon 10 Oct 2011 12:28:29 AM UTC, comment #10: 

I've attached my 2nd attempt.

Qualifier: Interpolating lines between vertices is not supported by the gnuplot bacekd (I didn't check the fltk backend).

(file #24123)

Ben Abbott <bpabbott>
Group Member
Sun 09 Oct 2011 03:00:23 PM UTC, comment #9: 

I got to this faster than I'd expected. Before pushing another reversion, does this look ok?

I'll do some more testting before I push.

(file #24122)

Ben Abbott <bpabbott>
Group Member
Sun 09 Oct 2011 02:35:17 PM UTC, comment #8: 

Thanks for catching this. I'll take a look later today.

Ben Abbott <bpabbott>
Group Member
Sun 09 Oct 2011 03:01:59 AM UTC, comment #7: 

Ben,
With your new patch in place (e9f6a6edec42) I went to try the list of test cases at http://www.mathworks.com/help/techdoc/ref/patch.html.

The first 'cdata' case no longer works.  It appears that zdata is being interpreted as cdata.


xdata = [2 2 0 2 5;
         2 8 2 4 5;
         8 8 2 4 8];
ydata = [4 4 4 2 0;
         8 4 6 2 2;
         4 0 4 0 0];
zdata = ones(3,5);
p = patch(xdata,ydata,zdata,'b')

error: patch: size of x, y, and c must be equal
error: called from:
error:   /home/rik/wip/Projects_Mine/octave-dev/scripts/plot/private/__patch__.m at line 139, column 15
error:   /home/rik/wip/Projects_Mine/octave-dev/scripts/plot/patch.m at line 50, column 20


Rik <rik5>
Group administrator
Mon 03 Oct 2011 03:04:41 AM UTC, comment #6: 

Yes.  The stable branch is essentially frozen.  Release Candidate 0 was put on the FTP site and I only know of one bug which may be incorporated into RC1.  Even though bug fixes would normally go on to stable I am putting them on to default as 3.6 will be the next release.

Rik <rik5>
Group administrator
Sun 02 Oct 2011 04:41:00 PM UTC, comment #5: 

Rik,

I've prepared a changeset for the remaining problems I found. While I was finishing it, I noticed you pushed this change to default (rather than to stable).

Was that done on purpose?

Ben Abbott <bpabbott>
Group Member
Fri 30 Sep 2011 04:00:53 PM UTC, comment #4: 

Ben,

No.  I needed to resolve the orientation of cdata issue so that I could close another bug.  Matlab documentation has extensive references for what should happen in every situation ((http://www.mathworks.com/help/techdoc/ref/patch.html).  I went through the examples last night and there are some failures with Octave when trying to do the most complex colorings such as having the edges one color and the facecolor something else or having gradients across the faces.  Results were better when using the 'faces','vertices' style of patch creation rather than x,y data but Octave is still imperfect in this regard.

If you like, you can hijack this bug and re-title it to something more specific.  Otherwise, you could close it and open up another bug report for your issue.

Rik <rik5>
Group administrator
Fri 30 Sep 2011 11:24:55 AM UTC, comment #3: 

Rik,

Do you plan to continue working on the patch() command?

Ben

Ben Abbott <bpabbott>
Group Member
Fri 30 Sep 2011 05:08:03 AM UTC, comment #2: 

I've gone ahead and applied the patch in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/41c2f4633a62).

Rik <rik5>
Group administrator
Fri 30 Sep 2011 01:03:52 AM UTC, comment #1: 

I ran the plot demos, and did not see any regressions. However, I tried using scalar colors in the way I've done with ML, and discovered they fail with and without your patch.


clf ()
x = [0 1 1 0];
y = [0 0 1 1];
subplot (2, 1, 1)
for n = 1:3
  patch (x + (n - 1), y, n * ones (size (x)));
end
title ('One scalar color per vertex')
subplot (2, 1, 2)
for n = 1:3
  patch (x + (n - 1), y, n);
end
title ('One scalar per patch')


Perhaps some new tests should be included when this is fixed?

Ben Abbott <bpabbott>
Group Member
Wed 28 Sep 2011 04:24:16 PM UTC, original submission:  

There are two ways of setting the color for patches.  The first method is to create the patch with 'faces' and 'vertices' and use 'facevertexcdata'.  This approach works.  The second method is to create the patch with x and y vertices and use 'cdata' to set the color.  This approach seems to fail.  Extensive reference on how to set the color of patch faces is given here (http://www.mathworks.com/help/techdoc/ref/patch.html).

Sample code for method 1 (Working)


verts = [ 0 0
          1 0
          1 1
          0 1];
faces = [ 1 2 3
          1 3 4];
p = patch ('faces', faces, 'vertices', verts, 'facecolor', 'b');
# Produces two opposed triangles both colored blue
set (p, 'cdatamapping', 'direct', 'facecolor', 'flat', 'facevertexcdata', [1 ; 32])
# Changes color of triangles to blue and green
get (p, 'facevertexcdata')
ans =

    1
   32
get (p, 'cdata')
ans =

    1   32


Sample code for method 2 (Not Working)


clf;
x = [ 0 0
      1 1
      1 0 ];

y = [ 0 0
      0 1
      1 1 ];
p = patch (x, y, 'facecolor', 'b');
set (p, 'cdatamapping', 'direct', 'facecolor', 'flat', 'cdata', [1 32])
error: invalid value for array property "facevertexcdata"
error: called from:
error:   /home/rik/wip/Projects_Mine/octave-dev/scripts/plot/private/__patch__.m at line 315, column 7
error:   /home/rik/wip/Projects_Mine/octave-dev/scripts/plot/private/__patch__.m at line 299, column 3

get (p, 'cdata')
ans =

    1   32

get (p, 'facevertexcdata')
ans = [](1x0)


My hunch is that cdata and facevertexcdata are supposed to be transposes of each other.  If one is a row vector the other needs to be a column vector.

The following change to _patch_.m at line 292 eliminates the error for me.


    #fvc = c(:).';
    fvc = c.';


I have attached a changeset which does just that.  If someone could verify that this doesn't mess up anything else I think it should be adopted.

Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #24123:  changeset.patch added by bpabbott (2KiB - application/octet-stream - 2nd attempt)
file #24122:  changeset.patch added by bpabbott (947B - application/octet-stream)
file #24033:  patch.cdata added by rik5 (763B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by arnaudnaud (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-29 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2011-10-10 bpabbott Attached File- Added changeset.patch, #24123
        Assigned toNone bpabbott
    2011-10-09 bpabbott Attached File- Added changeset.patch, #24122
    2011-09-28 rik5 Attached File- Added patch.cdata, #24033
        Carbon-Copy- Added kahacjde

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code