|
|
# HW image transformations
|
|
|
|
|
|
A camera can apply different image transformations like binning, flip or crop (RoI) in order to increase the maximum frame rate or reduce software processing overhead. For example, the `FReLoN` camera can perform simultaneously this three operations by hardware. There are typically alignment constraints on this operations, so it is not always possible to fulfill an arbitrary user request.
|
|
|
|
|
|
In Lima1 the control layer provides the `CtImage::ImageOpMode` to implement three different policies: `HardOnly`, `SoftOnly` and `HardAndSoft`. Lima1 core queries the HW to provide the closest configuration that satisfies the constraints and then, depending of the `ImageOpMode`, fulfill the user request with the software alternative.
|
|
|
|
|
|
In case of offering multiple hardware transformations, each manufacturer specifies the order in which they are applied. For instance, the `FReLoN` camera applies RoI, then binning and then flip. This is exactly the opposite sequence specified by Lima1, so the code inside the plugin has to perform many internal calculations to program the HW.
|
|
|
|
|
|
The proposition in Lima2 is to let the HW provide a description of the sequence of image transformations and to expose that to the user. The same kind of description is expected to be provided by the processing pipeline, coupling both HW and SW chains will allow transform any coordinate between any stage, from the detector sensor to the final image provided to the user.
|
|
|
|
|
|
# High level user configuration
|
|
|
# Layout vs HW reconstruction tasks |
|
|
\ No newline at end of file |