Re: [matplotlib-devel] Colormap that prints nicely in black and white
2010/8/11 Eric Firing : > 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 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. >> 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 > 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. > 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. I'll just hack my matplotlib now to do the LUMA XXX conversion now always, and will see what it does ... Friedrich -- 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
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On Wed, Aug 11, 2010 at 11:47 AM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > 2010/8/11 Eric Firing : > > 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
[matplotlib-devel] Fwd: Re: [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab
John et al., Is this a reasonable time to put out 1.0.1? There have been quite a few bugfixes and other cleanups since 1.0. Most likely the biggest problem with 1.0 is my error in the tk show(), which you tripped over, and which prompted the thread below. Eric Original Message Subject: Re: [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab Date: Wed, 11 Aug 2010 09:35:24 -0700 From: Christoph Gohlke To: matplotlib-us...@lists.sourceforge.net Ryan: you could try matplotlib-1.0.0.svn.win32-py2.6.exe from http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib .It was built this morning from svn. Christoph On 8/11/2010 7:26 AM, Ryan Krauss wrote: > 0.99.3 is more or less fine, but there is an annoying exception window > that pops up if you close IPython with a plot window open (using the > TkAgg backend). But in my mind this is less bothersome than having to > close all the plot windows every time I run a script (I tend to write > scripts that generate 5-10 plots at a minimum). > > If I could easily build an installer from svn, I would try it. I > don't have any microsoft compilers installed on my windows computers. > > Thanks again, > > Ryan > > On Wed, Aug 11, 2010 at 9:09 AM, Ryan Krauss wrote: >> Thanks. >> >> I need to role out a python install for my students. Classes start in >> a week and a half. What should I do? The installation for most of >> them needs to be fairly simple. >> >> Thanks, >> >> Ryan >> >> On Wed, Aug 11, 2010 at 2:25 AM, Eric Firing wrote: >>> On 08/10/2010 05:43 PM, Ryan Krauss wrote: I just upgraded my windows machine to matplotlib 1.0.0 and a simple script such as from pylab import * from scipy import * t = arange(0,1,0.01) y = sin(2*pi*t) figure(1) clf() plot(t,y) show() Now halts execution when run from the ipython -pylab prompt. The same commands typed at the commandline do not lead to show() halting execution. Is this expected behavior? >>> >>> This was fixed three weeks ago in svn, both the maintenance branch and >>> the trunk. I made some changes in show() shortly before 1.0, trying to >>> get uniform and reasonable behavior in all backends, and I didn't quite >>> succeed. I think I got it all straightened out--but only after the >>> release, unfortunately. I hope it won't be too long before a 1.0.1 >>> bugfix release can be made, but I am aware of no schedule. >>> >>> Eric >>> Thanks, Ryan -- 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
Re: [matplotlib-devel] Fwd: Re: [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab
FWIW, I responded to a thread on the IPython list where someone else was asking why show() was blocking execution on Windows 7. I think he was really experiencing the tk show() problem from mpl. So, I think this is causing issues with other users (in my opinion). Ryan On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing wrote: > John et al., > > Is this a reasonable time to put out 1.0.1? There have been quite a few > bugfixes and other cleanups since 1.0. Most likely the biggest problem > with 1.0 is my error in the tk show(), which you tripped over, and which > prompted the thread below. > > Eric > > Original Message > Subject: Re: [Matplotlib-users] show() blocks script execution for > TkAgg from ipython -pylab > Date: Wed, 11 Aug 2010 09:35:24 -0700 > From: Christoph Gohlke > To: matplotlib-us...@lists.sourceforge.net > > Ryan: you could try matplotlib-1.0.0.svn.win32-py2.6.exe from > http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib .It was built this > morning from svn. > > Christoph > > On 8/11/2010 7:26 AM, Ryan Krauss wrote: >> 0.99.3 is more or less fine, but there is an annoying exception window >> that pops up if you close IPython with a plot window open (using the >> TkAgg backend). But in my mind this is less bothersome than having to >> close all the plot windows every time I run a script (I tend to write >> scripts that generate 5-10 plots at a minimum). >> >> If I could easily build an installer from svn, I would try it. I >> don't have any microsoft compilers installed on my windows computers. >> >> Thanks again, >> >> Ryan >> >> On Wed, Aug 11, 2010 at 9:09 AM, Ryan Krauss wrote: >>> Thanks. >>> >>> I need to role out a python install for my students. Classes start in >>> a week and a half. What should I do? The installation for most of >>> them needs to be fairly simple. >>> >>> Thanks, >>> >>> Ryan >>> >>> On Wed, Aug 11, 2010 at 2:25 AM, Eric Firing wrote: On 08/10/2010 05:43 PM, Ryan Krauss wrote: > I just upgraded my windows machine to matplotlib 1.0.0 and a simple > script such as > > from pylab import * > from scipy import * > > t = arange(0,1,0.01) > y = sin(2*pi*t) > > figure(1) > clf() > plot(t,y) > > show() > > Now halts execution when run from the ipython -pylab prompt. The same > commands typed at the commandline do not lead to show() halting > execution. > > Is this expected behavior? This was fixed three weeks ago in svn, both the maintenance branch and the trunk. I made some changes in show() shortly before 1.0, trying to get uniform and reasonable behavior in all backends, and I didn't quite succeed. I think I got it all straightened out--but only after the release, unfortunately. I hope it won't be too long before a 1.0.1 bugfix release can be made, but I am aware of no schedule. Eric > > Thanks, > > Ryan > > > > -- > 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 > -- 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
Re: [matplotlib-devel] [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab
On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing wrote: > John et al., > > Is this a reasonable time to put out 1.0.1? There have been quite a few > bugfixes and other cleanups since 1.0. Most likely the biggest problem with > 1.0 is my error in the tk show(), which you tripped over, and which prompted > the thread below. I've been meaning to ask you the same thing :-). We probably need to have a go at the bug tracker before 1.0.1, but I am happy to do a bugfix release as soon as we are ready. Or perhaps we should be a little more aggressive on our numbering. Ie, bugfix releases could be 1.1.0 and 1.0.1, a micro release would be for installer fixes and the like. major numbers: significant new features, minor API breakage minor numbers: significant bugfixes and near guaranteed API compat micro: minor bugfixes, API compat I think 1.0 understates the maturity of the project so we may want to get to 2.0 in less than 10 years :-) JDH -- 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
Re: [matplotlib-devel] Colormap that prints nicely in black and white
http://www.youtube.com/watch?v=aa5eWT-J3v0 -- 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
Re: [matplotlib-devel] [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab
On Wed, Aug 11, 2010 at 1:27 PM, John Hunter wrote: > On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing wrote: > > John et al., > > > > Is this a reasonable time to put out 1.0.1? There have been quite a few > > bugfixes and other cleanups since 1.0. Most likely the biggest problem > with > > 1.0 is my error in the tk show(), which you tripped over, and which > prompted > > the thread below. > > I've been meaning to ask you the same thing :-). We probably need to > have a go at the bug tracker before 1.0.1, but I am happy to do a > bugfix release as soon as we are ready. > > Or perhaps we should be a little more aggressive on our numbering. > Ie, bugfix releases could be 1.1.0 and 1.0.1, a micro release would be > for installer fixes and the like. > > major numbers: significant new features, minor API breakage > minor numbers: significant bugfixes and near guaranteed API compat > micro: minor bugfixes, API compat > > I think 1.0 understates the maturity of the project so we may want to > get to 2.0 in less than 10 years :-) > > JDH > > Couldn't we just do what Google does and put a "Beta" label on everything? "Matplotlib Beta" Sounds almost like a planet or something... 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
Re: [matplotlib-devel] Colormap that prints nicely in black and white
Sorry, forgot source code (you cannot run it, though). Friedrich test.py Description: Binary data -- 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
Re: [matplotlib-devel] [Matplotlib-users] show() blocks script execution for TkAgg from ipython -pylab
On Wed, Aug 11, 2010 at 1:32 PM, Benjamin Root wrote: > Couldn't we just do what Google does and put a "Beta" label on everything? > > "Matplotlib Beta" > > Sounds almost like a planet or something... That used to be my attitude. Turns out there are a lot of legitimate users who cannot (due to company IT policy) or will not use software at 1.0 and below or in beta. It's a nice crutch for developers to say "hey it's in beta so don't count on us not pulling the API rug out from under you". We have historically been very cautious about breaking API, and the code is mature and stable, so the version number should reflect that in my view. JDH -- 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
[matplotlib-devel] purpose of 'stepfilled' in hist()?
I am tracing down a bug in hist() and I am trying to figure out what is it about the 'stepfilled' mode that is different from the regular 'bar' mode. Currently, the hist() code has a separate if branch for dealing with 'step' and 'stepfilled', and that branch has a bunch of bugs. The best that I can figure is that it prevents lines from being drawn in between the bins. If that is the only difference, maybe we could somehow use the bar functions? At the very least, I think this needs to be documented better to make it clear why this oddball approach is happening. Thanks, 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
Re: [matplotlib-devel] purpose of 'stepfilled' in hist()?
On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root wrote: > I am tracing down a bug in hist() and I am trying to figure out what is it > about the 'stepfilled' mode that is different from the regular 'bar' mode. > Currently, the hist() code has a separate if branch for dealing with 'step' > and 'stepfilled', and that branch has a bunch of bugs. The best that I can > figure is that it prevents lines from being drawn in between the bins. If > that is the only difference, maybe we could somehow use the bar functions? > > At the very least, I think this needs to be documented better to make it > clear why this oddball approach is happening. > > Thanks, > Ben Root > By the way, the bugs I was referring to both have to do with log=True and the two stepped modes. First, the smallest of values to histogram (the minimum bin value) is, for some reason, used to clip the lower bounds of the histogram count. In some situations, this can result in most if not all the graph not being shown. Second, related to the first is a problem with the 'stepfilled' mode in log space. The stepfilled mode uses the minimum bin value to anchor the patches. However, this can cause the polygon to not close correctly and can get some unsightly artifacts. I have attached an image demonstrating this bug. This has been reported before: http://old.nabble.com/hist%28%29-with-log-and-step-tp2742p2742.html http://old.nabble.com/Bug-in-stepfilled-hist-with-log-y-tp28538074p28538074.html In one of the comments, the reporter concluded that it appeared fixed, but either he was experiencing a slightly different problem, or he was mistaken. I have also included a possible patch for addressing these issues. The approach simply sets the minimum value to be zero when not doing log, and use 1.0 when log=True. This differs slightly from how the normal bar graphs are done where a value of 1e-100 is used when log=True, but then the axes limits are adjusted to use 1.0 as a lower limit. Cheers, Ben Root <> histlog.patch Description: Binary data -- 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
