Return
to Index PageFor photographic contributors with own scanning facilities
Here are the theoretical magic numbers for this publication. We are assuming all photos printed at the highest quality and largest size possible in an A4 monochrome format. In practise, we will not need many images this large, so make your own assessment as to whether the image will ever be used larger, if intended for a small illustration in an article. If practical though, we would rather have more data than less – this gives us more flexibility in the layouts. Also bear in mind that once scanned, the image source file is likely to be stored for posterity, so the best scan of your work, the better for future cave historians. (Hyperlinks) See Copyright Issues, See File Identification Captions
Working backwards from final image size:
Maximum size
we can print, assuming A4: 11" x 7.8"
Finest screen assumed 133
lpi
LineRes x 1.5 = ScanRes = 200dpi (normalised to O/P size)
Total
image data: 2200 x 1560 pixels
= 3.4Mbytes for 8-bit greyscale
=
10Mbytes for 24-bit RGB.
Note that this is the image data, not the
file size. Scanning resolution should be in proportion to capture this amount of
data, regardless of the size of the original. It also assumes that the whole of
the frame is to be used; if cropping heavily, increase the scanning resolution
in proportion. Some useful numbers for scanning common photographic sizes:
10" x 8" 200dpi
8.5 x 6.5 250dpi
7"x 5" 300dpi
6" x 4" 360dpi
5"x 4" 400dpi
6cm x 6cm 800dpi
6cm x 4.5cm 1000dpi
36mm x 24mm 1600dpi
No need to be too pedantic about the exact numbers – these are offered merely for comparative purposes. In practice, most scanners have a preferred series of resolutions that they can work at properly, ie. at integer relationship to the CCD pitch. It is best to stick to these; any other interpolated resolutions are usually best done (very carefully), as a separate process in a good image package, or not done at all.
Well, this is a nuisance if you want to fit the file on a single 1.4M floppy or send Email in a sensible time. All is not lost however. There are a number of things we can do to reduce file size. In order of usefulness:
1/ Drop the colour to 8-bit grey. (3.4Mbyes)
2/ Drop
the resolution. Remember that halving the dpi reduces the image size by a factor
of four. Try about 75% reduction, eg. 200dpi down to 150dpi. (1.9Mbytes)
3/
Save in LZW compressed TIF. This takes it down to typically* less than 70% of
the image size. (1.3Mbyte) This is a lossless compression, so we open the file
from a 1.4M disc and get about 2M real data. With care, we can usually get a
good size print, say 6x8 inches, from this amount of greyscale data, though it
does depend on other factors, including the type of subject
* Varies
enormously with subject –. 50% common, 25% sometimes. See TIFF LZW
compression (hyperlink this) (and get rid of this beastly footnote?)
OK, it's a compromise. We would rather have the whole 3.4 / 10M of data to store. Even if destined for greyscale conversion, we would prefer to have a colour scan of colour originals. This permits us to use the RGB data in selective conversions – analogous to using contrast filters with pan film at the taking stage. (e.g. a red filter to enhance cloudy skies – not that we see many of these in cave photos, but the principle is the same.) We currently keep images on the 100M Iomega Zipdiscs, so that is not a problem, assuming you can get the data through. So you could:
1/ Send it Email, and damn the expense. Please send to
Kym's address only – kym@dhios.demon.co.uk and discuss it with her before
sending 50M of images!
2/ Send on 100M Iomega Zipdisc. Current cost about
ukp15 each. We return it :>). Machine costs about ukp/usd150.
3/ Lend us
the original prints, up to 10x8 (or A4). We scan on colour flatbed up to 600dpi
optical. We can't do slides inhouse, but bureau it out to CD-rom.
4/ CD-rom
it locally yourself. Several High-Street shops are offering this competitively.
We prefer to use a local agent who is also a photographer – he is more
likely appreciate the value of the originals. Needs checking out in your area.
Could be an excellent route – it also means you get a good digital copy to
archive Do remember to ask (insist!) that frames are not "auto
colour-balanced" (This will wreck a typical cave scene.). Costs about
ukp0.50 per frame plus ukp10 to start a CD (holds 100 images).You can also
include mono and colour negs. If really keen, look also at "ProCD" –
much more expensive, but gives a quality (and file size!) suitable for enormous
enlargements. We want to look at CD for archiving longer term ourselves, on a
general-purpose CD cutter. (We don't really like the limitations of the "domestic
standard" photo CD.)
In desperation to get just the last few percent off the
file size, try:
1/ Crop tighter - try shaving a few pixels off your least
favourite edge.
2/ Drop the number of greys still further – 6 or 7 bit
gives quite a saving. We can (psuedo) recover some of it in later pre-press
stages, but cannot print more than about 120 (effective) shades of grey at best
anyway.
3/ Drop the resolution some more. If going to some arbitrary
non-standard resolution, look at the result carefully at high magnification.
Sometimes you can get odd repeating glitches on sloping edges for example, where
a simple 1-of-n pixel-cut algorithm has been used. In general, these processes
give additive degradation of image quality. It is therefore best not to
overwrite the original scan data – do a "save as" to a temp file
to see how much size reduction you get, and then revert to saved and apply all
the resampling attempts in as few steps as possible.
Manually or auto adjust the scanner "exposure" and "contrast" to just capture the highlight and shadow. If the scanner cannot capture the full dynamic rance of the image, it is usually better to sacrifice the shadows in cave photos. (A generalisation: you'll have to make your own artistic judgement here.) Also consider the midtones: sometimes it is better to sacrifice a little more shadow to get more data in the light grey areas, where unwanted posterisation is most likely to show. It is difficult to make rules about this as very dependent on the type of image. If you are using a hi-bit scanner, make these moves before dropping to 8-bit for output. An important point to consider is that good source files for archiving or mapping to print are not the same as files that look good on an RGB monitor screen. A good source file contains the maximum amount of image detail and tonal range. It can then be "targeted" for specific output technologies (some of which have not yet been invented). A file that is already targeted has lost data, which can never be truly recovered. If the targeting moves have been made for a vastly different output process, our problems are doubled.
We prefer TIFF for our own purposes. It is generally the most portable and useful format, supported universally without proprietary claims. It supports the whole range of photo and prepress colourspace models, from an RGB or greyscale scan, to CMYK or mono halftone printing plates. It is a generic standard, with flexibility built in for the future. Older sub-formats are automatically recognised and read by later packages. Older packages can usually read the relevant parts of newer files, simply losing the unsupported functions. It generally works very well, especially considering the ambitious scope of the specification. Although promoted by Microsoft and Aldus, it is an open standard, with the detailed specification freely available. We have never met an alien TIFF file that we could not open one way or another. TIF preferred, all formats. LZW compression only. type 5 JPEG mono cell patterning problems JPEG more relevant for colour work. Histogram Tiff captioning, saved in data file. Assoc. Press standards? Copyright name, year. Give sample for cut & paste? COLOUR OR MONO ISSUES Even if destined for greyscale conversion, we would prefer to have a colour scan of colour originals. No useful way of using the colour data to increase res on mono conversion. (Is this true?) Web pages use colour data, lower res treat separately and generate two 1.4M files. C:\UPHOT\SCANOTES.DOC 15/08/96 10:13 PM