... | ... | @@ -22,7 +22,7 @@ Detectors generating independent sub-images from different modules require an as |
|
|
|
|
|
This information must be provided by the camera plugin so the processing pipeline can properly assemble the image. Three variants are being analyzed:
|
|
|
|
|
|
1. Include the RoI, flip and rotation information in the detector layout structure. This simplifies the camera plugin implementation because it does not need to know about the processing API. However, the camera plugin must anyway be able to describe the image transformation performed by hardware, [as mentioned before](# HW image transformations). Such `HardwareLayout` is specific to the insertion of the image into the processing pipeline, and the order of the transformation must be explicitly defined.
|
|
|
1. Include the RoI, flip and rotation information in the detector layout structure. This simplifies the camera plugin implementation because it does not need to know about the processing API. However, the camera plugin must anyway be able to describe the image transformation performed by hardware, [as mentioned before](# HW image transformations). Such `HardwareLayout` is specific to the insertion of the image into the processing pipeline, and the order of the transformations must be explicitly defined.
|
|
|
|
|
|
2. The camera plugin can provide the a description of a chain of transformations tasks in order to reconstruct the sub-images in terms of RoI, flip and/or rotation, so the Layout structure only includes the final translation to assemble the image. This can be done in a similar way the camera exposes the sequence of transformations made by the hardware.
|
|
|
|
... | ... | |