On Wed, Aug 11, 2010 at 11:47 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote:
> 2010/8/11 Eric Firing <efir...@hawaii.edu>: > > Why make a whole new class instead of switching a behavior in an existing > > class? > > To my understanding, making object having "behaviours" is usually not > a good idea - I like different classes much more. I believe this is > just a matter of taste, both solutions will work. > > But when you think about Ben's last problem with global effects, this > would not happen when using a different colormap instance. > > Btw, I think it's undesired to mix colour and b/w in a figure. What > is the use-case? Making one figure in one paper at a time. As soon > as color is in, everything can be color. Maybe we should decide here > clearly by the best design proposal, and leave the use-case question > alone. > > My thinking here is that I really don't want to place unnecessary restrictions upon how a user uses a feature. Things should be a modular as possible (which is why I was looking more for a convenience function than anything else). Why should we have to declare that a user will never need a B&W and color figure? Maybe a user wants to produce both B&W and color versions simultaneously? In my case in particular, it takes about 15 minutes to generate one of my publication-quality images, but only a couple of minutes to save it. It would be beneficial to me to save both b&w and color versions. Another possible use-case would be someone who wants to take a figure that might usually be colored but make a version of it in B&W with color annotations for highlighting purposes. The point is that I would like to give the users fine-grained control over what they need, especially when the barrier to provide such control is virtually non-existent. > My thinking about moving it to the renderers is driven by the question > where the functionality belongs to. When we want to product b/w > plots, this has initially nothing to do with colormaps. It also > applies to lines, scatterplots, images, whatever one can imagine. So > I thought it may be a good idea to apply b/w to the rendered objects > in the end, i.e. LineCollections, QuadMeshs, and so on. > > That would be a nice feature, too. And it would also apply globally across all elements within the figure. I would not object to also having this feature in addition to the ability to control my colormaps. > >> Another option would be, to wrap the Colormap into a thin layer with > >> __call__, but this appears way too clumsy and too hacky to me. It's a > >> clumsy way of deriving from the class. Otherwise it's maybe also > >> nice, because it's generic, for all Colormaps. __getattr__ and > >> __setattr__ (iirc) could be used to simulate the wrapped instance > >> fully. > > > > I don't follow you on this--I don't understand at all. > > Well, personally I have abandoned this possibility, but just for > completeness: > > class GrayWrapper: > def __init__(self, wrapped_colormap): > self._wrapped_colormap = wrapped_colormap > > def __call__(self, value): > wrapped_colour = self._wrapped_colormap(value) > ... > return turned_into_gray > > Interesting, but I still wonder if it is just better to have a function that returns a grey version of the colormap. Although, one could extend this idea (albeit probably not necessary) to include a variety of different colormap transformations (brighten, darken, invert, etc.). > > I don't understand why you would want to push this down into the > renderers > > instead of keeping it at a higher level. And I don't know what you mean > by > > "getting rid of the alpha stuff". > > See above. Here is an example for QuadMesh, it breaks down via > QuadMesh.set_facecolors(), > matplotlib.colors.colorConvert.to_rgba_array(), > ColorConverter.to_rgba(), ColorConverter.to_rgb() (note the missing > 'a'), and there it's in principle: > > >>> color = tuple(arg[:3]) > or some other conversion to a 3-tuple > >>> return color > and just before we could do the rgb->pseudogray conversion > . So in my opinion this is the perfect place to do the color > conversion. I suppose all the other color conversions also break down > to ColorConverter. > > But, the alpha information is important. The renderers need it. I am not seeing the rational for completely stripping it out. I can see a rational for being able to modify the alpha, but not for stripping it out. > > Yes, there does seem to be a need for these sorts of switching > operations. > > Getting back to the colormap question, our discussions have been based > on > > the assumption that an rgb_to_gray function is all that is needed. But > is > > this true? Or will users actually need completely different graymaps > rather > > than something resembling a black-and-white photo of a colormap? If so, > > then my suggested strategy is useless. > > No it's not it's just complementary. What we want do here is the b/w > photography. > > Do we want to allow for users to specify their own LUMA conversion coefficients? > I'll just hack my matplotlib now to do the LUMA XXX conversion now > always, and will see what it does ... > > Friedrich > > Regards, Ben Root
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
