Pcolormesh vs contourf

Hello,

I'd like to know about the difference between contourf and pcolormesh and
their intended uses. So far, I've been using contourf with a large number
of levels (150 - 200) to plot two dimensional data. Are their any
disadvantages of this and is pcolormesh better suited for this task?

As far as I can make out, contourf displays a "smoothened-out" image and
pcolormesh is more "boxy".

Thanks.

Sameer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170106/b19ef2f4/attachment.html>

Sameer,

They are fundamentally different in what they do; this is most clear if
you experiment with using both methods on a low-resolution field (say 10
by 12 points), and with a small number of contours (5 or 10).
Contouring is most typically done with a moderate number of contours,
maybe 30 or fewer. It is most immediately appropriate for data values
at discrete points, since it is interpolating. pcolormesh does not
interpolate, but shows the value in each quadrilateral as a block of
solid color, so it is more like an image.

There are data sets and situations for which either of the two methods
can be appropriate, and other cases where one is clearly better than the
other. For a somewhat noisy field, pcolormesh is usually better; it
allows one to see the signal and the noise, and let one's eye pick out
the former. Isolated extreme values are represented better with
pcolormesh. For smoother fields and for seeing large-scale structure,
contourf may be more appropriate.

What kind of data are you plotting?

Eric

···

On 2017/01/05 2:40 PM, Sameer Grover wrote:

Hello,

I'd like to know about the difference between contourf and pcolormesh
and their intended uses. So far, I've been using contourf with a large
number of levels (150 - 200) to plot two dimensional data. Are their any
disadvantages of this and is pcolormesh better suited for this task?

As far as I can make out, contourf displays a "smoothened-out" image and
pcolormesh is more "boxy".

Thanks.

Sameer

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org
Matplotlib-users Info Page

Hi Eric,

The data is usually around 1000 X 1000 large or smaller, mainly
experimental or theoretical data obtained by varying two independent
parameters. With a large number of contours, the visual output from them
doesn't look too different, especially if pcolormesh is used with gouraud
shading. But I realize they do things differently. Thank you for the
clarification.

My only comment is that contourf(x,y,z) expects z of shape(size(y),
size(x)) whereas pcolormesh (x,y,z) expects z of shape (size(y)+1,
size(x)+1), for obvious reasons.

It would be nice if pcolormesh could adjust x and y so that the centres of
each quadrilateral is at the value of x and y, so that both functions could
be called in the same way.

It's not hard to do but something that could be considered if there are
enough use cases.

Sameer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170108/0b90a0bc/attachment.html&gt;

···

On 6 January 2017 at 06:50, Eric Firing <efiring at hawaii.edu> wrote:

Sameer,

They are fundamentally different in what they do; this is most clear if
you experiment with using both methods on a low-resolution field (say 10 by
12 points), and with a small number of contours (5 or 10). Contouring is
most typically done with a moderate number of contours, maybe 30 or fewer.
It is most immediately appropriate for data values at discrete points,
since it is interpolating. pcolormesh does not interpolate, but shows the
value in each quadrilateral as a block of solid color, so it is more like
an image.

There are data sets and situations for which either of the two methods can
be appropriate, and other cases where one is clearly better than the
other. For a somewhat noisy field, pcolormesh is usually better; it allows
one to see the signal and the noise, and let one's eye pick out the
former. Isolated extreme values are represented better with pcolormesh.
For smoother fields and for seeing large-scale structure, contourf may be
more appropriate.

What kind of data are you plotting?

Eric

On 2017/01/05 2:40 PM, Sameer Grover wrote:

Hello,

I'd like to know about the difference between contourf and pcolormesh
and their intended uses. So far, I've been using contourf with a large
number of levels (150 - 200) to plot two dimensional data. Are their any
disadvantages of this and is pcolormesh better suited for this task?

As far as I can make out, contourf displays a "smoothened-out" image and
pcolormesh is more "boxy".

Thanks.

Sameer

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org
Matplotlib-users Info Page

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org
Matplotlib-users Info Page

    Sameer,

    They are fundamentally different in what they do; this is most clear
    if you experiment with using both methods on a low-resolution field
    (say 10 by 12 points), and with a small number of contours (5 or
    10). Contouring is most typically done with a moderate number of
    contours, maybe 30 or fewer. It is most immediately appropriate for
    data values at discrete points, since it is interpolating.
    pcolormesh does not interpolate, but shows the value in each
    quadrilateral as a block of solid color, so it is more like an image.

    There are data sets and situations for which either of the two
    methods can be appropriate, and other cases where one is clearly
    better than the other. For a somewhat noisy field, pcolormesh is
    usually better; it allows one to see the signal and the noise, and
    let one's eye pick out the former. Isolated extreme values are
    represented better with pcolormesh. For smoother fields and for
    seeing large-scale structure, contourf may be more appropriate.

    What kind of data are you plotting?

    Eric

        Hello,

        I'd like to know about the difference between contourf and
        pcolormesh
        and their intended uses. So far, I've been using contourf with a
        large
        number of levels (150 - 200) to plot two dimensional data. Are
        their any
        disadvantages of this and is pcolormesh better suited for this task?

        As far as I can make out, contourf displays a "smoothened-out"
        image and
        pcolormesh is more "boxy".

        Thanks.

        Sameer

        _______________________________________________
        Matplotlib-users mailing list
        Matplotlib-users at python.org <mailto:Matplotlib-users at python.org>
        Matplotlib-users Info Page
        <https://mail.python.org/mailman/listinfo/matplotlib-users&gt;

    _______________________________________________
    Matplotlib-users mailing list
    Matplotlib-users at python.org <mailto:Matplotlib-users at python.org>
    Matplotlib-users Info Page
    <https://mail.python.org/mailman/listinfo/matplotlib-users&gt;

Hi Eric,

The data is usually around 1000 X 1000 large or smaller, mainly
experimental or theoretical data obtained by varying two independent
parameters. With a large number of contours, the visual output from them
doesn't look too different, especially if pcolormesh is used with
gouraud shading. But I realize they do things differently. Thank you
for the clarification.

My only comment is that contourf(x,y,z) expects z of shape(size(y),
size(x)) whereas pcolormesh (x,y,z) expects z of shape (size(y)+1,
size(x)+1), for obvious reasons.

It would be nice if pcolormesh could adjust x and y so that the centres
of each quadrilateral is at the value of x and y, so that both functions
could be called in the same way.

If x and y are uniformly spaced, then imshow does that (and much
faster), with suitable specification of extent, aspect, and interpolation.

I view the way pcolormesh handles x and y as fundamental, so I am
reluctant to add an option to interpolate/extrapolate a pixel-centered
grid to the the edge grid that pcolormesh absolutely requires. In the
simplest cases, such as a uniform rectangular grid, such a
transformation is straightforward, but in the more general cases that
pcolormesh handles, it is not; there is no single algorithm that would
"do the right thing" in all cases.

There is scope for making it easier to do common things, but rather than
fold it into functions like pcolormesh, I think it is better to break it
out into standalone grid manipulation functions.

We also have a NonuniformImage class that handles irregular (and
regular) rectangular pixel-centered grids, and can be used directly.
That class needs an Axes method and a pyplot function.

Eric

···

On 2017/01/07 9:24 AM, Sameer Grover wrote:

On 6 January 2017 at 06:50, Eric Firing <efiring at hawaii.edu > <mailto:efiring at hawaii.edu>> wrote:
    On 2017/01/05 2:40 PM, Sameer Grover wrote:

It's not hard to do but something that could be considered if there are
enough use cases.

Sameer

I added a related issue:
https://github.com/matplotlib/matplotlib/issues/7763.

Eric

Hi Eric, Sameer

I view the way pcolormesh handles x and y as fundamental, so I am reluctant to add an option to interpolate/extrapolate a pixel-centered grid to the the edge grid that pcolormesh absolutely requires. In the simplest cases, such as a uniform rectangular grid, such a transformation is straightforward, but in the more general cases that pcolormesh handles, it is not; there is no single algorithm that would "do the right thing" in all cases.

Maybe I?ve misunderstood, but in 1.5.x, if I run pcolormesh with len(x) = m, len(y) = n and size(z) = m,n then it works just fine (like matlab?s implimentation). its great that it also does m+1 and n+1, but I think it does the ?easy? thing. Maybe in 2.0 this has changed?

To the original question: pcolormesh(x,y,z,rasterized=True) is your friend if m and n are large and you want to print things.

Cheers, Jody

There is scope for making it easier to do common things, but rather than fold it into functions like pcolormesh, I think it is better to break it out into standalone grid manipulation functions.

We also have a NonuniformImage class that handles irregular (and regular) rectangular pixel-centered grids, and can be used directly. That class needs an Axes method and a pyplot function.

Eric

It's not hard to do but something that could be considered if there are
enough use cases.

Sameer

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org <mailto:Matplotlib-users at python.org>
Matplotlib-users Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170107/d5a1e5d2/attachment-0001.html&gt;

Hi Jody, Eric,

Hi Eric, Sameer

I view the way pcolormesh handles x and y as fundamental, so I am
reluctant to add an option to interpolate/extrapolate a pixel-centered grid
to the the edge grid that pcolormesh absolutely requires. In the simplest
cases, such as a uniform rectangular grid, such a transformation is
straightforward, but in the more general cases that pcolormesh handles, it
is not; there is no single algorithm that would "do the right thing" in all
cases.

Maybe I?ve misunderstood, but in 1.5.x, if I run pcolormesh with len(x) =
m, len(y) = n and size(z) = m,n then it works just fine (like matlab?s
implimentation). its great that it also does m+1 and n+1, but I think it
does the ?easy? thing. Maybe in 2.0 this has changed?

To the original question: pcolormesh(x,y,z,rasterized=True) is your
friend if m and n are large and you want to print things.

Cheers, Jody

What I meant was that pcolormesh(z) gives an identical output to
pcolormesh(range(m),range(n),z), only when z.shape is (n-1,m-1). It does
work when z.shape=(m,n) by omitting the last quadrilateral. I thought it
more correct (for my use case) that the number of quadrilaterals should be
the number of elements in x or y.

There is scope for making it easier to do common things, but rather than
fold it into functions like pcolormesh, I think it is better to break it
out into standalone grid manipulation functions.

We also have a NonuniformImage class that handles irregular (and regular)
rectangular pixel-centered grids, and can be used directly. That class
needs an Axes method and a pyplot function.

Eric

Thanks for the information about the nonuniformimage class.

It's not hard to do but something that could be considered if there are
enough use cases.

Sameer

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org
Matplotlib-users Info Page

Sameer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170108/3959e9ee/attachment.html&gt;

···

On 8 January 2017 at 02:01, Jody Klymak <jklymak at uvic.ca> wrote:

Yes, it works like matlab's implementation, for the sake of convenience
and compatibility, but matlab's implementation is wrong, and is not the
behavior that Sameer is understandably asking for.

···

On 2017/01/07 10:31 AM, Jody Klymak wrote:

Maybe I?ve misunderstood, but in 1.5.x, if I run pcolormesh with len(x)
= m, len(y) = n and size(z) = m,n then it works just fine (like matlab?s
implimentation). its great that it also does m+1 and n+1, but I think
it does the ?easy? thing. Maybe in 2.0 this has changed?