Section 8 - Output Image Data

Output Background Pixel Value

Q) How do I set the "background" color for OrthoVista output imagery.
A) You must edit the 'bigmo.cfg' configuration by hand (e.g. using any text editor). Locate (or add) a configuration variable "OutputBackground" and set it's value to a comma separated list of 3 values representing the Red, Green and Blue components respectively. Each value must be between 0 and 255 inclusive (e.g. 0,0,0 for black, 255,0,0 for red, etc.)
For example the following line in 'bigmo.cfg' sets background to black.
OutputBackground    0,0,0
Note: There is a bug in version 2.2.1 which causes this configuration variable to be ignored. Therefore the default background color setting cannot be overridden in this version.

Automatic Seamlines

Q) Is it possible to determine where the automatically generated seamlines have been placed?
A) It is possible to replace the mosaic output image with a "blending intensity image" that indicates were input images have been 'stitched' together. The resulting image replaces overlapping image areas with a 'blending intensity image'. The brightness of the blending intensity image indicates the extent to which individual images were blended. Where the blending image is dark, one of the source images dominates. Where the blending image is brightest, the output mosaic pixels are a nearly equally weighted combination of source image pixels.
You can review and display the blending image as you would the normal mosaic output (e.g. load it into orthovista, use image viewers, etc...)
Note that the "blending intensity image" REPLACES the output mosaic. Although the result can be interesting to look at, generation of "blending intensity images" can interfere significantly with production operation workflow. As an option, a nonlicensed version of the program can be used to generate the blending intensity image on another system in order to keep the production system free.
To generate the "blending intensity image", you must modify the 'bigmo.cfg' configuration file by hand (e.g. using any text editor). In bigmo.cfg, locate (or add) the configuration variable "Mosaic::OverlayAlphaBlend" and enable/disable it as follows:
To produce "Normal" mosaics (normal production operations)
Mosaic::OverlayAlphaBlend                  FALSE
Produce "Blending Intensity Images"
Mosaic::OverlayAlphaBlend                  TRUE

Missing Output Data

Q) One or more images are "missing" from the output mosaic (e.g. mosaic in this location contains all background data). What is happening?
A) The blank output is probably related to border detection and background pixel values (e.g. white or black) - e.g. there may be an "island" of image data surrounded by large areas of 'background' pixel values. If the image data regions are small enough, they may be missed during a search through the image. One workaround is to crop the data file so that the image pixel regions occupy a larger portion of the file footprint.

Output Tiles have 1-pixel Gap or Overlap

Q) Mosaic output tiles have either a one pixel gap or a duplicated pixel value where they join. What is happening?

A) The most likely situation is that the tile definitions are inconsistent with the pixel size.
OrthoVista utilizes precise (subpixel) computations in creating image composites and output data tiles. OrthoVista essentially computes one big "virtual" mosaic which is subsequently segmented into pixel regions based on the tiles you specify. Therefore, near the edges of adjacent tiles, the action of "cutting tiles" should be considered a process of assigning each pixel to one tile or other. A typical problem situation is illustrated by the following simple example.
Let's say you are working with 3 meter pixels and you want tiles each of which is 10km on a side so that the tiles will align with even map coordinate values (e.g. with xxxxx0000 values). However, note that these data are inconsistent! The 10000 meter tile width can not be filled exactly with 3 meter pixels. To make the data consistent with 3 meter pixels, you would need to specify a tile size which is a multiple of 3 meters (e.g. 9999m or 10002m tiles). To make the data consistent with a 10000 meter tile, you would need to be using pixels which "exactly" fit into the tile size (e.g. 3.00030003 meters (for 3333 pixels per tile) or 2.99940012 meters (for 3334 pixels per tile)).
That seems like a lot of complexity. Isn't there an alternative? A 'gut reaction' is often to think that the border pixels should "just be split at the edge of the tiles. E.g. for this example, the first tile would have 3333 pixels in a row, each of which is 3 meters wide and then at the end of this row, have one pixel which is only 1 meter wide. The adjacent tile would then have a first pixel which is 2 meters wide followed by 3332 pixels each of which is 3 meters wide then followed by a pixel which is 2 meters wide. And so on.... This is also the approach of "changing the pixel size to fit the tile size" - just that it is not being done uniformly. And of course, this collection of different pixel sizes would be problematic when attempting to store the image in most all conventional image file formats.
So... can't the pixels just be "scrunched" or "puffed up" so that the extra pixel fits entirely into the tile. This is exactly the case of changing pixel sizes as described above. Okay. So what about just adding the whole pixel to the output tile, if the "fractional pixel" would be more than 1/2 and not adding it if the fractional half is less than 1/2. This is exactly the case of adjusting the tile definition boundaries to align with pixel edges as described above.
This second "tile adjustment" approach is what OrthoVista does if you provide it with inconsistent pixel/tile size data. In effect, it "moves the edges" of the tiles just enough to exactly accommodate the unique assignment of border pixels into one tile or another. Note that in theory, this is fine, but in practice can be corrupted by computer numerical "roundoff" noise (e.g. errors at the level of about a femto-pixel (10^-15 pixels)). For a pixel that is "exactly" 1/2 in one tile and 1/2 in the other tile, computer noise makes it possible that the pixel will 1) show up only in one tile or another - with the tile boundaries being adjusted correctly to compensate this); 2) show up in neither tile - with boundaries being adjusted such that a gap exists; or 3) show up in both tiles - with boundaries adjusted such that a (1 pixel) overlap exists. Therefore, it is better that you explicitly control this by providing pixel and tile sizes which are consistent with each other and also with your specific requirements. Also note that the "noise" effect is significantly increased if you work with rotated image data (e.g. 1/2 pixel in what direction?)
Although the simple 3/10000 example above may seem somewhat contrived it is indeed from an actual production situation. In general, pixel size/tile size consistency issues can arise fairly often in practice - especially when using multiple units on a project such as metric pixels placed on english unit maps or vice versa, etc. Unfortunately, there is no after-the-fact "magic bullet" for this situation. It is a simple law of arithmetic based on dividing the tile size by the pixel size and requiring that the answer be in "whole units" - e.g. "whole" PICture ELementS.
In practice, the most straightforward and effective technique for addressing this situation is to contemplate the pixel size / tile size relationship during project planning and then creating pixel sizes and tile definitions which are commensurate with project requirements and consistent with each other.

Alignment of Images in Output Mosaic

Q) The input source images are well aligned with each other in the OrthoVista main window display. However, data from the individual source images do not align with each other in the output mosaic.
A) This is likely the result of using input images with different pixel sizes. The output mosaic can have only one pixel size. This is computed from the input orthophoto pixel size. OrthoVista expects the source images to have the same pixel size so that the output can be created without resampling.
This is important because additional resampling degrades the image quality. In particular, if the difference in pixel sizes is a small percentage (e.g. from international feet to U.S. Survey feet), then resampling operations will introduce a pattern of alternating 'sharp' and 'fuzzy' regions of the image. In signal processing terms, this is a manifestation of the 'beat frequency' between the input and output image pixel repetition frequencies. In the alternating bands, high spatial frequency image content (detail information) is alternately lost and preserved. Therefore, it is usually ill-advised to resample images by only a small amount since the results will be visually unattractive.
Therefore, resampling of images is more appropriate for large changes in pixel size (for example from feet to meters, etc.). However, in this situation, you should questions yourself and think three times about what purpose is served by combining such very different image data into a single mosaic. Either you will lose tremendous amount of detail (from the image with the smaller pixel size) or you will vastly and unnecessarily increase the storage space requirements (by vastly oversampling the image with the large pixel size).
In any case, resampling the image degrades the quality of the image. Assuming that the image has been resampled at least once already (i.e. during orthorectification process), an additional resampling unnecessarily degrades the image. Therefore, it is much much better to incorporate the pixel size resampling into the same resample operation performed during orthorectification. Note that this same logic applies also to rotation of images - However, OrthoVista does provide secondary resampling for rotation - this is to facilitate corridor mapping application in which sheet rotation takes priority over image quality and processing speed.
OrthoVista is based on the assumption that image resampling operations are most appropriately performed during the orthophoto creation process at which time the image must be resampled. Therefore, OrthoVista assume that the input images are meant to have the same pixel size - and that any differences in pixel size are the result of numerical roundoff or truncation error. To handle pixel size roundoff/truncation error, an 'average pixel size' is computed for all input images to be used in the mosaic.
To compute the location at which source images are inserted into the output mosaic, OrthoVista utilizes this average pixel size. If an input image deviates significantly from this average pixel size (as would be the case with all images if, for example, half were one pixel size and half another size!) then a very significant scale error will result when each image is inserted into the mosaic. The end result will be that the mosaic will look like it is constructed from input images which have been improperly expanded or contracted in scale.
For versions of OrthoVista up through and including 2.2.4, there is NO user notification about the different scales (the differences are assumed to be round off). Future versions of the program will incorporate a warning about this condition if the pixel size varies significantly among input source images.

Alignment of Downsampled Images

Q) After creating downsampled images (e.g. via. the "Output Ratio" option in the Processing Dialog box), the downsampled images do not align at the pixel level. For example if the downsampled images are reloaded into OrthoVista, an error message is generated "Warning: Mosaic: Image #### is not offset by an even number of pixels...."
A) The downsampling begins at the upper left corner of the upper left pixel. The output ratio specifies the stride at which additional pixels are included in the output. For example an output ratio of 3, specifies that input pixels 1,2,3 become output pixel 1, that input pixels 4,5,6 become output pixel 2, and so on. Therefore, the pixel size changes but the starting location (e.g. the edge of input pixel 1 in this case) remains the same. Although the input images may align at the pixel level (for the smaller input pixels), there is no gaurentee that the larger pixels of the downsampled images will align. For example two 1-meter images may align at the pixel level if the first one has a western edge at 1000 meters and the second one has a western edge at 1001 meters. Then for example, A 1:3 downsample will produce two images which each have 3 meter pixels. However, the first downsampled image western edge will remain at 1000 and the second downsampled image western edge will remain at 1001 so that the downsampled second image will have a 1/3 downsampled pixel shift relative to the downsampled first image.
Therefore, if you anticipate creating downsampled image products, you should consider aligning the high resolution image pixels on a multiple of the anticipated larger downsample pixel size. For example if you anticipate producing a set of 50-meter pixel downsample images, you should generate 1-meter source imagery with North and West edges aligned with coordinate values ###00 or ###50 so that subsequently downsampled imagery will exhibit pixel alignment with the larger downsampled pixels.

Visual Quality

Q) I'm using version (2.2, 2.2.1, 2.2.2 or 2.2.3) and the color adjustment (Global Tilting) results seem to be better in an older version (e.g. from the 2.1.x series). Is there a reason for this? What can be done about it?
A) For versions (2.2, 2.2.1, 2.2.2, and 2.2.3) computation of the sampling locations is performed in a manner that can potentially produce sparse sampling of the input images. The reduced number of samples can, in some cases, lead to destabilization of the radiometric "tilting" computations. This can result in a subtle intensity mismatch between adjacent images or, in extreme cases, can produce strange coloring of output image data.
The actual effects on output image data depend on a complex combination of the regions selected for processing, the total mosaic area and shape, the portion of output mosaic covered by source imagery, the geometric configuration of source imagery, as well as the internal and relative radiometric variation characteristics of the source imagery. The situation is exacerbated somewhat when the source imagery is sparsely distributed throughout a processing region (e.g. as with a narrow corridor of source imagery running diagonally through a large square mosaic tile).
Changes incorporated into version 2.2.4 are 100% effective and avoid this problem completely. Therefore, it is recommended that you upgrade any early versions of the 2.2.x series to at least version 2.2.4.

(c) Copyright 1999 OrthoVista Direct. All rights reserved. OrthoVista(TM) is a Trademark of Stellacore Corporation Parker Colorado USA.