Another factor affecting CPU usage is the order of the polynomial used to perform the geometric warping. The polynomials have to be evaluated for each pixel in the output image. High order polynomials require substantially more operations to compute than low order polynomials.
GCPWorks maintains a number of input scanlines in memory. These are called the ``Cache'', and the size of the cache determines the number of input scanlines that can be ``remembered'' at a time.
The registration process involves moving over the output image one scanline at a time. As each pixel along an output scanline is processed, the location is transformed according to the polynomial model to find a sampling position on the input image. The pixel value at this point in the input image is then fetched from the scanlines in the cache. If the transformed point does not fall on one of the scanlines already in the cache, the scanline is read in from disk, and the least recently used scanline in the cache is replaced.
Ideally each input scanline would only be read once, and kept in the cache until it is not needed again. This is the case where either no rotation, or a ninety degree rotation takes place. As one scanline in the output image is processed, the transformation requests samples from the same input scanline each time.
Unfortunately this is not a typical case. In cases with significant rotation and with a small cache relative to the size of the input image, it is likely that requested scanlines will not be in the cache already. In the worst case, it might be necessary to read an entire input scanline for each output pixel processed. To register a 6000x6000 output image from a 6000x6000 input image, the worst possible case is having to read each input scanline 6000 times; which means that the entire input file would have been read 6000 times. This could make the registration as much as 6000 times slower than if everything remained in the cache! This is the state known as ``Thrashing''.
Fortunately, the registration algorithm includes extra logic to detect thrashing and to take helpful measures. When GCPWorks detects that thrashing is taking place, it will abort the registration and start over again. When it starts over, it will only attempt a thin vertical strip of the output file at a time.
This will, hopefully, result in reuse of most of the input scanlines in the cache over a number of partial output scanlines, thus reducing the number of times each input scanline has to be read. This is most helpful in the case of a ninety degree rotation, and most destructive in the case of no rotation.
If GCPWorks detects thrashing, the progress monitor for the registration will drop back to zero as the algorithm starts again on smaller strips.
If increasing the size of the cache does not help enough, it can also be useful to reduce the number of channels registered at once. For instance, if seven bands of a full Landsat TM scene (6000x6000) are registered at once with a 4MB cache, then only about 100 scanlines of the input image can be held at once (6000x100x7=4200000); however, if only one band is registered, then 700 scanlines can be held (6000x700x1 = 4200000). If only one band at a time is registered, the polynomial transform and resampling calculations have to be performed once for each band; so this is a tradeoff of I/O against CPU usage. It is also wise to ensure that the input file is stored in band interleaved form if it is registered one band at a time.
Since the input image caching tends to break down when rotating by a large angle, it is helpful to scan input images in such an orientation that little rotation is needed (north up). This is not possible with data received in digital form.
See Also: Memory Cache