moved from matplotlib-users: http://sourceforge.net/mailarchive/forum.php?thread_name=CAN06%3DCx2zgh8YrnF2WRaJ%3D0E8i3ROLdYW4VuurtqKrx3mdkeEg%40mail.gmail.com&forum_name=matplotlib-users
On 10/22/2011 09:31 AM, Friedrich Romstedt wrote: > 2011/10/21 Friedrich Romstedt<friedrichromst...@gmail.com>: >> I will try to dig out that emails. > > Did that, the email I meant dates back to 10 November 2010! Here's the > snippet: > > <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. > > </snippet> > > 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 > responding. > > Friedrich Friedrich, 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. Eric ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
