[matplotlib-devel] Transparent backgrounds for savefig
Hi all, I'm generating plots for a document with a non-white background, and I need the outer rectangle (the one is normally gray on the screen) to be transparent. Savefig doesn't seem to have such an option: is it possible to do it already, and if not, would there be any interest in a patch? Regards Stéfan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
Something similar was added to SVN yesterday. Pass "transparent=True" to savefig. This will set both the figure rectangle and the axes rectangles to transparent. If you just want a transparent figure rectangle, you can do: fig().figurePatch.set_alpha(0.0) Maybe this should be made an option on the "transparent" kwarg to savefig, something like: transparent = 'figure' | 'figure_and_axes' Or is that just making things too complicated? Cheers, Mike Stéfan van der Walt wrote: > Hi all, > > I'm generating plots for a document with a non-white background, and I > need the outer rectangle (the one is normally gray on the screen) to > be transparent. Savefig doesn't seem to have such an option: is it > possible to do it already, and if not, would there be any interest in > a patch? > > Regards > Stéfan > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Strange moray patterns with pcolor
Rob Hetland wrote: > > When I do a pcolor, there are white lines between the patches that > cause strange moray patterns, even when saved to a png. The attached > sample shows what I mean. Notice the strange coffee-cup ring, where > the pattern goes away. This is new behavior. Unfortunately, I > haven't been paying enough attention to the devel list to know what > the changes that cause this might be. The quads need to be enlarged by about 1 pixel, and the easiest way to do this is to give them an edge of width 1 pixel. The pcolormesh code has had this fix for a while, but it was overlooked for pcolor. (Both of which were virtually rewritten for 0.98, which is why this is a regression from 0.91). I have fixed this in SVN. > > This moray pattern is very distracting, and means that publication > quality prints will be very difficult to produce, probably involving > printing at some insanely high resolution, then decimating with > imagemagick. Yeah, let's try to avoid that... ;) > > I notice also that pcolormesh works with masked arrays (hurray!). > This could be a suitable substitution. However, pcolormesh does not > dither at the patch edges, so that there are jagged lines through the > image, especially at lower resolutions. I assume by dithering you mean antialiasing. For speed, pcolormesh uses non-antialiased rendering by default. You can force it to be antialiased by passing "antialiased=True". Cheers, Mike > > Can pcolor be fixed? > > -Rob > > > > > > > > > Rob Hetland, Associate Professor > Dept. of Oceanography, Texas A&M University > http://pong.tamu.edu/~rob > phone: 979-458-0096, fax: 979-845-6331 > > > > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > > > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
2008/6/25 Michael Droettboom <[EMAIL PROTECTED]>: > Maybe this should be made an option on the "transparent" kwarg to savefig, > something like: > > transparent = 'figure' | 'figure_and_axes' > > Or is that just making things too complicated? Those options would both be very handy. In the meantime, thanks for the workaround! My hack was to export to SVG, then edit with Inkscape (first compiled Inkscape for OSX :), save to PNG and finally convert the PNG to a PNG that Firefox can understand, using GIMP (also compiled for OSX). Phew! Regarding OSX: it seems that, for the first time in months, I can now build matplotlib on OSX with gcc 4.1 without jumping through all sorts of crazy loops. Thanks! Regards Stéfan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
On Wed, Jun 25, 2008 at 8:25 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > 2008/6/25 Michael Droettboom <[EMAIL PROTECTED]>: >> Maybe this should be made an option on the "transparent" kwarg to savefig, >> something like: >> >> transparent = 'figure' | 'figure_and_axes' >> >> Or is that just making things too complicated? > > Those options would both be very handy. Stefan -- just for a little background. The figure has a matplotlib.patches.Rectangle instance called "figurePatch" and the axes has a Rectangle instance called axesPatch. You can set any property on them directly (facecolor, edgecolor, linewidth, linestyle, alpha). Eg, fig = plt.figure() fig.figurePatch.set_alpha(0.5) ax = fig.add_subplot(111) ax.axesPatch.set_alpha(0.5) Michael's transparent kwarg is just a helper function to do this automatically at save time w/o affecting the screen rendered figure. For stylistic reasons, I'd like a new name for figurePatch and rectanglePatch. "background", "rectangle" and "patch" would all be nicer. I'm inclined toward "rectangle" -- I think I'll just put an alias in Figure and Axes unless someone has a better idea. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
"rectangle" might be a bad name for "axesPatch" since it can be a circle for polar plots, and ellipse for geo plots etc. Cheers, Mike John Hunter wrote: > On Wed, Jun 25, 2008 at 8:25 AM, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: > >> 2008/6/25 Michael Droettboom <[EMAIL PROTECTED]>: >> >>> Maybe this should be made an option on the "transparent" kwarg to savefig, >>> something like: >>> >>> transparent = 'figure' | 'figure_and_axes' >>> >>> Or is that just making things too complicated? >>> >> Those options would both be very handy. >> > > Stefan -- just for a little background. The figure has a > matplotlib.patches.Rectangle instance called "figurePatch" and the > axes has a Rectangle instance called axesPatch. You can set any > property on them directly (facecolor, edgecolor, linewidth, linestyle, > alpha). Eg, > > fig = plt.figure() > fig.figurePatch.set_alpha(0.5) > ax = fig.add_subplot(111) > ax.axesPatch.set_alpha(0.5) > > Michael's transparent kwarg is just a helper function to do this > automatically at save time w/o affecting the screen rendered figure. > For stylistic reasons, I'd like a new name for figurePatch and > rectanglePatch. "background", "rectangle" and "patch" would all be > nicer. I'm inclined toward "rectangle" -- I think I'll just put an > alias in Figure and Axes unless someone has a better idea. > > JDH > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > "rectangle" might be a bad name for "axesPatch" since it can be a circle for > polar plots, and ellipse for geo plots etc. Ahh yes, mind still mushy even after a good night's sleep. "patch" or "background" I feel about the same. "patch" isn't terribly mnemonic unless you are a matlab user, but at least it points you to the base class and is most consistent with the current name, in which the "figure" part of "figurePatch" is simply redundant. patch, going once, going twice,... JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
On Wed, Jun 25, 2008 at 9:23 AM, John Hunter <[EMAIL PROTECTED]> wrote: > On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> "rectangle" might be a bad name for "axesPatch" since it can be a circle for >> polar plots, and ellipse for geo plots etc. > > Ahh yes, mind still mushy even after a good night's sleep. "patch" or > "background" I feel about the same. "patch" isn't terribly mnemonic > unless you are a matlab user, but at least it points you to the base > class and is most consistent with the current name, in which the > "figure" part of "figurePatch" is simply redundant. I was just confused by the method "get_axes_patch" which looks like an accessor method for the axesPatch, but instead is the method that generates a new rectangle (or circle or whatever). To add to the confusion, there is the method get_frame, which returns the axesPatch even though there is also an axesFrame (which was created by get_axes_patch). Is you head spinning like mine? How about: _generate_axes_patch to replace get_axes_patch - internal class use only get_frame and get_patch deprecated - just use "patch" and "frame", formerly "axesPatch" and "axesFrame". We'll add a deprecation warning to get_frame and keep axesPatch and axesFrame around as aliases. Michael -- IIRC you added the axesFrame. Was this to support to separate drawing of the edge and face since our patches don't (currently) have support for separate alpha channels for edge and face. Or are there additional motivations for the projection backends? JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
John Hunter wrote: > On Wed, Jun 25, 2008 at 9:23 AM, John Hunter <[EMAIL PROTECTED]> wrote: > >> On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <[EMAIL PROTECTED]> >> wrote: >> >>> "rectangle" might be a bad name for "axesPatch" since it can be a circle for >>> polar plots, and ellipse for geo plots etc. >>> >> Ahh yes, mind still mushy even after a good night's sleep. "patch" or >> "background" I feel about the same. "patch" isn't terribly mnemonic >> unless you are a matlab user, but at least it points you to the base >> class and is most consistent with the current name, in which the >> "figure" part of "figurePatch" is simply redundant. >> > > I was just confused by the method "get_axes_patch" which looks like an > accessor method for the axesPatch, but instead is the method that > generates a new rectangle (or circle or whatever). To add to the > confusion, there is the method get_frame, which returns the axesPatch > even though there is also an axesFrame (which was created by > get_axes_patch). Is you head spinning like mine? > Yes, I saw that when I added the transparent kwarg and was also confused, but thought best to leave it at the time... ;) > How about: > >_generate_axes_patch to replace get_axes_patch - internal class use only > >get_frame and get_patch deprecated - just use "patch" and "frame", > formerly "axesPatch" and "axesFrame". We'll add a deprecation warning > to get_frame and keep axesPatch and axesFrame around as aliases. > > Michael -- IIRC you added the axesFrame. Was this to support to > separate drawing of the edge and face since our patches don't > (currently) have support for separate alpha channels for edge and > face. Or are there additional motivations for the projection > backends? It was so that the zorder could be something like: axesPatch ... data ... ... grids ... axesFrame It prevents data from overlapping the axes frame. This was most crucial in the PDF and Cairo backends where the clipping rectangle is pixel-aligned but the axes frame and background are not necessarily. In the Agg backend, where we have more fine control, it actually doesn't really matter. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transparent backgrounds for savefig
Michael Droettboom wrote: >>get_frame and get_patch deprecated - just use "patch" and "frame", >> formerly "axesPatch" and "axesFrame". We'll add a deprecation warning >> to get_frame and keep axesPatch and axesFrame around as aliases. >> >> Michael -- IIRC you added the axesFrame. Was this to support to >> separate drawing of the edge and face since our patches don't >> (currently) have support for separate alpha channels for edge and >> face. Or are there additional motivations for the projection >> backends? I did it two years ago, r2415. > It was so that the zorder could be something like: > >axesPatch >... data ... >... grids ... >axesFrame > This was the main motivation, but the secondary thought was that it would facilitate doing something that people ask for now and then, which is allow one to specify only some axes boundaries instead of the whole rectangle. A common plot style is to have axes lines on the left and bottom, for example; but sometimes people want only a line on the bottom, and I am sure that sooner or later someone will want top and right, or top and bottom, or whatever. Obviously, I never got around to putting that option in place. > It prevents data from overlapping the axes frame. This was most crucial > in the PDF and Cairo backends where the clipping rectangle is > pixel-aligned but the axes frame and background are not necessarily. In > the Agg backend, where we have more fine control, it actually doesn't > really matter. No, I think it matters on all backends, especially if the frame is thick. Whether the zorder above is what one wants may be a matter of taste, but on any backend it will make a difference in the way the plot looks. Eric > > Cheers, > Mike > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Strange moray patterns with pcolor
Michael Droettboom wrote:
Rob Hetland wrote:
When I do a pcolor, there are white lines between the patches that
cause strange moray patterns, even when saved to a png. The attached
sample shows what I mean. Notice the strange coffee-cup ring, where
the pattern goes away. This is new behavior. Unfortunately, I
haven't been paying enough attention to the devel list to know what
the changes that cause this might be.
The quads need to be enlarged by about 1 pixel, and the easiest way to
do this is to give them an edge of width 1 pixel. The pcolormesh code
has had this fix for a while, but it was overlooked for pcolor. (Both
of which were virtually rewritten for 0.98, which is why this is a
regression from 0.91).
I have fixed this in SVN.
Mike,
Not exactly. This is a very old problem and an old attempted solution.
I struggled with it a long time ago, and among the various
combinations of backends and antialiasing settings, I never found a
completely satisfactory solution. I don't know what the best solution
will be, but a linewidth of 1 point is definitely not it. It is
fundamentally wrong--expanding the patch dimensions by 1/144 inch, so
that they overlap--and consequently creates its own artifacts. If you
run the attached script and look at the ps output, you will see
artifacts in the rectangle corners, and some of the tick marks will be
more misplaced than they used to be relative to the rectangle boundaries.
I'm sorry I don't have a good solution right now and can't look at it in
detail immediately, and I don't mean to dump more work on you. Let's
just consider the issue as open for discussion and investigation. I can
try to get back to it later.
(It is conceivable that a thinner linewidth will be an adequate
compromise--still a hack, but maybe acceptable--although the last time I
worked on this problem, long before 0.98, I could not get it to work
well under all circumstances.)
Eric
import numpy as np
import matplotlib.pyplot as plt
z = np.random.rand(30,50)
plt.pcolor(z)
plt.colorbar()
plt.savefig('pcalias1.ps')
plt.savefig('pcalias1.png')
plt.savefig('pcalias1.pdf')
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Strange moray patterns with pcolor
Ok -- sorry about that. It looked pretty good on the quadmesh_demo example, but I suppose that's just by accident due to the nature of the data. By this assessment, we should probably back out this hack in pcolormesh as well. Curiously, though, Rob says this is new behavior... Cheers, Mike Eric Firing wrote: > Michael Droettboom wrote: >> Rob Hetland wrote: >>> When I do a pcolor, there are white lines between the patches that >>> cause strange moray patterns, even when saved to a png. The >>> attached sample shows what I mean. Notice the strange coffee-cup >>> ring, where the pattern goes away. This is new behavior. >>> Unfortunately, I haven't been paying enough attention to the devel >>> list to know what the changes that cause this might be. >> The quads need to be enlarged by about 1 pixel, and the easiest way >> to do this is to give them an edge of width 1 pixel. The pcolormesh >> code has had this fix for a while, but it was overlooked for pcolor. >> (Both of which were virtually rewritten for 0.98, which is why this >> is a regression from 0.91). >> >> I have fixed this in SVN. > > Mike, > > Not exactly. This is a very old problem and an old attempted > solution. I struggled with it a long time ago, and among the various > combinations of backends and antialiasing settings, I never found a > completely satisfactory solution. I don't know what the best solution > will be, but a linewidth of 1 point is definitely not it. It is > fundamentally wrong--expanding the patch dimensions by 1/144 inch, so > that they overlap--and consequently creates its own artifacts. If you > run the attached script and look at the ps output, you will see > artifacts in the rectangle corners, and some of the tick marks will be > more misplaced than they used to be relative to the rectangle boundaries. > > I'm sorry I don't have a good solution right now and can't look at it > in detail immediately, and I don't mean to dump more work on you. > Let's just consider the issue as open for discussion and > investigation. I can try to get back to it later. > > (It is conceivable that a thinner linewidth will be an adequate > compromise--still a hack, but maybe acceptable--although the last time > I worked on this problem, long before 0.98, I could not get it to work > well under all circumstances.) > > Eric -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Strange moray patterns with pcolor
Ahh -- 0.91 avoided this by using non-antialiased rendering by default for pcolor as well as pcolormesh. That's probably what Rob is seeing when he went from 0.91 to 0.98. Of course, non-antialiased rendering has its own quality limitations, and it only applies to the bitmap backends. The moire pattern still appears in (for example) a pdf viewed with Acrobat Reader without the edge workaround. Eric -- maybe we should experiment with different values for the edge width to find a good compromise. Also, it might be good to add a regression test example where the edge workaround introduces noticeable negative artifacts. quadmesh_demo.py (with its built-in smoothness) doesn't really highlight the problems with that approach. Cheers, Mike Michael Droettboom wrote: > Ok -- sorry about that. It looked pretty good on the quadmesh_demo > example, but I suppose that's just by accident due to the nature of the > data. By this assessment, we should probably back out this hack in > pcolormesh as well. > > Curiously, though, Rob says this is new behavior... > > Cheers, > Mike > > Eric Firing wrote: > >> Michael Droettboom wrote: >> >>> Rob Hetland wrote: >>> When I do a pcolor, there are white lines between the patches that cause strange moray patterns, even when saved to a png. The attached sample shows what I mean. Notice the strange coffee-cup ring, where the pattern goes away. This is new behavior. Unfortunately, I haven't been paying enough attention to the devel list to know what the changes that cause this might be. >>> The quads need to be enlarged by about 1 pixel, and the easiest way >>> to do this is to give them an edge of width 1 pixel. The pcolormesh >>> code has had this fix for a while, but it was overlooked for pcolor. >>> (Both of which were virtually rewritten for 0.98, which is why this >>> is a regression from 0.91). >>> >>> I have fixed this in SVN. >>> >> Mike, >> >> Not exactly. This is a very old problem and an old attempted >> solution. I struggled with it a long time ago, and among the various >> combinations of backends and antialiasing settings, I never found a >> completely satisfactory solution. I don't know what the best solution >> will be, but a linewidth of 1 point is definitely not it. It is >> fundamentally wrong--expanding the patch dimensions by 1/144 inch, so >> that they overlap--and consequently creates its own artifacts. If you >> run the attached script and look at the ps output, you will see >> artifacts in the rectangle corners, and some of the tick marks will be >> more misplaced than they used to be relative to the rectangle boundaries. >> >> I'm sorry I don't have a good solution right now and can't look at it >> in detail immediately, and I don't mean to dump more work on you. >> Let's just consider the issue as open for discussion and >> investigation. I can try to get back to it later. >> >> (It is conceivable that a thinner linewidth will be an adequate >> compromise--still a hack, but maybe acceptable--although the last time >> I worked on this problem, long before 0.98, I could not get it to work >> well under all circumstances.) >> >> Eric >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Strange moray patterns with pcolor
Michael Droettboom wrote: > Ahh -- 0.91 avoided this by using non-antialiased rendering by default > for pcolor as well as pcolormesh. That's probably what Rob is seeing > when he went from 0.91 to 0.98. I suspected that. > > Of course, non-antialiased rendering has its own quality limitations, > and it only applies to the bitmap backends. The moire pattern still > appears in (for example) a pdf viewed with Acrobat Reader without the > edge workaround. True. Still, it might be that turning off antialiasing is part of the best compromise for some backends. We weren't getting complaints with 0.91, as far as I recall. There may be speed considerations here also. > > Eric -- maybe we should experiment with different values for the edge > width to find a good compromise. Also, it might be good to add a Yes, this is worth some more experimentation. A problem is that the edge width is specified in points, and the effect of this will depend on backend and scaling. If it turns out that there is an optimal value for each backend then we could pass in a special value for this case, say -1, which would be intercepted by the backend and converted to whatever works for that backend. As you note, the problem is made even more complex by the fact that different programs may render the vector graphics (pdf, ps, svg) differently. Someone must have already sorted all this out for some software project, somewhere. Does cairo handle it better? I have not looked yet. > regression test example where the edge workaround introduces noticeable > negative artifacts. quadmesh_demo.py (with its built-in smoothness) > doesn't really highlight the problems with that approach. Yes, a really good set of test cases would help. Eric > > Cheers, > Mike > > Michael Droettboom wrote: >> Ok -- sorry about that. It looked pretty good on the quadmesh_demo >> example, but I suppose that's just by accident due to the nature of >> the data. By this assessment, we should probably back out this hack >> in pcolormesh as well. >> >> Curiously, though, Rob says this is new behavior... >> >> Cheers, >> Mike >> >> Eric Firing wrote: >> >>> Michael Droettboom wrote: >>> Rob Hetland wrote: > When I do a pcolor, there are white lines between the patches that > cause strange moray patterns, even when saved to a png. The > attached sample shows what I mean. Notice the strange coffee-cup > ring, where the pattern goes away. This is new behavior. > Unfortunately, I haven't been paying enough attention to the devel > list to know what the changes that cause this might be. > The quads need to be enlarged by about 1 pixel, and the easiest way to do this is to give them an edge of width 1 pixel. The pcolormesh code has had this fix for a while, but it was overlooked for pcolor. (Both of which were virtually rewritten for 0.98, which is why this is a regression from 0.91). I have fixed this in SVN. >>> Mike, >>> >>> Not exactly. This is a very old problem and an old attempted >>> solution. I struggled with it a long time ago, and among the >>> various combinations of backends and antialiasing settings, I never >>> found a completely satisfactory solution. I don't know what the best >>> solution will be, but a linewidth of 1 point is definitely not it. >>> It is fundamentally wrong--expanding the patch dimensions by 1/144 >>> inch, so that they overlap--and consequently creates its own >>> artifacts. If you run the attached script and look at the ps output, >>> you will see artifacts in the rectangle corners, and some of the tick >>> marks will be more misplaced than they used to be relative to the >>> rectangle boundaries. >>> >>> I'm sorry I don't have a good solution right now and can't look at it >>> in detail immediately, and I don't mean to dump more work on you. >>> Let's just consider the issue as open for discussion and >>> investigation. I can try to get back to it later. >>> >>> (It is conceivable that a thinner linewidth will be an adequate >>> compromise--still a hack, but maybe acceptable--although the last >>> time I worked on this problem, long before 0.98, I could not get it >>> to work well under all circumstances.) >>> >>> Eric >>> >> >> > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
