matplotlib-grayscale

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<friedrichromstedt@...149...>:

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

2011/10/22 Eric Firing <efiring@...229...>:

moved from matplotlib-users:

http://sourceforge.net/mailarchive/forum.php?thread_name=CAN06%3DCx2zgh8YrnF2WRaJ%3D0E8i3ROLdYW4VuurtqKrx3mdkeEg%40mail.gmail.com&forum_name=matplotlib-users

OK

2011/10/21 Friedrich Romstedt<friedrichromstedt@...149...>:
<snippet>
3) Providing a dedicated Filter class, that can be fed to
set_filter() instead of set_gray(). This I like best.
</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.

This is apparently a no-go. The backends are too tightly bound to the
C extensions moduled, e.g. aggdraw. E.g. the image drawing method of
the Agg backend is directly assigned in the fashion::

    self.draw_image = self._renderer.draw_image

So no, this will not work this way.

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.

So I'll touch it again. I will just check my refactor I did a year
ago on ColorConverter, which was pretty decent, but well, it needs
some check. I would first commit that to my repo, than people who are
interested can test, and then we can go on testing the higher level
functionality.

I think the filters will, instead of signalling colors.colorConveter
via rcParams that some conversion mode is turned on, signal that in
the decorator function simply directly to colors.colorConverter.
There are some open ends, though.

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.

:slight_smile: Apparently I found out the same thing a year ago.

The methodology will be like this: The Artists can store a stack of
filters, and also provide some easy-appetite-wetter .set_gray()
method. When their draw method is decorated with a special decorator,
say @filtered, then the filters will be activated upon entering and
deactivated upon exit. The activation happens via putting the filters
onto the filter stack in the ColorConverter instance. I'm pretty sure
this will work, somehow at least. :wink:

I've run into some strange Bus error compiling the latest matplotlib,
I'll drop another email on the user list probably (since I'm acting
here as a user, I just want to run the tests).

Friedrich

···

On 10/22/2011 09:31 AM, Friedrich Romstedt wrote: