On Tue, Aug 17, 2010 at 4:19 PM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote:
> 2010/8/17 Benjamin Root <ben.r...@ou.edu>: > > "...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. > > Okay, may be you're right and we should include the usecase you're > having in mind. > > > 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. > > Yes, that's neat. > > > 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)) > > Hmm, that's much more complicated ... For Collections, one could set a > local flag, but it would be nevertheless quite buried in the API ... > When setting it in the axes, one has to care about all artists added > later too, and all pathes an artist may sneak into the axes. > > I had a thought... and it is based on my admittedly incomplete understanding of matplotlib. Everything that gets drawn is derived from the artist class, right? So, what if there was a 'grey' boolean in that base class, and the .draw() function passes that bool down through all the subsequent .draw() calls of its child objects (it could be None by default to accept the parent's property, or allowed to be explicitly set by the user to override the parent's value.) By the time we get to the backends, all the color data should be in a clean, broadcasted rgba form, so it should then be a relatively simple check of the grey flag before writing out the color information. Admittedly, I would much rather have this flag check done before getting to the backends and through a single point of code. At first, I thought that ColorConverter would be it, but as I now understand it, it is treated more like a utility module rather than an important step in the rendering process. It gets used for things at different points in the matplotlib process. Maybe I am just going overboard here... > What I'm going to solve is simply a toplevel boolean 'gray' switch in > the rcParams. It's working in an abstract way. > > Maybe a complementary approach would be useful. A global switch for > everything, and more fine-tuning control coming from your side? > > I think the issue with my approach is that it would only impact things that uses colormaps. Anything that explicitly sets its colors without a colormap will be totally unaffected. > For the "road map", I cannot put myself under strong pressure with > this, I would say, although being a rather tiny thing, I will finish > it until end of next week. > > Can't wait to see what you have. > Ahh, and shall we name the switch 'gray' or 'grey' > > Heh, even matplotlib can't provide too much precedence here because it tries to cater to both spellings (and I keep flipping back and forth due to a stupid bug in the Ubuntu packaging that packaged a en_UK spell-checker instead of en_US, but my Fedora setup has it right...). I should note that for Colormaps, there is only a "is_gray" function. Cheers, Ben Root
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
