Raster Images are commonplace in archaeological archives and, while they can be the product or component of a number of different processes, they essentially consist of the same basic elements i.e. an image composed of a matrix of pixels with a fixed size/resolution. In archaeology, raster images can be created from a wide variety of processes ranging from original data capture such as digital photographs, scans and drawings through to outputs or 'products' such as plotted geophysical survey data and images from GIS layouts.
This guide aims to cover the common types of raster image created as components of archaeological research, these include:
Although some technical description will be given in this guide, in depth discussion of aspects of raster images such as resolution, colour space and bit depth won't be covered and are more than adequately explained in existing guides, specifically JISC Digital Media's 'Advice on Still Images' and in the AHDS Bitmap (raster) Image Preservation Handbook. Likewise, vector images are covered in more detail in the Vector Images guide. For both raster and vector images, as common components of larger project workflows, links are also made to technique focused guides such as CAD, GIS and Virtual Reality.
One of the most obvious issues with digital raster images is the wide range of formats available in which images can be created and stored. Raster image formats can vary massively in terms of individual features and capabilities and can cover the whole gamut of format types from proprietary, software specific formats through to open standards. A key component of this assortment of file types is also the range of individual features and capabilities each file format possesses - such as compression (lossless or lossy), colour depth, support for transparency, embedded metadata - and it is important that an appropriate file format is chosen for the image being created both during the data creation stage and for long-term storage. In addition, in certain project workflows, images may change formats at different points in the project depending on how they are being used. In these scenarios it is also important to be aware of what range of functionality and metadata each format supports and what could potentially be lost during each format migration.