Graphic Tests

By converting high resolution lineart to grayscale first, then by scaling down using some kind of "smart sizing" or "re-sampling" technique you are effectively anti-aliasing any text characters. If you then convert to an appropriate (gray) color palette with 16 or 64 levels and store as an interlaced gif, you get something that looks acceptable to the eye.

In these tests a low resolution version is one which is 600 or fewer pixels wide (or 800 or fewer pixels high.) A medium resolution version is twice the width and height, but displayed with sizing information in the <img src=...> call-out so that it displays in the same space on the screen. One problem with using the medium resolution technique is that it is necessary to obtain the size information to include in the call-out, which may make automation difficult. (If the decision is to only encode a few images this way, it would be easier to specify the size manually.)

600 pixels is about the maximum width fits on a 640 by 480 monitor without scrooling; it comes out about 6.5 inches wide when printed by most browsers. A little over 800 pixels high is about the maximum which fits on page when printed.

The very low resolution version is included only for reference, this version was obtained by resizing the 300 dpi version, not by using a technique which resulted in anti-aliasing of the characters. It is not recommended.

Test 1 uses a long table which was scaled to fit on the 6x9 page. Because this table is so long, instead of limiting the width to 600 pixels, the height was limited to 800 pixels so it would print on a single page. (The original uncompressed TIFF is 4,077,658.)

Test 2 uses the same source document, but the source image was a version which was first decimated to 300 dpi on Xyvision. (This is an uncompressed version of the 300 dpi versions currently being distributed. Uncompressed the TIFF is 356,517 bytes.)

It's interesting to note that the images which result from using the high res source take much less space on disk (and to transfer) than the ones from the 300 dpi source. The only problem is that they take much more in the way of computer resources to create: The 1016 dpi Test 1 image was 4352 x 7488 pixels or about 4MB. When converted to graylevel it becomes 32MB. Processing it requires over 64MB of virtual memory (or probably real memory on a MAC.)

Test 3 is an example of a much less dense table where we could use the full 600 pixel width. This table was scanned at only 300 dpi, and the quality of the original scan was not as good. For this kind of image, the medium resolution technique is clearly overkill.

There is probably no reason for not converting to 16 levels of gray before storing -- the compression will be better and there is little difference in quality. However, even if only 16 gray levels are stored, it is likely that the web browsers may still devote 8 bits, not 4, to each pixel when building the displays and/or printing. This means that each 600 x 800 image might consume 1.8MB when being displayed -- another reason to avoid these medium resolution versions except when absolutely necessary.

Size Summary