Errors in rendering boundaries between filled paths and within a quadmesh

This is the underlying problem raised in #1178.
It is illustrated by the test below; note that boundary anomalies are visible in all forms--agg on the screen, and pdf and svg displayed with a viewer--but in different places depending on the viewer and the size of the figure as rendered.
Note that the colorbar is rendered using pcolormesh, which has its own renderer with agg but otherwise is handled by draw_path_collection.

import numpy as np
import matplotlib.pyplot as plt

z = np.arange(150)
z.shape = (10,15)

fig, axs = plt.subplots(2,2)

ax = axs[0,0]
cs0 = ax.contourf(z, 20)
cbar0 = fig.colorbar(cs0, ax=ax)

ax = axs[0,1]
cs1 = ax.contourf(z, 20, alpha=0.3)
cbar1 = fig.colorbar(cs1, ax=ax)

ax = axs[1,0]
im2 = ax.imshow(z, interpolation='nearest')
cbar2 = fig.colorbar(im2, ax=ax)

ax = axs[1,1]
im3 = ax.imshow(z, interpolation='nearest', alpha=0.3)
cbar3 = fig.colorbar(im3, ax=ax)

plt.savefig("test1.pdf")
plt.savefig("test1.svg")
plt.show()

If you start the code block with ```python you'll get some syntax highlighting.

To me it seems like the pdf backend draws them correctly without addition edges however some viewers render these incorrectly and adds some white space. In the agg backend however even without edges there is an overlap between the paths visible only when alpha is less than 1. I guess this is an unrelated bug in the agg drawing code. It is correctly called with no edges. The pngs from the cairo backends are drawn without any overlap. However it does seem like this backend does not support alpha for imshow. I will open a separate issue for this.

The pdf problem in evince is probably equivalent to this one
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/318130
which was reported in 2009

Indeed the pdf problem in evince is fixed by applying the patch to poppler linked to in that bug report (0001-Align-fills-to-device-integer-coordinates.patch) so it seems like an aliasing problem.

Colorbar Add kw arguement to colorbar to reenable edges around faces in

Add documentation of colorbar issue matplotlib#1188 to colorbar docum…

Merge pull request #1315 from jenshnielsen/colorbar_issuedoc

Did we decide that this is a viewer problem? If so, should this be closed as it requires an upstream fix?

No there is another issue. The agg backend still renders the colorbar with overlap like the pdf did
before meaning that the colorbar with alpha < 1 will look wrong in png. Furthermore alpha is ignored for images (#1193) in the cairo backend so it is not actually possible to render png colorbars with alpha < 1 correctly.

@jenshnielsen

@jenshnielsen Thanks for clarifying.

Is there still somebody looking into this one? I'm using matplotlib 1.4.2 (linux-x64) and still get these white stripes in the colorbar or contourf plots.

I tested the pdf-files with various readers, i.e. okular (libpoppler), google-chrome, Adobe Reader/Acrobat XI‎ (both Windows), and always see these stripes.
Interestingly, for the ps-files the issue is less pronounced but I would say still present.
The svg-files also have the same issue as the pdf-files.

The stripes almost disappear when I plot the same data twice (see the script below), but I consider this as a very bad workaround.

The only fix that works consistently is to set edgecolor="face", but I guess that was also regarded as a workaround and not a fix.

Here is a script that shows how to reproduce and work around the white stripes for contourf plots and the colorbar. I hope it helps to debug and fix this problem.

#!/usr/bin/env python

""" This script illustrates a rendering bug for PDF and SVG files
"""

from matplotlib import pyplot as plt
import numpy as np

plt.close('all')

def gaussian_2d(x, y, x0, y0, xsig, ysig):
    return np.exp(-0.5*(((x-x0) / xsig)**2 + ((y-y0) / ysig)**2))

delta = 0.025
x = np.arange(-3.0, 3.0, delta)
y = np.arange(-2.0, 2.0, delta)
X, Y = np.meshgrid(x, y)
Z = gaussian_2d(X, Y, 1., 1., 1.5, 0.5)

fig, axs = plt.subplots(2, 2, sharex=True, sharey=True)

ax = axs[0,0]
C = ax.contourf(X,Y,Z, 50, cmap='gnuplot')
fig.colorbar(C, ax=ax)
ax.set_title('contourf')

ax = axs[0,1]
C = ax.contourf(X,Y,Z, 50, cmap='gnuplot')
C = ax.contourf(X,Y,Z, 50, cmap='gnuplot')
fig.colorbar(C, ax=ax)
ax.set_title('2x contourf')

ax = axs[1,0]
C = ax.contourf(X,Y,Z, 50, cmap='gnuplot')
Cbar = fig.colorbar(C, ax=ax)
Cbar.solids.set_edgecolor("face")
plt.setp(C.collections, edgecolor="face")
ax.set_title('contourf + edgecolor="face"')

ax = axs[1,1]
C = ax.contourf(X,Y,Z, 50, cmap='gnuplot')
plt.setp(C.collections, rasterized=True)
fig.colorbar(C, ax=ax)
ax.set_title('contourf + rasterized')

fig.savefig('./Gaussian2D.ps')
fig.savefig('./Gaussian2D.pdf')
fig.savefig('./Gaussian2D.svg')
fig.show()

As far as I understand this is a bug in the pdf renders which there is very little we can do about. If you draw 2 faces next to each other with no overlap a gab will often show due roundoff/snapping (Adobe seems to handle this better than most others in my tests).

We can't draw them with an overlap in general since that would break partially transparent contours with alpha< 1. Try adding alpha=0.5 to all your contourf calls to see what I mean i.e ax.contourf(X,Y,Z, 50, cmap='gnuplot', alpha=0.5) and so on.

Using edgecolor='face' is a workaround which adds a small border to all faces. The border gives an non zero overlap which looks strange when alpha<1 but is otherwise perfectly fine. I would consider that a way better solution than plotting the data twice.

@godot11

@godot11 I cannot reproduce this on 3.4.2, so maybe upgrade? If you still have problems, please open a new issue with your explicit save command specified.

@godot11

@godot11 I cannot reproduce this on 3.4.2, so maybe upgrade?

Oops, seems it was indeed matplotlib. It slipped my eyes that I did a conda update wrongly before I posted.
In case it may help here's my conda update output:

conda update log

nagyg -> conda update --all
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /home/nagyg/anaconda3/envs/radpolpy


The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    fftw-3.3.9                 |       h27cfd23_1         2.3 MB
    gsl-2.4                    |       h14c3975_4         1.8 MB
    ipython-7.26.0             |   py38hb070fc8_0         994 KB
    jedi-0.18.0                |   py38h06a4308_1         911 KB
    matplotlib-3.4.2           |   py38h06a4308_0          26 KB
    matplotlib-base-3.4.2      |   py38hab158f2_0         5.6 MB
    matplotlib-inline-0.1.2    |     pyhd3eb1b0_2          12 KB
    notebook-6.4.3             |   py38h06a4308_0         4.2 MB
    parso-0.8.2                |     pyhd3eb1b0_0          69 KB
    progressbar2-3.37.1        |   py38h06a4308_0          38 KB
    python-3.8.11              |h12debd9_0_cpython        18.2 MB
    termcolor-1.1.0            |   py38h06a4308_1           9 KB
    ------------------------------------------------------------
                                           Total:        34.2 MB

The following NEW packages will be INSTALLED:

  _openmp_mutex      pkgs/main/linux-64::_openmp_mutex-4.5-1_gnu
  brotli             pkgs/main/linux-64::brotli-1.0.9-he6710b0_2
  fonttools          pkgs/main/noarch::fonttools-4.25.0-pyhd3eb1b0_0
  libgomp            pkgs/main/linux-64::libgomp-9.3.0-h5101ec6_17
  matplotlib-inline  pkgs/main/noarch::matplotlib-inline-0.1.2-pyhd3eb1b0_2
  munkres            pkgs/main/noarch::munkres-1.1.4-py_0
  pip                pkgs/main/linux-64::pip-21.0.1-py38h06a4308_0
  wheel              pkgs/main/noarch::wheel-0.37.0-pyhd3eb1b0_0

The following packages will be REMOVED:

  libblas-3.8.0-21_mkl
  libcblas-3.8.0-21_mkl

The following packages will be UPDATED:

  fftw                                     3.3.8-h7b6447c_3 --> 3.3.9-h27cfd23_1
  ipython                             7.19.0-py38hb070fc8_0 --> 7.26.0-py38hb070fc8_0
  jedi                                0.17.2-py38h06a4308_1 --> 0.18.0-py38h06a4308_1
  libgcc-ng                                9.1.0-hdf63c60_0 --> 9.3.0-h5101ec6_17
  libxml2                                 2.9.10-hb55368b_3 --> 2.9.12-h03d6c58_0
  matplotlib                           3.3.4-py38h06a4308_0 --> 3.4.2-py38h06a4308_0
  matplotlib-base                      3.3.4-py38h62a2d02_0 --> 3.4.2-py38hab158f2_0
  mkl                                            2020.2-256 --> 2021.3.0-h06a4308_520
  mkl-service                          2.3.0-py38he904b0f_0 --> 2.4.0-py38h7f8727e_0
  mkl_fft                              1.3.0-py38h54f3939_0 --> 1.3.0-py38h42c9631_2
  mkl_random         conda-forge::mkl_random-1.2.0-py38hc5~ --> pkgs/main::mkl_random-1.2.2-py38h51133e4_0
  notebook                                     6.1.4-py38_0 --> 6.4.3-py38h06a4308_0
  numpy                               1.19.2-py38h54aff64_0 --> 1.20.3-py38hf144106_0
  numpy-base                          1.19.2-py38hfa32c7d_0 --> 1.20.3-py38h74d4b33_0
  parso               conda-forge::parso-0.7.1-pyh9f0ad1d_0 --> pkgs/main::parso-0.8.2-pyhd3eb1b0_0
  python                                   3.8.5-h7579374_1 --> 3.8.11-h12debd9_0_cpython
  scipy                                1.5.2-py38h0b6359f_0 --> 1.6.2-py38had2a1c9_1

The following packages will be SUPERSEDED by a higher-priority channel:

  gsl                       conda-forge::gsl-2.6-hf94e986_0 --> pkgs/main::gsl-2.4-h14c3975_4

The following packages will be DOWNGRADED:

  progressbar2                                3.37.1-py38_0 --> 3.37.1-py38h06a4308_0
  termcolor                                    1.1.0-py38_1 --> 1.1.0-py38h06a4308_1


Proceed ([y]/n)? y

(....)

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

Re: github-actions, this is still present in 3.6.3.

@gkatev

@gkatev Can you tell us exactly what is still present? This thread has many different issues.

Hi, yes, sorry for being vague. Below is where the issue is exhibited for me -- please let me know if it's not relevant.

This script reproduces the issue. Use this dataset: data.txt

#!/usr/bin/python

import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv('data.txt', delim_whitespace=True)
df = df.pivot(index='core_1', columns='core_2', values='latency')

plt.pcolor(df, cmap='YlGnBu', rasterized=False)
plt.savefig('c2c.svg')

The resulting svg file has unexpected white lines between the cells (viewing it in eog or in firefox).

I know I assigned this ages ago, but I'm planning to work on it for 3.8. Though at the moment, I don't know that there is any way to fix SVG.

I think this is really hard to fix. This is basically the same issue as with contours and arises because it is impossible to anti-alias properly: https://github.com/jklymak/contourfIssues. If you make your svg viewer not anti-alias this problem goes away. However, I really suggest rasterizing the pcolor. It can make for larger files, but pdf/svg viewers are pretty efficient at dealing with images in the svg.

I actually think this should be closed as "can't fix", but maybe someone has a solution.

The original post is about all formats, and at least Agg and PDF can be fixed.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

Navigation Menu

Errors in rendering boundaries between filled paths and within a quadmesh #1188

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Errors in rendering boundaries between filled paths and within a quadmesh #1188

Description

Activity

dmcdougall commented on Sep 1, 2012

jenshnielsen commented on Sep 2, 2012

jenshnielsen commented on Sep 2, 2012

jenshnielsen commented on Sep 2, 2012

dmcdougall commented on Sep 28, 2012

jenshnielsen commented on Sep 28, 2012

dmcdougall commented on Sep 28, 2012

awehrfritz commented on Feb 3, 2015

jenshnielsen commented on Feb 3, 2015

17 remaining items

jklymak commented on Aug 27, 2021

godot11 commented on Aug 27, 2021

github-actions commented on Feb 27, 2023

gkatev commented on Feb 27, 2023

jklymak commented on Feb 27, 2023

gkatev commented on Feb 27, 2023

QuLogic commented on Feb 27, 2023

jklymak commented on Feb 27, 2023

QuLogic commented on Feb 27, 2023

github-actions commented on Feb 28, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions