Fast PNG embedding using pdflatex

Question

I have a LaTeX document, that includes a lot PNG images. It takes about 18 second to compile. Most of the time is spent for the inclusion of the PNG images. The pdfTeX 1.40 manual from ctan states on page 40, that PNG are recompressed during the pdfTeX run in general, but in some cases, a direct copy is possible, which is much faster. According to the manual the string "PNG copy" is written to the console log in this case.

I tried many different PNG files, until I found one, that gives the desired output.

My minimal example is just

\documentclass{article}
\usepackage{graphicx}
\begin{document}
    \includegraphics{test.png}
\end{document}

Using this image as test.png produces "PNG copy", while this image (like all of my PNG images) doesn't.

Does anyone know, which requirements on the PNG file are needed to achieve the fast, direct copy?

Answer 1

Hartmut Henkel states these conditions in a mail on the context mailing list:

• non-interlaced
• no palette
• no transparency
• no gamma coming with it
• no gamma modification requested
• no white adjustment in the PNG
• and a few more rare others.

He also states:

These are about the factors affecting the PNG to PDF size. For your big PNG graphic you may find a preprocessing (e. g., pngtopnm | pnmtopng) will definitely remove all fat) that makes it compliant with the PNG copy.

Answer 2

^{Disclaimer: I'll try to write a technical explanation of what I found, but I'm not versed in those image witchcrafts. Please bear with me. :)}

This is just a partial answer. I have no idea of the impact of such formats when processed by pdfTeX. EDIT: See Patrick's answer.

Just to make our lives easier, I'll name the images:

• The "normal" one: subject1.png
• The "PNG Copy" one: subject2.png

These are similar images to the ones provided. Your output might differ.

Thanks to the awesome ImageMagick tools, I found some clues on what is probably going on here.

> identify subject1.png
subject1.png PNG 672x656 672x656+0+0 8-bit DirectClass 38.2KB 0.000u 0:00.000

and

> identify subject2.png
subject2.png PNG 672x656 672x656+0+0 8-bit PseudoClass 16c 23.7KB 0.000u 0:00.000

The main difference appears to be in the class definition of both images. Since I'm not versed in this subject, this ImageMagick page might help understand what's going on:

Next comes the binary image data itself. How the image data is formatted depends upon the class of the image as specified (or not specified) by the value of the class key in the header.

• DirectClass images are continuous-tone, images stored as RGB (red, green, blue), RGBA (red, green, blue, alpha), CMYK (cyan, yellow, magenta, black), or CMYKA (cyan, yellow, magenta, black, alpha) intensity values as defined by the colorspace key. Each intensity value is one byte in length for images of depth 8 (0..255), two bytes for a depth of 16 (0..65535), and images of depth 32 (0..4294967295) require four bytes in most significant byte first order.

• PseudoClass images are colormapped RGB images. The colormap is stored as a series of red, green, and blue pixel values, each value being a byte in size. If the image depth is 16, each colormap entry consumes two bytes with the most significant byte being first. The number of colormap entries is defined by the colors key. The colormap data occurs immediately following the header (or image directory if the montage key is in the header). PseudoClass image data is an array of index values into the color map. If there are 256 or fewer colors in the image, each byte of image data contains an index value. If the image contains more than 256 colors or the image depth is 16, the index value is stored as two contiguous bytes with the most significant byte being first. If matte is true, each colormap index is followed by a 1 or 2-byte alpha value.

By running

convert -type Palette subject1.png subject3.png

the class was changed from DirectClass to PseudoClass.

Now, running a sample .tex with \includegraphics{subject3.png}, the log file now tells me:

subject3.png (PNG copy)

At least, now the image is processed differently. :)