2011/10/20 Benjamin Root <ben.r...@ou.edu>: > 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.
You are facing the OO design of Mpl. I believe they cannot be solved in mpl, only remedied partially. This is the reason why I don't want to get entangled with mpl. > 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". No, this would hinder further differentiation. You just gave the example: Shading. "Uniting", i.e. seeing everything as a ScalarMappable, would make it impossible without further "unification" to take two parameters into account: Height + Viewing angle. But the problem exists, as I said it stems from the Oo approach. > 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). Exactly. But this is a functional approach. Isn't it? > We can use the lessons and successes of the projections framework to guide > our design here. I strongly believe, although I don't know the projections framework, that is has functional ideas strongly expressed in the way it works. Is that true? I just had a walk and tapped in my thoughts into my notebook device while walking, this is some way of meditation. So here they come (The postscripta are now-thoughts): 1. There are two different ways of specifying a colour: Either a thing is simply red or you need something that spits out a colour when the specification is given. Uniting both under the spit-out-with-specification constraint hinders further differentiation. P.S.: In fact, it would be better if the "red" spits out a colour when called with *nothing*. But hey, this is functional. 2. In fact I believe the Oo approach does not work well for frame generation (and plotting is a frame generation). This is why I coded moviemaker using functional paradigm. It just didn't work out the Oo way - just because you needed a new class for each type of plotting directive; you have to pass everything through. The functional approach solved my headaches - Classes are too rigid for plotting. 3. I don't want to "pollute" my mind with the Oo ideas of mpl; rather I would like to learn to avoid the mistakes made here. 4. Your idea is a functional one. 5. In functional programming, each object (i.e. each function) has one entry point, in Python this is implemented by the __call__() method. - I can give further details but it doesn't matter here, since we're talking to give mpl grayscale and filter properties, right. I will try to dig out my old private ideas I sent you some monthes ago - I believe I already found the solution for our matter here. (i.e. avoiding rcParams and stuff.) I believe the one and only solution would, if thought thru completely, unveil that we need functional approach to get better results. In matplotlib, each type of structure is an object of a class, which is not callable mostly, and this means, you have to formulate each alteration explicitly. It's not easy in this frame of thinking to get the flexibility we in fact want - this might be the reason why mpl is so monolithic with all its different kind of Artist objects ... with the counterparts in the Renderer objects and so on. It's hard to keep a common style when differentiating things in plotting using the Oo approach. This is just what we see in fact. We feel that things are somehow united and should work better together and be more exchangable, but they aren't, because it has never been formulated in terms of code, of a common base class Function, as I would do it (and did it in moviemaker). Addendum: It has been attempted with the Artist class, with the .render() method. I cannot judge how well it worked out, but to my understanding, it didn't foster plug-in architecture much. ADD: I think this is because .render() happens on high-level, so it's not attractive for data-munging objects. The functional approach is attractive there. This can be understood as some advertisement for plotlayers, but believe me, I have coded not a single line of it so far. There exists moviemaker3, though, and that one works fine. What's missing are things like polygons and fast drawing routines for scaled pixmaps. I'll not go into details here. For me it's hard to stay focussed on mpl here. I will try to dig out that emails. Friedrich ------------------------------------------------------------------------------ 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
