Subject: Color Plates in Electronic Journals

From: [email-masked] (George Seibel)
Date: Sun, 30 Jan 94 16:58:40 -0500

>Dr. Rzepa wrote on Jan 15:
>
>> c) Whether www might be suitable for otherwise VERY expensive
>> color plates?

and Rainer Stumpe of Springer-Verlag replied:

>Well, if you consider a 10 square centimeter (4 by 4 inches)
>color illustration, printed with a resolution of 14.000 dpi, 16
>bit colors, you will either have to sacrifice resolution (300
>dpi, 8 bit colors), or you will have to handle VERY large
>files. I feel, the technology to match color prints is only
>emerging; it might take another 5 years to become generally
>available.

The technology is here today.  First of all, we need to understand the
difference between the use of the term "dpi" (dots per inch) in
printing and in computer image processing.  The printer creates subtle
variations in color by combining many small dots of primary colors (1
bit color) into a much larger cell.  The cell is somewhat analogous to
a pixel that is displayed on a CRT (where the primary colors come from
the phosphor dots on the inner surface of the CRT).  The effective
(pixel) resolution of printed color images in most journals is in the
small numbers of hundreds of dpi, not thousands.  The source of most
molecular graphics images is a workstation screen of about 100 dpi.  If
you displayed a full screendump from an Iris at 14,000 dpi, it would be
about 0.09 inches tall.

Modern image compression software is quite effective at reducing the
storage requirements of images.  In order to demonstrate this, I
generated two images typical of the molecular graphics that are popular
in scientific journals today.  I used UCSF MidasPlus to display a
backbone trace of IL-8, including carbonyl oxygens, amide hydrogens,
and disulfides.  This was colored by atom and depthcued appropriately
on a 24 bit Iris.  I captured a 560x544 pixel screen dump using
imgsnap.  This image was identical to the 24 bit, depthcued image on
the screen.  There were four different colors of atoms (red, yellow,
blue, and gray), yet the variations in intensity due to depth cueing
resulted in a total of only 44 different colors of pixels in the
image.  This may seem surprising but it represents about 4 bits of
depth cueing per color, which is what GL was effectively providing.  I
used free software (toppm from SGI and Jef Poskanzer's pbmplus package)
to convert this image to GIF format.  GIF uses a form of Lempel-Ziv
compression and is a good choice for a mostly monochrome image such as
this.  The resulting file was 11,814 bytes.  This was not a grainy,
postage-stamp sized image.  It was about 6 inches square at 100 dpi,
and was identical in appearance to the original image.  I would not
consider 12 kilobytes to be huge.

The second test image was a 666 by 590 pixel ribbon rendering, sized
such that there was more continuous tone content than black
background.  This image had over 4000 colors.  I compressed it using
public domain JPEG compression software written by Tom Lane's
Independent JPEG Group.  JPEG compression is designed for real-world
photographic images, which have a lot of tonal variation.  JPEG
discards from the image some information to which humans are not very
sensitive.  The amount of information discarded is a user-selected
parameter and may range from a great deal of information loss,
resulting in a degraded image but an extremely small file, to
essentially no information loss, in which case the image is identical
in appearance to the original, but there is not as much compression as
is possible.  Normally one sets the parameter such that the file is as
small as possible while still looking good.  When compressed, the
ribbon image (6.25 x 7 inches on my Iris screen) occupied 39,809
bytes.  Once again, this is a large, beautiful image, very similar in
appearance to the original.  There were some compression artifacts
visible, although they were fairly subtle and did not in my opinion
detract from the image.

So there you have it.  12K for a stick figure and 40K for a ribbon
rendering, both of which looked very good when displayed.  All of the
image processing was done with software available for free on the net.
The decompression and display of the JPEG image took about 3 seconds on
my R4000 indigo using xli for image display.  GIF images can be displayed
very quickly.

I believe that there are no *technical* barriers to fully electronic
scientific journals today.  The barriers are largely political.  If the
text and graphics are compressed with the best currently available (not
to mention free) software, then conventional networking, storage, and
display hardware is adequate for the task.  Much of it is already in
place.

The profusion of journal titles, many of which are egregiously
overpriced, has forced us into a situation where something has to
give.  What gives today is usually our access to the scientific
literature.

George Seibel, SmithKline Beecham
[email-masked]