2010/8/11 Eric Firing <efir...@hawaii.edu>:
> Why make a whole new class instead of switching a behavior in an existing
> class?
To my understanding, making object having "behaviours" is usually not
a good idea - I like different classes much more. I believe this is
just a matter of taste, both solutions will work.
But when you think about Ben's last problem with global effects, this
would not happen when using a different colormap instance.
Btw, I think it's undesired to mix colour and b/w in a figure. What
is the use-case? Making one figure in one paper at a time. As soon
as color is in, everything can be color. Maybe we should decide here
clearly by the best design proposal, and leave the use-case question
alone.
My thinking about moving it to the renderers is driven by the question
where the functionality belongs to. When we want to product b/w
plots, this has initially nothing to do with colormaps. It also
applies to lines, scatterplots, images, whatever one can imagine. So
I thought it may be a good idea to apply b/w to the rendered objects
in the end, i.e. LineCollections, QuadMeshs, and so on.
>> 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.
Well, personally I have abandoned this possibility, but just for completeness:
class GrayWrapper:
def __init__(self, wrapped_colormap):
self._wrapped_colormap = wrapped_colormap
def __call__(self, value):
wrapped_colour = self._wrapped_colormap(value)
...
return turned_into_gray
> 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".
See above. Here is an example for QuadMesh, it breaks down via
QuadMesh.set_facecolors(),
matplotlib.colors.colorConvert.to_rgba_array(),
ColorConverter.to_rgba(), ColorConverter.to_rgb() (note the missing
'a'), and there it's in principle:
>>> color = tuple(arg[:3])
or some other conversion to a 3-tuple
>>> return color
and just before we could do the rgb->pseudogray conversion
. So in my opinion this is the perfect place to do the color
conversion. I suppose all the other color conversions also break down
to ColorConverter.
> 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.
No it's not it's just complementary. What we want do here is the b/w
photography.
I'll just hack my matplotlib now to do the LUMA XXX conversion now
always, and will see what it does ...
Friedrich
------------------------------------------------------------------------------
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
