Advanced Topics

Output Delay for PushBroom Cameras

When sequentially processing PushBroom lines, some models may have an output delay. Take, for example, the following model:

Here we perform a simple thresholding to create a mask, and then use a 2D kernel-based operation to erode that mask. This eroded mask is then passed into an OutputSink that returns the data.

When processing PushBroom lines, since the kernel-based operation has to take into account neighboring pixels both in the x and y directions, it cannot immediately start returning data once the first line is being processed. Instead it only starts returning data once a later line (which one depends on the size of the kernel) is being processed. But the data returned on that line will be the data corresponding to the first line that was processed, not the current line that is being processed.

For example, if the kernel has a size of 3 by 3, this means that to obtain the value of any given pixel, both the lines above and below the current lines will have to be looked at. This means that when the first line is processed with this model, the erosion filter will not output anything, and on the second frame it will output the now processed first line.

This means that when processing PushBroom lines specific outputs may have a delay (measured in lines) relative to the input data that is being provided. In the above example of an erosion filter with a 3 by 3 kernel size, the output would have a delay of 1.

The framework behind fluxEngine automatically takes this into account, so processing within the model always stays consistent, but the delay may propagate through the entire model into the output, and the user of fluxEngine should be aware of this.

This delay can be queried by fluxEngine once a model has been loaded and a processing context been created.

Note

When processing entire image cubes there is never any delay between processing, and the result of processing a cube is independent of any other cubes cubes that came before it.