matplotlib-devel Mailing List for matplotlib

On Mon, Aug 16, 2010 at 4:48 PM, Friedrich Romstedt <
fri...@gm...> wrote:
> Ben, I fully agree with you that figures should be able to be saved
> both coloured and grayscale. It was a misunderstanding. What I meant
> was, that it will not be necessary to display one part of the figure
> in colour and the other in grayscale at the same time.
>
> Friedrich
>
>
"...it will not be necessary..."
I think we are still getting confused here. I was listing off several
different kinds of use-cases where one would like to have a mix of grey
colormaps and colored colormaps. The reason I mention being able to save a
greyscale and a color version of the same figure is in the context of my
approach to solving this problem (the swapping out of colormaps). Honestly,
I think that your approach is better for dealing with that particular use
case.
However, I mention other cases where one is merely wanting a modified
version of a particular colormap to use, be it greyscale, or inverse, or
brighter/darker, etc. What I envision your solution to be solving would be
something like this:
fig = plt.figure()
ax = fig.add_subplot(1, 2, 1)
ax.plot(np.linspace(1, 10, 10), np.linspace(2, 8, 10))
ax.plot(np.linspace(1, 10, 10), np.linspace(4, 9, 10))
ax = fig.add_subplot(1, 2, 2)
ax.set_grey(True)
ax.plot(np.linspace(1, 10, 10), np.linspace(1, 8, 10))
ax.plot(np.linspace(1, 10, 10), np.linspace(3, 7, 10))
ax.plot(np.linspace(1, 10, 10), np.linspace(2, 9, 10))
plt.show()
And see one in color and one as grey and the other as color. This would be
a nice feature, but I would settle for it to be at the level of the entire
figure.
I think my approach is trying to solve a related, but different problem. My
approach is trying to make colormaps more usable and flexible for the
users. I would like to ensure that matplotlib does not artificially limit
the ability of a user to fully utilize the variety of colormaps available to
him.
Ben Root

Michael Droettboom wrote:
> On 08/14/2010 07:22 PM, Eric Firing wrote:
> 
>> Mike,
>>
>> Is there any reason why the Path.unit_* methods shouldn't include the 
>> codes, so that they can all have CLOSEPOLY? Or shouldn't they at 
>> least have a kwarg to allow that as an option? In working on patch 
>> drawing via bar(), I noticed that the rectangle outline is not closing 
>> properly, with the same rounded join as at the other 3 corners. It 
>> isn't apparent unless you set a large linewidth.
>>
>> Or is there a better way to ensure that polygons close correctly?
>> 
>
> I don't think there's a better way. The renderer can't assume CLOSEPOLY 
> at the end, obviously, because it may in fact by a line and not a filled 
> shape.
>
> I think this was left out just as shorthand (not having a codes array 
> makes things a little faster, too), but I think for correctness the 
> unit_* methods should have explicit codes arrays with CLOSEPOLYs. I'll 
> go ahead and fix this.
>
> Mike
>
> 
Hi Mike, all the buildbots have errors with the
matplotlib.tests.test_simplification.test_hatch test on r8639 that
weren't there in r8635, and I think it's due to the code you committed.
Could you have a look?
(Don't worry about the doc build errors -- I think that's a bug with the
recent Sphinx 1.0.2 release, for which I have filed a report at
http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)
(I was proud of all the green on the buildbot -- hopefully it won't turn
me into a chronic nag!)
-Andrew

I'm currently working on a patch to enable the matplotlib feature
shown in the video. Notice that it's pure matplotlib, no change of
any plot parameters. Unfortunately, or better to say fortunately? I
lost my changes by installing from svn, so I have to redo it, but this
times it's less hacky I believe. I'm reworking colors.ColorConverter
completely but backwards compatible.
The second change applies to cm.ScalarMappable.to_rgba(), to use the
colors.colorConverter for applying the rc gray setting.
Then printing in grayscale will be possible for all features of
matplolib going one of this routes to get their colors, which should
be most. Do you know any more?
To pursue on the ColorConverter class, it seems to me that this has
evolved organically, merging class attributes with module attributes.
Shouldn't this be fixed, by putting the class's methods into module
space?
Ben, I fully agree with you that figures should be able to be saved
both coloured and grayscale. It was a misunderstanding. What I meant
was, that it will not be necessary to display one part of the figure
in colour and the other in grayscale at the same time.
Friedrich
2010年8月11日 Friedrich Romstedt <fri...@gm...>:
> http://www.youtube.com/watch?v=aa5eWT-J3v0

On 08/14/2010 07:22 PM, Eric Firing wrote:
> Mike,
>
> Is there any reason why the Path.unit_* methods shouldn't include the 
> codes, so that they can all have CLOSEPOLY? Or shouldn't they at 
> least have a kwarg to allow that as an option? In working on patch 
> drawing via bar(), I noticed that the rectangle outline is not closing 
> properly, with the same rounded join as at the other 3 corners. It 
> isn't apparent unless you set a large linewidth.
>
> Or is there a better way to ensure that polygons close correctly?
I don't think there's a better way. The renderer can't assume CLOSEPOLY 
at the end, obviously, because it may in fact by a line and not a filled 
shape.
I think this was left out just as shorthand (not having a codes array 
makes things a little faster, too), but I think for correctness the 
unit_* methods should have explicit codes arrays with CLOSEPOLYs. I'll 
go ahead and fix this.
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA