Showing results for 
Search instead for 
Do you mean 

Fill "holes" in an athematic multispectral image

by Technical Evangelist ‎12-16-2020 02:03 PM - edited ‎12-17-2020 11:20 AM (98 Views)


Download model and sample data





When processing image data, especially when switching between software applications and data formats with differing ways of handling NoData, it's often possible to lose track of which pixels are supposed to be NoData, which are Background, which are validly dark pixels with a DN value of 0, etc. So people end up with "holes" in their data - pixels set to a value which ends up being incorrectly displayed as transparent in some applications.


Panchromatic image displayed with 0s transparent over a red background. Note the red "holes" in areas of shadow


This often happens after running processes which might stretch, or otherwise alter, the DN values of the data and the data is truncated to unsigned integers. By doing this pixels that were stretched to negative DN values get truncated to 0 and mixed in with pixels which are supposed to represent NoData.


Since these pixels are generally dark it is a valid approach to try to set them to a "close to 0" value (e.g. 1) to disambiguate them, rather than trying to interpolate values from surrounding pixels (which can be a questionable approach to take for athematic imagery). However the difficulty is in identifying which pixels with a DN value of 0 in the image should be NoData and which should be valid dark pixels.




That's the problem this Spatial Model attempts to solve. Images are always rectangular, but there are often wedges of NoData at the edges of the image introduced when the image was georeferenced or for other reasons. The spatial model assumes that pixels around the "outside edges" that are 0 should in fact be NoData, whereas pixels "inside" the true image which are 0 should be valid dark (opaque) pixels.


To do this it uses the Compute Footprint operator to determine the "outside edge" and thereby can discriminate between pixels with DN 0 outside the footprint and pixels with DN 0 inside the footprint. The ones outside are used to define a NoData mask while the ones inside are set to a DN value of 1. When the output image is created it may be in a format that does not support mask-based NoData, so 0 is defined as value-based NoData.


Panchromatic image after being run through the spatial model


Another advantage of using the approach is that extraneous pixels (such as the padding at the bottom edge of our example image) is trimmed away by the process. This occurs because the area geometry that represents the footprint has (in this case) a smaller extent than the input image itself. So when the two data streams are combined in the Apply Mask operator the standard processing rule of "intersection" used by the Spatial Modeler is applied, as can be seen by the diminished red collar around the data in the output screenshot. If you wanted to use a different rule you could insert a Define Processing Area operator ahead of the Apply Mask


Data Requirements & Assumptions


Requires ERDAS IMAGINE 2020 Update 2 or later


The input image is assumed to have a bad, faulty, or just plain missing definition of NoData which needs correcting. So any pixels marked NoData are set to 0 in the first steps of the model. If the assumption of NoData being badly defined is incorrect you should not use the spatial model as-is.


The input image is also assumed to contain unsigned integer DN values. If this is not the case then 0 may not be an appropriate DN value to be identifying and using as NoData. 


If the input image has at some point been lossily compressed (and then any NoData mask lost) the pixels that were in the NoData locations may nolonger be a uniform value such as 0. The lossy compression may have created a mixture of 0s, 1s, 2s, etc. If this is the case, then the BackgroundValues port on the Compute Footprint operator could be modified accordingly.  


The spatial model works best if the input is a Georectified image. If the input is a geometrically calibrated (GeoReferenceable) raster grid then the geometry created by Compute Footprint will be Georectified and recombining that with the GeoReferenceable grid at the Apply Mask step may result in an extent larger than expected. It should not be wrong, but may cover more pixels than desired. 



Input parameters:

Input Image: Name of the input image with poorly defined NoData

Output Image: Name of the output image with corrected NoData