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.
|
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?
|
Wed 24 May 2017 08:54:48 PM UTC, comment #19:
@Dan: Your patch appears to work for me.
|
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
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.
|
Wed 24 May 2017 02:23:20 AM UTC, comment #17:
Here's a diff that fixes the gnuplot issue:
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.
|
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:
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.
|
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.
|
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:
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
|
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
https://uk.mathworks.com/help/matlab/ref/colormap.html
> 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.
|
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:
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
Do the two plots have different color schemes? Or are they the same which means imshow just overwrites the figure level colormap property.
|
Tue 11 Oct 2016 04:01:13 PM UTC, comment #11:
Martin,
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)
|
Tue 11 Oct 2016 07:02:35 AM UTC, comment #10:
Markus,
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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]:
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
|
Tue 02 Aug 2016 01:53:26 AM UTC, comment #3:
Here's the current documentation regarding a handle used in the colormap function:
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.
|
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
|
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.
|
Mon 01 Aug 2016 07:07:19 AM UTC, original submission:
Try the following example:
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?
|