# Fast PNG embedding using pdflatex

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?

-

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.

-
That's strange. "No palette" seems to directly contradict what @Paulo Cereda is seeing. –  You Jan 3 '12 at 12:37
Thanks very much for the quick answer. Unluckily I have not been able to create such PNGs using Gimp. Saving the file in a different format and then using convert to create the PNG did the job. Having no transparency is bad, but it is good to know the limitations. I will try to embed the images directly into PDF files and include them in the .tex file. Maybe this is even faster. –  porst17 Jan 3 '12 at 12:38
I converted my PNG images into PDFs using ImageMagick. This works nicely!! The alpha channel is preserved. So I could overlay several of these files in LaTeX. And the best thing about this approach: compilation time dropped from 18s to 1s. –  porst17 Jan 3 '12 at 13:23
Using pdf images instead of png lowers your compilation from 18s to 1s? Wow. I wish I had known this for the last 50 page paper I wrote ... so much time wasted on png inclusions. –  Trevor Boyd Smith Jan 3 '12 at 13:54
Ok ... since people seem to be interested in saving time ;-) I need to clarify this a little bit more: It took 18s on my laptop in battery mode (this was, when I wrote the question) ... in high performance mode, it takes "only" 8s. In both modes, the compile time is around 1s using PDF images. The reencoding of the PNG images is somewhat CPU intensive, while for the direct-copy PDF version the hard disk seems to be the limiting device. Still, a factor of 8 in compile time is great! –  porst17 Jan 3 '12 at 14:22

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. :)

-
Hmm ... that palette thing does not seem to be the true reason (according to @patrick). But anyway ... ImageMagick somehow does the job. –  porst17 Jan 3 '12 at 12:57
@porst17: Maybe the "palette" terminology is confusing. :) An image has to have a palette, i.e, a finite set of colors. Perhaps the reason is about the range of the palette, perhaps bounded by the amount of colors pdfTeX can manage. But that's a wild guess. :) –  Paulo Cereda Jan 3 '12 at 13:11