The site is finished. It looks good. It's ready to be announced. Then the client asks the developer to put on "just one more graphic." They supply a full-screen portrait of their founder, in a 1M TIFF file. This sequence isn't the story line behind a pain-reliever commercial but it could be. Part I, "Writing Great HTML," emphasizes the importance of watching bandwidth: the capacity of users to receive information.
If a page doesn't turn control back over to users within a few seconds, the users may find their way to the "Stop" button instead. Using the formula given in Chapter 4, "Designing Faster Sites," a 1M file would take over 10 minutes to download using a 14.4-Kbps modem.
This chapter shows how high-end graphics-those that display large, complex images-can enhance a Web site. They must be used carefully, however, or they will ruin an otherwise effective site.
The key to building an effective Web site is to measure everything by the standard of effectiveness. Even if a graphic takes zero time to download, it is unlikely that a portrait of the organization's founder would increase a commercial organization's sales.
It is conceivable that a member of a nonprofit organization might like to have a picture of its charismatic leader-and might send in a donation based on that image. Decades of experience in the entertainment industry suggest that distributing posters of recording artists and actors brings in sales at the box office. Used in the right way, a high-end graphic can indeed make a site more effective.
Now suppose that for each pixel, the file format stores 24 bits of information-typically color. That's three bytes per pixel. Before compression, this file takes up 93,312 bytes and needs over a minute to download over a 14.4-Kbps modem.
If a raster file contains random data (if the information in a given pixel is independent of all the other pixels in the file), there is little opportunity for compression. But images are far from random. If a given pixel is set to a particular value, there is a good likelihood that the pixels around it are set to similar values.
The designers of graphics formats take advantage of this fact to build in compression. Compression of 2:1 is common; 10:1 compression is not unheard of.
Designers of raster formats can also decide to get more compression
by making a format lossy. A standard developed by the Joint
Photographic Experts Group (JPEG), for example, computes a mathematical
function that describes the pixels.
| Note |
The word "lossy" means that a graphics format does not preserve all of the information in the original. Most lossy formats, like JPEG, allow the graphic artists to set an acceptable level of loss, using a control called Quality. At all but the very lowest settings of Quality, the information loss is imperceptible to the human eye. |
For a particular graphic, the fidelity of that function can be set to very high or it can be set low. The higher the resolution of the function (JPEG calls it "quality"), the closer the rendered image is to the original and the larger the file is.
For many purposes, the difference between a file with very high quality and a file with moderate quality is invisible to the human eye. Thus, many JPEGs on the Web are set with medium quality to keep their size down.
The use of lossy functions explains why graphic artists are cautioned not to edit JPEG files but to work from the original. When a JPEG file is opened, edited, and saved, the functions must be recomputed. Recomputing functions from data that has already lost some information only causes it to lose more information.
Raster formats are a natural choice for photographs or fine art. Figure 33.1 shows a JPEG of fine art from the Nikka Galleria site, http://www.dse.com/nikka.
Figure 33.1 : A JPEG of "Tattoo Stone Bird," an original work by Dempsey Crane.
Most Web sites have some GIF files, ranging from a few bytes in size to perhaps as much as 100 kilobytes. Many sites also sport a JPEG or two, delivering 24-bit quality in a few tens of kilobytes.
Methods for squeezing those graphics tighter and delivering them faster are in Chapter 4, "Designing Faster Sites." General methods for making a site download faster are also in Chapter 4.
For our purposes, a graphics format is high-end if it stores so much information that a typical image needs more than about 100K. This is a soft definition but it works. Plenty of effective Web pages use Graphical Interchange Format (GIF) and JPEG images of 20K to 70K-those formats are clearly not high-end.
Although the Portable Network Graphic (PNG) format is less popular, it competes well with GIF and is simple enough to serve on Web pages without taking extraordinary measures. Other formats, such as Tagged Image File Format (TIFF), store detailed information about colors with every pixel, making it hard to serve a TIFF in less than several 100K.
High-end graphics formats have these characteristics:
Two-dimensional images come in one of three internal formats:
Raster files view the image as a collection of pixels and store enough information with each pixel to recreate it on a variety of output devices. Raster graphics can be huge-after all, they are storing information about every dot in the image.
Suppose a graphic is displayed as a 2-inch by 3-inch image on a screen with resolution of 72 dots per inch. That file has 144 times 216, or 31,104 pixels. If the image is monochrome, each pixel can be represented by a bit. It is either on or off, black or white.
Many sites have graphics that do not need to be of photographic quality. Incidental graphics as well as maps, cut-away drawings, and illustrated instructions can be displayed using line art and stored in a vector graphics format.
Consider the image of a monochrome rectangle in Figure 33.2. It occupies about two inches by three inches on a 72-dpi screen. If that rectangle is stored in a raster (or bitmapped) format, data for 31,104 pixels must be stored. Before compression, this file occupies 3888 bytes.
Figure 32.2 : Monochrome rectangle.
Now store the same information in a vector format. To re-create the rectangle, the program needs to know that this is a rectangle. It needs to know where the two opposing corners are and the thickness of the lines. With many formats, we can also specify a fill pattern. If two bytes are allocated to each coordinate, the total file comes to about 10 or 11 bytes. Now, that's compression.
Design drawings such as blueprints, schematics, and general computer-aided design (CAD) output are typically stored in vector graphics.
Some of the raster formats (notably GIF) allow a developer to store multiple images in a single file. These images can be retrieved in sequence to form a short animated graphic. This chapter tells you about animation. Chapter 35, "How to Add Video," addresses the use of video on the site.
Real-world graphics are a complex combination of line art, bitmaps, and text. Formats exist to store different kinds of information in a single file. These formats are called metafiles.
Page description language (PDL) files are metafiles that contain specific information about how to render the graphic on a printer. PostScript is the best-known PDL, though the Hewlett Packard Printer Control Language (PCL) is common due to the large number of HP printers. The Hewlett Packard Graphics Language (HPGL) is also popular and can be embedded into an HP PCL file.
One of the hottest new technologies to hit the Net in recent years is ray-tracing software to produce 3-D images. Software such as POV-Ray 3.0, available at http://www.povray.org/ makes it possible for users with a desktop machine to credible ray-tracing.
Ray-tracing is a way of producing photo-realistic images by setting up a three-dimensional model, complete with lighting sources. The model contains information about the color, shape, and texture of each surface. This model is then given to a program which computes for a given point of view what surfaces, highlights, shadows, and colors would be visible from that point.
Ray-tracing can produce stunning graphics, such as the one shown in Figure 33.3. The downside of ray-tracing is that it is slow. On a fast machine, a relatively simple scene can be rendered in a few minutes. On a slower machine with a complex scene, the delay can literally be days.
Figure 33.3 : A three dimensional figure using ray-tracing.
Dozens of ray-tracers are available, each with its own modeling language. Good lists of these tools are available at http://www.povray.org/documents/rayfaq/part1/faq-doc-3.html and http://arachnid.cs.cf.ac.uk/Ray.Tracing/. The latter site also provides pointers to FAQs and general information on ray-tracing.
One of the best ray-tracers is called Persistence of Vision, or
POV. The long-awaited POV version 3.0 is now available at http://www.pov.org/.
This software is free and runs on all popular platforms, including
DOS, Macintosh, and UNIX. The POV site is also a good jumping-off
point for many resources on ray-tracing.
| Tip |
Remember that ray-tracing is compute-intensive. It particularly needs lots of floating-point computations. Do your ray-tracing on the fastest computer you have. The PowerPC processor, now available in both IBM and Apple computers, is particularly strong in floating-point calculations. |
Not all photo-realism is achieved by ray-tracing, though the quality is such that many visitors will assume that all high-quality images are ray-traced.
For most of us, our first exposure to animation came from Disney or Warner Brothers. The animation common in children's cartoons is two-dimensional. Before computers became commonplace, these animations were produced using a technique called cel-based animation. Key frames were drawn by the animator to plot the course of the story. Later, in-betweens were added by interpolating between the keys.
Today, that same technique can be used to produce two-dimensional
computer animation. The animator draws the key frames and lets
the computer morph the key frames to produce in-betweens. A good
reference on morphing is available at ftp://marsh.cs.curtin.edu.au/pub/graphics/bibliography/Morph/morph_intro.ps.Z.
| Tip |
On the Net, many files use nested file suffixes to show how they should be read. For example, .gz files are opened using gzip. Files with .z open with the UNIX utility compress. The .tar suffix means the file is an archive made with the tar utility. .ps means the file contains PostScript. And .uu indicates that the file has been changed to 7-bit ASCII using uuencode. Thus, a file named foo.ps.tar.z.uu would be read by using, first, uudecode, then uncompress, then tar. The result would be a PostScript file which could be viewed in Ghostscript or printed to a PostScript printer. |
Most professional computer animation today is done in three dimensions, using the event-based paradigm. Event-based animation, also called track-based animation, is loosely based on the cel-animation technique described earlier.
The system allows the developer to visualize the world as a series of "tracks" with a time and a value. An "event" is a series of <time, value> combinations that define the track's state. The computer can interpolate between events to provide in-betweens.
Some animation system permit particle animation, in which each animated entity obeys a few simple rules, like "stick close to others like you but not too close." Particle animation is useful for drawing herds of animals or flocks of birds. The animator uses event-based animation on the "leader" particle, then tells each member of the group to stay near the others but to bounce back a bit if it gets too close.
A small random factor is inserted into the motion so the entire herd or flock does not move in lockstep. Now, when the leader starts moving, the particles around it follow. Soon all the particles are moving with the leader, and the animator only has to do detailed animation on a single leader particle.
GIF89a files have the capacity to store multiple images in one file. Using Netscape Navigator 2.0, the user can download such a file and have the browser step through each image quickly, providing a form of animation. A tutorial on using multi-image GIFs is online at http://members.aol.com/royalef/gifmake.htm.
This section provides a few tips and techniques for use with this
method.
| Tip |
Start each frame inside a Bounding Box that does not change from one frame to the next. If you do not provide such a box as a reference point, each frame will inevitably be a few pixels larger or smaller than the last, and the image will appear to jump on the screen as the animation runs. |
Simple animations can be used as decoration or to show a simple sequences of steps. www.vivanet.com/~stevemd/juggle1.htmlSteveShowsHowToJuggle*** teaches the basics of juggling using an animated GIF, as shown in Figure 33.4.
Figure 33.4 : Mechanical skills like juggling can be effectively demonstrated using animation.
| Tip |
Make a dissolve with multi-image GIFs. Attack frames toward the end of the sequence with the spray paint tool. Gradually paint in the GIF's transparency color until the last frame is completely transparent. Do the same thing in reverse to have the image fade in. |
| Caution |
If the sequence ends up with a rainbow of colors, be careful about running out of slots in the color table. To "stake a claim" on the color map, load the global palette into the first frame. Many programs, including GIF Construction Set, support this command explicitly-but you only get this option once. |
When an image is displayed, it remains up for the number of hundredths of a second specified in the control block. Once the timer expires, the browser displays the next frame. There are four choices for what to do with the image just displayed, which you choose using the Remove By option in GIF Construction Set:
| Tip |
To set the GIF to loop continuously, set the number of iterations to loop to zero. Your users will appreciate it if you set the animation to end after a few seconds, or to have long delays between frames, or both. |
Listing 33.1 shows another CGI script from Matt's Script Archive at http://www.worldwidemart.com/scripts.
Listing 33.1 animation.pl-This Script Is an Example
of Server Push Animation
#!/usr/bin/perl
# Animation Perl Script
# Written by Matt Wright
# Created on: 9/28/95 Last Modified on: 11/21/95
# Version 1.2
# I can be reached at:_mattw@misha.net
# Scripts Archive at:_http://www.worldwidemart.com/scripts/
# Consult the file README for more information
and Installation Instructions.
#########################################################
# Variables
$times = "1";
$basefile = "/WWW/images/animation/";
@files = ("begin.gif","second.gif","third.gif","last.gif");
$con_type = "gif";
# Done
#########################################################
# Unbuffer the output so it streams through faster and better
select (STDOUT);
$| = 1;
# Print out a HTTP/1.0 compatible header. Comment this line out if you
# change the name to not have an nph in front of it.
print "HTTP/1.0 200 Okay\n";
# Start the multipart content
print "Content-Type: multipart/x-mixed replace; boundary=myboundary\n\n";
print "--myboundary\n";
# For each file print the image out,
and then loop back and print the next
# image. Do this for all images as many times as $times is defined as.
for ($num=1;$num<=$times;$num++) {
foreach $file (@files) {
print "Content-Type: image/$con_type\n\n";
open(PIC,"$basefile$file");
print <PIC>;
close(PIC);
print "\n--myboundary\n";
}
}
This script takes advantage of the multipart/x-mixed MIME type. The server sends the first file down, followed by the boundary string. As soon as the client sees the boundary string, it knows to prepare for another file, replacing the one it just got. If the link is fast enough, the effect is a form of animation known as Server Push, or MIME-based.
To work in its present form, the script must have a name that starts with nph-. This notation, which stands for "no parse header," tells the browser that the script will handle the required http headers.
Recall that Netscape supports the REFRESH function through the META tag. A page can use this feature to "time out" and request that the client send a new page down. That next page can also time out and request its successor. If the connection is fast enough, the result is a form of animation known as client pull.
A limiting factor with both server push and client pull is that both Java and JavaScript allow the programmer to put an image on the page. By moving the image around or putting up a succession of images, the programmer gives the appearance of motion. Figures 33.5 and 33.6 are illustrations of this.
Figure 33.5 : An animation example from Matt's Script Archive.
Figure 33.6 : This is the same shot with the picture moving further across the screen.
Information on Java is available at http://java.sun.com/. There is a strange but useful tutorial on Java programming at http://www.neca.com/~vmis/. That tutorial illustrates image manipulation and the use of the RGB color map. The standard description of JavaScript is on Netscape's site, at http://home.netscape.com/comprod/products/navigator/version_2.0/script/. A good tutorial is located at http://rummelplatz.uni-mannheim.de/~skoch/js/script.htm.
PHP/FI is a server-side HTML-embedded scripting language, not unlike JavaScript. The package is documented at http://www.vex.net/php/, and includes myriad capabilities. Its database access functions are described in Chapter 18, "How to Query Databases."
PHP/FI allows the programmer to call Thomas Boutell's GD image
library and generate GIF images on the fly. A developer can combine
this feature with Server Push to produce animation on the fly.
| Caution |
Done well, on-the-fly animation is a big traffic builder. Since generating each frame at runtime requires extensive computations, consider building as many components as possible ahead of time and then combining them at runtime. Get a fast server and wide connections to make this technique work well. |
On many Web sites, it is enough to put up a color image and leave it at that. But if the subject is artwork or other material where the exact colors matter, high-end graphics must be used.
Our perception of color is a complex process, depending on the prevailing light, the chemistry of interacting pigments, and a good deal of psychology. This section provides an overview of the science of colorimetry, or color measurement, as it applies to high-end graphics that can be displayed on the Web or downloaded from a Web site.
The color our eyes see depends in part on how it is produced. The sun and many light bulbs produce light that contains many different colors added together. This color is commonly called white light.
Our understanding of this kind of color goes back to the work of Sir Isaac Newton, who discovered that almost all colors can be produced by adding quantities of just three colors: red, green, and deep blue (RGB).
Formally, these colors are called the primaries or additive primaries for additive color mixing. When two of the primaries are mixed, they produce the complementary color of the third. The following table shows this effect:
Color 1_Plus_Color 2_Gives_Which Complements
Red__Green_Yellow_Deep Blue
Red__Deep Blue_Magenta_Green
Green__Deep Blue_Cyan_Red
By mixing various quantities of light from the three primaries, you can form many colors.
Additive color is the proper model to use when light arrives at the eyes directly from a light source, such as a computer screen. When the light reflects off a surface such as a printed page before we see it, its color is described by a subtractive process.
The subtractive primaries are cyan, magenta, and yellow-the very colors that complement the additive primaries. Paints, inks, and dyes can be applied to surfaces to change the way colored light is absorbed into the page. Any light not absorbed is reflected back to our eyes.
If a white light shines on a page with an ink that absorbs the complement of yellow (deep blue), the remaining light (containing everything except deep blue) reflects to our eyes and we see yellow. For this reason, yellow is sometimes called minus-blue by color specialists.
Likewise cyan (minus-red) absorbs red light and magenta (minus-green) absorbs green light. Mixing all three subtractive primaries theoretically causes the surface to absorb all colors and appear black.
In practice, the exact shade and density of black depends on the chemistry of the interacting pigments. Because black is such an important and common color, printing experts do not usually try to produce black by overlapping cyan, magenta, and yellow inks. Instead, they make one pass with black ink.
When displaying colors on a color monitor, graphic artists use the additive model: RGB. When they think about the printed page, they use a subtractive model: cyan, magenta, yellow, and black (CMYK; the "K" stands for black).
Recall that most colors can be produced by adding various mixtures of red, green, and blue light. Likewise, most colors can be produced on a printed page by adding various combinations of cyan, magenta, and yellow pigments.
To make matters more complicated, the colors that are not reachable in the RGB model are not the same colors that are unreachable in the CMYK model. The process of converting an RGB image into a CMYK image is not perfect. Some formats, such as TIFF, provide explicit support for the CMYK color model.
In addition, the color of a pixel depends not just on its RGB values (the hue) but on the relative amounts of white (the value) and the saturation of the hue (the chroma). Numerous classification systems have been proposed. The standard is set by the Commission Internationale de l'Éclairage (the International Commission on Illumination).
For more information on the CIE color model, see http://www.inforamp.net/~poynton/Poynton-colour.html. When using the CIE system, you can specify any color. However, the CIE system is not computationally efficient. For most images, only a handful of the millions of possible colors are needed.
For use on computers, you need a color-coding scheme rather than a color-specification scheme. For example, a manufacturer of nail polish uses a color-specification scheme to describe exactly what is meant by the color "coral" but uses a color-coding scheme to cause that color to appear on-screen.
Some formats store color using a hue, saturation, and intensity (HSI) model. The hue describes what most of us think of as color. Saturation measures how much color is present and ranges from neutral gray through pastel to saturated color. Intensity is more akin to brightness and ranges from black to white. Brightness is largely a function of the user's monitor.
The human eye is more sensitive to colors in the middle of the spectrum (around green), so if the monitor is built to have equal radiance across the spectrum, greens appear brighter to the user than, say, reds. The better monitors take this fact into account.
Thus, the weights to compute true luminance from linear red, green, and blue have changed over the years as the nature of the phosphor on the screen has changed. CIE Recommendation BT.709, "Basic Parameter Values for the HDTV Standard for the Studio and for International Programme Exchange (1990)," gives the recommended weights for current phosphors.
For a given monitor, the amount of light produced from the screen varies nonlinearly with respect to the applied signal. Doubling the applied voltage produces approximately a 5.66-fold increase in intensity. The exponent in this equation (approximately 2.5) is called the gamma of the monitor.
When you take pictures of real images, the camera applies a correction (called gamma correction) to take into account the screen's gamma. When the image is intended for television, the camera deliberately underestimates the gamma of the television screen so the image is suitable for viewing in a dim room.
Some images on the Net have had no gamma correction. Others have been gamma-corrected for TV screens. Still others have been gamma-corrected for CRTs. Gamma correction should be applied once; for use on the Web, a reasonable value is 2.5. If an image has not been gamma-corrected, the midtones appear dark and murky. If gamma correction has been applied twice, the midtones appear too light.
If the image is designed for use in a dim environment like television, it has too much contrast when viewed on a bright computer monitor. When you apply a correction function with a power of 1/1.1 or 1/1.2, the contrast of the image looks more natural on a computer screen.
Remember that most computer monitors are not designed for sophisticated images. They often ignore the international image standards or provide users with a control labeled Gamma to let the users manipulate the transfer function themselves. (By convention, gamma correction is applied at the source.)
The gamma of a good CRT is about 2.35 to 2.55. If the originator
uses a transfer function with a power of 0.45, the image quality
should be acceptable on most monitors.
| Caution |
Many graphics libraries, input devices, and applications make some attempt at gamma correction. Take these transfer functions into account when applying gamma correction to any image you produce. |
Gamma correction should be applied before the image is delivered
to the user. GIF and palette-color TIFF files have their own color
map in the file. That color map should be gamma-corrected so that
it can be presented directly to a CRT.
| Tip |
To show users how to set up their monitor's brightness and contrast controls, refer them to |
The above discussion applies to color images such as photographs. Spot color can be produced using a precise combination of inks. The popular PANTONE system is based on proprietary inks that closely match standardized colors.
Some high-end applications allow users to specify spot color using the PANTONE number. Graphic formats like TIFF allow the application to save that color in an additional sample and give the ink for that sample the proper PANTONE name.
To fully specify a pixel, a developer would want to specify the red, green, and blue values of the hue, the saturation, and the brightness. Some image formats, such as TIFF, allow all this information to be stored in each pixel. Such images are called full-color or true-color images.
The quality of these images is excellent. The tradeoff is that the size of the file becomes quite large. Various compression schemes can reduce the overall size somewhat, but the image is still likely to be over a megabyte-far too large to include directly on a Web page. Since most images do not need millions of colors, designers have achieved significant compression using indexed color schemes.
The palette afforded by 256 levels of red, 256 levels of green, and 256 levels of blue offers 16,777,216 colors. No image uses all these colors. Indeed, many computer video systems can't display more than a small selection from this palette at once. So many graphics designers reduce image size by using indexed color, also called palette color or pseudocolor.
In this scheme, the computer scans the image and reads the color of each pixel. Each distinct color is stored in a table, up to some maximum table size such as 255 entries. Then the RGB color value of each pixel (say, three bytes) is replaced by a pointer into the color map. If there are 255 entries in the color map, the pointer only needs one byte and the overall image size shrinks by nearly two-thirds.
Some systems provide a predefined color index. Encoding red, green,
and blue each in six levels (0 through 5) gives a 6 ¥
6 ¥ 6 "cube" of 216
distinct colors. Other systems fill the color table based on the
actual colors in the image, up to a limit such as 255.
| Note |
The human eye is sensitive to differences in hue of less than one percent. If the length of an "edge" in the color cube is less than around 100, many images are rendered with noticeable banding or contouring. This effect can be seen when fewer than seven bits are used to encode each pixel |
.
If the image is particularly rich, it may have more than 255 colors. Some systems replace pixels of one color with pixels of a close match from the color table. Colors not available in the color table can also be dithered-produced by mixing colors in the lookup table.
Suppose a region is to be colored in #21FF1D. Red has value 33 (21 in hexadecimal) out of 256, green has value 256 (FF in hex), blue has value 29 (1D in hex), and the color table has no more room. One approach might fill the region with alternating pixels of #17FF1C and #25FF1E, colors in the color map. Dithering works because the pixels are small. The human eye integrates the actual pixels present to produce a color that is not actually present on the screen.
Depending on the size of the color map, the colors already present,
and the sophistication of the software, this process can produce
an image almost indistinguishable from the original-or it can
produce a hideous mess, with blue sunsets and orange apples. When
producing images with indexed colors, try to keep the number of
colors smaller than the format's color map.
| Caution |
Once the image arrives on the user's desktop, it may have to share space in the color map of the computer's video card. Some slots in that table will have been taken by the browser. Others may have been taken by other images on the page. Use tools like DeBabelizer to force multiple images to share one color map. |
Standardization and innovation often compete. The world of graphics formats is an example of this competition. To ensure that graphics are readable by as many people as possible, we want just a few stable formats. To make sure that graphics can take advantage of the latest research in compression, we wish for a new format every day.
In practice, the Web is dominated by two standards (GIF and JPEG), with perhaps a dozen or so other formats that offer special capabilities and are widely available on most platforms.
The Virtual Reality Modeling Language (VRML) stores information about 3-D objects. Chapter 36, "The Third-Dimension: VRML," describes VRML.
Multimedia file formats store graphics, sound, and video. The most popular multimedia format is a Moving Pictures Experts Group (MPEG) standard. The video aspects of MPEG are discussed in Chapter 35, "How to Add Video." Chapter 34, "How to Add Sound," describes the MPEG audio channel.
To read most of these formats from the Web, the user must install a "helper application." Figure 33.7 shows http://www-dsed.llnl.gov/documents/wwwtest.html, a site that describes a variety of formats for use on the Web and gives information about obtaining and installing helper applications on UNIX machines, PCs, and Macintoshes.
The standard online description of graphics file formats is the graphics/fileformats-faq, maintained by James Murray. The latest version of this FAQ is available at ftp://rtfm.mit.edu/pub/usenet/news.answers/graphics/fileformats-faq. An HTML version (which may not be as current) is available at www.smartpages.com/faqs/graphics/fileformats-faq/faq.html.
One of the most common high-end graphic formats is the TIFF. Ask most graphic artists what they develop when they produce an image and they will tell you they make TIFF files. While they may later save the file as a GIF or JPEG, they do their day-to-day work in TIFF. They do this because TIFF is a rich format-it never throws away information about the image.
TIFF files are complete to the point of being enormous. Starting with a TIFF file, a developer can produce a file in almost any raster format. TIFFs are also commonly used as the output of scanning software.
One of the features of TIFF that adds a bit of complexity is the fact that TIFF is extensible and even supports private extensions. It is entirely possible for a user to produce a file that conforms entirely to the TIFF specification, only to find that that file can't be read by a different application.
To reduce this confusion, the TIFF standard discourages developers from calling their output "TIFF" if they use proprietary extensions or proposed extensions that have not yet been incorporated into the standard.
This section focuses on the so-called Baseline TIFF. All TIFF files can be expected to conform to the baseline requirements. Information on TIFF extensions is available in the TIFF specification.
TIFF files consist of a header and one or more Image File Directories (IFDs). There can be more than one IFD in a file. Each IFD describes an image. Each image can be bi-level, grayscale, palette-color, or full-color. Recall from Chapter 5, "Designing Graphics for the Web," that some raster formats, such as GIF, store an index in each pixel that points into the color palette. That palette contains descriptions of colors in terms of RGB.
TIFF palette-color files are built on the same principle. This section describes the structure of a full-color image-that has no color table. Details on the other formats are available in the specification.
A full-color TIFF image (also called a TIFF RGB image) consists of at least the following fields:
If the PhotometricInterpretation field contains a 2, the image is full-color.
ImageWidth and ImageLength are measured in pixels, and give the number of pixels per row and the number of rows, respectively.
BitsPerSample and SamplesPerPixel work together. Recall that the number of bits in a number measures the number of things that number can count. (A 1-bit number can count up to two, a 2-bit number can count up to four, and so on.)
TIFF RGB color images have three samples per pixel. One sample gives the measure of red in that pixel, another of green, the third of blue. Each sample is stored in an 8-bit number; 8 bits can store 256 discrete values so each pixel contains one of 256 different levels of red, one of 256 different levels of green, and one of 256 different levels of blue.
An application can also include additional samples, typically used for noncolor information such as opacity and transparency.
With all this storage of all these pixels, full-color TIFF files can become uncomfortably large. The Compression field defaults to 1: no compression. Setting it to 32773 says that the image has been compressed using a run-length compression algorithm.
In addition to the previously mentioned fields, TIFF affords support for dithering and half-toning, transparency (through an AssociatedAlpha field), and orientation. The AssociatedAlpha field allows the developer to specify a premultiplier for the pixel. If the premultiplier is zero, that pixel is transparent. Using graphics with transparent backgrounds, a developer can assemble new images out of components.
TIFF allows support for the Lempel-Ziv-Welch (LZW) compression algorithm. Recall from Chapter 5, "Designing Graphics for the Web," that LZW was included in many software standards based on the assumption that it was in the public domain.
The patent holder, Unisys, has asserted its rights under the patent. Software developers who use the LZW algorithm are required to obtain a license from Unisys. There are no licensing requirements on the users of LZW-compressed files. The TIFF standard allows, but does not require, a variety of compression schemes, including LZW.
By default, TIFF RGB files assume a gamma of 2.2. Advanced users can set the GrayResponseCurve or TransferFunction field for gamma correction.
The RGB color model is most appropriate for images that are to be displayed on a computer screen. When an image is intended primarily for printing, you should use CMYK encoding. In color prepress work, a color separation is prepared that shows which portions of the image should be printed with cyan ink, which with magenta, which with yellow, and which with black.
Many applications are available to store CMYK values in a TIFF
file. Remember, too, that some colors are not reachable in the
CYMK model. TIFF supports adding additional samples to each pixel
(at the expense of size) to capture more colors and get a higher
fidelity.
| Tip |
The Macintosh power function is almost the same as that of offset printing. For quick results with good quality, design the graphic to look right on a Macintosh monitor, then send it to the offset printer. |
Remember, too, that the translation between RGB and CMYK is not perfect. Translating an RGB image to CMYK and back again generally does not yield the exact same starting image. When an application writes a CMYK TIFF file, it sets the PhotometricInterpretation field to 5 (for Separated), it sets the InkSet field to 1 (for "CMYK"), and it typically uses NumberOfInks=4.
Commercial printers use a process called halftoning to put graphics on a page. Halftoning uses dot size to convey brightness and saturation. An array of small dots printed on white paper produces an image with low saturation-lots of white shows through. As the dot size increases, the amount of color increases and the amount of white diminishes. The screens for cyan, magenta, yellow, and black have the same pitch but different angles.
An image designed for halftone printing specifies each pixel in terms of the dot percentage in the film. The TIFF DotRange field indexes the 8-bit sample to describe how much ink should be applied to produce a 0-percent dot and a 100-percent dot.
If the 0-percent dot is set at, say, 20 hex and the 100-percent dot is set at 200 hex, then a pixel with a CMYK value of 20, 50, 200, 20 produces no output on the cyan separation, a 27-percent dot on the magenta pass, a 100-percent dot on yellow, and no black.
TIFF 6.0 supports a HalftoneHints extension field. High-end graphics applications use it with all images. It can improve the quality of screen images as well as print images, and is applicable to monochrome as well as color.
HalftoneHints help tune the contrast based on the "keyness"
of the image, the absolute range of the image, and the dynamic
range of the output device (such as a printer). For most images,
artists should specify a normal key. The normal key brings up
the contrast of the midtones at the expense of the lighter and
darker tones. If the important information is in the darker tones,
artists should switch to a low key. For images with important
information closer to the white end, a high key is appropriate.
| Note |
Automatic computation of the key can only go so far. The image of a bride in a white wedding dress might have information important to the bride's parents (like her smile) in the midtones, but information important to her dressmaker (like the details of the gown) at the high end. It is up to the artist and the Web site developer to decide which part of the range to emphasize. |
Offset printing has a transfer function (gamma) just as monitors do. During the printing process, the dot of ink is flattened and smeared, enlarging the spot of color. The ink is also absorbed to some extent (depending on the characteristics of the paper). These two factors combine to form dot gain.
Typical offset machinery has a dot gain of about 24 percent on 50-percent dots. The graphic artist expects to see 50-percent absorption but gets about 74 percent. The exponent of the power function is about 1.75, compared to 2.2 for video and 2.5 for computer monitors.
High-end software allows the user to specify the parameters of
dot gain compensation in a manner analogous to gamma correction.
| Tip |
Agfa Corporation distributes a booklet that addresses the practical issues of getting high quality in print. Call their Prepress Education Resources staff at 1-800-395-7007 and ask about "An Introduction to Digital Color Prepress," volumes 1 and 2. |
Different printers have different capabilities. You can produce a series of CMYK TIFF files, each for a different printer. TIFF uses the TargetPrinter field to name the printing environment for which each of these color separations is intended.
For more device independence, vendors such as Agfa, Kodak, and Electronics for Imaging (EFI) offer color management systems (CMSs)-software that negotiates color between the application and color devices. Sun is planning to use Kodak's CMS in Solaris. Apple's ColorSync offers similar functionality for the Macintosh.
As TIFF readers become more intelligent, you will be able to store
the image in a device-independent manner such as YCbCr (described
in the following section) and have the reader and its color management
system deal with producing the desired results.
| Tip |
Aldus Corporation has several online guides to color publishing. Visit their site at http://www.adobe.com/. In particular, check out the index at http://www.adobe.com/ptx.html for a complete list of online documentation. |
TIFF supports colorimetry with such fields as:
Using the values in the above fields, TIFF supports a transformation from RGB to the Commission Internationale de l'Éclairage (CIE) 1931 XYZ color-matching functions. CIE XYZ is the international standard for color comparison and is device-independent.
Once an application has enough information to transform an image into XYZ format, it can negotiate with the output device to transform the image again to meet the device's requirements and give high-quality output.
WhitePoint contains a pair of rational numbers that specify the chromaticity of the white point of the image in terms of X and from the CIE XYZ model. Color experts typically recommend that white be set to a daylight standard, CIE Standard Illuminant D65, or a compromise standard (between indoor and daylight), D50. The WhitePoint values for D65 are 3127/10000 and 3290/10000 and are built into high-end graphics programs.
The CIE-recommended primary chromaticities are
Red_640/1000_330/1000
Green_300/1000_600/1000
Blue_150/1000_60/1000
Most monitors are close to these values, so users without a CMS will see the image in something close to the colors of the original.
Unless there are reasons to use a special transfer function, set the TransferFunction field to the Recommendation 709 transfer function, which has a 0.45-power law gamma correction. If the image will be viewed primarily on a Macintosh, set the transfer function to 1/1.8-power.
Digital video is a distinct file type in TIFF, called TIFF YCbCr, and based on CIE Recommendation 601-1, "Encoding Parameters of Digital Televation for Studios." The Y in YCbCr refers to luminance. Cb and Cr refer to two chrominance components.
When using YCbCr, be sure the application sets the YCbCr coefficients field to the Recommendation 601 standards of 299/1000 for LumaRed, 587/1000 for LumaGreen, and 114/1000 for LumaBlue, the Reference White to 235, and the Reference Black to 16. These values allow intelligent TIFF readers to give the best possible results.
Another emerging device-independent color encoding system is CIE L*a*b (CIELab). CIELab is in the public domain with many advantages over the RGB model. It is likely to be available in next-generation high-end applications.
TIFF is a proprietary format developed by Aldus Corporation and Microsoft. It is maintained by an industry working group called the TIFF Advisory Committee. The specification for TIFF 6.0 is available through http://www.cica.indiana.edu/graphics/image.formats.html.
The next-generation TIFF, called Transport Independent File Format for Image Technology (TIFF/IT), is under development by the ANSI IT8 committee and ISO. One goal is to identify a subset of the TIFF tags that are appropriate for prepress applications so that interoperability between TIFF implementations is enhanced.
Strictly speaking, there is no "JPEG graphics format." The format most people on the Web think of as JPEG is actually the JPEG File Interchange Format (JFIF). JFIF uses the JPEG compression algorithm. For many reasons, the "JPEG" name stuck, but be aware of this difference since some graphics software do use the JFIF name.
The Joint Photographic Experts Group (JPEG) determined that no one compression algorithm could meet everyone's requirements, so they defined a "toolkit" of compression algorithms. TIFF files can be compressed with a lossy JPEG algorithm based on the Discrete Cosine Transform (DCT).
As mentioned in Chapter 5, "Designing Graphics for the Web," the term "lossy" is used here in its mathematical sense. At most quality settings, there is little or no change in the visible image quality. The DCT can also be applied to TIFF grayscale images, as well as RGB, CMYK, and YCbCr.
The standard color space for JFIF is YCbCr as defined by Recommendation 601. In accordance with this standard, the software converting the YCbCr values back into RGB does not apply any gamma correction.
The JFIF also supports a thumbnail so applications have a small copy readily available without decompressing the entire file. Thumbnails are typically stored with one or three bytes per pixel.
JFIF seems tailor-made for the Web. The image shown in Figure 33.8 was derived from a TIFF file over 1M long. The JPEG (JFIF) version is less than 32K.
Figure 33.8 : JPEG graphic built from large TIFF file.
The Computer Graphics Metafile (CGM) is a U.S. and international standard (ANSI/ISO 8632:1992[1994]) for graphics data interchange. It is a two-dimensional standard independent of any particular computer or operating system. As the name implies, it is a metafile standard.
CGM files can contain vector graphics, raster graphics, and text. CGM is commonly used to exchange technical documentation and illustrations, and is known for its strong vector-graphics capability. CGM has been adopted by the U.S. Federal Government as a Federal Information Processing Standard (FIPS 128-1), which has led to widespread support in the technical illustration community.
CGM version 1 supports basic drawing and picture capability. Many applications are available that support CGM version 1. Version 2 introduces about 30 new graphical elements, including the graphical segment-a group of graphical elements that can be named and referred to throughout the file. Version 3 adds about 40 new elements, including compressed tiled raster images, external symbol libraries, and greater drawing control.
CGM is a comprehensive standard. Some applications implement only a subset of its capabilities, leading to incompatibility between applications. To help solve this problem, the CGM standard encourages the use of application profiles.
An application profile identifies which elements of CGM meet a particular class of requirements. Profiles are available for the Airline Transport Association and Airline Industry Association (called the ATA profile), military logistics (called the CALS profile), and the petroleum exploration and production community (called the PIP profile).
Amendment 1 to the 1992 standard introduces the Model Profile, which can be used as a guide to writing profiles, and the Profile Proforma (PPF), a set of tables to be used as a template by profile writers.
Amendment 2 of the CGM standard introduces the concept of application structuring extensions. Applications can use these extensions to define "intelligent graphics." Such graphics could draw components from external databases distributed across the network and hyperlinked into comprehensive documents.
Figure 33.9 shows a representative CGM image.
Figure 33.9 : CGM is a vector format-each part of the image is a line or a region.
A particularly rich application for using CGM and many other standards is ForReview, a commercial markup application from the Advanced Technology Center. ForReview is described at http://www.atc.com/PRODUCT_DOCS /docimg.html.
PostScript is best known as a page description language (PDL). Some people are familiar with Display PostScript, used as the screen language on Next computers. This section looks at the potential for PostScript to offer high-end graphics through the Web.
Most of the applications that read PostScript are printer drivers-those that don't look a lot like printers. GhostScript, for example, is a popular program that allows PostScript files to be displayed to the screen. It brings the pages up one at a time, allows the user to view them, and then moves on to the next page, in a manner reminiscent of a printer.
PostScript is, in essence, a programming language for describing how to print a page. It contains many powerful primitives for precisely controlling the layout and appearance of the page. The PostScript code is often written by another piece of software.
For example, Apple Computer, which introduced PostScript into their LaserWriter line of printers in 1985, bundles a LaserWriter driver into their system software. Macintosh applications use Apple's proprietary QuickDraw software to put images and text on the screen.
When the user chooses Print, the LaserWriter driver reads the QuickDraw commands that render the on-screen image and translates them into PostScript. Then it sends the resulting PostScript program to the printer, where it is interpreted.
Most PostScript printers have a fairly powerful processor, including large amounts of memory and sometimes even disk drives, to enable the interpretation the PostScript program. The process of interpreting and executing the program causes the page to print. Within limits, the faster the printer's computer, the faster it prints.
To PostScript, everything is a graphical element, including text. To print text, the program must specify a location and a font. For example, the code in Listing 33.2 causes the classic "Hello, world!" text to be printed:
Listing 33.2 hello.ps-Program to Write "Hello,
world!"
%!PS-Adobe-1.0 %%Title: Hello, World! %%Creator: Michael Morgan %%CreationDate: Sat March 23 11:29:03 1996 %%For: Webmasters... Chapte 33 %%Pages: (atend) %%DocumentFonts: (atend) %%BoundingBox: 0 0 612 792 %%EndComments %%EndProlog %%Page: 0 1 /page1 save def /Helvetica findfont 12 scalefont setfont 288 720 moveto (Hello, world!) show showpage /page1 restore %%Trailer %%DocumentFonts: Helvetica %%Pages: 1 /page1 save def_% snapshot virtual memory--call it page1 /Helvetica findfont_% look for and load the named font 12 scalefont setfont_% set 12-point Helvetica as the default 288 720 moveto_% prepare to draw at the specified coords. (Hello, world!) show_% draw the text showpage__% output the page /page1 restore_% restore the snapshot
Most of this program is comments (lines that begin with %%), but comments play an important role in PostScript. The program itself begins with the line /page1 save def and ends with /page1 restore.
A page description can be organized into various sections using properly formatted comments. The prologue contains application-dependent definitions; the script describes the results to be output in terms of those definitions. The body can be broken up into pages by comments.
Within each page, it is customary to begin with a save and end with a restore. This technique allows a user to ask PostScript to print, say, page 5, without PostScript having to run the programs for the first four pages to find out where page five starts.
These conventions are defined by the Adobe Document Structuring Committee (DSC). If a PostScript program conforms to both of these conventions, other programs can perform useful services for the user, such as printing in reverse order or printing a range of pages.
Programs that observe the conventions are called conforming. Programs that provide only the %!, %%DocumentFonts, %%EndProlog, %%Page, and %%Trailer comments are minimally conforming. Other programs are nonconforming.
PostScript supports both the Hue-Saturation-Brightness (HSB) and the Red-Green-Blue (RGB) color models. PostScript also supports a form of gamma correction through the setgray and settransfer operators.
As PostScript grew in popularity, the designers realized it had potential as a graphics file format as well as a PDL. Encapsulated Postscript (EPS) files contain a single-page, DSC-conforming PostScript program, optionally bundled with a bitmapped image preview.
On Macintoshes, the preview is stored in PICT format. On DOS and Windows machines, the preview is typically a TIFF. On any machine, a special format called EPSI can also be used for the preview. EPSI is an ASCII representation of a bitmapped image.
Using a graphically oriented word processing program, users can embed EPS graphics in a document. If the EPS has a preview, users see the preview; otherwise, they get an empty box of the proper size. (Many applications put diagonal lines in the box to help keep the user oriented.)
When the document is printed, the program inside the EPS runs, adding its output to the document. Many high-end clip art libraries are based on EPS since it allows complex graphics to be stored in compact vector format.
To convert a PostScript program to an EPS file, make sure the program does not make any permanent changes to the machine. For example, it should not use any of the init commands, such as initgraphics. It should also not make any assumptions about its environment since that is under the control of the calling application.
The PostScript Red Book (PostScript Language Reference Manual, Addison Wesley, 1985) lists the operators that can't be used in an EPS file. The Red Book also shows warnings about some operators, which may be used carefully, and lists the needed comments (Creator, Creation Date, Title, and Bounding Box). When satisfied that a program can legitimately be called as an EPS file, the programmer changes the first line to:
%!PS-Adobe-2.0 EPSF-2.0
The Frequently Asked Questions list for PostScript is maintained at http://www.cis. ohio-state.edu/hypertext/faq/usenet/postscript/faq/part1-4/faq.html. Figure 33.10 shows a representative EPS graphic.
| Note |
PostScript was introduced in 1985, just a year after the Macintosh was announced. The next generation of PostScript is PostScript Level 2. It integrates over a decade of PDL experience into one new language. Some of the extensions developed over the years include Color PostScript and the Composite Font Extensions. |
If these features are important for your applications, be sure to get a printer which supports PostScript Level 2. Most new printers do-many older printers do not.
Color PostScript was introduced in 1988 with RGB and HSB color models. Extensions have included CMYK, black generation, and undercolor removal functions.
The composite font technology extends PostScript to handle large character sets and nonhorizontal writing modes, such as those typical of Asian languages.
Level 2 also includes new compression technology (including Run Length encoding, Lempel-Ziv-Welch lossless encoding, and DCT lossy encoding). New operators optimized for graphics and text have been introduced, the CIE 1931 XYZ-space is supported, and native handling of indexed color and color separations is available. A richer set of screening and halftoning options is built into the language.
The downside of using PostScript and EPSF is that both formats are still in their hearts PDLs. Web users generally want to see an image on the screen and only incidentally to print the file.
Adobe has addressed this need with their Portable Document Format (PDF) and Acrobat software. Since Adobe has developed Acrobat readers for Macintosh, Windows, and UNIX computers and distributes them for free, the format is becoming quite popular.
To produce PDF files, obtain Adobe Acrobat Exchange (a commercial product). Once installed, Acrobat Exchange looks like a printer to application software. Printing to Exchange writes a PDF file to the disk. Adobe also offers Web-Link and Movie-Link, which allow you to put hyperlinks to URLs, or to QuickTime or AVI movies in the file.
The latest generation of PDF is code named Amber. Amber is tightly integrated with Netscape Navigator, using a Netscape plug-in, so PDF documents come up in the browser's window. Designers now have two choices for displaying content.
For most purposes, HTML suffices. When the appearance of the file must closely match the appearance of the original, however, PDF is indicated. Typical applications are handbooks, manuals, proposals, and online magazines that need a distinctive look and feel.
PDF files are much larger than the corresponding HTML documents. Unlike HTML, PDF contains all the information necessary to duplicate the original document: fonts, kerning information, positioning data. Until the introduction of Amber, this was a significant deterrent to the use of PDF. Amber allows the PDF to be displayed a page at a time, instead of after the entire file has downloaded.
To serve documents a page at a time, the server must have byteserver capability. Future versions of Netscape and Open Market's servers have promised this capability. In the meantime, Adobe will distribute a CGI script that enables byteserving.
For full details, as well as links to download the reader, visit http://www.adobe.com/Amber/amberfaq.html. A representative page from a PDF file is shown in Figure 33.11.
Figure 33.11 : A PDF file showing an article from the New York Times.
Once the decision is made to offer high-end graphics, the Webmaster must decide how to get those images into the hands of the user. The one option not to choose is to put a 1-Mbyte file on the home page of the site, letting users discover it when the page takes 10 minutes or more to download!
For many applications, it is not necessary to deliver the graphic online. Online art and poster galleries, for example, use the Web to show low-resolution samples of their stock. Once the user has made a selection, the actual work is shipped using conventional means. This approach works in a surprisingly large number of cases in which a client wants to get high-resolution graphics into the hands of the user.
Sometimes the objective is to get the file into the user's hands, but there is no need for the graphic to be viewed on a Web page. If the site includes an FTP server, put the image file in the FTP document tree and allow the user to download it. Users who won't wait 10 seconds for a Web site to open will patiently spend an hour or more to download the files they want.
| Caution |
If you allow uploading to your FTP site, restrict it to a special "incoming" directory that is not in the directory tree. Allowing a user to upload a file and then access it via the Web opens a security hole. The user might upload an arbitrary CGI script and be able to execute it. |
To save download time, compress the graphics before storing them
on the FTP site. GZip is available for all platforms and is among
the tightest compression programs around. Most PC users have PKZIP
installed on their disk. Most Mac users have one of the programs
that can decode binhex (the .hqz
suffix). If you have enough disk room, provide several alternative
compression approaches, as well as one uncompressed version, and
let the user decide.
| Tip |
Before spending a lot of time compressing every file, try a few representative graphics. Many graphics formats are already compressed and there is little opportunity for other compressors to further reduce the size. |
If you absolutely have to put a high-end graphic on a Web page, there's a right way and a wrong way. As mentioned previously, the wrong way is to just put it up there and hope users are patient. To understand the right way, let's first look at how graphics and other files are served by a Web server.
Suppose a request comes in to the server for a particular file, say, /path/to/my/file.xyz. The server finds that the file exists. Permissions are OK so the server is ready to send it out. Recall that HTTP needs the server to announce the file's MIME type. How is the server to know what kind of file it is serving?
NCSA and Apache servers have a configuration file called mime.types. In that file is a list mapping file extensions to MIME types. A typical entry looks like this:
application/pdf_pdf
This entry says that if the filename ends in .pdf, the server should announce the file as
Content-type: application/pdf
Other servers use different file names and the syntax of the line is a little different but the principle is the same.
Now it's the client's turn. Most clients have a way of allowing the user to say what should happen when a particular MIME type arrives. For example, Netscape 2.0 handles both GIF and JPEG formats itself. If the content type is image/gif or image/jpeg, Netscape displays the image in the browser window.
These are called in-line graphics, since they appear in the browser's window along with the HTML page. If the client doesn't recognize the MIME type as one of its native types, it looks for a helper application.
Helper applications open their own window to display the downloaded file. (For graphics formats, helper applications are sometimes called viewers.) Most graphical browsers (such as Netscape and Mosaic) provide a form that allows the user to say what should happen for each MIME type. A typical behavior is to launch the helper application.
Netscape 2.0 users have another option. Netscape now allows vendors to write plug-in modules. When Netscape sees a MIME type that it does not handle natively, it first checks to see if there is a plug-in module for this type. If there is, the plug-in displays the file in the Netscape browser's own window. This approach allows the browser to give inline appearance to a variety of types.
A Webmaster can safely expect a user to have a browser that handles inline GIFs. Most browsers today also handle inline JPEGs. If you serve other image types, include a link to a page telling the user where to get the plug-in or helper application, how to download it, and how to install it.
Remember that users are busy people. Don't serve that 1M file; find a way to compress it. Unfortunately, when you compress a file with an application called, xyz, the MIME type changes to application/xyz.
The server expects the client to use xyz to open the file and extract the contents. The user is expecting to see a page and finds the client starting up an application. This behavior can be unsettling, to say the least. (For xyz, fill in your favorite compressor, such as gzip.)
One way around this problem is to send files that are inherently compressed. GIF, JPEG, and PNG all meet this requirement. Vector graphics are also inherently smaller than raster graphics. If the file can be displayed as, say, a CGM, that file format gives faster downloads than the equivalent raster format.
Look for ways to serve large files in a vector format (or metafile with vector components) like CGM or PostScript. Remember to give users a link telling them how to set their browsers for this MIME type.
Recall from the discussion of TIFF that raster file formats store a lot of information about each pixel. A TIFF file may contain multiple versions of the image (in RGB, CMYK, and perhaps even YCbCr). If the intent of downloading the file is to have the user view it, only one version is needed.
Recall, too, that formats like TIFF support three 8-bit samples per pixel. For viewing purposes, fewer bits per sample may be adequate. Changing from full color to indexed color reduces the file size. Physically making the graphic smaller can have a dramatic effect. Try to reduce the file size to around 20K; such a file downloads over a 14.4-Kbps connection in about 12 to 15 seconds.
Before sending a file larger than about 20K, it is courteous to give users a notice about the file size and let them decide whether to take the time. Here are three ways of giving users a "Warning, large file ahead."
Graphics lend themselves to the use of thumbnails. Visit the Nikka Galleria site, at http://www.dse.com/nikka and look at the page for artist Thomas McLauchlin at http://www.dse.com/nikka/Talent/Painting/5.McLauchlin.shtml.
This page is shown in Figure 33.12. At any given time, this page has four to five samples of Mr. McLauchlin's work. Each image is a GIF under 20K. The full page may take a minute or more to download but because each image has a specified WIDTH and HEIGHT, the page is back under user control within a few seconds. Now select one of the works.It expands to a much larger image, this time a JPEG. If the browser has inline JPEGs, the page appears as shown in Figure 33.13.
Figure 33.12 : Thomas McLauchlin's page shows several of his works for sale.
Figure 33.13 : Thomas McLauchlin's painting, "Cafe;" is a 44K JPEG.
Now choose Back to return to the artist's page and choose Search at the bottom of that page. The search form is shown in Figure 33.14.
Ask for all works by Mr. McLauchlin and the form returns several works (see Fig. 33.15). Depending on the search criteria, this page might have dozens of graphics on it so it is important for each graphic to be as small as possible.
These graphics are tiny GIFs with just a few bits per pixel. The average thumbnail file size is about 2.8K so a page with 10 images still downloads in under 30 seconds and turns control over to the user much sooner than that.
Another approach is to explicitly tell the user the file size. If the file changes from time to time, use the #fsize server-side include or adapt the isNew script from Chapter 6, "Reducing Maintenance Costs with sever-side includes," to look at file size rather than age. If we tell the user there's a 1M file at the other end of that link, they are less likely to complain when the download takes a long time.
http://www.matterform.com/qbullets/aboutqbullets.html offers a helpful set of tiny icons that characterize hyperlinks. One use for them is to identify the size of a downloadable file. Figure 33.16 shows various thermometers and some recommended file sizes associated with each.
Figure 33.16 : QBullets thermometers can be used to "hint" at the size of an image file.
| Tip |
The interpretation of the QBullet thermometers is not intuitive. Include a link to a page that shows what each one means and give some reasonable interpretations of download times. |
Remember that if you try to convert from file sizes to download times, you nearly always mis-estimate. Many users on 14,400 or even 28,800 modems have to share a T-1 from their ISP out to the Net.
Even some users who have direct access to a T-1 may compete for bandwidth during the work day. It is not unheard of for a 14,400 Kbps line to surge to over 2,000 bytes per second (with modem compression turned on) or sag to 10 bytes per second.
For more info on QBullets, see http://www.matterform.com/qbullets/aboutqbullets.html.