Showing results for 
Search instead for 
Do you mean 

Mosaic a set of Tiled Imagery (handling NoData)

by Technical Evangelist on ‎06-27-2017 12:57 PM - edited on ‎02-24-2020 03:37 AM by Community Manager (4,632 Views)

Download Model




As part of a larger model it is often necessary to locate and input a varying number of input images. These might represent multiple image tiles covering a larger extent, or might be multi-date layers covering generally the same extent. 


You can use the Multi Filename Input and Iterator operators to stitch tiles together into a single image. This requires an understanding of NoData, how Spatial Modeler uses it and how to work with it to achieve the desired result.


See this thread for a general discussion of NoData in Spatial Modeler, largely pertaining to handling NoData if there's only a single input raster in the Model.  


In this simple scenario though, we need to input two or more images which either abut against each other (no overlap) or have minimal overlap. Taking the simplest example of two butt-joining images, the approach in Spatial Modeler seems simple - perform a Conditional test which outputs ImageA if it exists (is something other than 0) or output ImageB otherwise.


 Figure 1: Partially overlapping image tiles


We need to remember that Spatial Modeler's default processing extent (when an Operator needs to consider two or more input spatial streams) is the intersection of the inputs. So by default, considering the above Conditional test would result in only the dark blue Intersection Extent being output, which doesn't fulfill the requirement of a mosaicing operation. So we will need to use a Define Processing Area operator to over-ride the defaults and specify the Union extent instead.


We also need to be aware of two basic rules of NoData in Spatial Modeler: 


  1. At a given pixel location, no processing occurs if any input value to that operator is NoData (and NoData will subsequently be output at that location)

  2. Everything beyond the extent of an input image is considered NoData

These two rules have a serious consequence if trying to assemble two or more "super-setting" datasets, such as those shown in Figure 1 above. Even if we are now processing based on the Union of all inputs, more then 2/3rds of ImageA exists in ImageB's NoData area (i.e. all areas beyond the extent of ImageB). So processing any pixels in that light blue area of ImageA will be considering inputs of Data (from ImageA) and NoData (from ImageB) and therefore the output will be NoData. Similarly in the light blue area of ImageB you would be comparing NoData from ImageA with Data from ImageB, resulting in NoData again. Only in the overlap area is Data being compared with Data. So we would end up with an output image that has the union extent of both inputs, but all except the dark blue Intersection Area would be NoData. 


Now extend that problem to inputting a thousand image tiles!


The solution is to use the Replace NoData With operator to (unsurprisingly) replace the NoData masks with a value that is hopefully not being used in the input data tiles. Refer to the article linked above for some background on the importance of being able to differentiate between, for example, a value of 0 being used to represent "background", and valid pixel locations where the DN value of the image data is 0. One approach to this is by replacing valid 0s with 1s prior to converting NoData to 0s.


Here's the basic model:


Figure 2: mosaic_tiles_v16_1_0.gmdx


How does it work? The Multi Filename Input operator will search the specified directories, find the images that match the search criteria and build a List of filenames. The first Iterator is basically wrapped around a Raster Input operator which iterates through that list of filenames and converts them into a List of rasters.


Figure 3: Iterator 1 sub-model


The List of rasters is then passed to a Define Processing Area operator in which the only non-default setting is to set the processing area to the Union of all the inputs rather than the intersection. Another List of rasters is produced, but now the processing extent is set to that of the entire extent covered by all input images. This List then goes into and controls a second Iterator sub-model. 


Figure 4: Iterator 2 sub-model


The second Iterator iterates through each input raster stream (but using the extent of the union of all input raster streams), sets any valid (non-NoData) DN values of 0 to 1, then replaces NoData locations with a value of 0. Finally it splits each raster steam into it's constituent bands (assuming that the input images were three band images) and outputs three lists of rasters - one for each band.


After the second Iterator the model then takes the list of Band 1 rasters and Stack Layers them (so if you input 1000 image tiles to the model you'd have a 1000 layer stack), but immediately calculates the Stack Max. Since "background" has been set to 0 this effectively "flattens" the data back down to a single layer mosaic of all of the Band 1 data that was input to the Model.

The same is done for Bands 2 and 3 and then the flattened results of those branches are themselves Stack Layered to form a 3 band mosaic raster stream.


One final thought - we would want the two white rectangles at top-right and lower-left of the above diagram (Figure 1) to be NoData in the output mosaiced data. So a Set to NoData is used to convert DNs of 0 back to NoData.


Assumptions / Limitations


This model is designed to process input images with 3 bands. It will require minor adjustments to handle more, or less, bands.


The model also assumes that 0s in the input images represent valid values. If instead there are wedges of 0s at the edges of the images which represent background areas, these should first be set to NoData prior to running the Model. Alternatively the model will need to be edited to reflect the different differing interpretations that should be placed on specific DN values.


The model also assumes that the inputs are unsigned integers (u8, u16, etc) and that 0 is the minimum value. If instead you are mosaicing, for example, multiple DEMs in s16 or float values (with areas that drop below sea level), you should change the value that NoData is replaced with to an appropriate value which is less than any values that could occur as valid data. As well as removing the branches that deal with bands 2 and 3 of course! Remember to change the Set to NoData value as well.


Input parameters:


Directory: Select a directory which will be searched for input images which match the Extension pattern

Extension: Enter a wildcard search string to identify the imagery to be input to the model, For example *.ntf would select all files with an extension of .ntf

Search Sub-directories: Defaults to False, in which case just the directory identified by Directory will be searched. If set to True, Directory and all sub-directories of Directory will be searched to compile the list of input files.

Output: Specify the name (and extension, if a format other than IMG is desired) of the output mosaiced image file



Figure 5: Run dialog
by Technical Evangelist
‎01-23-2019 01:45 PM - edited ‎02-20-2019 07:31 AM

You can never remove background pixels. An image is always rectangular, So when performing classification on an image which includeds "background" pixels you'll generally be producing a class that is "background".


Or did you mean something like this?:



on ‎02-19-2019 11:11 PM

Hi Ian, thank you for this great article. I built the same model and it works fine, but now I am trying to edit it to make it work inside Erdas Apollo. I changed the Multi filename Input operator with List operator with 6 raster inputs connected.


mosaic model.PNG


This model works fine too, but I want to ask, if there is any option to make the raster inputs optional, so e.g. if someone wants to make a mosaic just out of 4 rasters, the model will exclude remaining raster inputs. Or the best way would be to have no limitation of number of raster inputs (user would be able to choose 2-n rasters), but I did not find a solution for this task. Thank you




by Technical Evangelist
on ‎02-20-2019 08:41 AM - last edited on ‎02-24-2020 04:13 AM by Community Manager

Hi jan,


Absolutely. The main avenue would be to use Multi File Input which lets you pick specific images as well as offering the wildcard searching. But I guess the implication of your post is that APOLLO doesn't yet support Multi File Input? If so then that'd definitely be something to log in the Ideas board.


However you can definitely do something like the following (model download linked):




I made the first Port Input required (because you need atleast a single layer of data as input). But the other three Port Inputs are marked Optional. The If Else's then takes care of whether the Raster Input is run or not and the Remove Empty Items removes any resulting nulls in the List. So when I ran this model I supplied input rasters on Image 1 and Image 2 but not on Image 3 and Image 4 and you can see that the result was a 2 band image.


Just add as many Image n / Raster Input / If Else pairings as you are likely to need. 


Hope that helps.





on ‎02-22-2019 05:53 AM

Hi, exactly, the Multi File Input operator is not supported in Erdas Apollo. Thank you for your solution, but there is still a problem with geospatial portal geoprocessing inputs. Even if the port inputs are defined as optional, in geospatial portal the columns cannot be left empty.


I tried to fill these fields with several options (like null, NoData, []) but process was only successed when using "" (quotation marks). But this option somehow breaks down the progress bar, even if there is correct output image added to catalog, the process informations are empty and status remain just Accepted (the printscreen shows process executed at least 1 hour before):

proces status.PNG


Could this be somehow solved or is it a bug that needs to be reported?



by Technical Evangelist
on ‎02-22-2019 06:04 AM

Hi jan,


Unfortunately I'm not that familiar with ERDAS APOLLO. I would recommend either contacting your local support group, or perhaps pose this question on the ERDAS APOLLO group in the Discussions section of the Community. I'll see if I can dig anyhting up as well.