[matplotlib-devel] SVG backend - edge alpha channel fix?

[Bob]

I'm using matplotlib v0.99.1.1 pyplot savefig() to generate svg files
using the matplotlib.use('SVG') backend. My networkx plot contains
semi-transparent edges which were not carrying over to the svg xml
correctly. The node transparencies were correct.
I was able to fix this problem by modifying
/matplotlib/backends/backend_svg.py ...


@@ -150 +149 @@
- gc.get_alpha(),
+ gc.get_rgb()[3],


While gc.get_rgb()[3] was able to return the correct alpha float
value, gc.get_alpha() was always returning 1.0.
Has anyone else seen this problem? Perhaps it's my use of
draw_networkx_edges() to style the edges.

Hope this helps,
Bob

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SVG backend - edge alpha channel fix?

[Eric Firing]

On 06/04/2010 07:46 AM, Bob wrote:
> I'm using matplotlib v0.99.1.1 pyplot savefig() to generate svg files
> using the matplotlib.use('SVG') backend. My networkx plot contains
> semi-transparent edges which were not carrying over to the svg xml
> correctly. The node transparencies were correct.
> I was able to fix this problem by modifying
> /matplotlib/backends/backend_svg.py ...
>
>
> @@ -150 +149 @@
> - gc.get_alpha(),
> + gc.get_rgb()[3],

I don't think this is the right thing to do in general--as far as I can 
see, gc.get_rgb() can return an rgb triplet instead of an rgba quad.

>
>
> While gc.get_rgb()[3] was able to return the correct alpha float
> value, gc.get_alpha() was always returning 1.0.
> Has anyone else seen this problem? Perhaps it's my use of
> draw_networkx_edges() to style the edges.

No, I think it is part of some difficulties in alpha-handling that have 
been around for a long time, and that I hope I have solved--although 
most likely there are still glitches to be smoothed out.

Can you build from svn and see whether that solves the problem?  If not, 
please provide a simplest-possible standalone script that illustrates 
the problem, so I can try running it from current mpl.

Eric


>
> Hope this helps,
> Bob

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh

[Jae-Joon Lee]

I'm attaching a copy of my comment to Ben's bug report for a reference.

here is a bug report.

https://sourceforge.net/tracker/index.php?func=detail&aid=3010569&group_id=80706&atid=560720#

My comment:

As far as I can see, this is not a bug of matplotlib, but an artifact of
the rasterizer you're using. For example, the pdf file you uploaded looks
fine with acrobat reader but shows white lines on gs-based pdf viewer. Even
in gs-based viewer, if you turn off anti-aliasing, you will notice that the
white lines are gone.

I'm not sure if there is anything we can do to avoid this artifact from
the matplotlib side.
If anyone has any suggestion, please open a new feature request ticket.
Meanwhile, I'm closing this ticket.


-JJ


On Tue, Jun 1, 2010 at 11:21 PM, Benjamin Root  wrote:
> I have finally managed to test against TkAgg, and the faint white lines do
> not appear to occur.  So, as far as I can tell (no clue about Macs), the
> GTKCairo, pdf and svg backends have this display bug.  Shall I file a bug
> report for this and another for the misaligned title?
>
> Ben Root
>
> On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root  wrote:
>>
>> Correction -- the problem with pcolormesh and the faint white lines are
>> occurring for pdf and svg files, *not* eps files as I originally stated.  I
>> am also checking a number of display backends and found that the problem
>> occurs for GTKCairo.  I am sure it also happens for TkAgg, but I can not
>> confirm that right now.  I am unable to test the Mac backends, though.
>>
>> On a side note, when testing the backends, I noticed that GTKCairo was
>> *slow* for displaying the figures.  Also, the GTK backend produced
>> misaligned titles.  I can start a new thread about the misaligned titles, if
>> someone wishes.
>>
>> Ben Root
>>
>> On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root  wrote:
>>>
>>>
>>> On Tue, Jun 1, 2010 at 9:39 AM, Ryan May  wrote:

 On Mon, May 31, 2010 at 11:28 AM, Benjamin Root  wrote:
 > Markus,
 >
 > That is good to know that it has been fixed.  As for the difference in
 > pcolor and pcolormesh, I think it has to do with the fact that
 > pcolormesh is
 > composed of many lines while pcolor is composed of many polygons.  It
 > is
 > probably more efficient to rasterize polygons than lines.

 To be blunt, this makes no sense whatsoever.  First, pcolormesh and
 pcolor differ in that it pcolor uses a generic PolyCollection to draw
 the quads, while pcolormesh uses a quadmesh object, which can be more
 efficient at the cost of generality, as it only needs to render a set
 of identical quads. Second, if you're talking rasterized drawing, in
 the end what gets written to a file is a 2D array of RGBA values.  It
 doesn't matter what you use to produce the results: identical image on
 the screen -> identical array in file.  It's possible that there are
 slight differences that you can't really see that produce different
 arrays, but that won't cause a factor of 8 difference in size. My
 guess is that pcolormesh isn't rasterizing properly.

>>> Indeed, you are right that lines aren't drawn.  I have looked back at the
>>> images produced by my test script that I posted to this thread and I see
>>> where I got confused.  The pcolormesh result in pdf and eps files have very
>>> faint white blocks around each quad.  At high enough data resolution, the
>>> color part of the quads look like lines while the white lines look like
>>> dots.  This happens regardless of using rasterized=True or not, and I don't
>>> think it is visible in png files (although I am testing some very high
>>> resolution png files to verify).
>>>
>>> Ben Root
>>
>
>
> --
>
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh

[Jae-Joon Lee]

On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root  wrote:
> I have noticed that the svn repo still does not have rasterization
> decorators for some of the collections (e.g., PolyCollection,
> EllipseCollection, CircleCollection if I remember correctly).  Don't know
> what are supposed to be the final list of Collection that are eligible for
> that decorator, but it is incomplete at this point in the trunk.

Did you actually test that the rasterization does not work for these artist?
They are supposed to, and and they do in my installation.

If you simply saying that the draw method of these artist are not
decorated, they don't need one because Collection.draw which is called
inside their draw method is already decorated.

Regards,

-JJ

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] wxagg backend: using any Print* functionality?

[Eric Firing]

See 
https://sourceforge.net/tracker/?func=detail&aid=2564093&group_id=80706&atid=560720

My guess is that the problem is the call to Printer_Init().  Based on a 
little code scanning and grepping, and on the default wxagg plot with 
toolbar, I don't see that any of the Print* stuff is being used by 
mpl--but I know very little about wx, and I have not looked deeply into 
backend_wx*.

Can we simply remove Printer_Init() from FigureCanvasWx.__init__, or 
will that have dire consequences for someone?  Is there a wx wizard who 
can provide a good solution?

One way or another, I would like to get this ancient ticket closed.

Eric

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh

[Benjamin Root]

On Fri, Jun 4, 2010 at 4:53 PM, Jae-Joon Lee  wrote:

> On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root  wrote:
> > I have noticed that the svn repo still does not have rasterization
> > decorators for some of the collections (e.g., PolyCollection,
> > EllipseCollection, CircleCollection if I remember correctly).  Don't know
> > what are supposed to be the final list of Collection that are eligible
> for
> > that decorator, but it is incomplete at this point in the trunk.
>
> Did you actually test that the rasterization does not work for these
> artist?
> They are supposed to, and and they do in my installation.
>
> If you simply saying that the draw method of these artist are not
> decorated, they don't need one because Collection.draw which is called
> inside their draw method is already decorated.
>
> Regards,
>
> -JJ
>

No, they do work when decorated, I am not claiming that they don't.  Maybe
the CircleCollection and the EllipseCollection don't need the decorator, but
the PolyCollector generates a warning if you set rasterized=True without the
decorator.

Ben Root
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh

[Eric Firing]

On 06/04/2010 02:50 PM, Benjamin Root wrote:
>
>
> On Fri, Jun 4, 2010 at 4:53 PM, Jae-Joon Lee  > wrote:
>
> On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root  > wrote:
>  > I have noticed that the svn repo still does not have rasterization
>  > decorators for some of the collections (e.g., PolyCollection,
>  > EllipseCollection, CircleCollection if I remember correctly).
> Don't know
>  > what are supposed to be the final list of Collection that are
> eligible for
>  > that decorator, but it is incomplete at this point in the trunk.
>
> Did you actually test that the rasterization does not work for these
> artist?
> They are supposed to, and and they do in my installation.
>
> If you simply saying that the draw method of these artist are not
> decorated, they don't need one because Collection.draw which is called
> inside their draw method is already decorated.
>
> Regards,
>
> -JJ
>
>
> No, they do work when decorated, I am not claiming that they don't.
> Maybe the CircleCollection and the EllipseCollection don't need the
> decorator, but the PolyCollector generates a warning if you set
> rasterized=True without the decorator.

They all need the decorator because of the flag it adds.  Having a 
decorated draw call a decorated base draw doesn't hurt.

I added the missing Collection subclass draw decorators in svn 8381.

Eric

>
> Ben Root

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel