2010/8/11 Eric Firing <efiring@…706…29…>:
Why make a whole new class instead of switching a behavior in an existing
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
My thinking here is that I really don’t want to place unnecessary restrictions upon how a user uses a feature. Things should be a modular as possible (which is why I was looking more for a convenience function than anything else).
Why should we have to declare that a user will never need a B&W and color figure? Maybe a user wants to produce both B&W and color versions simultaneously? In my case in particular, it takes about 15 minutes to generate one of my publication-quality images, but only a couple of minutes to save it. It would be beneficial to me to save both b&w and color versions. Another possible use-case would be someone who wants to take a figure that might usually be colored but make a version of it in B&W with color annotations for highlighting purposes.
The point is that I would like to give the users fine-grained control over what they need, especially when the barrier to provide such control is virtually non-existent.
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.
That would be a nice feature, too. And it would also apply globally across all elements within the figure. I would not object to also having this feature in addition to the ability to control my colormaps.
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
I don’t follow you on this–I don’t understand at all.
Well, personally I have abandoned this possibility, but just for completeness:
def __init__(self, wrapped_colormap):
self._wrapped_colormap = wrapped_colormap
def __call__(self, value):
wrapped_colour = self._wrapped_colormap(value)
Interesting, but I still wonder if it is just better to have a function that returns a grey version of the colormap. Although, one could extend this idea (albeit probably not necessary) to include a variety of different colormap transformations (brighten, darken, invert, etc.).
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
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
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
But, the alpha information is important. The renderers need it. I am not seeing the rational for completely stripping it out. I can see a rational for being able to modify the alpha, but not for stripping it out.
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
Do we want to allow for users to specify their own LUMA conversion coefficients?
I’ll just hack my matplotlib now to do the LUMA XXX conversion now
always, and will see what it does …
On Wed, Aug 11, 2010 at 11:47 AM, Friedrich Romstedt <friedrichromstedt@…149…> wrote: