bugGNU Octave - Bugs: bug #50511, colororder property seems to be...

 
 

bug #50511: colororder property seems to be reset on plot

Submitter:  Andrei Kramer <akramer>
Submitted:  Fri 10 Mar 2017 06:48:29 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Andrei Kramer Open/Closed:  * Closed
Release:  * 4.2.1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 12 Mar 2017 08:13:31 PM UTC, comment #9: 

Executing the test code from comment #3 in Matlab R2016a yields "plot command resets axes" with a blue line.

Since this is also the same behaviour as described by the original reporter and in other comments, closing report as invalid.

The slightly modified code from comment #0 that produces the output with the colororder as expected by the OR:

x=linspace(0,2*pi,n=64);
Y=[sin(x);cos(x);tan(x);cot(x)]';
figure(); clf;
hold on
CO=gray(4);
set(gca,'colororder',CO);
plot(x,Y,";;");
ylim([-1,1]);

current_CO=get(gca,"colororder");
if (size(current_CO)==size(CO))
  if (current_CO==CO)
    printf("colororder worked.\n");
  else
    warning("wrong colororder.\n");
  endif
else
  warning("set colororder did not work");
endif


Markus Mützel <mmuetzel>
Group administrator
Sun 12 Mar 2017 07:08:49 PM UTC, comment #8: 

Octave is designed to run Matlab scripts without modification.  The Mathworks has defined how the "ColorOrder" property is to be implemented.  You might not like their specification, but it is their language to do with as they please.  Unless Octave is incompatible, for example the test code from comment #3 produces a different result when run under Matlab, then I don't see a bug here.

Rik <rik5>
Group administrator
Sun 12 Mar 2017 06:35:17 PM UTC, comment #7: 

So, are you saying that it is alright that set(gca,"colororder",CO) never does anything unless the defaults are changed or the "NextPlot" property is set to "replacechildren", and only then?

So, you are ok with this


set(0,"defaultlinelinewidth",4);
plot([0,1],[1:4]'*[1,1],";;");
set(gca,'colororder',gray(4));
set(gca,'xtick',[0,1]);



get(gca,'colororder')
ans =

   0.00000   0.00000   0.00000
   0.33333   0.33333   0.33333
   0.66667   0.66667   0.66667
   1.00000   1.00000   1.00000


producing a plot with the default colororder (see attached picture). So, the get property gets the misleading gray() colororder, which doesn't reflect the actual graphic.

Note how set xtick worked as expected, but the colororder property did not. If this is the expected behaviour, then your expectation is incorrect. Some consistency should apply with these settings.

I will include an updated testcase and results.


(file #39979,

Andrei Kramer <akramer>
Fri 10 Mar 2017 11:06:49 PM UTC, comment #6: 

Check the documentation for colororder carefully.  It is doing what is documented.


ColorOrder
m-by-3 matrix of RGB values

Colors to use for multiline plots. ColorOrder is an m-by-3 matrix of RGB values that define the colors used by the plot and plot3 functions to color each line plotted. If you do not specify a line color with plot and plot3, these functions cycle through the ColorOrder to obtain the color for each line plotted. To obtain the current ColorOrder, which may be set during startup, get the property value:

get(gca,'ColorOrder')

Note that if the axes NextPlot property is set to replace (the default), high-level functions like plot reset the ColorOrder property before determining the colors to use. If you want MATLAB to use a ColorOrder that is different from the default, set NextPlot to replacechildren. You can also specify your own default ColorOrder.



Rik <rik5>
Group administrator
Fri 10 Mar 2017 08:33:09 PM UTC, comment #5: 

Setting:


set(0,'defaultAxesColorOrder',CO)


is a workaround.

But, it should also work without changing the defaults. So there is incorrect behaviour here. Either plot() then set() should do it or the other way around, neither does.

When you changed the status to "Works For Me" did you actually check the colour of the lines?

Andrei Kramer <akramer>
Fri 10 Mar 2017 08:21:22 PM UTC, comment #4: 

Well, I tried to change the order (before I posted this bug).
Plotting first, then changing the colororder property has no effect on the plot. Issuing a command like ylim(), that could potentially cause the plot to update, doesn't help with the colors.

But, setting the colororder after plot() will make my little if statement go to printing the "colororder worked." line.

The plot does not change however.

Update: I also tried it with octave 4.2.0 on Gentoo Linux, same problem in both cases. So, it doesn't seem to be my specific build.

So, in summary:
plot() then set(gca,'colororder',CO); does not change the plot.

@rik5: doesn't your test-code show that my proposed order is correct?
I see

set (hax, 'colororder', [1 0 0; 0 1 0; 0 0 1])
[...]
plot (1:10)

So, this property is supposed to be set before plotting.

And, besides, I think that it should work either way, ideally. But, I'd be content if one of the orders worked.

Andrei Kramer <akramer>
Fri 10 Mar 2017 07:55:31 PM UTC, comment #3: 

Are you sure this isn't the correct behavior?  See the equivalent ColorOrder property for Matlab at http://www.mathworks.com/help/matlab/ref/axes-properties.html.

The ColorOrder property belongs to the current axes.  If you issue a new plot command the old axes gets reset.  If you want a persistent colororder you can either use 'hold on' for an individual figure, or 'set (0, "DefaultAxesColorOrder", ...) to set a global default.

Test code for both Octave and Matlab:


close all
hax = gca
co1 = get (hax, 'colororder')
set (hax, 'colororder', [1 0 0; 0 1 0; 0 0 1])
co2 = get (hax, 'colororder')
plot (1:10)
co3 = get (hax, 'colororder')
if (isequal (co1, co3))
   disp ("plot command resets axes");
else
   disp ("plot command preserves axes");
end



Rik <rik5>
Group administrator
Fri 10 Mar 2017 07:10:48 PM UTC, comment #2: 

Oh wait.  This may be proper behavior.  I think "plot" resets almost everything and modifications have to come after the plot command.  Isn't that the standard concept?  Or maybe it doesn't apply for some features like color maps, don't know.  Or, there might be some global settings via the special plot handle 0.  Sometimes

set(0, ...)

does some magic stuff.

Dan Sebald <sebald>
Fri 10 Mar 2017 07:06:38 PM UTC, comment #1: 

If you are building from source, the easiest way to locate the pertinent code or script is to use "grep".  First, keep your build directory separate from the source tree (see "configure" etc.).  Then, go to root of the source tree and try:


sebald@moorglade ~/octave/octave/octave $ grep -is colororder */*
sebald@moorglade ~/octave/octave/octave $ grep -is colororder */*/*
sebald@moorglade ~/octave/octave/octave $ grep -is colororder */*/*/*


until something useful seems to appear.  Having done that here, it looks to me that none of the scripts (i.e., .m files) set colororder at a base level (there are plenty of demo scripts that call the "set('colororder')" command).  So it must be C++ code:


libinterp/corefcn/graphics.cc:default_colororder (void)
libinterp/corefcn/graphics.cc:  colororder.add_constraint (dim_vector (-1, 3));
libinterp/corefcn/graphics.cc:  colororder = default_colororder ();
libinterp/corefcn/graphics.cc:  colororderindex = 1.0;


Locating the source of the issue isn't a precise process.

Dan Sebald <sebald>
Fri 10 Mar 2017 06:48:29 PM UTC, original submission:  

ColorOrder

a set colororder property is reset when plot() is called.

It is a freshly compiled octave-4.2.1

Example


version
x=linspace(0,2*pi,n=64);
Y=[sin(x);cos(x);tan(x);cot(x)]';
figure(); #clf; cla;
CO=gray(4);
set(gca,'colororder',CO);
plot(x,Y,";;");
ylim([-1,1]);

current_CO=get(gca,"colororder");
if (size(current_CO)==size(CO))
  if (current_CO==CO)
    printf("colororder worked.\n");
  else
    warning("wrong colororder.\n");
  endif
else
  warning("set colororder did not work");
endif


produces the output:


ColorOrderTest
ans = 4.2.1
warning: set colororder did not work
warning: called from
    ColorOrderTest at line 19 column 3


and of course a plot with default colours.

Further Information

There was this bug [bug #39291](https://savannah.gnu.org/bugs/?func=detailitem&item_id=39291) for an older version and different OS, so it's probably a different thing.

where could I possibly begin to investigate why that is?

This is also happening in Ubuntu's build of Octave 4.0.3, so it is probably unrelated to the change of the default colors.

Andrei Kramer <akramer>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #39979:  ColorOrderTest2.m added by akramer (210B - text/x-objcsrc)
file #39980:  WrongColorOrder.png added by akramer (9KiB - image/png)
file #39967:  ColorOrderTest.m added by akramer (384B - text/x-objcsrc - test script, same as in submission)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by akramer (Submitted the item)
  •  

    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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-03-12 mmuetzel StatusWorks For Me Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2017-03-12 akramer Attached File- Added ColorOrderTest2.m, #39979
        Attached File- Added WrongColorOrder.png, #39980
    2017-03-10 rik5 StatusNone Works For Me
    2017-03-10 akramer Attached File- Added ColorOrderTest.m, #39967

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code