[Tex/LaTex] How to convert pgfplots to high quality PNG file with Ghostscript

conversionghostscriptpgfplotspng

Note: This is not a duplicate of How to save a figure produced by tikz save/export as JPG/PNG file. This question deals with Ghostscript and quality concerns. The other question does not deal with Ghostscript, so none of the discussion at the other question is about quality considerations related to Ghostscript. Further, in the comments section, there is a good comment which should be posted as an answer.

Here is my code:

\documentclass[border=5pt]{standalone}
\usepackage{pgfplots}
\begin{document}
\begin{tikzpicture}

\begin{axis}[xmin=0, xmax=4, xlabel=x, ylabel=y]
    \addplot[domain=0:4, samples=100, blue, thick] {cos(deg(x))};
\end{axis}

\end{tikzpicture}
\end{document}

When I compile this with pdflatex foo.tex I get a good quality PDF. Here is a screenshot of the PDF:

Now I try to convert the PDF into PNG. Here is my first attempt with -sDEVICE=png16m:

gs -sDEVICE=png16m -sBATCH -sNOPAUSE -r300 -sOutputFile=foo1.png foo.pdf

The output is of pretty disappointing quality. The curve appears to be pixelated. The slopes seem like staircase. It looks like this:

Here is my second attempt with -sDEVICE=pngalpha:

gs -sDEVICE=pngalpha -sBATCH -sNOPAUSE -r300 -sOutputFile=foo2.png foo.pdf

The output is much better but the background is transparent:

My questions:

Why does the png16m device produce so much poorer quality output than pngalpha?
How do you produce good quality images from pgfplots using Ghostscript?

Best Answer

The apparent quality improvement with -sDEVICE=pngalpha as compared to -sDEVICE=pn16m is achieved by application of anti-aliasing.

According to https://www.ghostscript.com/doc/current/Devices.htm#PNG , with -sDEVICE=pngalpha antialiasing is enabled by default:

The pngalpha device is 32-bit RGBA color with transparency indicating pixel coverage. The background is transparent unless it has been explicitly filled. PDF 1.4 transparent files do not give a transparent background with this device. Text and graphics anti-aliasing are enabled by default.

For the png16m output device, antialiasing must be enabled explicitly for text and graphics. Add options -dTextAlphaBits=4 -dGraphicsAlphaBits=4:

-dTextAlphaBits=n
-dGraphicsAlphaBits=n
These options control the use of subsample antialiasing. Their use is highly recommended for producing high quality rasterizations of the input files. The size of the subsampling box n should be 4 for optimum output, but smaller values can be used for faster rendering. Antialiasing is enabled separately for text and graphics content.

ROOT data export

Before, I generated the scatter plot values via ROOT's Python bindings as:

import csv

def th2f_to_csv(hist, csv_file):
    """Print TH2F bin data to CSV file."""
    xbins, ybins = hist.GetNbinsX(), hist.GetNbinsY()
    xaxis, yaxis = hist.GetXaxis(), hist.GetYaxis()
    with open(csv_file, 'w') as f:
        c = csv.writer(f, delimiter=' ', lineterminator='\n')
        for xbin in xrange(xbins+2):
            xcenter = xaxis.GetBinCenter(xbin)
            for ybin in xrange(ybins+2):
                ycenter = yaxis.GetBinCenter(ybin)
                weight = hist.GetBinContent(xbin, ybin)
                if weight > 0:
                    c.writerow((xcenter, ycenter, weight))

The input argument hist is a TH2F object. See the ROOT and PyROOT documentation for more information.

The "+2" in xrange handles that ROOT saves an underflow and an overflow bin on top of the bins that are actually drawn. I at this stage explicitly threw out the points with no content to keep the "scatter plot" in PGFPlots clean.

But now I instead want to output a complete matrix, which I did as follows:

import csv

def th2f_to_csv(hist, csv_file):
    """Print TH2F bin data to CSV file."""
    xbins, ybins = hist.GetNbinsX(), hist.GetNbinsY()
    xaxis, yaxis = hist.GetXaxis(), hist.GetYaxis()
    with open(csv_file, 'w') as f:
        c = csv.writer(f, delimiter=' ', lineterminator='\n')
        for ybin in xrange(1, ybins+2):
            y_lowedge = yaxis.GetBinLowEdge(ybin)
            for xbin in xrange(1, xbins+2):
                x_lowedge = xaxis.GetBinLowEdge(xbin)
                weight = hist.GetBinContent(xbin, ybin)
                c.writerow((x_lowedge, y_lowedge, weight))

I now discard the underflow bin by starting the range from 1, and I also discard the overflow bin, since the last bin will not be shown when choosing shader=flat corner in PFDPlots later. I could have just given a dummy value instead of the actual overflow value, but it does not matter (EDIT: actually, it might matter if the overflow value is larger/smaller than the maximum/minimum "real" value — it would then affect the color map scale, so beware).

Instead of extracting the center of the bins, I now am interested in the lower bin edges.

I also change the order of the x and y loops to get the matrix data in a form that PGFPlots processes more efficiently, as described in section 7.2.1 in the manual: "Importing Mesh Data From Matlab To PGFPlots". This made a noticeable difference in compilation time.

Working examples

Now that I have the matrix, a minimal working example of plotting this data (matrix.csv) as a 2D histogram was:

\documentclass{article}

\usepackage{tikz}
\usepackage{pgfplots}
\pgfplotsset{compat=newest}

\begin{document}

\begin{tikzpicture}
  \begin{axis}[
    view={0}{90},
    colorbar,
  ]
    \addplot3[
      surf,
      shader=flat corner,
      mesh/cols=51,
      mesh/ordering=rowwise,
    ] file {matrix.csv};
  \end{axis}
\end{tikzpicture}

\end{document}

Minimum working example.

Section 7.2.1 in the manual and the earlier linked question explains the parameters. mesh/cols=51 comes from the known fact that the histogram contains 50 horizontal bins, and the extra one accounts for the "dummy bin" mentioned in the above linked TeX.SE question. The bin count could be output to a CSV specific configuration file along with the data if more automation is needed.

One issue was that the compiler (xelatex in this case) threw exactly 5000 rows to the terminal with content:

pgfplotsplothandlermesh@get@flat@color

There should be 50⨯100 = 5000 "cells" to be rendered in total in the image. This excess of messages might be a bug in itself, or something that I could have suppressed in some way.

Another issue is that the "background", i.e. the parts of the graph that represents value zero, is colored in, which is not optimal. The most obvious solution to this I found was to create a color map that "began" at white, which makes sense for these types of graphs anyway.

Along with some minor other formatting fixes, this gave the following result:

\documentclass{article}

\usepackage{tikz}
\usepackage{pgfplots}
\pgfplotsset{compat=newest}
\usepackage{siunitx}

\begin{document}

\pgfplotsset{
  /pgfplots/colormap={coldredux}{
    [1cm]
    rgb255(0cm)=(255,255,255)
    rgb255(2cm)=(0,192,255)
    rgb255(4cm)=(0,0,255)
    rgb255(6cm)=(0,0,0)
  }
}

\begin{tikzpicture}
  \begin{axis}[
    view={0}{90},
    xlabel={$\theta$ /degrees},
    ylabel={Energy /\si{\MeV}},
    minor tick num=4,
    colorbar,
    colorbar style={ylabel={Counts}},
  ]
    \addplot3[
      surf,
      shader=flat corner,
      mesh/cols=51,
      mesh/ordering=rowwise,
      x filter/.code={\pgfmathparse{#1*180}\pgfmathresult},
      y filter/.code={\pgfmathparse{#1/1000}\pgfmathresult},
    ] file {matrix.csv};
  \end{axis}
\end{tikzpicture}

\end{document}

Graphically updated version of histogram.

I will implement the x filter and y filter transformations in the analysis stage instead of the plotting stage.

Probably not a finished "product" yet, but now I can apply styling freely, and it is produced with a definitely manageable amount of code.

Best Answer

Related Solutions

[Tex/LaTex] Positioning pgfplots axis in tikzpicture

[Tex/LaTex] Building a 2D histogram with PGFPlots

ROOT data export

Working examples

Related Question