On Thursday, October 20, 2011, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2011/10/20 Eric Firing <efir...@hawaii.edu>:
>> Friedrich (or others),
>>
>> I hope you will consider the following to be constructive.
>
> I agree :-/  It was very very late in the night [5:30 a.m.], so things
> happen, but I think that's no kind of excuse for my rude tone in that
> email.  I'm sorry.
>
>> I understand one use case for a gray switch: sometimes one needs to make
>> gray versions of plots for formal publication, but one wants to have
>> nicer color versions for other purposes.
>
> Exactly, but I believe when we have the functionality the use cases
> will just start to emerge - like it always is.
>
> For instance, but this is just guessing, someone came up with the will
> to write out his figure in CMYK.  Others might want to turn black into
> white and vice versa, keeping other colours invariant.
>
>> What is the use case for grayscale support for parts of the Figure?  It
>> seems to me that this requires a much more complex and extensive set of
>> changes than a switch for the whole Figure.  Is it really worth it?
>
> I think yes.
>
> It is a bit of effort, yes.
>
>> You indicate that some caching will need to be eliminated.  Is this
>> correct?  If your branch causes a significant loss of speed in
>> displaying and interacting with large data sets, then I will oppose
>> merging it.  Speed matters for a significant fraction of mpl usage.
>
> Correct.  I think it is measurable, but only of O(2).  I believe this
> kind of fluctuation can be called noise :-)
>
> The tests cannot esily resolve this because they do everything once.
>
> And with a bit of work I might be able to keep the caching.
>
>> Improvements in mpl architecture that maintain or increase speed, and
>> that make it more comprehensible, maintainable, and capable, are
>> certainly welcome.  Color handling has grown organically, often
>> bedeviled by that pesky alpha, and I have no doubt that it could be
>> cleaned up and improved.
>
> I can capably only speak of colors.py and some conversion functions
> somewhere else.  I've noticed a rather small-grained approach.  I
> tried to unify things.
>
> But this you already said.
>
> cu,
> Friedrich
>

Friedrich,

Great to hear from you again!

I have been doing some thinking about this problem and how it could relate
to issues I have encountered in my work on mplot3d.  The key problem I
encounter there is that shading of the colors needs to be performed based on
perspective (rotation of the scene and such).

In many ways, this is a similar problem to wanting b&w versions of graphs.

The problem I have had in addressing this is that there are two primary ways
to specify color in mpl.  First, you can specify it directly with strings or
rgb(a) tuples.  Second, you can specify it through a ScalarMappable (eg,
colormap). This makes for two very different code paths to account for, and
it can often be difficult to detect which path is needed.

So, what if we unify everything under ScalarMappable?  The use case of
directly specifying the color could be envisioned as the color spec being
the data applied to an "identity colormap".

Then, we extend ScalarMappable such that a chain of transforms could be
performed on the rgba array.  I envision this to be very similar to how the
projections framework operates.  We can then have a set of stock transforms
that users could select at will (such as color to b&w).

We can use the lessons and successes of the projections framework to guide
our design here.

Thoughts?
Ben Root
------------------------------------------------------------------------------
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@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Reply via email to