moved from matplotlib-users:
On 10/22/2011 09:31 AM, Friedrich Romstedt wrote:
> 2011/10/21 Friedrich Romstedt<friedrichromstedt@...>:
>> I will try to dig out that emails.
> Did that, the email I meant dates back to 10 November 2010! Here's the snippet:
> (Ben Root):
>> I am curious, could this approach you have done be generalized to any sort
>> of color transformation? Admittedly, a gray mode is probably the most
>> common request, but what if someone wants a different transformation? Maybe
>> even apply a filter that would produce sepia colors, or high-contrast
>> colors, or a different grayscale transform? Heck, I could imagine a use
>> where a user might want to do a color substitution?
> Oh Yes, this is *ealily* possible. The new framework in the
> ColorConverter class just uses a filter function, if we want to see it
> like that, already. It's just the apply_rc_gray_setting() function or
> sth like that. If you want to, you can try to add the functionality.
> But we should discuss beforehand how to design it. There are several
> possibilites. In fact, I like this filter function quite a lot!
> 1) Hardcoding other filters in ColorConverter (what a decent name!),
> and switching them on or off
> 2) Inserting filters as functions on runtime into the ColorConverter
> instance, some hooking mechanism
> 3) Providing a dedicated Filter class, that can be fed to
> set_filter() instead of set_gray(). This I like best.
> I will, when i find some time, first implement the propagation of gray
> settings by allowing objects in set_gray(). Might be a good time to
> rename it to set_filter() right away, or maybe not do it, if
> set_gray() goes in, and expects a bool, it might break compat when
> changing the argument spec later. So later set_gray() would just call
> set_filter() or add_filter() or whatever.
> So the filter idea was Ben's idea. I still like idea (3) for the
> design best. I will check if it is possible to inject the filter code
> into the renderer framework, since all colour settings arguments
> somewhen flow into a call into the renderer. Pro: No rcParams
> addition necessary, no modification of the peculiar colors.py
> ColorConverter framework necessary, just leaving those things
> untouched and hence no worries and headaches about them. No disabling
> of higher-level caching and at the same time negligible small impact
> if there is no filter active. Con: I don't know yet if it works. I
> vaguely remember there were some problems when I checked that
> possibility last time (with pixmaps or something like that). I think
> I will find out soon enough.
> Eric, Ben, do you think we should go off-list with this now? I would
> prefer on-list now. There might be people following but not
The matplotlib-devel list is really the place for this, and I think that
it will be very helpful to move the discussion there. So, I am doing
that now by simply addressing this to matplotlib-devel and removing
-users from the address list.