Orthoimagery is frequently supplied as tiled 8-bit images where the data has already been processed and stretched to fully utilize the 0 - 255 DN range and to provide a true color display where the DN values are mapped directly to screen brightness when the data is displayed.
However, ERDAS IMAGINE was originally developed to process raw imagery (and produce ortho mosaics) and so generally defaults to a behavior of applying a statistical stretch to any data that is displayed in its Views (unless Preferences have been set to No Stretch, or if a suitable contrast stretch is already embedded into the image's header). When displaying multiple orthoimage tiles into a single View this per-image statistical LUT approach means that the data can take on a "checkerboard" appearance since each image tile has a unique statistical distribution of data. This can give the impression of bad data, when it is really the nature of the LUTs being used.
|Several hundred orthomosaic image tiles, each displayed using its own 2 Standard Deviation LUT stretch|
There are several approaches to avoiding this issue in ERDAS IMAGINE: The multiple image tiles can be opened as a Virtual Mosaic, thereby accumulating a single set of statistics and therefore a consistent LUT; or, in the case of pre-stretched 8-bit orthoimage tiles, the user can turn on the No Stretch option in the View's File Chooser when adding the data.
This Model provides another alternative, which is to write a standardized contrast LUT into the header of the existing image files. When opened into a View, such images will then default to using the saved LUT and therefore have a consistent appearance.
As implemented the contrast LUT is the equivalent of a "No Stretch", i.e. DN values will be mapped linearly and directly to screen brightness values.
|The same tiled data, but after writing a No Stretch LUT into the contrast table of every image using NoStretchLUT-v15-0-7.gmdx|
The Model is currently designed to apply to three-band, 8-bit images, where the Layer Names are Layer_1, Layer_2 and Layer_3. The Model could be easily modified if this is not the case.
|What the Model could have looked like (and which works in many instances):|
|But what it ended up looking like after catering for all the vagaries of image format and statistical binning:|
For a full discussion of many of the reasons for the complexity of the Model please refer to the "Why Does It Do That?" section of the Article ". "
One additional complication of this Model was that it works on the input image itself (there's no new output file) and that may be an image that was not created by ERDAS IMAGINE. Consequently, the input image may not have existing Contrast tables or statistics to be read to provide a measure of the size of the input histogram. So the first set of three Raster Attribute Output operators (upper left of the screenshot) are used to create default Contrast tables on the input data. These are then analysed by the remainder of the Model and updated by the last set of three Raster Attribute Output operators.
Raster In: Input three-band, unsigned 8-bit image which will have a LUT saved into its header (and which therefore must have write permissions for the user).
Skip Factor: Statistics approximation factor. A value of 4 will increase processing speed, but may result in an output "NoStretch" LUT which does not encompass the entire stretched image data range. A value of 1 will result in slower processing, but guarantees the full range is encapsulated by the created LUT. If the input image already has statistics available in its header, those statistics will be used and no calculation will be required / performed.