• SensorWidth – The effective width of the sensor, in pixels.
• SensorHeight – The effective height of the sensor, in pixels.
• Width – The actual image width expelled by the camera, in pixels (AOI width).
• Height – The actual image height expelled by the camera, in pixels (AOI height).
• OffsetX – The horizontal offset from the AOI origin to the AOI, in pixels.
• OffsetY – The vertical offset from the AOI origin to the AOI, in pixels.
The relationship between these features is represented by the following diagram.
• MaxSensorWidth – The true width of the sensor, in pixels.
• MaxSensorHeight – The true height of the sensor, in pixels.
• RoiWidth – The actual image width expelled by the imaging sensor, in pixels.
• RoiHeight – The actual image height expelled by the imaging sensor, in pixels.
• RoiOffsetX – The horizontal offset from the ROI origin to the ROI, in pixels.
• RoiOffsetY – The vertical offset from the ROI origin to the ROI, in pixels.
The Pixel Addressing features controls the number of pixels read from the ROI, in essence, compressing an image (with data loss). It is controlled by two features:
• PixelAddressingFactor – The compression factor to use for the ROI – an image will be compressed by the square of the value. For instance, a value of “By_4” will, reduce the number of pixels in the ROI width by 4, AND reduce the number of pixels in the ROI height by 4 – thus the entire image will only contain 1/16th the number of pixels.
• PixelAddressingMode – Defines the compression strategy used. ‘Decimation’ mode for instance, will compress the image by ignoring specified pixels within the ROI. See the PixeLINK documentation for a detail explanation on the various Pixel Addressing Modes available for different camera models.
AOI vs ROI
The AOI features have the advantage in that they are ‘standards’ based. That means that if an application were being developed based on some sample code, or a pre-existing application – it is quite likely that this code will contain support for the AOI features. Conversely, the ROI adjustment features have the advantage of providing a sub-windowing control as it relates to the sensor. That is, once an ROI has been established, the camera only needs to scan that portion of the sensor that is related to the ROI. This has some performance advantages, as it will allow for more frequent image scans, thus permitting the camera to operate at higher frame rates.
If an application were to use the AOI features together with either the ROI or Pixel Addressing features, it is important to realise that the features are applied in the following order; any ROI is applied, then any Pixel Addressing is applied, then finally, AOI is applied. This order is supported by the fact that ROI and Pixel Addressing is applied to images read from the sensor, and AOI is applied to images as they are expelled from the camera. Consequently, if an application were to adjust any of the Pixel Addressing or ROI features, then they may want to make comparable adjustments to the AOI features (specifically Width and Height). This is best explained by example. Say an application was working with a sensor whose dimensions were 1024x768 pixels, and is using the full field of view (no AOI, no ROI). In this case, Width would be 1024, and Height would be 768. However, if the application were to apply a Pixel Addressing of ‘Decimate, By_2’, then image being read from the camera would be reduced to 512x384. It is common for applications to display (preview) images that are based on the Width and Height fields, which in this case, do not match the images size expelled from the camera. To compensate for this, the application should set the Width and Height fields to the new values (512 and 384 respectively) so that the image preview can be seen correctly.
The relationship between the AOI and ROI features is characterised in the following diagram: