Case study of the scanning of an engraving.
Image "Front View of the Skeleton" is Figure 2, page 20 in Duval's Artistic Anatomy by A. Melville Paterson, M.D. Cassell and Company, Limited, London, copyright 1907.
As seen in HP Precision Pro, the image is detected as a full-color image occupying 11.7 MB of space. This is clearly a smidge too large for ordinary web consumption.

In the words of an anonymous web-programming instructor, "if worse comes to worst, you can always panic!" Or, following Nero's lead we may fiddle. It turns out that when we select just the one page (trying to copy just the good parts), the image is only 3.1M as displayed in Photoshop.
Do we really need color here? Well the underlying image was, once upon a time, an engraving. Probably a copper plate had crafty little slits cut into it by a practiced artisan, whereafter ink was pressed through the holes to create a sharply defined image. The ink didn't come in varying tones of color. It was just black ink. Accordingly, any color in the image is induced by a) the color of the page (we suppose the paper was white back in 1907) b) the discoloration of the page over time (I suspect higher rag or linen content holds up better than wood pulp with acid used in the processing) and c) potential threeway interactions between the chemistry of the ink and of the paper with time. Using techniques of forensic anthropology, we might be able (in some theoretical way) to use the chroma in the image to more accurately reconstruct what the image was really like when printed in 1907, but, given that it will cost us dearly in terms of file sizes. By the time the definitive article appears on the use of spectroscopy to aid in the reverse-engineering of time as confounded with printing techniques, chances are that a) we'll have better file compression formats and b) space constraints of images used on the web will be lessened. Maybe we'll rescan then (assuming the paper hasn't disintegrated).
Accordingly, let's scrap color and turn it into greyscale:


Color and greyscale versions of the same file.
Yippee! The 3.1 meg image is now only 1.03 MB. Hey! By the time it's been Jpegged, it won't be so bad after all.
Looking at the greyscale image, we have to make some determination on what information is relevant, and whether or not this image is, in some sense, the best we can do.
a) There are lines leading from features in the image to textual explanations. Eliminating those lines is likely to be time-consuming and destructive to the surrounding picture. Secondly, the textual explanations may prove useful to some audiences. Let's leave the lines and text intact.
b) we see some differential shading near the spine of the book, induced by the curvature of the page as it rests on the scanner. While we might play with ways to eliminate that, those are likely to interfere with the legibility of the text.
c) the image appears to be tilted a bit on the page. Let's rotate it a little (like 1.5 degrees). Since multiple rotation will degrade the image a bit (rotating by x degrees and that rotating the result by -x degrees will indeed induce degradation, unless x is an integer multiple of 45 degrees) we don't want to do this more than once. So rotate x degrees and observe. If it's not right, use "undo" then try x+delta degrees. (Use Rotate canvas/arbitrary from the Image menu in Photoshop.)


Before and after rotation through 1.5 degrees.
After rotation, we may wish to crop, since we will have introduced undesirable edges to the image. Use the rectangular marquis tool to select a portion, then use "Crop" from the Image menu.
When it is time to save the image, let's think about file types. Since the image is in greyscale, it uses 8 bits of information per pixel (256 shades of grey). GIF format uses 8 bits per pixel and will accordingly, provide a loss-less format. JPEG on the other hand will likely be smaller, but with some degradation of the image. Let's try both.
Here is the GIF version occupying 419 KB. Here's the JPG version occupying 168 KB. The two may appear indistinguishable, but we may investigate their differences empirically. Paste one on top of the other using a difference paste. If we subtract one image from another and the result is a monochromatic black image, it means the two are identical. While we may be unable to see differences, we may amplify those differences, by flattening the results and then equalizing. equalized(GIF image minus JPEG image). This reveals that though the differences may not be detectible by the eye, there are differences worth noting. On the basis of what we know of JPG and GIF, we know the GIF image is better, though considerably larger.
How to proceed? Well, given that the images will probably be available through thumbnails, downloading the bigger GIF file will only be done by people who actually want to see it, and it does contain a more accurate rendition of the original. Hence we may reason that GIF is better. If the image is of little historical value, though, we may prefer to opt for the smaller file size.
Before we stop, though, let's take a close look. If we zoom in on the image (to a zoom factor of 200%), we see what appears to be shades of grey filling in the skull. We sense, however that the original is an engraving containing no grey. We are thus motivated to scan again at a higher spatial resolution.
![]() |
Back to the scanner software, we can usually reset the scan resolution. Default resolution is usually 150 dpi. Let's change that to 300 dpi. In HP ScanJet Pro, we can do that from the Tools menu. |
The result of scanning at 300 dpi. 426 KB in JPG.
Let's compare:

150 dpi GIF image on left; 300 dpi JPG image on right.
This will likely persuade us that the 300dpi scan does a much better job than the 150 dpi scan, even though the file size is considerably larger. The engraver's marks were too close together to be visible at the lower resolution. Yet, at 426KB, we may have cause for concern.
Just for fun, though, let's play with dpi a bit more.
Here is a 600 dpi scan of a detail. Here is a 400 dpi scan .
The 600 dpi scan doesn't show any more detail, realistically, than the 400 dpi scan, though the 400 dpi scan does show better detail on the crosshatching in the scapular region, for example. We are already nervous about file size, so we might be tempted to stop at 300 dpi
There are a few more tricks we may be tempted to try. Since the original was actually monochrome, we may wish to scan as a high resolution monochrome. I generally advise against this since a) there is no certainty that even 1200 dpi will catch all the spatial resolution of the engraver b) bitmaps (1 bit per pixel images) scale down poorly in browsers c) the image will be so large that people won't be able to see it and d) aging and print-smudging could have produced actual or simulated grey that is meaningful in perceiving the image.

A 400 dpi monochrome image scaled by the browser.
However, at strand of that reasoning may be relevant. Suppose we limit the image, not to black and white (2 colors) but to a small number of color values, like 8 or 16. Powers of two a generally a good idea. First we may spread out the spectrum a bit, by auto-adjusting the levels (Image/adjustment/auto-levels). This has the effect of homogenizing some of the "noisy pixels" in the once-white background. We may next quantize or posterize by reducing the number of bits per pixel. The net result will be to map nearly white pixels (the differences between which are noise) into the same shade of grey, hence reducing noise.
![]() |
![]() |
| detail at 400 dpi | its spectral frequency histogram |
![]() |
![]() |
| Reducing to 3 bits per pixel | The resulting spatial frequency chart. |
Interestingly, for these details, reducing bits per pixel and saving as GIF produces substantial savings in file size as well:
| description and link to image | file size |
| 8 bit gif image | 229 KB |
| 3 bit gif image | 41 KB |
| 3 bit jpg image | 100 KB |
The 3 bit GIF image is smaller and probably in the long run more accurate, than the JPG version.