Re: [matplotlib-devel] path unit_* methods: CLOSEPOLY?
On 08/14/2010 07:22 PM, Eric Firing wrote: > Mike, > > Is there any reason why the Path.unit_* methods shouldn't include the > codes, so that they can all have CLOSEPOLY? Or shouldn't they at > least have a kwarg to allow that as an option? In working on patch > drawing via bar(), I noticed that the rectangle outline is not closing > properly, with the same rounded join as at the other 3 corners. It > isn't apparent unless you set a large linewidth. > > Or is there a better way to ensure that polygons close correctly? I don't think there's a better way. The renderer can't assume CLOSEPOLY at the end, obviously, because it may in fact by a line and not a filled shape. I think this was left out just as shorthand (not having a codes array makes things a little faster, too), but I think for correctness the unit_* methods should have explicit codes arrays with CLOSEPOLYs. I'll go ahead and fix this. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
I'm currently working on a patch to enable the matplotlib feature shown in the video. Notice that it's pure matplotlib, no change of any plot parameters. Unfortunately, or better to say fortunately? I lost my changes by installing from svn, so I have to redo it, but this times it's less hacky I believe. I'm reworking colors.ColorConverter completely but backwards compatible. The second change applies to cm.ScalarMappable.to_rgba(), to use the colors.colorConverter for applying the rc gray setting. Then printing in grayscale will be possible for all features of matplolib going one of this routes to get their colors, which should be most. Do you know any more? To pursue on the ColorConverter class, it seems to me that this has evolved organically, merging class attributes with module attributes. Shouldn't this be fixed, by putting the class's methods into module space? Ben, I fully agree with you that figures should be able to be saved both coloured and grayscale. It was a misunderstanding. What I meant was, that it will not be necessary to display one part of the figure in colour and the other in grayscale at the same time. Friedrich 2010/8/11 Friedrich Romstedt : > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] path unit_* methods: CLOSEPOLY?
Michael Droettboom wrote: > On 08/14/2010 07:22 PM, Eric Firing wrote: > >> Mike, >> >> Is there any reason why the Path.unit_* methods shouldn't include the >> codes, so that they can all have CLOSEPOLY? Or shouldn't they at >> least have a kwarg to allow that as an option? In working on patch >> drawing via bar(), I noticed that the rectangle outline is not closing >> properly, with the same rounded join as at the other 3 corners. It >> isn't apparent unless you set a large linewidth. >> >> Or is there a better way to ensure that polygons close correctly? >> > > I don't think there's a better way. The renderer can't assume CLOSEPOLY > at the end, obviously, because it may in fact by a line and not a filled > shape. > > I think this was left out just as shorthand (not having a codes array > makes things a little faster, too), but I think for correctness the > unit_* methods should have explicit codes arrays with CLOSEPOLYs. I'll > go ahead and fix this. > > Mike > > Hi Mike, all the buildbots have errors with the matplotlib.tests.test_simplification.test_hatch test on r8639 that weren't there in r8635, and I think it's due to the code you committed. Could you have a look? (Don't worry about the doc build errors -- I think that's a bug with the recent Sphinx 1.0.2 release, for which I have filed a report at http://bitbucket.org/birkenfeld/sphinx/issue/501 for.) (I was proud of all the green on the buildbot -- hopefully it won't turn me into a chronic nag!) -Andrew -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On Mon, Aug 16, 2010 at 4:48 PM, Friedrich Romstedt < [email protected]> wrote: > Ben, I fully agree with you that figures should be able to be saved > both coloured and grayscale. It was a misunderstanding. What I meant > was, that it will not be necessary to display one part of the figure > in colour and the other in grayscale at the same time. > > Friedrich > > "...it will not be necessary..." I think we are still getting confused here. I was listing off several different kinds of use-cases where one would like to have a mix of grey colormaps and colored colormaps. The reason I mention being able to save a greyscale and a color version of the same figure is in the context of my approach to solving this problem (the swapping out of colormaps). Honestly, I think that your approach is better for dealing with that particular use case. However, I mention other cases where one is merely wanting a modified version of a particular colormap to use, be it greyscale, or inverse, or brighter/darker, etc. What I envision your solution to be solving would be something like this: fig = plt.figure() ax = fig.add_subplot(1, 2, 1) ax.plot(np.linspace(1, 10, 10), np.linspace(2, 8, 10)) ax.plot(np.linspace(1, 10, 10), np.linspace(4, 9, 10)) ax = fig.add_subplot(1, 2, 2) ax.set_grey(True) ax.plot(np.linspace(1, 10, 10), np.linspace(1, 8, 10)) ax.plot(np.linspace(1, 10, 10), np.linspace(3, 7, 10)) ax.plot(np.linspace(1, 10, 10), np.linspace(2, 9, 10)) plt.show() And see one in color and one as grey and the other as color. This would be a nice feature, but I would settle for it to be at the level of the entire figure. I think my approach is trying to solve a related, but different problem. My approach is trying to make colormaps more usable and flexible for the users. I would like to ensure that matplotlib does not artificially limit the ability of a user to fully utilize the variety of colormaps available to him. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
