[pdftex] pdftex compression -- proposed addition to manual

[George N. White III]

On Mon, 20 Aug 2001, Ben Crowell wrote:

>   Thanks, Siep Kroonenberg, for your comments! I took the liberty
>   of incorporating them more or less verbatim into the proposed
>   addition to the manual. Is this OK with you?
>
>   However, this just makes me wish more for an answer to the question
>   I previously posed about what pdflatex actually does with PNG
>   images, since, AFAICT from the Adobe docs, PNG can't be incorporated
>   in PDF without converting to some other format such as JPEG, CCITT,...

This is a misconception -- some PNG files can be translated directly to
the format of a PDF image.  It is easy to see how a PNG image is stored:

1.  create a simple png image
2.  "place" the image using pdftex
3.  examine the pdf file with an ascii viewer

In the pdf file you will see something like:

2 0 obj <<
/Type /XObject
/Subtype /Image
/Width 290 /Height 50
/BitsPerComponent 8
/ColorSpace [/Indexed /DeviceRGB 255 29 0 R]
/Length 14500
>>

For details, consult the Adobe PDF reference manual.

Unfortunately, this subject goes far beyond what can reasonably be
included in a pdftex FAQ.  Image storage requirements are a function of
resolution, color model, and compression method.  PDF supports scaling of
images, so you can store lower or higher resolution than you intend to use
for rendering.  PDF also supports multiple color models and compression
methods.

Image compression technology has made great advances in the past
few years (for example, wavelet methods such as those employed by
JPEG2000 greatly reduce some of the drawbacks of the original JPEG
format).  PDF can be expected to add new methods in the future.

The image support in pdftex is convenient, but for maximum control over
how images are stored, convert each image to pdf using a tool that
provides appropriate resolution, color model, and compression.
Unfortunately, there are lots of tools that do "easy" conversions, and few
(if any) that handle harder cases.  A widely used strategy for pdftex
is to convert images to EPS and then run epsftopdf.  Many tools that
create EPS will use 24-bit RGB color even when the input image is indexed
color, so one needs to understand how images are stored in EPS files
and choose your tools carefully.

One area that causes problems is the handling of "out of gammut" colors.
CRT screens can display "neon" colors that few color printers provide.
People often choose bright colors when creating images, particularly when
the images will be used in WWW displays.  Adobe Photoshop, for example,
usually does an excellent job of printing such files.  Pdftex, however,
gives very poor results when such images are placed directly (e.g., as
PNG), compared to saving EPS from photoshop and using epsftopdf.
Photoshop's EPS files use 24-bit RGB color, so the resulting PDF's are
much larger than those created directly from PNG.

My work involves remote sensing.  We often publish false-color images
where the color scale needs to a) conform to certain conventions
established for each variable, and b) maintain sufficient contrast
in particular areas so the key features remain visible in print (not
to mention that scientific journals are now archived in B&W microfiche
so ideally the features would remain visible in a poor quality printout
from microfiche!).  We have yet to find a simple formula that works
for all images.

-- 
George N. White III <gnw3 at acm.org> Bedford Institute of Oceanography