bugGNU Octave - Bugs: bug #48667, Colormap not controllable at the...


bug #48667: Colormap not controllable at the axes level with gnuplot

Submitted by:  Dan Sebald <sebald>
Submitted on:  Mon 01 Aug 2016 07:07:19 AM UTC  
Category:  Plotting with gnuplot Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

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)

Wed 31 May 2017 03:59:11 PM UTC, comment #21: 

I pushed Dan's patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/2fd1745398e3).  Closing report.

Rik <rik5>
Project Administrator
Fri 26 May 2017 03:41:38 PM UTC, comment #20: 

@Dan: Can I go ahead and push your fix for gnuplot and colormaps on axes?

Rik <rik5>
Project Administrator
Wed 24 May 2017 08:54:48 PM UTC, comment #19: 

@Dan: Your patch appears to work for me.

Rik <rik5>
Project Administrator
Wed 24 May 2017 08:45:04 PM UTC, comment #18: 

@Dan: Can you see if there isn't some cruft left in your build system?  Maybe try

make maintainer-clean

I ask, because the storage of graphic object properties is separate from their eventual display.  For me, I can assign colormaps and read them back even when the toolkit is gnuplot.

Rik <rik5>
Project Administrator
Wed 24 May 2017 02:23:20 AM UTC, comment #17: 

Here's a diff that fixes the gnuplot issue:

sebald@moorglade ~/octave/octave/octave/scripts/plot/util/private $ hg diff
diff --git a/scripts/plot/util/private/__gnuplot_draw_axes__.m b/scripts/plot/ut
--- a/scripts/plot/util/private/__gnuplot_draw_axes__.m
+++ b/scripts/plot/util/private/__gnuplot_draw_axes__.m
@@ -465,21 +465,12 @@ function __gnuplot_draw_axes__ (h, plot_

   if (rows (parent_figure_obj.colormap) != 2)
-    ## Second pass to change color map for binary images (not sure correct)
     kids1 = kids;
     while (! isempty (kids1))
       obj = get (kids1(end));
       kids1 = kids1(1:(end-1));

       switch (obj.type)
-        case {"image"}
-          if (isfield (obj, "cdata") && islogical (obj.cdata))
-            parent_figure_obj.colormap = [0 0 0; 1 1 1];
-            axis_obj.clim = [0 1];
-            axis_obj.climmode = "manual";
-            break;
-          endif
         case "hggroup"
           ## Push group children into the kid list.
           if (isempty (kids1))
@@ -491,7 +482,7 @@ function __gnuplot_draw_axes__ (h, plot_

-  cmap = parent_figure_obj.colormap;
+  cmap = axis_obj.colormap;
   cmap_sz = rows (cmap);
   addedcmap = [];

but let me think about this for a bit.  I've forgotten what all the logical cases and so on was about, but judging from the comment in the code I wondered if it made sense to handle logical data the way I did.

Dan Sebald <sebald>
Wed 24 May 2017 01:29:04 AM UTC, comment #16: 

I've downloaded the latest code and compiled.  I certainly prefer this behavior, as I'm sure many will like this.

There are a couple issues when I try the first set of commands in the original post:

1) In gnuplot graphics toolkit the color

>> get(gca, 'colormap')

ans =

   1   0   0
   0   1   0

is coming out as binary black and white rather than red-green.  That seems like something I need to fix in gnuplot script functions.  Should I open a new bug report for that, or just attach a patch file here?

2) When I switch to 'fltk' graphics toolkit, the GUI command line output freezes here:

>> graphics_toolkit ('fltk')
>> demo('image', 1);
image example 1:
colormap (jet (21));
img = 1 ./ hilb (11);
x = y = -5:5;
subplot (2,2,1);
  h = image (x, y, img);
  ylabel ("limits = [-5.5, 5.5]");
  title ("image (x, y, img)");
subplot (2,2,2);
  h = image (-x, y, img);
  title ("image (-x, y, img)");
subplot (2,2,3);
  h = image (x, -y, img);
  title ("image (x, -y, img)");
  ylabel ("limits = [-5.5, 5.5]");
subplot (2,2,4);
  h = image (-x, -y, img);
  title ("image (-x, -y, img)");

The window will still accept commands and I see a red/green binary image in the lower-right corner.  'exit' will exit properly as well.  It's just that the keystrokes don't appear in the window.

With the --no-gui option the command line output does not freeze.

Dan Sebald <sebald>
Tue 23 May 2017 08:38:07 PM UTC, comment #15: 

I applied the patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/7c278572db66).  Closing report.

Rik <rik5>
Project Administrator
Tue 23 May 2017 04:35:29 PM UTC, comment #14: 

The following is valid at least in Matlab R2016a. I don't know whether something has changed in newer versions.

The axes do not have a "colormap" property directly. However, with the function in [1], I found that there is a hidden "ColorSpace" property which in turn has a "Colormap" property:

>> cs = get(hax, 'ColorSpace');
>> get(cs)
                ALim: [0 1]
            ALimMode: 'auto'
        ALimWithInfs: [0 1]
    ALimWithInfsMode: 'auto'
            Alphamap: [1x64 double]
                CLim: [0 1]
            CLimMode: 'auto'
        CLimWithInfs: [0 1]
    CLimWithInfsMode: 'auto'
            Children: [0x0 GraphicsPlaceholder]
            Colormap: [64x3 double]
    HandleVisibility: 'off'
              Parent: [1x1 CartesianDataSpace]
             Visible: 'on'

This is very HG2 which Octave doesn't support.

Rik's example in comment #12 results in two identical subplots (both using colormap "winter"). However, I am still tempted to consider this a bug in Matlab (at the very least it is not what a user would expect).

Could the patch provided in comment #11 be considered anyway, given that we do not support HG2 (and probably won't in a long time).

[1] http://undocumentedmatlab.com/blog/getundoc-get-undocumented-object-properties

Markus Mützel <mmuetzel>
Project Member
Mon 22 May 2017 07:38:07 PM UTC, comment #13: 

Rik said:

> so someone will have to check whether "colormap" is now an axes property.

From Matlab documentation to colormap

> The figure colormap affects all axes in the figure, unless you set an axes colormap separately.

I think this is a pretty Matlab addition recently, they used to only support a single colormap per figure. This is the whole reason why subimage (from the image package) existed in the first place. I'm guessing this is also why subimage is now no longer recommended.

Carnë Draug <carandraug>
Project Member
Mon 22 May 2017 07:25:24 PM UTC, comment #12: 

Amazingly the patch still applies.  I can't tell from Matlab's documentation, so someone will have to check whether "colormap" is now an axes property.  Test code:

hax = axes ();
get (hax, 'colormap')

Also, I see why you changed imshow to adjust the colormap of the axes, but is that what Matlab does?  Further Matlab code for testing

x = round (63*rand (4,4) + 1);
subplot (2,1,1)
imshow (x, summer (64))
subplot (2,1,2)
imshow (x, winter (64))

Do the two plots have different color schemes?  Or are they the same which means imshow just overwrites the figure level colormap property.

Rik <rik5>
Project Administrator
Tue 11 Oct 2016 04:01:13 PM UTC, comment #11: 


Sorry, I must have forgotten to attach the patch. Here it is (refreshed to apply on the current default tip).
However, it includes changes to C++ files. Afaik, there is currently no way to compile Octave on Windows.

(file #38703)

Markus Mützel <mmuetzel>
Project Member
Tue 11 Oct 2016 07:02:35 AM UTC, comment #10: 


As far as I can see there is no patch attached. I would be happy to test it if it contains just m-files or can easily be compiled on Windows.

Martin Kunz <mkunz>
Thu 15 Sep 2016 05:04:45 PM UTC, comment #9: 

The attached patch adds a "colormap" property to "axes" objects. That property is only used to set and get the colormap for the axes. The actual colormap (if set) is stored in the hidden property "__colormap__". If the colormap is not set specificly (or is empty) in the axes, the one of its ancestor figure is returned.

I guess it would be quite easy to change existing code to always query the "colormap" from the axes. However, it is not so straight forward when it comes to decide whether the colormap of the axes or the one of the figure should be set with certain syntaxes.

To get the original example in comment #0 to produce the result that Dan (and I) expected, I changed "colormap" and "imshow" slightly to set the colormap in the axes.

This should definitely wait until after 4.2. But I am looking forward to receiving feedback anyway.

Markus Mützel <mmuetzel>
Project Member
Fri 12 Aug 2016 12:37:11 AM UTC, comment #8: 

This seems to be an awfully new addition to Matlab.  They may have added a property to the axes object to hold the colormap.  Rather than be a fast follower, I think we can wait a bit to implement this.

Rik <rik5>
Project Administrator
Tue 09 Aug 2016 02:48:43 PM UTC, comment #7: 

That's fine.  This one is going to take some time.  We know there should be a way to specify colormap individually per axes, but how isn't 100% clear.  Plus, what to do in those cases where a colormap is specified in some image/surface/patch function somewhere?

This isn't critical for version 4.2 either, so feel free to drop the priority.

Dan Sebald <sebald>
Tue 09 Aug 2016 01:11:08 PM UTC, comment #6: 

Sorry for the confusion I caused. But axes already store the "clim" and "climmode" properties.
I agree with you that adding a "colormap property" to axes is probably enough for most use cases. However, I won't be able to start work on a changeset for this until in two weeks. But with your last comment, I think I know what to do.

Markus Mützel <mmuetzel>
Project Member
Thu 04 Aug 2016 05:43:04 PM UTC, comment #5: 

[1] goes on to give an example of separate colormaps.  Odd that's all that is mentioned for this, isn't it?  [1] is tagged with R2016a, while [2] is 2012.  Perhaps it is so recent that documentation hasn't caught up.

To me, what would make sense is that axes also have colormap and clim, climmode, but perhaps have a further option "parent" which means that the info comes from the parent figure.

In any case, if there is some way of creating an object for the colormap and simply reuse that code whether the object is an axes or a figure, that would be nice.  I can change the _gnuplot_draw_axes_.m to look for the colormap first at the axes level and then at the figure level.

Should hggroup, patch, et al. get a colormap?  I don't know.  The reason is that multiple colormaps within an axes might just be confusing.  For each colormap there needs to be the ability to add an associated color box/bar on the plot.  It's conceivable to do such a thing by say, picking a color tone for the two different objects and modulating the intensity to correlate against the colorbox scale.  But at the same time, the user could just create two different subplots side by side to achieve that.  That is, what application is going to need both spatial dimensions and color dimension critical to displaying information?  I'd say, just axes for now, as that one seems obvious.  And if later some user finds a need for individual elements, reconsider.

Dan Sebald <sebald>
Thu 04 Aug 2016 04:52:11 PM UTC, comment #4: 

A "colormap" property could be added to axes, hggroup(?), patch, surface, and image objects which sets the aforementioned "__colormap__" property of the respective graphics object and gets the "__colormap__" property of the closest parent (starting from the object itself up to the parent figure). The same for "clim" and "climmode".

That would fit Matlab's current implementation for axes [1]:

Each axes within a figure can have a unique colormap. After you set an axes colormap, changing the figure colormap does not affect the axes.

It could also work more nicely for the other examples in [2] that only work with nasty workarounds in Matlab since each graphics object would be able to hold its own colormap (and clim and climmode). Additionally, it would still be transparent to the user in that she could query (and set) the colormap on an object level.

I could prepare a patch for the necessary changes in graphics.cc and graphics.in.h if this approach sounds good to you.

As far as I can see, there is no (documented and visible) property in the axes object which holds the colormap in Matlab.

[1] http://de.mathworks.com/help/matlab/ref/colormap.html#description
[2] https://de.mathworks.com/matlabcentral/answers/101346-how-do-i-use-multiple-colormaps-in-a-single-figure

Markus Mützel <mmuetzel>
Project Member
Tue 02 Aug 2016 01:53:26 AM UTC, comment #3: 

Here's the current documentation regarding a handle used in the colormap function:

     If the first argument HAX is an axes handle, then the colormap for
     the parent figure of HAX is queried or set.

That is the way that Octave behaves.  But the change would be that colormap now only applies to that axes.  (And one would think that, for example, passing the color map into the imshow function would behave similar to calling colormap(HAX, cmap) internally.)  The hidden property '__colormap__' approach would work, but the colormap data should be visible in some way.  The handle is passed into the function--is there a colormap object that shows up in the axes children list?  That might be another way of doing it, but such a scheme could end up with multiple colormaps attached to the axes, which doesn't make sense.

Dan Sebald <sebald>
Mon 01 Aug 2016 06:02:37 PM UTC, comment #2: 

In general, Matlab seems to be able to assign different colormaps to different axes of the same figure, see e.g. here [1].
This seems to have been introduced with Matlab R2014b [2].

Maybe, we could add a hidden property "__colormap__" to the axes that would be used if it is not empty and use the "colormap" property of the figure otherwise.
But that would probably mean that we would have to duplicate "clim" and "climmode" (and maybe other properties?) as well.

[1] http://de.mathworks.com/help/matlab/ref/colormap.html#budglf3-1
[2] https://de.mathworks.com/matlabcentral/answers/101346-how-do-i-use-multiple-colormaps-in-a-single-figure

Markus Mützel <mmuetzel>
Project Member
Mon 01 Aug 2016 08:06:17 AM UTC, comment #1: 

Matlab behaves the same as Octave in this case. However, I am inclined to consider this a bug in Matlab.

Markus Mützel <mmuetzel>
Project Member
Mon 01 Aug 2016 07:07:19 AM UTC, original submission:  

Try the following example:

demo('image', 1);
a = rand(10,10);
imshow(a > 0.5, [1,0,0;0,1,0]);

It doesn't seem logical that the colormap used in all subplots (i.e., different axes) should take on the same colormap as the most recently used colormap.

Well, that's the general issue, but more than that is a question of how imshow() should process the "MAP", i.e., the [1,0,0;0,1,0] in this case.  Does that MAP mean it should be used just for that image, or that the axes/figure should inherit that map as the color-map?

Dan Sebald <sebald>


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

Attach Files:

Attached Files


Depends on the following items: None found

   bug dependencies.


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

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

    Only project members can vote.




    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-31 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2017-05-24 rik5 StatusConfirmed => Patch Submitted
    2017-05-24 rik5 CategoryPlotting => Plotting with gnuplot
        StatusFixed => Confirmed
        Open/ClosedClosed => Open
        SummaryColormap not controllable at the axes level => Colormap not controllable at the axes level with gnuplot
    2017-05-23 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2017-05-22 rik5 Dependencies- => bugs #51082 is dependent
    2016-10-11 mmuetzel Attached File- => Added bug48667_axes_colormap.patch, #38703
    2016-08-12 rik5 Severity3 - Normal => 1 - Wish
        Item GroupIncorrect Result => Matlab Compatibility
        StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.5