mvDriverBaseEnums.h File Reference
Define Documentation
| #define IGNORE_MVBLUEFOX_SPECIFIC_DOCUMENTATION |
| #define IGNORE_MVBLUELYNX_SPECIFIC_DOCUMENTATION |
| #define IGNORE_MVBLUELYNXX_SPECIFIC_DOCUMENTATION |
| #define IGNORE_MVGRABBER_SPECIFIC_DOCUMENTATION |
| #define IGNORE_MVV4L2_SPECIFIC_DOCUMENTATION |
| #define IGNORE_MVVIRTUALDEVICE_SPECIFIC_DOCUMENTATION |
Enumeration Type Documentation
| enum TAcquisitionField |
| enum TAcquisitionMode |
Defines valid acquisition modes.
- Note:
- This feature might change in future releases! Use it with care and be ready to change your code later.
- Enumerator:
Defines valid modes for acquisition start/stop behaviour.
- Enumerator:
| enum TAoiMode |
Defines valid Area Of Interest modes.
- Enumerator:
| enum TAutoControlMode |
| enum TAutoControlSpeed |
Defines valid AutoControlSpeed modes.
Auto control speed modes define the time in which the controller tries to adapt it's parameters to reach the desired result.
- Enumerator:
| enum TAutoExposureControl |
| enum TAutoGainControl |
| enum TBayerConversionMode |
Defines the bayer conversion algorithm to use.
- Enumerator:
| enum TBayerMosaicParity |
Defines valid bayer formats.
- Enumerator:
Defines valid results of a white balance calibration.
- Enumerator:
| enum TBoolean |
| enum TCameraAoiMode |
| enum TCameraBinningMode |
Defines valid binning modes for the camera.
- Note:
- Binning might be available for colour sensors that do not support colour binning. This will result in incorrect colour information when the data is converted from a Bayer sensor. However under some circumstances this feature might be useful (e.g. when taking image in a very dark surrounding or at night where almost no colour information will be contained in the image anyway thus resulting in useful images again). Therefore this feature has deliberately left available.
- Enumerator:
| enum TCameraExposeMode |
Defines recognized camera sensor expose modes.
- Enumerator:
| enum TCameraFlashMode |
| enum TCameraFlashType |
Defines valid camera flash control types.
- Enumerator:
| enum TCameraHDRMode |
Defines valid camera High Dynamic Range modes.
- Enumerator:
Defines how the camera transmits its video signal.
- Enumerator:
| enum TCameraPixelClock |
Defines valid camera pixel frequencies.
- Enumerator:
| enum TCameraScanMode |
| enum TCameraShutterMode |
Defines recognized camera sensor shutter modes.
- Enumerator:
| enum TCameraTestMode |
Defines valid transmission modes for the camera.
| enum TCameraTriggerMode |
Defines valid camera sensor trigger modes.
- Enumerator:
| enum TCameraTriggerSource |
Sensor trigger source.
- Enumerator:
| enum TChannelSplitMode |
Defines valid modes for channel split filters.
- Enumerator:
| enum TColorProcessingMode |
Defines the color processing mode.
- Enumerator:
Defines valid modes for defective pixels filter.
- Enumerator:
| enum TDeviceAccessMode |
Defines valid device access modes.
- Enumerator:
Defines valid advanced options.
These enums may be 'ored' together.
| enum TDeviceCapability |
Defines valid device capabilities.
Values of these enum type may be 'OR'ed together.
- Enumerator:
| enum TDeviceClass |
Defines grabber specific digital output modes.
- Enumerator:
| enum TDeviceEventMode |
Defines valid event states.
A driver might offer to inform the user about certain events that occur at runtime. This e.g. might be unplugging the device if it's PnP compliant or the detection of a digital input change.
| enum TDeviceEventType |
Defines valid device event types.
- Note:
- Not every device will support every event.
- Enumerator:
Defines valid interface layouts for the device.
The device interface layout defines what kind of features will be available after the device driver has been opened and where these features will be located.
- Enumerator:
-
dilGeneric A generic interface layout shall be used(deprecated). This interface layout might be available when a third party hardware is (or claims to be) compliant with a certain standard and the used device driver also implements this standard. The main purpose of this interface layout is to grant access to third party devices without having in-depth information about the device.
As an example a device might be GenICam compliant and the device driver also implements access to a GenICam™ layer via a certain transport layer protocol driver (e.g. GigE Vision™). In that case any third party device that is compliant with these standards can be operated using the generic interface layout.
This interface layout has been declared deprecated. Please use dilGenICam instead.
- See also:
- Working with the GenICam™ interface
dilDeviceSpecific A device specific interface shall be used. For most devices supported by this user API this will be the only layout available. In this interface layout also most of the features will have the same name and location for every device even if a device is operated using another device driver. However this interface layout requires the driver to have detailed information about the underlying hardware, thus it will not be available for third party hardware, that can be used with this device driver.
dilGenICam A GenICam™ like interface layout shall be used. This interface layout will be available when a device is (or claims to be) compliant with a the GenICam™ standard, thus provides a GenICam™ compliant XML interface description. This also applies for third party devices, which can be used with the GenICam GenTL Producer of mvIMPACT Acquire.
This interface layout will allow to access third party devices as well.
- See also:
- Working with the GenICam™ interface
| enum TDeviceLoadSettings |
Defines valid modes for the loading of settings during initialisation.
Whenever a Device is initialised this enumeration type defines the mode the Device tries to restore settings from a previously stored session.
- Enumerator:
| enum TDeviceState |
Defines valid Device states.
- Enumerator:
Defines which trigger interface is currently active for the device.
A device might offer different views on the properties that can be used to configure trigger signals and events.
- Enumerator:
Specifies the type trigger overlap permitted with the previous frame.
This defines when a valid trigger will be accepted (or latched) for a new frame.
| enum TDigIOState |
| enum TDMR_ERROR |
Errors reported by the device manager.
These are errors which might occur in connection with the device manager itself or while working with the single devices.
- Enumerator:
| enum TFlatFieldFilterMode |
| enum THWUpdateResult |
Defines valid Device HW update results.
This defines valid result e.g. of a user executed firmware update.
- Enumerator:
| enum TI2COperationMode |
| enum TI2COperationStatus |
Valid I2C operation status values.
- Enumerator:
Valid image buffer pixel formats.
- Enumerator:
-
ibpfRaw An unprocessed block of data. ibpfMono8 A single channel 8 bit per pixel format. ibpfMono16 A single channel 16 bit per pixel format. ibpfRGBx888Packed A three channel RGB image with 32 bit per pixel containing one fill byte per pixel. This is an interleaved pixel format suitable for most display functions. The data is stored pixel-wise. The memory layout of the pixel data is like this:
4 bytes 4 bytes etc. B(1) G(1) R(1) A(1) B(2) G(2) R(2) A(2) etc. ....................................... B(n) G(n) R(n) A(n)So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a byte pointer.
ibpfYUV422Packed This is a YUV422 packed image with 32 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 8 bits, the pair of pixels requires 32 bits.
Two consecutive pixels (32 bit, 0xaabbccdd ) contain 8 bit luminance of pixel 1(aa), 8 bit chrominance blue of pixel 1 and 2(bb), 8 bit luminance of pixel 2(cc) and finally 8 bit chrominance red of pixels 1 and 2(dd).
Thus in memory the data will be stored like this:
4 bytes 4 bytes etc. Y(1) Cb(1,2) Y(2) Cr(1,2) Y(3) Cb(3,4) Y(4) Cr(3,4) etc. ..........................Y(n-1) Cb(n-1,n) Y(n) Cr(n-1,n)So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a byte pointer.
ibpfRGBx888Planar The image will be transferred as an RGB image in planar format. This is a format best suitable for most image processing functions. The image will be converted into four planes(a plane for each color component and one alpha plane).
R(1) R(2) R(3) R(4) etc. ................... .............. R(n) G(1) G(2) G(3) G(4) etc. ................... .............. G(n) B(1) B(2) B(3) B(4) etc. ................... .............. B(n) A(1) A(2) A(3) A(4) etc. ................... .............. A(n)So the first byte in memory is the first pixels red component. ImageBuffer::vpData will therefore point to R(1) when using a byte pointer.
ibpfMono10 A single channel 10 bit per pixel format. Each pixel in this format consumes 2 bytes of memory. The lower 10 bit of this 2 bytes will contain valid data.
ibpfMono12 A single channel 12 bit per pixel format. Each pixel in this format consumes 2 bytes of memory. The lower 12 bit of this 2 bytes will contain valid data.
ibpfMono14 A single channel 14 bit per pixel format. Each pixel in this format consumes 2 bytes of memory. The lower 14 bit of this 2 bytes will contain valid data.
ibpfRGB888Packed The image will be transferred as an RGB image with 24 bit per pixel. This is an interleaved pixel format suitable for most display and processing functions. The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a byte pointer.
ibpfYUV444Planar This is a YUV444 planar image with 24 bit per pixels. A planar YUV format. In memory the data will be stored plane-wise like this:
Y(1) Y(2) Y(3) Y(4) etc. ............................ .............. Y(n-1) Y(n) Cr(1) Cr(2) Cr(3) Cr(4) etc. ............................ .............. Cr(n-1) Cr(n) Cb(1) Cb(2) Cb(3) Cb(4) etc. ............................ ............. Cb(n-1) Cb(n)So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a byte pointer.
ibpfMono32 A single channel 32 bit per pixel format. ibpfYUV422Planar This is a YUV422 planar image with 32 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 8 bits, the pair of pixels requires 32 bits.
In memory the data will be stored like this:
Y(1) Y(2) Y(3) Y(4) etc. ............................ .............. Y(n-1) Y(n) Cr(1,2) Cr(3,4) etc. ............... ....... Cr(n/2) Cb(1,2) Cb(3,4) etc. ............... ....... Cb(n/2)Thus the Y planes size in bytes equals the sum of the 2 other planes.
So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a byte pointer.
ibpfRGB101010Packed The image will be transferred as an RGB image with 30 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned, thus the 6 MSB of each 16 bit will not contain valid data.
So the first 2 bytes in memory are the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
ibpfRGB121212Packed The image will be transferred as an RGB image with 36 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned, thus the 4 MSB of each 16 bit will not contain valid data.
So the first 2 bytes in memory are the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
ibpfRGB141414Packed The image will be transferred as an RGB image with 42 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned, thus the 2 MSB of each 16 bit will not contain valid data.
So the first 2 bytes in memory are the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
ibpfRGB161616Packed The image will be transferred as an RGB image with 48 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned.
So the first 2 bytes in memory are the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
ibpfYUV422_UYVYPacked This is a YUV422 packed image with 32 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 8 bits, the pair of pixels requires 32 bits.
Two consecutive pixels (32 bit, 0xaabbccdd ) will contain 8 bit chrominance blue of pixel 1 and 2(aa), 8 bit luminance of pixel 1(bb), 8 bit chrominance red of pixel 1 and 2 (cc) and finally 8 bit luminance of pixel 2(dd).
Thus in memory the data will be stored like this:
4 bytes 4 bytes etc. Cb(1,2) Y(1) Cr(1,2) Y(2) Cb(3,4) Y(3) Cr(3,4) Y(4) etc. ..........................Cb(n-1,n) Y(n-1) Cr(n-1,n) Y(n)So the first byte in memory is the first pixels Cb component. ImageBuffer::vpData will therefore point to Cb(1,2) when using a byte pointer.
ibpfMono12Packed_V2 A single channel 12 bit per pixel packed format. This format will use 3 bytes to store 2 12 bit pixel. Every 3 bytes will use the following layout in memory:
3 bytes 3 bytes etc. bits 11..4(1) bits 3..0(1) bits 3..0(2) bits 11..4(2) bits 11..4(3) bits 3..0(3) bits 3..0(4) bits 11..4(4) etc.- Note:
- When the width is not divisible by 2 the line pitch of buffer can't be used to calculate line start offsets in a buffer. In that case something like this can be used to access a certain pixel:
Show C++ code
ibpfYUV422_10Packed This is a YUV422 packed image with 64 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 16 bits, the pair of pixels requires 64 bits.
Two consecutive pixels (64 bit, 0xaaaabbbbccccdddd ) contain 10 bit luminance of pixel 1(aaaa), 10 bit chrominance blue of pixel 1 and 2(bbbb), 10 bit luminance of pixel 2(cccc) and finally 10 bit chrominance red of pixels 1 and 2(dddd). The upper 6 bits of each component will be 0.
Thus in memory the data will be stored like this:
8 bytes 8 bytes etc. Y(1) Cb(1,2) Y(2) Cr(1,2) Y(3) Cb(3,4) Y(4) Cr(3,4) etc. ..........................Y(n-1) Cb(n-1,n) Y(n) Cr(n-1,n)So the first 2 bytes in memory are the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a 16 bit pointer.
ibpfYUV422_UYVY_10Packed This is a YUV422 packed image with 64 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 16 bits, the pair of pixels requires 64 bits.
Two consecutive pixels (64 bit, 0xaaaabbbbccccdddd ) will contain 10 bit chrominance blue of pixel 1 and 2(aaaa), 10 bit luminance of pixel 1(bbbb), 10 bit chrominance red of pixel 1 and 2 (cccc) and finally 10 bit luminance of pixel 2(dddd). The upper 6 bits of each component will be 0.
Thus in memory the data will be stored like this:
8 bytes 8 bytes etc. Cb(1,2) Y(1) Cr(1,2) Y(2) Cb(3,4) Y(3) Cr(3,4) Y(4) etc. ..........................Cb(n-1,n) Y(n-1) Cr(n-1,n) Y(n)So the first 2 bytes in memory are the first pixels luminance component. ImageBuffer::vpData will therefore point to Cb(1,2) when using a 16 bit pointer.
ibpfBGR888Packed The image will be transferred as an RGB image with 24 bit per pixel. This is an interleaved pixel format suitable for most processing functions. Most blit/display function however will expect ibpfRGB888Packed. The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. R(1)G(1)B(1) R(2)G(2)B(2) R(3)G(3)B(3) etc. .......................................... ........................... R(n)G(n)B(n)So the first byte in memory is the first pixels red component. ImageBuffer::vpData will therefore point to R(1) when using a byte pointer.
ibpfBGR101010Packed_V2 A 10 bit per colour component RGB packed format. This format will use 4 bytes to store one 10 bit per colour component RGB pixel. The following memory layout is used for each pixel:
byte 0 | byte 1 | byte 2 | byte 3 | 0 7 | 890....5 | 6..90..3 | 4 9xx | RRRRRRRR | RRGGGGGG | GGGGBBBB | BBBBBB |- Note:
- Access to a certain pixel can e.g. be implemented like this:
Show C++ code
ibpfYUV444_UYVPacked The image will be transferred as an YUV image with 24 bit per pixel. This is an interleaved pixel format.
The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. Cb(1)Y(1)Cr(1) Cb(2)Y(2)Cr(2) Cb(3)Y(3)Cr(3) etc. .......................................... ........................... Cb(n)Y(n)Cr(n)So the first byte in memory is the first pixels Cb component. ImageBuffer::vpData will therefore point to Cb(1) when using a byte pointer.
ibpfYUV444_UYV_10Packed The image will be transferred as an YUV image with 30 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. Cb(1)Y(1)Cr(1) Cb(2)Y(2)Cr(2) Cb(3)Y(3)Cr(3) etc. .......................................... ........................... Cb(n)Y(n)Cr(n)The data of each color component will be LSB aligned, thus the 6 MSB of each 16 bit will not contain valid data.
So the first byte in memory is the first pixels Cb component. ImageBuffer::vpData will therefore point to Cb(1) when using a 16 bit pointer.
ibpfYUV444Packed The image will be transferred as an YUV image with 24 bit per pixel. This is an interleaved pixel format.
The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. Y(1)Cb(1)Cr(1) Y(2)Cb(2)Cr(2) Y(3)Cb(3)Cr(3) etc. .......................................... ........................... Y(n)Cb(n)Cr(n)So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a byte pointer.
ibpfYUV444_10Packed The image will be transferred as an YUV image with 30 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per color component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. Y(1)Cb(1)Cr(1) Y(2)Cb(2)Cr(2) Y(3)Cb(3)Cr(3) etc. .......................................... ........................... Y(n)Cb(n)Cr(n)The data of each color component will be LSB aligned, thus the 6 MSB of each 16 bit will not contain valid data.
So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a 16 bit pointer.
ibpfAuto The driver will decide which format will be used.
Hide C++ codeDefines the pixel format of the result image.
- Enumerator:
-
idpfAuto The driver will decide which destination format will be used. idpfRaw The image will be transferred as an unprocessed block of data. idpfMono8 The image will be transferred as a mono channel 8 bit per pixel image. idpfRGBx888Packed The image will be transferred as an RGB image with 32 bit per pixel containing one fill byte per pixel. This is an interleaved pixel format suitable for most display functions. The data is stored pixel-wise. When accessed 4-byte wise the data layout in memory can be interpreted like this (starting with the MSB):
4 bytes 4 bytes etc. B(1) G(1) R(1) A(1) B(2) G(2) R(2) A(2) etc. ....................................... B(n) G(n) R(n) A(n)So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a byte pointer.
idpfYUV422Packed This is a YUV422 packed image with 32 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 8 bits, the pair of pixels requires 32 bits.
Two consecutive pixels (32 bit, 0xaabbccdd ) contain 8 bit luminance of pixel 1(aa), 8 bit chrominance blue of pixel 1 and 2(bb), 8 bit luminance of pixel 2(cc) and finally 8 bit chrominance red of pixels 1 and 2(dd).
Thus in memory the data will be stored like this:
4 bytes 4 bytes etc. Y(1) Cb(1,2) Y(2) Cr(1,2) Y(3) Cb(3,4) Y(4) Cr(3,4) etc. ..........................Y(n-1) Cb(n-1,n) Y(n) Cr(n-1,n)So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a byte pointer.
idpfRGBx888Planar The image will be transferred as an RGB image in planar format. This is a format best suitable for most image processing functions. The image will be converted into four planes(a plane for each color component and one alpha plane).
R(1) R(2) R(3) R(4) etc. ................... .............. R(n) G(1) G(2) G(3) G(4) etc. ................... .............. G(n) B(1) B(2) B(3) B(4) etc. ................... .............. B(n) A(1) A(2) A(3) A(4) etc. ................... .............. A(n)So the first byte in memory is the first pixels red component. ImageBuffer::vpData will therefore point to R(1) when using a byte pointer.
idpfMono10 The image will be transferred as a mono channel 10 bit per pixel image. Each pixel in this format consumes 2 bytes of memory. The lower 10 bit of this 2 bytes will contain valid data.
idpfMono12 The image will be transferred as a mono channel 12 bit per pixel image. Each pixel in this format consumes 2 bytes of memory. The lower 12 bit of this 2 bytes will contain valid data.
idpfMono14 The image will be transferred as a mono channel 14 bit per pixel image. Each pixel in this format consumes 2 bytes of memory. The lower 14 bit of this 2 bytes will contain valid data.
idpfMono16 The image will be transferred as a mono channel 16 bit per pixel image. idpfRGB888Packed The image will be transferred as an RGB image with 24 bit per pixel. This is an interleaved pixel format suitable for most display and processing functions. The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a byte pointer.
idpfYUV422Planar The image will be transferred as a YUV422 image with 16 bit per pixel. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 8 bits, the pair of pixels requires 32 bits.
In memory the data will be stored like this:
Y(1) Y(2) Y(3) Y(4) etc. ............................ .............. Y(n-1) Y(n) Cr(1,2) Cr(3,4) etc. ............... ....... Cr(n/2) Cb(1,2) Cb(3,4) etc. ............... ....... Cb(n/2)Thus the Y planes size in bytes equals the sum of the 2 other planes.
So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a byte pointer.
idpfRGB101010Packed The image will be transferred as an RGB image with 30 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned, thus the 6 MSB of each 16 bit will not contain valid data.
So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
idpfRGB121212Packed The image will be transferred as an RGB image with 36 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned, thus the 4 MSB of each 16 bit will not contain valid data.
So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
idpfRGB141414Packed The image will be transferred as an RGB image with 42 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned, thus the 2 MSB of each 16 bit will not contain valid data.
So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
idpfRGB161616Packed The image will be transferred as an RGB image with 48 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. B(1)G(1)R(1) B(2)G(2)R(2) B(3)G(3)R(3) etc. .......................................... ........................... B(n)G(n)R(n)The data of each colour component will be LSB aligned.
So the first byte in memory is the first pixels blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.
idpfYUV422_UYVYPacked This is a YUV422 packed image with 32 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 8 bits, the pair of pixels requires 32 bits.
Two consecutive pixels (32 bit, 0xaabbccdd ) will contain 8 bit chrominance blue of pixel 1 and 2(aa), 8 bit luminance of pixel 1(bb), 8 bit chrominance red of pixel 1 and 2 (cc) and finally 8 bit luminance of pixel 2(dd).
Thus in memory the data will be stored like this:
4 bytes 4 bytes etc. Cb(1,2) Y(1) Cr(1,2) Y(2) Cb(3,4) Y(3) Cr(3,4) Y(4) etc. ..........................Cb(n-1,n) Y(n-1) Cr(n-1,n) Y(n)So the first byte in memory is the first pixels Cb component. ImageBuffer::vpData will therefore point to Cb(1,2) when using a byte pointer.
idpfMono12Packed_V2 A single channel 12 bit per pixel packed format. This format will use 3 bytes to store 2 12 bit pixel. Every 3 bytes will use the following layout in memory:
3 bytes 3 bytes etc. bits 11..4(1) bits 3..0(1) bits 3..0(2) bits 11..4(2) bits 11..4(3) bits 3..0(3) bits 3..0(4) bits 11..4(4) etc.- Note:
- When the width is not divisible by 2 the line pitch of buffer can't be used to calculate line start offsets in a buffer. In that case something like this can be used to access a certain pixel:
Show C++ code
idpfYUV422_10Packed This is a YUV422 packed image with 64 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 16 bits, the pair of pixels requires 64 bits.
Two consecutive pixels (64 bit, 0xaaaabbbbccccdddd ) contain 10 bit luminance of pixel 1(aaaa), 10 bit chrominance blue of pixel 1 and 2(bbbb), 10 bit luminance of pixel 2(cccc) and finally 10 bit chrominance red of pixels 1 and 2(dddd). The upper 6 bits of each component will be 0.
Thus in memory the data will be stored like this:
8 bytes 8 bytes etc. Y(1) Cb(1,2) Y(2) Cr(1,2) Y(3) Cb(3,4) Y(4) Cr(3,4) etc. ..........................Y(n-1) Cb(n-1,n) Y(n) Cr(n-1,n)So the first 2 bytes in memory are the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a 16 bit pointer.
idpfYUV422_UYVY_10Packed This is a YUV422 packed image with 64 bit for a pair of pixels. This format uses 2:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 2 pixels in horizontal direction. If each component takes 16 bits, the pair of pixels requires 64 bits.
Two consecutive pixels (64 bit, 0xaaaabbbbccccdddd ) will contain 10 bit chrominance blue of pixel 1 and 2(aaaa), 10 bit luminance of pixel 1(bbbb), 10 bit chrominance red of pixel 1 and 2 (cccc) and finally 10 bit luminance of pixel 2(dddd). The upper 6 bits of each component will be 0.
Thus in memory the data will be stored like this:
8 bytes 8 bytes etc. Cb(1,2) Y(1) Cr(1,2) Y(2) Cb(3,4) Y(3) Cr(3,4) Y(4) etc. ..........................Cb(n-1,n) Y(n-1) Cr(n-1,n) Y(n)So the first 2 bytes in memory are the first pixels luminance component. ImageBuffer::vpData will therefore point to Cb(1,2) when using a 16 bit pointer.
idpfBGR888Packed The image will be transferred as an RGB image with 24 bit per pixel. This is an interleaved pixel format suitable for most processing functions. Most blit/display function however will expect idpfRGB888Packed. The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. R(1)G(1)B(1) R(2)G(2)B(2) R(3)G(3)B(3) etc. .......................................... ........................... R(n)G(n)B(n)So the first byte in memory is the first pixels red component. ImageBuffer::vpData will therefore point to R(1) when using a byte pointer.
idpfBGR101010Packed_V2 A 10 bit per colour component RGB packed format. This format will use 4 bytes to store one 10 bit per colour component RGB pixel. The following memory layout is used for each pixel:
byte 0 | byte 1 | byte 2 | byte 3 | 0 7 | 890....5 | 6..90..3 | 4 9xx | RRRRRRRR | RRGGGGGG | GGGGBBBB | BBBBBB |- Note:
- Access to a certain pixel can e.g. be implemented like this:
Show C++ code
idpfYUV444_UYVPacked The image will be transferred as an YUV image with 24 bit per pixel. This is an interleaved pixel format.
The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. Cb(1)Y(1)Cr(1) Cb(2)Y(2)Cr(2) Cb(3)Y(3)Cr(3) etc. .......................................... ........................... Cb(n)Y(n)Cr(n)So the first byte in memory is the first pixels Cb component. ImageBuffer::vpData will therefore point to Cb(1) when using a byte pointer.
idpfYUV444_UYV_10Packed The image will be transferred as an YUV image with 30 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. Cb(1)Y(1)Cr(1) Cb(2)Y(2)Cr(2) Cb(3)Y(3)Cr(3) etc. .......................................... ........................... Cb(n)Y(n)Cr(n)The data of each colour component will be LSB aligned, thus the 6 MSB of each 16 bit will not contain valid data.
So the first byte in memory is the first pixels Cb component. ImageBuffer::vpData will therefore point to Cb(1) when using a 16 bit pointer.
idpfYUV444Packed The image will be transferred as an YUV image with 24 bit per pixel. This is an interleaved pixel format.
The data is stored pixel-wise:
3 bytes 3 bytes 3 bytes etc. Y(1)Cb(1)Cr(1) Y(2)Cb(2)Cr(2) Y(3)Cb(3)Cr(3) etc. .......................................... ........................... Y(n)Cb(n)Cr(n)So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a byte pointer.
idpfYUV444_10Packed The image will be transferred as an YUV image with 30 bit of usable data per pixel. This is an interleaved pixel format with 2 bytes per colour component. The data is stored pixel-wise:
6 bytes 6 bytes 6 bytes etc. Y(1)Cb(1)Cr(1) Y(2)Cb(2)Cr(2) Y(3)Cb(3)Cr(3) etc. .......................................... ........................... Y(n)Cb(n)Cr(n)The data of each colour component will be LSB aligned, thus the 6 MSB of each 16 bit will not contain valid data.
So the first byte in memory is the first pixels luminance component. ImageBuffer::vpData will therefore point to Y(1) when using a 16 bit pointer.
Defines the behaviour of an ImageRequestControl.
- Enumerator:
| enum TInfoSensorColorMode |
Defines the bayer pattern of the sensor.
- Enumerator:
| enum TInfoSensorType |
| enum TInterlacedMode |
Defines how to handle interlaced image data.
Image data might be transmitted as fields. These later can either be combined back into a full frame or can be handled individually.
| enum TLUTGammaMode |
Defines valid LUT(LookUp Table) gamma modes.
- Enumerator:
| enum TLUTImplementation |
Defines valid LUT(LookUp Table) interpolation modes.
| enum TLUTMapping |
Defines valid LUT(LookUp Table) mapping modes.
- Enumerator:
| enum TLUTMode |
Defines valid LUT(LookUp Table) modes.
| enum TMemoryManagerMode |
Defines valid modes to operate the memory manager in.
- Enumerator:
| enum TMirrorMode |
Defines valid mirror modes.
These enumeration values may be 'ored' together.
| enum TMirrorOperationMode |
| enum TPulseStartTrigger |
- Enumerator:
Defines valid image modes for request objects.
- Enumerator:
| enum TRequestResult |
Defines valid result of an image request.
Whenever during the processing of the capture parameters but well before the actual image capture and error is detected the MSB of this enumeration will be set to 1. In this case almost every time the current input parameters can't lead to a correct image and have to be changed.
- Enumerator:
| enum TRequestState |
Defines the current state of this Request.
- Enumerator:
| enum TRTCtrlModes |
| enum TRTProgOpCodes |
Defines valid RTProg OpCodes.
- Enumerator:
| enum TScalerMode |
| enum TThreadPriority |
Defines valid thread priorities.
| enum TTriggerMoment |
| enum TUserDataAccessRight |
Defines valid flags for controlling the user access rights to the user data that can be stored in the devices non-volatile memory.
- Enumerator:
Defined valid values for the behaviour of the user data when a device has been disconnected and reconnected within a running process.
- Enumerator:
| enum TVideoStandard |
Defines valid video standards that might be supported by a video capture device.
- Enumerator:
Defines valid white balance calibration modes.
Defines valid parameter sets selectable via the WhiteBalance property.
- Enumerator:
