Bug rasterized image in pcolor and pcolormesh

Development matplotlib-devel
1

Hello,

I make colormap plots in matplotlib using pcolor or pcolormesh. With
both I have a problem:

If I use pcolormesh ("p2 = ax2.pcolormesh(10**temp,rasterized=True)") I
get perfectly small file sizes, but the position of the rasterized
colormap is a little bit displaced with respect to the frame, showing a
white border on the top and right side. Is this a bug, or can I change
this?

If I try with pcolor, I get the
message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:
UserWarning: Rasterization of '<matplotlib.collections.PolyCollection
object at 0x2aac890>' will be ignored
  warnings.warn("Rasterization of '%s' will be ignored" % self)

Thank you very much for your help,
Markus

335_sbt.pdf (210 KB)

2

I have been doing some testing with pcolor() and pcolormesh() with regards to rasterization. I can not see a displacement when choosing between different file types or with setting rasterized to be True or False. What I have noticed is a half grid-space displacement between pcolor() and pcolormesh().

You can see if this is the cause of your displacement by choosing a higher resolution grid. In such a case, the displacement should be smaller.

Ben Root

···

On Fri, May 21, 2010 at 5:03 AM, Markus Haider <markus.haider@…850…> wrote:

Hello,

I make colormap plots in matplotlib using pcolor or pcolormesh. With

both I have a problem:

If I use pcolormesh (“p2 = ax2.pcolormesh(10**temp,rasterized=True)”) I

get perfectly small file sizes, but the position of the rasterized

colormap is a little bit displaced with respect to the frame, showing a

white border on the top and right side. Is this a bug, or can I change

this?

If I try with pcolor, I get the

message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:

UserWarning: Rasterization of '<matplotlib.collections.PolyCollection

object at 0x2aac890>’ will be ignored

warnings.warn(“Rasterization of ‘%s’ will be ignored” % self)

Thank you very much for your help,

Markus

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

3

Hi,

Thank you for your reply.

I have been doing some testing with pcolor() and pcolormesh() with
regards to rasterization. I can not see a displacement when choosing
between different file types or with setting rasterized to be True or
False. What I have noticed is a half grid-space displacement between
pcolor() and pcolormesh().

Can you see the displacement in the before enclosed pdf file?

You can see if this is the cause of your displacement by choosing a
higher resolution grid. In such a case, the displacement should be
smaller.

How can I choose a higher resolution grid?
Thank you for your help,
Greetings,
Markus

···

Ben Root

On Fri, May 21, 2010 at 5:03 AM, Markus Haider > <markus.haider@...850...> wrote:
        Hello,
        
        I make colormap plots in matplotlib using pcolor or
        pcolormesh. With
        both I have a problem:
        
        If I use pcolormesh ("p2 =
        ax2.pcolormesh(10**temp,rasterized=True)") I
        get perfectly small file sizes, but the position of the
        rasterized
        colormap is a little bit displaced with respect to the frame,
        showing a
        white border on the top and right side. Is this a bug, or can
        I change
        this?
        
        If I try with pcolor, I get the
        message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:
        UserWarning: Rasterization of
        '<matplotlib.collections.PolyCollection
        object at 0x2aac890>' will be ignored
         warnings.warn("Rasterization of '%s' will be ignored" % self)
        
        Thank you very much for your help,
        Markus
        
        ------------------------------------------------------------------------------
        
        _______________________________________________
        Matplotlib-devel mailing list
        Matplotlib-devel@lists.sourceforge.net
        matplotlib-devel List Signup and Options
        

4

Markus,

Looking again at your image, I realized that you are probably using real data, not simulated data, therefore you can’t easily use a higher grid resolution.

So, I created a test script to examine this. I have found that there is definitely a difference between filetypes. In my test script, there is a white row that occurs for pcolor, but not for pcolormesh (Note, I have a patched version of matplotlib that rasterizes pcolormesh). Also, this effect does not happen if rasterization is set to False. Lastly, the effect is more pronounced with lower-resolution data.

Let me clean up the test script so that the devels to use to visualize this issue.

Ben Root

···

On Fri, May 21, 2010 at 9:45 AM, Markus Haider <markus.haider@…850…> wrote:

Hi,

Thank you for your reply.

I have been doing some testing with pcolor() and pcolormesh() with

regards to rasterization. I can not see a displacement when choosing

between different file types or with setting rasterized to be True or

False. What I have noticed is a half grid-space displacement between

pcolor() and pcolormesh().

Can you see the displacement in the before enclosed pdf file?

You can see if this is the cause of your displacement by choosing a

higher resolution grid. In such a case, the displacement should be

smaller.

How can I choose a higher resolution grid?

Thank you for your help,

Greetings,

Markus

Ben Root

On Fri, May 21, 2010 at 5:03 AM, Markus Haider > > > <markus.haider@…850…> wrote:

    Hello,

    I make colormap plots in matplotlib using pcolor or

    pcolormesh. With

    both I have a problem:

    If I use pcolormesh ("p2 =

    ax2.pcolormesh(10**temp,rasterized=True)") I

    get perfectly small file sizes, but the position of the

    rasterized

    colormap is a little bit displaced with respect to the frame,

    showing a

    white border on the top and right side. Is this a bug, or can

    I change

    this?

    If I try with pcolor, I get the

    message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:

    UserWarning: Rasterization of

    '<matplotlib.collections.PolyCollection

    object at 0x2aac890>' will be ignored

     warnings.warn("Rasterization of '%s' will be ignored" % self)

    Thank you very much for your help,

    Markus

    ------------------------------------------------------------------------------

    _______________________________________________

    Matplotlib-devel mailing list

    Matplotlib-devel@lists.sourceforge.net

    [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)
5

If possible, can you try the latest svn version and see if it makes
any difference?
Also, see if increasing the dpi helps, i.e.,

savefig(..., dpi=150)

Given the nature of the rasterization, I'm not sure if we can
completely avoid the white gap for low dpi settings.
But the displacement issue you see (although think it has been fixed
in the svn) needs to be fixed.

Regards,

-JJ

6

Hello,

Attached is a test script to produce low and high resolution (data-wise) images in multiple formats. You can change the dpi in the script, however, I have not noticed any significant difference. It also appears that the data resolution doesn’t impact the size of the artifact as much as I originally thought.

I hope this is helpful!

Ben Root

testpcolor.py (1.45 KB)

···

On Fri, May 21, 2010 at 10:39 AM, Jae-Joon Lee <lee.j.joon@…149…> wrote:

If possible, can you try the latest svn version and see if it makes

any difference?

Also, see if increasing the dpi helps, i.e.,

savefig(…, dpi=150)

Given the nature of the rasterization, I’m not sure if we can

completely avoid the white gap for low dpi settings.

But the displacement issue you see (although think it has been fixed

in the svn) needs to be fixed.

Regards,

-JJ

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

7

But the displacement issue you see (although think it has been fixed
in the svn) needs to be fixed.

Hi,

I just tried out the svn version, and the displacement issue is indeed
fixed in svn. There is one more question: If I use pcolor with
rasterized, filesize is 165 kb, if I use pcolormesh it is 864 kb. What
is the difference between pcolor and pcolormesh?

Greetings,
Markus

8

By the way, in the current svn version, there is a small white distance
between the image and the axis frame on the right hand and lower side,
if I output to svg.

Greetings,
Markus

9

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.

Ben Root

···

On Mon, May 31, 2010 at 4:45 AM, Markus Haider <markus.haider@…850…> wrote:

But the displacement issue you see (although think it has been fixed

in the svn) needs to be fixed.

Hi,

I just tried out the svn version, and the displacement issue is indeed

fixed in svn. There is one more question: If I use pcolor with

rasterized, filesize is 165 kb, if I use pcolormesh it is 864 kb. What

is the difference between pcolor and pcolormesh?

Greetings,

Markus

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

10

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.

Ryan

···

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.root@...553...> 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.

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

11

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

···

On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@…149…> wrote:

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.root@…553…> 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.

12

It seems that pcolormesh silently ignores some of the keyword
parameters, and "rasterized" is one of them. And I'm not sure this is
intended behavior or not and I hope other developers step in.

In the meantime, use a member method explicitly.

p2 = pcolormesh(arr)
p2.set_rasterized(True)

Regards,

-JJ

···

On Tue, Jun 1, 2010 at 12:05 PM, Benjamin Root <ben.root@...553...> wrote:

On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@...149...> wrote:

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.root@...553...> 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
matplotlib-devel List Signup and Options

13

Confirmed. This might also explain some other behaviors I have noticed with pcolormesh and rasterized=True.

Ben Root

···

On Tue, Jun 1, 2010 at 11:18 AM, Jae-Joon Lee <lee.j.joon@…149…> wrote:

It seems that pcolormesh silently ignores some of the keyword

parameters, and “rasterized” is one of them. And I’m not sure this is

intended behavior or not and I hope other developers step in.

In the meantime, use a member method explicitly.

p2 = pcolormesh(arr)

p2.set_rasterized(True)

Regards,

-JJ

On Tue, Jun 1, 2010 at 12:05 PM, Benjamin Root <ben.root@…553…> wrote:

On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@…149…> wrote:

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.root@…553…> 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

14

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 <ben.root@…553…> wrote:

On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@…149…> wrote:

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.root@…553…> 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

15

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 <ben.root@…553…> 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 <ben.root@…553…> wrote:

On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@…149…> wrote:

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.root@…553…> 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

16

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?

Yes. Please include the simplest scripts you can devise that generate and illustrate the problems. In the pcolormesh case, this means keeping the plot (and the data being plotted) as simple as possible. If the problem can be illustrated with only two color regions, for example, that is ideal.

Eric

···

On 06/01/2010 05:21 PM, Benjamin Root wrote:

Ben Root

On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root <ben.root@...553... > <mailto:ben.root@…553…>> 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 <ben.root@...553... > <mailto:ben.root@…553…>> wrote:

        On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@...149... > <mailto:rmay31@…149…>> wrote:

            On Mon, May 31, 2010 at 11:28 AM, Benjamin Root > <ben.root@...553... <mailto:ben.root@…553…>> 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
matplotlib-devel List Signup and Options

17

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?

Yes. Please include the simplest scripts you can devise that generate

and illustrate the problems. In the pcolormesh case, this means keeping

the plot (and the data being plotted) as simple as possible. If the

problem can be illustrated with only two color regions, for example,

that is ideal.

Eric, I have attached scripts to both bug reports. 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.

Ben Root

···

On Wed, Jun 2, 2010 at 11:41 AM, Eric Firing <efiring@…552…229…> wrote:

On 06/01/2010 05:21 PM, Benjamin Root wrote:

Eric

Ben Root

On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root <ben.root@…553… > > mailto:ben.root@...553...> 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 <ben.root@...553... > >     <mailto:ben.root@...553...>> wrote:

    On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@...149... > >         <mailto:rmay31@...149...>> wrote:

        On Mon, May 31, 2010 at 11:28 AM, Benjamin Root > >             <ben.root@...553... <mailto:ben.root@...553...>> 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

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

18

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 <ben.root@...553...> 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 <ben.root@...553...> 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 <ben.root@...553...> wrote:

On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rmay31@...149...> wrote:

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.root@...553...> 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
matplotlib-devel List Signup and Options

19

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

···

On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root <ben.root@...553...> 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.

20

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

···

On Fri, Jun 4, 2010 at 4:53 PM, Jae-Joon Lee <lee.j.joon@…149…> wrote:

On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root <ben.root@…553…> 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