Description

The GEN<i>CAM standard provides an image sub-windowing mechanism as part of it’s required features identified in the Standard Feature Naming Convention (SFNC) document.  All Pixelink Gigabit Ethernet cameras support this sub-windowing as defined in this specification.  What’s more, Pixelink provides additional (proprietary) sub-window control mechanisms, which provide the user more flexibility in application and system design.  This technical note will describe both the standard based and proprietary mechanisms, how they interrelate, and offers guidance on when to use one over the other.

SFNC Sub-windowing

The GEN<i>CAM standard sub-windowing scheme allows the user to define an ‘Area Of Interest (AOI)’ within the entire field of view of the sensor.  It uses the following SNFC features to define this AOI:


•    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.


Pixelink Sub-Windowing


Pixelink defines two feature ‘classes’ that affect sub-windowing; Region Of Interest (ROI) and Pixel Addressing.  Region of Interest is a very similar construct to the standard based Area of Interest; whereby it is also a technique that can be used to reduce the image to only a subset of the entire field of view.  The most distinguishing characteristic between the two, however, is that ROI affects images expelled from the imaging sensor, whereas AOI affects images expelled from the camera.  This is explained in more detail in the ‘AOI vs ROI’ section of this paper.

The ROI can be created using the following PixeLINK specific features:


•    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


Given the functional overlap between the AOI and ROI features, most applications will use one strategy or the other – rarely would an application require both.  Both sub-windowing techniques will result in the same amount of image data being expelled from the camera.  

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: