matplotlib-devel Mailing List for matplotlib

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

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

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

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
> Mat...@li...
> 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

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

> 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.

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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.
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.
> 
> 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.
> 
> 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.
> I have also removed MixedModeRenderer from svg as it conflicts with "svg.image_noscale"
> and does not seem to be used.
> 
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.
Eric