Re: [matplotlib-devel] [patch] Fix build failure with GCC 4.4
Sandro Tosi wrote: > Hello guys! > A Debian Developers just reported a bug[1] on debian matplotlib during > his preparation to introduce GCC 4.4: matplotlib will fail to build > with GCC 4.4 due to a missing include. > > Attached is a patch to fix this problem, forged from an updated trunk; > hope you can include it. > > [1] http://bugs.debian.org/505618 Hi Sandro, fixed in r6402. mm > Cheers, > > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > > > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom-sized and spanning subplots
> You may want to have a look at the mplsizer MPL toolkit I > wrote a long time ago and have failed to properly advertise > or maintain. Thanks; I'll take a look at it. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svg.image_noscale and others
Eric Firing wrote: > Jozef Vesely wrote: > >> Hello matplotlib developers, >> >> I have implemented "svg.image_noscale" feature for ps and pdf backends. I >> think >> that resampling/scaling should be avoided, when vector format can scale image >> itself. >> Unfortunately, the quality of interpolation is often subpar compared to what matplotlib (via Agg) provides. Worse, the quality will be different when using Acrobat Reader vs. xpdf, for instance. I don't think zooming in on individual pixels of data in Acroread is something we really are trying to support anyway -- for that you should use an interactive matplotlib GUI. The purpose of pdf, imho, is really for printing. In that case, you're likely to get better results and smaller file sizes by knowing the maximum resolution of your output device and letting matplotlib resample it -- and resample it with a method that is appropriate for the data, not the one in the printer or Acrobat that is (probably) optimized for photographs of the real world or whatever the driver is currently set to. > It seems to me best if there is an option to scale or not; depending on > the situation, one might want to generate a file with images downscaled. > Right. All the above notwithstanding, I don't have a problem with this being a user option, I just can't imagine using it myself. > >> One advantage is that original image can be recovered from final file. >> Moreover >> as it is vector format it should be dpi independent and always provide >> maximum >> possible quality - that's original data. >> The original image can theoretically be recovered from the final file. But not the original data, which may be floating point etc. If you anticipate users of your plot to need the original data, just distribute the original data alongside the plot. >> As for svg backend I have commented some transformation changes which >> I don't understand and which result in misaligned image and axes. >> Without it the misalignment is still there but smaller. >> Thanks for that. I'm not sure why that code is there. I see it looks much better without it. >> I have also removed MixedModeRenderer from svg as it conflicts with >> "svg.image_noscale" >> and does not seem to be used. >> I think it would be better to turn off mixed mode rendering only when svg.image_noscale is True. >> > > I think having the option of using the MixedModeRenderer is important in > the long run for the vector backends; without it, one can end up with > completely unwieldy and potentially unrenderable files. I'm not sure > what its status is at present; I think Mike got it working to a > considerable extent, but didn't quite finish, and therefore left it > temporarily disabled. > It's fully functional in all the backends where it makes sense. The part that is unfinished is the user interface -- how to turn the functionality on and off. We couldn't find both a general and easy way to do it. But it would be nice to have another go at it. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] partial ring patch
Paul Kienzle wrote: > Hi, > > We found we needed to draw a partial ring, but didn't see one in > patches.py. > > Attached is a generalization of Wedge to accept an inner and an outer > radius. > > Should I add this to patches? Looks like a useful feature to me. Could be used for doing these sort of "hierarchical pie chart" graphs: http://linux.byexamples.com/wp-content/uploads/2007/04/baobab.png Any reason not to implement this simply as an additional kwarg to Wedge, rather than a new class -- since Ring with a r2 == 0 is equivalent to Wedge anyway? Just thinking of having less code to maintain...but maybe that's more confusing for end users. > > Note that rather saving the unit ring and constructing a transform as > in Wedge: > > def get_patch_transform(self): > x = self.convert_xunits(self.center[0]) > y = self.convert_yunits(self.center[1]) > rx = self.convert_xunits(self.r2) > ry = self.convert_yunits(self.r2) > self._patch_transform = transforms.Affine2D() \ > .scale(rx, ry).translate(x, y) > return self._patch_transform > > I just transform the coordinates directly: > > v *= r2 > v += numpy.array(center) > self._path = Path(v,c) > self._patch_transform = transforms.IdentityTransform() > > Any reason to prefer one over the other? No strong reason. The reason I did it that way was so that if the patch were scaled or translated in an animation, the transformation of the wedge vertices would happen on-the-fly within backend_agg. It's not based on any benchmarking, but probably more on old habits from game programming (where it's common practice to keep shapes and transforms separated and let the hardware apply them). I doubt it matters here. Mike > > - Paul > > > > > > > > > > > One problem is that I had to explicitly set the axes limits 1because add_patch > > wasn't updating the limits to include the bounds of the new patch. > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ___ > 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] partial ring patch
On Nov 14, 2008, at 9:59 AM, Michael Droettboom wrote: > Paul Kienzle wrote: >> Hi, >> >> We found we needed to draw a partial ring, but didn't see one in >> patches.py. >> >> Attached is a generalization of Wedge to accept an inner and an >> outer radius. >> >> Should I add this to patches? > Looks like a useful feature to me. Could be used for doing these > sort of "hierarchical pie chart" graphs: > > http://linux.byexamples.com/wp-content/uploads/2007/04/baobab.png That's pretty, though I have no idea what it is supposed to represent. > > Any reason not to implement this simply as an additional kwarg to > Wedge, rather than a new class -- since Ring with a r2 == 0 is > equivalent to Wedge anyway? Just thinking of having less code to > maintain...but maybe that's more confusing for end users. Okay, I will replace Wedge on svn. - Paul - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] partial ring patch
Paul Kienzle wrote: > > On Nov 14, 2008, at 9:59 AM, Michael Droettboom wrote: > >> Paul Kienzle wrote: >>> Hi, >>> >>> We found we needed to draw a partial ring, but didn't see one in >>> patches.py. >>> >>> Attached is a generalization of Wedge to accept an inner and an >>> outer radius. >>> >>> Should I add this to patches? >> Looks like a useful feature to me. Could be used for doing these >> sort of "hierarchical pie chart" graphs: >> >> http://linux.byexamples.com/wp-content/uploads/2007/04/baobab.png > > That's pretty, though I have no idea what it is supposed to represent. It's the size of directories in a directory structure. Each ring is a different depth of nesting. Useful wherever you have a heirarchical percentages... 50% of %40 of %30... Of course, suffers from the same usability problems of pie charts. I'm not seriously suggesting we pursue this... Your Ring class just reminded me of it. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] partial ring patch
On Nov 14, 2008, at 12:36 PM, Paul Kienzle wrote: >> >> Any reason not to implement this simply as an additional kwarg to >> Wedge, rather than a new class -- since Ring with a r2 == 0 is >> equivalent to Wedge anyway? Just thinking of having less code to >> maintain...but maybe that's more confusing for end users. > > Okay, I will replace Wedge on svn. Done. The keyword I used is *width* for the width of the ring. Using width=None draws the whole wedge. - Paul - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
