On Tue, Aug 10, 2010 at 7:20 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 08/10/2010 11:58 AM, Friedrich Romstedt wrote: > > 2010/8/10 Eric Firing<efir...@hawaii.edu>: > >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote: > >>> So I think it is probably best to code it into the Colormap object > >>> itself, so that each and ever derived class can define its own method > >>> of how to create a greyscale version. What do you think about that? > >> > >> Good idea. The base class could define a default to_grayscale() method > >> that would do the conversion near the very end of the Colormap.__call__ > >> method if an as_gray attribute, also defined in the base class, is True. > >> No need for getters and setters--let it be a simple attribute. This > >> is much simpler than generating a whole new colormap--instead, just set > >> an attribute to switch an existing colormap to gray or back to color. I > >> would leave the switch out of the __init__ args and kwargs. > > > >> If someone > >> wants grey, they can add one more line of code to set the attribute. > > > > Hmm, one would have to do it for every colormap used. Also, it would > > be not so obvious if using the default colormap. > > > >> I > >> suspect only a small fraction of users will need this. > > > > I like this, it's a good idea enabling to not repeat all the stuff in > > the code. But hey, wouldn't it be the same to just overload the > > __call__ method? > > > > class GrayColorbar(RgbColorbar): > > """A colorbar returning grayscaled version.""" > > > > def __call__(self, value): > > """Transforms RgbColorbar's value into grayscale, and returns > it."""" > > > > rgb = BaseClass.__call__(self, value) > > [do stuff] > > return grayscale > > Why make a whole new class instead of switching a behavior in an > existing class? > > > > > Agreed, one has to this for all the classes, while your solution works > > generically in ColormapBase or whatever it's called. > > I think my solution (with slight modification) is also very compatible > with your suggestion below to have an rc param that switches between > color and gray. If as_gray is None, use the rc value; otherwise, let it > act as described above. > > The typical use case is when one wants color initially, but then must > regenerate plots in black and white to reduce publication costs. Your > rc suggestion facilitates such switching. > > > > > Another option would be, to wrap the Colormap into a thin layer with > > __call__, but this appears way too clumsy and too hacky to me. It's a > > clumsy way of deriving from the class. Otherwise it's maybe also > > nice, because it's generic, for all Colormaps. __getattr__ and > > __setattr__ (iirc) could be used to simulate the wrapped instance > > fully. > > I don't follow you on this--I don't understand at all. > > > > > > Is there some layer dealing with colors in the renderers, where the > > conversion could also happen? I'm asking because of displaying color > > images etc. and printing them as grayscale. With this, we would get > > rid of the alpha stuff completely, too. > > I don't understand why you would want to push this down into the > renderers instead of keeping it at a higher level. And I don't know > what you mean by "getting rid of the alpha stuff". > > > > > Maybe a general matplotlib.rc switch 'greyscale' would be possible. > > It would leave room for tons of improvement, e.g. automatically > > setting the color cycle to - -- -. etc., there was some monthes ago > > discussion about how to achieve that. Another advantage: It's zero > > loc if set in the config file ;-) > > Yes, there does seem to be a need for these sorts of switching > operations. Getting back to the colormap question, our discussions have > been based on the assumption that an rgb_to_gray function is all that is > needed. But is this true? Or will users actually need completely > different graymaps rather than something resembling a black-and-white > photo of a colormap? If so, then my suggested strategy is useless. > > Eric > > > > > I think that would be a real neat new feature. > > > > I agree what's not needed is mixed greyscale and colour display in the > > same Figure. > > > > Bear with me if my ideas are always too radical. > > > > Friedrich > > I have to agree with Eric on this. Maybe I am just not understanding Friedrich's thought process. If someone wants a specific greyscale colormapping, then they can make it themselves just like any other colormap. However, it is as a matter of convenience and ease to say "hey, I have this colormap that I have been using in my code, but I need its greyscale equivalent". My idea is this. It appears that all colormappings get a lookup table (self._lut) that contains rgba values. We could also simultaneously maintain a second lookup table (initialized only when needed). Therefore, one could take a colormap, switch on the greyscale attribute when desired (which would swap the two tables), and switch back over to the color-scale with the same amount of ease. It would be independent of any Colormap subclass because it would be in the base class. My only concern is when do the various drawing elements actually use the colormap info? If I create a b&w figure in one subplot, but also a colored figure in another subplot (for whatever reason) using the same colormap, would the figure show as expected at render-time? Thoughts, concerns, comments? 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
