mvIMPACT Acquire SDK C++
Common

Classes and functions that are available for all interface layouts. More...

Classes

class  BasicDeviceSettings
 A base class for essential device related settings. More...
 
class  BufferPart
 Contains information about a specific part of a captured buffer. More...
 
struct  ChannelData
 A structure for image buffer channel specific data. More...
 
class  Component
 A base class to implement access to internal driver components. More...
 
class  ComponentAccess
 A base class to implement access to internal driver objects. More...
 
class  ComponentCallback
 A simple helper class to wrap the creation of a callback object. More...
 
class  ComponentCollection
 A base class for sets of properties that can be modified by the user. More...
 
class  ComponentList
 A class to provide access to component lists. More...
 
class  ComponentLocator
 A class to locate components within the driver. More...
 
class  ComponentLocatorBase
 A base class to locate components within the driver. More...
 
class  Device
 This class and its functions represent an actual device detected by this interface in the current system. More...
 
class  DeviceComponentLocator
 A class to locate components within the driver. More...
 
class  DeviceManager
 Grants access to devices that can be operated by this software interface. More...
 
class  ECantAccessData
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_LIST_CANT_ACCESS_DATA error. More...
 
class  ECantAllocateNewList
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_CANT_ALLOCATE_LIST error. More...
 
class  ECantRegisterComponent
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_CANT_REGISTER_COMPONENT error. More...
 
class  ECantSerializeData
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_CANT_SERIALIZE_DATA error. More...
 
class  EComponent
 A base class for mvIMPACT::acquire::Component object related exceptions from the property module. More...
 
class  EComponentIDInvalid
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_COMPONENT_ID_INVALID error. More...
 
class  EComponentNotFound
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_COMPONENT_NOT_FOUND error. More...
 
class  EDeviceManager
 A base class for device manager related exceptions. More...
 
class  EImplementationMissing
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_IMPLEMENTATION_MISSING error. More...
 
class  EIncompatibleComponents
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_INCOMPATIBLE_COMPONENTS error. More...
 
class  EInputBufferTooSmall
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_INPUT_BUFFER_TOO_SMALL error. More...
 
class  EInvalidFileContent
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_INVALID_FILE_CONTENT error. More...
 
class  EInvalidInputParameter
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_INVALID_INPUT_PARAMETER error. More...
 
class  EInvalidListID
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_LIST_ID_INVALID error. More...
 
class  EInvalidParameterList
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_METHOD_INVALID_PARAM_LIST error. More...
 
class  EInvalidValue
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_INVALID_PROP_VALUE error. More...
 
class  EInvalidValueType
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_INVALID_PROP_VALUE_TYPE error. More...
 
class  EListEntryOccupied
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_LIST_ENTRY_OCCUPIED error. More...
 
class  EMethod
 A base class for mvIMPACT::acquire::Method object related exceptions from the property module. More...
 
class  EMethodPtrInvalid
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_METHOD_PTR_INVALID error. More...
 
class  ENoModifySizeRights
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_NO_MODIFY_SIZE_RIGHTS error. More...
 
class  ENoReadRights
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_NO_READ_RIGHTS error. More...
 
class  ENotAList
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_NOT_A_LIST error. More...
 
class  ENotAMethod
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_NOT_A_METHOD error. More...
 
class  ENotAProperty
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_NOT_A_PROPERTY error. More...
 
class  ENoWriteRights
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_NO_WRITE_RIGHTS error. More...
 
class  EnumPropertyF< ZYX >
 A template class to represent float properties and enumerated float properties. More...
 
class  EnumPropertyI< ZYX >
 A template class to represent 32 bit integer properties and 32 bit enumerated integer properties. More...
 
class  EnumPropertyI64< ZYX >
 A template class to represent 64 bit integer properties and enumerated 64 bit integer properties. More...
 
class  EProperty
 A base class for mvIMPACT::acquire::Property related exceptions from the property module. More...
 
class  EPropertyHandling
 A base class for exceptions related to the property module. More...
 
class  EPropertyList
 A base class for component list related exceptions from the property module. More...
 
class  ESizeMismatch
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_SIZE_MISMATCH error. More...
 
class  ETranslationTableCorrupted
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_PROP_TRANSLATION_TABLE_CORRUPTED error. More...
 
class  ETranslationTableNotDefined
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_PROP_TRANSLATION_TABLE_NOT_DEFINED error. More...
 
class  EUnsupportedOperation
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_UNSUPPORTED_OPERATION error. More...
 
class  EUnsupportedParameter
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_UNSUPPORTED_PARAMETER error. More...
 
class  EValidationFailed
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_PROP_VALIDATION_FAILED error. More...
 
class  EValIDOutOfBounds
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_PROP_VAL_ID_OUT_OF_BOUNDS error. More...
 
class  EValTooLarge
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_PROP_VAL_TOO_LARGE error. More...
 
class  EValTooSmall
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_PROP_VAL_TOO_SMALL error. More...
 
struct  EventData
 A structure containing information about an event that has been reported by the device driver and has been successfully waited for. More...
 
class  EWrongParamCount
 An exception thrown in case of a mvIMPACT::acquire::PROPHANDLING_WRONG_PARAM_COUNT error. More...
 
class  ExceptionFactory
 A factory class to raise mvIMPACT acquire related exceptions. More...
 
class  FullSettingsBase
 A base class that provides access to the most common settings for a device. More...
 
class  FunctionInterface
 The function interface to devices supported by this interface. More...
 
class  GainOffsetKneeChannelParameters
 Properties for configuring settings belonging to a certain channel of the GainOffsetKnee filter. More...
 
class  RequestProvider
 A helper class that can be used to implement a simple continuous acquisition from a device. More...
 
class  ThreadSafeQueue< T >
 A thread-safe queue. More...
 
struct  ImageBuffer
 Fully describes a captured image. More...
 
class  ImageBufferDesc
 A wrapper class to handle mvIMPACT::acquire::ImageBuffer structures. More...
 
class  ImageDestination
 Properties to define the format of resulting images. More...
 
class  ImageProcessing
 Base class for image processing related properties. More...
 
class  ImageRequestControl
 A helper class to control the way an image request will be processed. More...
 
class  ImpactAcquireException
 A base class for exceptions generated by mvIMPACT Acquire. More...
 
class  Info
 A base class to access various general information about the device and its driver. More...
 
class  FirmwareUpdater
 A class to perform a firmware update of a specific device. More...
 
class  VideoStream
 A class to create compressed video stream from images captured or loaded using the mvIMPACT Acquire API. More...
 
class  VideoStreamPauseScope
 A smaller helper class for pausing a video stream for a defined time. More...
 
class  LUTParameters
 Properties for configuring settings belonging to a certain LUT (Look Up Table) to be applied to a captured image. More...
 
class  Method
 A class to call arbitrary driver functions. More...
 
class  MirrorParameters
 Properties for configuring settings belonging to the mirror filter that processes a certain channel of a captured image. More...
 
class  Property
 A base class for properties. More...
 
class  PropertyPtr
 A class to represent pointer properties. More...
 
class  PropertyS
 A class to represent string properties. More...
 
class  Request
 Contains information about a captured buffer. More...
 
class  RequestFactory
 A default request factory. More...
 
class  RequestInfoConfiguration
 Properties to configure which information shall be attached to the resulting images. More...
 
class  Statistics
 Contains basic statistical information. More...
 
class  SystemSettings
 A base class for accessing settings that control the overall behaviour of a device driver. More...
 
class  TriggerControl
 A class to configure the behaviour of trigger signals. More...
 
class  UserData
 A helper class to work with the device specific non-volatile memory(if available). More...
 
class  UserDataEntry
 A helper class that represents one entry in the devices non-volatile memory. More...
 
class  WhiteBalancer
 Convenience class to provide an easy way for a more precise white balance calibration. More...
 
class  WhiteBalanceSettings
 Properties for adjusting the colors during a Bayer conversion. More...
 

Macros

#define MVIMPACT_H_
 

Typedefs

typedef Component ComponentIterator
 A class to iterate over component lists. More...
 
typedef Info InfoBase
 deprecated. Use the class mvIMPACT::acquire::Info instead. More...
 
typedef EnumPropertyF< double > PropertyF
 A type for floating point properties. More...
 
typedef EnumPropertyI< int > PropertyI
 A type for integer properties. More...
 
typedef EnumPropertyI64< int64_type > PropertyI64
 Provided for convenience only. This type represents a standard 64 bit integer property type. More...
 
typedef EnumPropertyI64< TBufferPartDataTypePropertyI64BufferPartDataType
 Defines a property for values defined by mvIMPACT::acquire::TImageBufferPartType. More...
 
typedef EnumPropertyI64< TDeviceTriggerOverlapPropertyI64DeviceTriggerOverlap
 Defines a property for values defined by mvIMPACT::acquire::TDeviceTriggerOverlap. More...
 
typedef EnumPropertyI< TAcquisitionModePropertyIAcquisitionMode
 Defines a property for values defined by mvIMPACT::acquire::TAcquisitionMode. More...
 
typedef EnumPropertyI< TAcquisitionStartStopBehaviourPropertyIAcquisitionStartStopBehaviour
 Defines a property for values defined by mvIMPACT::acquire::TAcquisitionStartStopBehaviour. More...
 
typedef EnumPropertyI< TAoiModePropertyIAoiMode
 Defines a property for values defined by mvIMPACT::acquire::TAoiMode. More...
 
typedef EnumPropertyI< TBayerConversionModePropertyIBayerConversionMode
 Defines a property for values defined by mvIMPACT::acquire::TBayerConversionMode. More...
 
typedef EnumPropertyI< TBayerMosaicParityPropertyIBayerMosaicParity
 Defines a property for values defined by mvIMPACT::acquire::TBayerMosaicParity. More...
 
typedef EnumPropertyI< TBayerWhiteBalanceResultPropertyIBayerWhiteBalanceResult
 Defines a property for values defined by mvIMPACT::acquire::TBayerWhiteBalanceResult. More...
 
typedef EnumPropertyI< TBooleanPropertyIBoolean
 Defines a property for values defined by mvIMPACT::acquire::TBoolean. More...
 
typedef EnumPropertyI< TCameraOutputPropertyICameraOutput
 Defines a property for values defined by mvIMPACT::acquire::TCameraOutput. More...
 
typedef EnumPropertyI< TChannelSplitModePropertyIChannelSplitMode
 Defines a property for values defined by mvIMPACT::acquire::TChannelSplitMode. More...
 
typedef EnumPropertyI< TColorProcessingModePropertyIColorProcessingMode
 Defines a property for values defined by mvIMPACT::acquire::TColorProcessingMode. More...
 
typedef EnumPropertyI< TColorTwistInputCorrectionMatrixModePropertyIColorTwistInputCorrectionMatrixMode
 Defines a property for values defined by mvIMPACT::acquire::TColorTwistInputCorrectionMatrixMode. More...
 
typedef EnumPropertyI< TColorTwistOutputCorrectionMatrixModePropertyIColorTwistOutputCorrectionMatrixMode
 Defines a property for values defined by mvIMPACT::acquire::TColorTwistOutputCorrectionMatrixMode. More...
 
typedef EnumPropertyI< TDarkCurrentFilterModePropertyIDarkCurrentFilterMode
 Defines a property for values defined by mvIMPACT::acquire::TDarkCurrentFilterMode. More...
 
typedef EnumPropertyI< TDefectivePixelsFilterModePropertyIDefectivePixelsFilterMode
 Defines a property for values defined by mvIMPACT::acquire::TDefectivePixelsFilterMode. More...
 
typedef EnumPropertyI< TDeviceAccessModePropertyIDeviceAccessMode
 Defines a property for values defined by mvIMPACT::acquire::TDeviceAccessMode. More...
 
typedef EnumPropertyI< TDeviceAutoNegotiatePacketSizeModePropertyIDeviceAutoNegotiatePacketSizeMode
 Defines a property for values defined by mvIMPACT::acquire::TDeviceAutoNegotiatePacketSizeMode. More...
 
typedef EnumPropertyI< TDeviceCapabilityPropertyIDeviceCapability
 Defines a property for values defined by mvIMPACT::acquire::TDeviceCapability. More...
 
typedef EnumPropertyI< TDeviceClassPropertyIDeviceClass
 Defines a property for values defined by mvIMPACT::acquire::TDeviceClass. More...
 
typedef EnumPropertyI< TDeviceInterfaceLayoutPropertyIDeviceInterfaceLayout
 Defines a property for values defined by mvIMPACT::acquire::TDeviceInterfaceLayout. More...
 
typedef EnumPropertyI< TDeviceLoadSettingsPropertyIDeviceLoadSettings
 Defines a property for values defined by mvIMPACT::acquire::TDeviceLoadSettings. More...
 
typedef EnumPropertyI< TDeviceStatePropertyIDeviceState
 Defines a property for values defined by mvIMPACT::acquire::TDeviceState. More...
 
typedef EnumPropertyI< TFlatFieldFilterCorrectionModePropertyIFlatFieldFilterCorrectionMode
 Defines a property for values defined by mvIMPACT::acquire::TFlatFieldFilterCorrectionMode. More...
 
typedef EnumPropertyI< TFlatFieldFilterModePropertyIFlatFieldFilterMode
 Defines a property for values defined by mvIMPACT::acquire::TFlatFieldFilterMode. More...
 
typedef EnumPropertyI< THWUpdateResultPropertyIHWUpdateResult
 Defines a property for values defined by mvIMPACT::acquire::THWUpdateResult. More...
 
typedef EnumPropertyI< TImageBufferFormatReinterpreterModePropertyIImageBufferFormatReinterpreterMode
 Defines a property for values defined by mvIMPACT::acquire::TImageBufferFormatReinterpreterMode. More...
 
typedef EnumPropertyI< TImageBufferPixelFormatPropertyIImageBufferPixelFormat
 Defines a property for values defined by mvIMPACT::acquire::TImageBufferPixelFormat. More...
 
typedef EnumPropertyI< TImageDestinationPixelFormatPropertyIImageDestinationPixelFormat
 Defines a property for values defined by mvIMPACT::acquire::TImageDestinationPixelFormat. More...
 
typedef EnumPropertyI< TImageProcessingFilterPropertyIImageProcessingFilter
 Defines a property for values defined by mvIMPACT::acquire::TImageProcessingFilter. More...
 
typedef EnumPropertyI< TImageProcessingModePropertyIImageProcessingMode
 Defines a property for values defined by mvIMPACT::acquire::TImageProcessingMode. More...
 
typedef EnumPropertyI< TImageProcessingOptimizationPropertyIImageProcessingOptimization
 Defines a property for values defined by mvIMPACT::acquire::TImageProcessingOptimization. More...
 
typedef EnumPropertyI< TImageProcessingResultPropertyIImageProcessingResult
 Defines a property for values defined by mvIMPACT::acquire::TImageProcessingResult. More...
 
typedef EnumPropertyI< TImageRequestControlModePropertyIImageRequestControlMode
 Defines a property for values defined by mvIMPACT::acquire::TImageRequestControlMode. More...
 
typedef EnumPropertyI< TInterfaceEnumerationBehaviourPropertyIInterfaceEnumerationBehaviour
 Defines a property for values defined by mvIMPACT::acquire::TInterfaceEnumerationBehaviour. More...
 
typedef EnumPropertyI< TLUTGammaModePropertyILUTGammaMode
 Defines a property for values defined by mvIMPACT::acquire::TLUTGammaMode. More...
 
typedef EnumPropertyI< TLUTImplementationPropertyILUTImplementation
 Defines a property for values defined by mvIMPACT::acquire::TLUTImplementation. More...
 
typedef EnumPropertyI< TLUTInterpolationModePropertyILUTInterpolationMode
 Defines a property for values defined by mvIMPACT::acquire::TLUTInterpolationMode. More...
 
typedef EnumPropertyI< TLUTMappingPropertyILUTMapping
 Defines a property for values defined by mvIMPACT::acquire::TLUTMapping. More...
 
typedef EnumPropertyI< TLUTModePropertyILUTMode
 Defines a property for values defined by mvIMPACT::acquire::TLUTMode. More...
 
typedef EnumPropertyI< TMirrorModePropertyIMirrorMode
 Defines a property for values defined by mvIMPACT::acquire::TMirrorMode. More...
 
typedef EnumPropertyI< TMirrorOperationModePropertyIMirrorOperationMode
 Defines a property for values defined by mvIMPACT::acquire::TMirrorOperationMode. More...
 
typedef EnumPropertyI< TPolarizedDataExtractionInterpolationModePropertyIPolarizedDataExtractionInterpolationMode
 Defines a property for values defined by mvIMPACT::acquire::TPolarizedDataExtractionInterpolationMode. More...
 
typedef EnumPropertyI< TPolarizedDataExtractionModePropertyIPolarizedDataExtractionMode
 Defines a property for values defined by mvIMPACT::acquire::TPolarizedDataExtractionMode. More...
 
typedef EnumPropertyI< TRequestImageMemoryModePropertyIRequestImageMemoryMode
 Defines a property for values defined by mvIMPACT::acquire::TRequestImageMemoryMode. More...
 
typedef EnumPropertyI< TRequestResultPropertyIRequestResult
 Defines a property for values defined by mvIMPACT::acquire::TRequestResult. More...
 
typedef EnumPropertyI< TRequestStatePropertyIRequestState
 Defines a property for values defined by mvIMPACT::acquire::TRequestState. More...
 
typedef EnumPropertyI< TScalerInterpolationModePropertyIScalerInterpolationMode
 Defines a property for values defined by mvIMPACT::acquire::TScalerInterpolationMode. More...
 
typedef EnumPropertyI< TScalerModePropertyIScalerMode
 Defines a property for values defined by mvIMPACT::acquire::TScalerMode. More...
 
typedef EnumPropertyI< TUserDataAccessRightPropertyIUserDataAccessRight
 Defines a property for values defined by mvIMPACT::acquire::TUserDataAccessRight. More...
 
typedef EnumPropertyI< TUserDataReconnectBehaviourPropertyIUserDataReconnectBehaviour
 Defines a property for values defined by mvIMPACT::acquire::TUserDataReconnectBehaviour. More...
 
typedef EnumPropertyI< TWhiteBalanceCalibrationModePropertyIWhiteBalanceCalibrationMode
 Defines a property for values defined by mvIMPACT::acquire::TWhiteBalanceCalibrationMode. More...
 
typedef EnumPropertyI< TWhiteBalanceParameterPropertyIWhiteBalanceParameter
 Defines a property for values defined by mvIMPACT::acquire::TWhiteBalanceParameter. More...
 
typedef Statistics StatisticsBase
 deprecated. Use the class mvIMPACT::acquire::Statistics instead More...
 
typedef SystemSettings SystemBase
 deprecated. Use the class mvIMPACT::acquire::SystemSettings instead More...
 

Enumerations

enum  TAcquisitionMode {
  amContinuous = 1 ,
  amMultiFrame = 2 ,
  amSingleFrame = 3
}
 Defines valid acquisition modes. More...
 
enum  TAcquisitionStartStopBehaviour {
  assbDefault ,
  assbUser
}
 Defines valid modes for acquisition start/stop behaviour. More...
 
enum  TAoiMode {
  amCentered = 0 ,
  amFull ,
  amUseAoi
}
 Defines valid Area Of Interest modes. More...
 
enum  TBayerConversionMode {
  bcmLinearInterpolation ,
  bcmAdaptiveEdgeSensing ,
  bcmAuto ,
  bcmPacked ,
  bcmLinearPacked ,
  bcmAdaptiveEdgeSensingPlus ,
  bcmAdaptiveHomogeneityDirected
}
 Defines the Bayer conversion algorithm to use. More...
 
enum  TBayerMosaicParity {
  bmpUndefined = -1 ,
  bmpGR ,
  bmpRG ,
  bmpBG ,
  bmpGB
}
 Defines valid Bayer formats. More...
 
enum  TBayerWhiteBalanceResult {
  bwbrUnknown = 0 ,
  bwbrOK = 1 ,
  bwbrErrorUnknown = 2 ,
  bwbrErrorTooDark = 3 ,
  bwbrErrorTooBright = 4
}
 Defines valid results of a white balance calibration. More...
 
enum  TBoolean {
  bFalse = 0 ,
  bTrue = 1
}
 Defines a Boolean value type. More...
 
enum  TBufferPartDataType {
  bpdtUnknown = 0 ,
  bpdt2DImage = 1 ,
  bpdt2DPlaneBiplanar = 2 ,
  bpdt2DPlaneTriplanar = 3 ,
  bpdt2DPlaneQuadplanar = 4 ,
  bpdt3DImage = 5 ,
  bpdt3DPlaneBiplanar = 6 ,
  bpdt3DPlaneTriplanar = 7 ,
  bpdt3DPlaneQuadplanar = 8 ,
  bpdtConfidenceMap = 9 ,
  bpdtJPEG = 1000 ,
  bpdtJPEG2000
}
 Defines buffer part data types. More...
 
enum  TCallbackType {
  ctOnChanged = 0 ,
  ctOnReadData = 1 ,
  ctOnWriteData = 2 ,
  ctOnRefreshCache = 3
}
 Defines the type of callback to register. More...
 
enum  TCameraDataFormat {
  cdfUnknown = 0 ,
  cdfMono ,
  cdfBayer ,
  cdfBayerPacked ,
  cdfRGB ,
  cdfYUV
}
 Defines the data format the camera is sending. More...
 
enum  TCameraOutput {
  coUndefined = -1 ,
  coAuto = 0 ,
  coComposite = 1 ,
  coBase = 2 ,
  coDigital = 3 ,
  coSVideo = 4 ,
  coMedium = 5 ,
  coRGB = 6 ,
  co2xComposite = 7 ,
  co3xComposite = 8 ,
  co4xComposite = 9 ,
  coFull = 10 ,
  coSDSDI = 11 ,
  coHDSDI = 12 ,
  co3GSDI = 13
}
 Defines valid ways a camera can offer image data to a capture device. More...
 
enum  TChannelSplitMode {
  csmVertical ,
  csmHorizontal ,
  csmExtractSingle
}
 Defines valid modes for channel split filters. More...
 
enum  TColorProcessingMode {
  cpmAuto = 0 ,
  cpmRaw ,
  cpmBayer ,
  cpmBayerToMono ,
  cpmRawToPlanes
}
 Defines the color processing mode. More...
 
enum  TColorTwistInputCorrectionMatrixMode {
  cticmmUser = 0x00010000 | 0x1000 ,
  cticmmDeviceSpecific = 0x00010000 | 0x2000
}
 Defines valid values for input color correction matrices. More...
 
enum  TColorTwistOutputCorrectionMatrixMode {
  ctocmmUser ,
  ctocmmXYZToAdobeRGB_D50 ,
  ctocmmXYZTosRGB_D50 ,
  ctocmmXYZToWideGamutRGB_D50 ,
  ctocmmXYZToAdobeRGB_D65 ,
  ctocmmXYZTosRGB_D65
}
 Defines valid values for output color correction matrices. More...
 
enum  TComponentFlag {
  cfUndefined = 0x0 ,
  cfReadAccess = 0x1 ,
  cfWriteAccess = 0x2 ,
  cfRWAccess = cfReadAccess | cfWriteAccess ,
  cfFixedSize = 0x4 ,
  cfInvisible = 0x10 ,
  cfAllowValueCombinations = 0x20 ,
  cfShouldBeDisplayedAsList = 0x40 ,
  cfDisallowSerialize = 0x80 ,
  cfAlwaysForceClone = 0x100 ,
  cfNotAvailable = 0x200 ,
  cfNotImplemented = 0x400 ,
  cfContainsBinaryData = 0x800 ,
  cfShouldBeDisplayedAsEnumeration = 0x1000 ,
  cfAlwaysForceUpdate = 0x2000
}
 Flags defining access rights and other component properties. More...
 
enum  TComponentRepresentation {
  crUndefined = 0 ,
  crLinear ,
  crLogarithmic ,
  crBoolean ,
  crPureNumber ,
  crHexNumber ,
  crIPv4Address ,
  crMACAddress ,
  crFileName ,
  crDirectoryName
}
 Defines valid recommended representations for features. More...
 
enum  TComponentType {
  ctProp = 0x00010000 ,
  ctList = 0x00020000 ,
  ctMeth = 0x00040000 ,
  ctPropInt = ctProp | vtInt ,
  ctPropFloat = ctProp | vtFloat ,
  ctPropString = ctProp | vtString ,
  ctPropPtr = ctProp | vtPtr ,
  ctPropInt64 = ctProp | vtInt64
}
 Allowed components handled by this module. More...
 
enum  TComponentVisibility {
  cvBeginner = 0 ,
  cvExpert = 1 ,
  cvGuru = 2 ,
  cvInvisible = 3
}
 Defines valid recommended visibilities for features. More...
 
enum  TDarkCurrentFilterMode {
  dcfmOff = 0 ,
  dcfmOn ,
  dcfmCalibrateDarkCurrent ,
  dcfmTransmitCorrectionImage
}
 Defines valid modes for the dark current filter. More...
 
enum  TDefectivePixelsFilterMode {
  dpfmOff = 0 ,
  dpfm3x1Average ,
  dpfm3x3Median ,
  dpfmResetCalibration ,
  dpfmCalibrateLeakyPixel ,
  dpfmCalibrateColdPixel ,
  dpfmCalibrateHotPixel ,
  dpfmCalibrateHotAndColdPixel ,
  dpfmReplaceDefectivePixelAfter3x3Filter
}
 Defines valid modes for defective pixels filter. More...
 
enum  TDeviceAccessMode {
  damUnknown ,
  damNone ,
  damRead ,
  damControl ,
  damExclusive
}
 Defines valid device access modes. More...
 
enum  TDeviceAutoNegotiatePacketSizeMode {
  danpsmHighToLow ,
  danpsmLowToHigh
}
 Defines the way the packet size auto negotiation is handled for GigE Vision devices. More...
 
enum  TDeviceCapability {
  dcNone = 0x0 ,
  dcHotplugable = 0x1 ,
  dcSelectableVideoInputs = 0x2 ,
  dcNonVolatileUserMemory = 0x4 ,
  dcCameraDescriptionSupport = 0x8 ,
  dcEventSupport = 0x10
}
 Defines valid device capabilities. More...
 
enum  TDeviceClass {
  dcGeneric ,
  dcCamera ,
  dcIntelligentCamera ,
  dcFrameGrabber ,
  dc3DCamera
}
 Defines valid generic device classes. More...
 
enum  TDeviceEventMode {
  demIgnore ,
  demNotify
}
 Defines valid event states. More...
 
enum  TDeviceEventType {
  detNone = 0 ,
  detPnPArrival = 0x1 ,
  detPnPRemoval = 0x2 ,
  detFrameStart = 0x4 ,
  detHistogramReady = 0x8 ,
  detAll = detPnPArrival | detPnPRemoval | detFrameStart | detHistogramReady
}
 Defines valid device event types. More...
 
enum  TDeviceInterfaceLayout {
  dilDeviceSpecific = 1 ,
  dilGenICam = 2
}
 Defines valid interface layouts for the device. More...
 
enum  TDeviceListType {
  dltUndefined = dmltUndefined ,
  dltSetting = dmltSetting ,
  dltRequest = dmltRequest ,
  dltRequestCtrl = dmltRequestCtrl ,
  dltInfo = dmltInfo ,
  dltStatistics = dmltStatistics ,
  dltSystemSettings = dmltSystemSettings ,
  dltIOSubSystem = dmltIOSubSystem ,
  dltRTCtr = dmltRTCtr ,
  dltCameraDescriptions = dmltCameraDescriptions ,
  dltDeviceSpecificData = dmltDeviceSpecificData ,
  dltEventSubSystemSettings = dmltEventSubSystemSettings ,
  dltEventSubSystemResults = dmltEventSubSystemResults ,
  dltImageMemoryManager = dmltImageMemoryManager ,
  dltLast = dltPseudoLast - 1
}
 Defines valid interface list types, which can be located using an instance of mvIMPACT::acquire::DeviceComponentLocator. More...
 
enum  TDeviceLoadSettings {
  dlsAuto = 0 ,
  dlsNoLoad
}
 Defines valid modes for the loading of settings during initialization. More...
 
enum  TDeviceState {
  dsAbsent = 0 ,
  dsPresent ,
  dsInitializing ,
  dsUnreachable ,
  dsPowerDown
}
 Defines valid Device states. More...
 
enum  TDMR_ERROR {
  DMR_NO_ERROR = 0 ,
  DMR_DEV_NOT_FOUND = -2100 ,
  DMR_INIT_FAILED = -2101 ,
  DMR_DRV_ALREADY_IN_USE = -2102 ,
  DMR_DEV_CANNOT_OPEN = -2103 ,
  DMR_NOT_INITIALIZED = -2104 ,
  DMR_DRV_CANNOT_OPEN = -2105 ,
  DMR_DEV_REQUEST_QUEUE_EMPTY = -2106 ,
  DMR_DEV_REQUEST_CREATION_FAILED = -2107 ,
  DMR_INVALID_PARAMETER = -2108 ,
  DMR_EXPORTED_SYMBOL_NOT_FOUND = -2109 ,
  DEV_UNKNOWN_ERROR = -2110 ,
  DEV_HANDLE_INVALID = -2111 ,
  DEV_INPUT_PARAM_INVALID = -2112 ,
  DEV_WRONG_INPUT_PARAM_COUNT = -2113 ,
  DEV_CREATE_SETTING_FAILED = -2114 ,
  DEV_REQUEST_CANT_BE_UNLOCKED = -2115 ,
  DEV_INVALID_REQUEST_NUMBER = -2116 ,
  DEV_LOCKED_REQUEST_IN_QUEUE = -2117 ,
  DEV_NO_FREE_REQUEST_AVAILABLE = -2118 ,
  DEV_WAIT_FOR_REQUEST_FAILED = -2119 ,
  DEV_UNSUPPORTED_PARAMETER = -2120 ,
  DEV_INVALID_RTC_NUMBER = -2121 ,
  DMR_INTERNAL_ERROR = -2122 ,
  DMR_INPUT_BUFFER_TOO_SMALL = -2123 ,
  DEV_INTERNAL_ERROR = -2124 ,
  DMR_LIBRARY_NOT_FOUND = -2125 ,
  DMR_FUNCTION_NOT_IMPLEMENTED = -2126 ,
  DMR_FEATURE_NOT_AVAILABLE = -2127 ,
  DMR_EXECUTION_PROHIBITED = -2128 ,
  DMR_FILE_NOT_FOUND = -2129 ,
  DMR_INVALID_LICENCE = -2130 ,
  DEV_SENSOR_TYPE_ERROR = -2131 ,
  DMR_CAMERA_DESCRIPTION_INVALID = -2132 ,
  DMR_NEWER_LIBRARY_REQUIRED = -2133 ,
  DMR_TIMEOUT = -2134 ,
  DMR_WAIT_ABANDONED = -2135 ,
  DMR_EXECUTION_FAILED = -2136 ,
  DEV_REQUEST_ALREADY_IN_USE = -2137 ,
  DEV_REQUEST_BUFFER_INVALID = -2138 ,
  DEV_REQUEST_BUFFER_MISALIGNED = -2139 ,
  DEV_ACCESS_DENIED = -2140 ,
  DMR_PRELOAD_CHECK_FAILED = -2141 ,
  DMR_CAMERA_DESCRIPTION_INVALID_PARAMETER = -2142 ,
  DMR_FILE_ACCESS_ERROR = -2143 ,
  DMR_INVALID_QUEUE_SELECTION = -2144 ,
  DMR_ACQUISITION_ENGINE_BUSY = -2145 ,
  DMR_BUSY = -2146 ,
  DMR_OUT_OF_MEMORY = -2147 ,
  DMR_LAST_VALID_ERROR_CODE = -2199
}
 Errors reported by the device manager. More...
 
enum  TFlatFieldFilterCorrectionMode {
  ffcmDefault = 0 ,
  ffcmBrightPreserving
}
 Defines valid modes for the flat field correction. More...
 
enum  TFlatFieldFilterMode {
  fffmOff = 0 ,
  fffmOn ,
  fffmCalibrateFlatField ,
  fffmTransmitCorrectionImage
}
 Defines valid modes for the flat field filter. More...
 
enum  THWUpdateResult {
  urNoUpdatePerformed = 0 ,
  urUpdateFW ,
  urUpdateFWError ,
  urDevAlreadyInUse ,
  urUpdateFWOK ,
  urSetDevID ,
  urSetDevIDError ,
  urSetDevIDInvalidID ,
  urSetDevIDOK ,
  urSetUserDataSizeError ,
  urSetUserDataWriteError ,
  urSetUserDataWriteOK ,
  urGetUserDataReadError ,
  urVerifyFWError ,
  urVerifyFWOK
}
 Defines valid Device HW update results. More...
 
enum  TImageBufferFormatReinterpreterMode {
  ibfrmMono8_To_Mono8 = ibpfMono8 << 16 | ibpfMono8 ,
  ibfrmMono8_To_RGB888Packed = ibpfMono8 << 16 | ibpfRGB888Packed ,
  ibfrmMono8_To_BGR888Packed = ibpfMono8 << 16 | ibpfBGR888Packed ,
  ibfrmMono10_To_Mono10 = ibpfMono10 << 16 | ibpfMono10 ,
  ibfrmMono10_To_RGB101010Packed = ibpfMono10 << 16 | ibpfRGB101010Packed ,
  ibfrmMono12_To_Mono12 = ibpfMono12 << 16 | ibpfMono12 ,
  ibfrmMono12_To_RGB121212Packed = ibpfMono12 << 16 | ibpfRGB121212Packed ,
  ibfrmMono14_To_Mono14 = ibpfMono14 << 16 | ibpfMono14 ,
  ibfrmMono14_To_RGB141414Packed = ibpfMono14 << 16 | ibpfRGB141414Packed ,
  ibfrmMono16_To_Mono16 = ibpfMono16 << 16 | ibpfMono16 ,
  ibfrmMono16_To_RGB161616Packed = ibpfMono16 << 16 | ibpfRGB161616Packed
}
 Valid image buffer format reinterpreter modes. More...
 
enum  TImageBufferPixelFormat {
  ibpfRaw = 0 ,
  ibpfMono8 = 1 ,
  ibpfMono16 = 2 ,
  ibpfRGBx888Packed = 3 ,
  ibpfYUV422Packed = 4 ,
  ibpfRGBx888Planar = 5 ,
  ibpfMono10 = 6 ,
  ibpfMono12 = 7 ,
  ibpfMono14 = 8 ,
  ibpfRGB888Packed = 9 ,
  ibpfYUV444Planar = 10 ,
  ibpfMono32 = 11 ,
  ibpfYUV422Planar = 12 ,
  ibpfRGB101010Packed = 13 ,
  ibpfRGB121212Packed = 14 ,
  ibpfRGB141414Packed = 15 ,
  ibpfRGB161616Packed = 16 ,
  ibpfYUV422_UYVYPacked = 17 ,
  ibpfMono12Packed_V2 = 18 ,
  ibpfYUV422_10Packed = 20 ,
  ibpfYUV422_UYVY_10Packed = 21 ,
  ibpfBGR888Packed = 22 ,
  ibpfBGR101010Packed_V2 = 23 ,
  ibpfYUV444_UYVPacked = 24 ,
  ibpfYUV444_UYV_10Packed = 25 ,
  ibpfYUV444Packed = 26 ,
  ibpfYUV444_10Packed = 27 ,
  ibpfMono12Packed_V1 = 28 ,
  ibpfYUV411_UYYVYY_Packed = 29 ,
  ibpfRGB888Planar = 30 ,
  ibpfAuto = -1
}
 Valid image buffer pixel formats. More...
 
enum  TImageDestinationPixelFormat {
  idpfAuto = 0 ,
  idpfRaw = 1 ,
  idpfMono8 = 2 ,
  idpfRGBx888Packed = 3 ,
  idpfYUV422Packed = 4 ,
  idpfRGBx888Planar = 5 ,
  idpfMono10 = 6 ,
  idpfMono12 = 7 ,
  idpfMono14 = 8 ,
  idpfMono16 = 9 ,
  idpfRGB888Packed = 10 ,
  idpfYUV422Planar = 13 ,
  idpfRGB101010Packed = 14 ,
  idpfRGB121212Packed = 15 ,
  idpfRGB141414Packed = 16 ,
  idpfRGB161616Packed = 17 ,
  idpfYUV422_UYVYPacked = 18 ,
  idpfMono12Packed_V2 = 19 ,
  idpfYUV422_10Packed = 20 ,
  idpfYUV422_UYVY_10Packed = 21 ,
  idpfBGR888Packed = 22 ,
  idpfBGR101010Packed_V2 = 23 ,
  idpfYUV444_UYVPacked = 24 ,
  idpfYUV444_UYV_10Packed = 25 ,
  idpfYUV444Packed = 26 ,
  idpfYUV444_10Packed = 27 ,
  idpfMono12Packed_V1 = 28 ,
  idpfYUV411_UYYVYY_Packed = 29 ,
  idpfRGB888Planar = 30
}
 Defines the pixel format of the result image. More...
 
enum  TImageFileFormat {
  iffAuto = -1 ,
  iffBMP = 1 ,
  iffJPEG = 2 ,
  iffPNG = 13 ,
  iffTIFF = 18
}
 Defines valid image file formats. More...
 
enum  TImageProcessingFilter {
  ipfOff = 0 ,
  ipfSharpen
}
 Defines valid filters which can be applied to the captured image before it is transferred to the user. More...
 
enum  TImageProcessingMode {
  ipmDefault = 0 ,
  ipmProcessLatestOnly = 1
}
 Defines valid modes the internal image processing pipeline can be operated in. More...
 
enum  TImageProcessingOptimization {
  ipoMaximizeSpeed = 0 ,
  ipoMinimizeMemoryUsage = 1
}
 Defines valid modes the internal image processing algorithms can be operated in. More...
 
enum  TImageProcessingResult {
  iprNotActive = 0 ,
  iprApplied ,
  iprFailure ,
  iprSkipped ,
  iprNotApplicable
}
 Defines valid values for the result of a certain image processing algorithm applied to a request. More...
 
enum  TImageRequestControlMode {
  ircmManual ,
  ircmLive ,
  ircmCounting ,
  ircmTrial ,
  ircmUpdateBufferLayout
}
 Defines the behaviour of an mvIMPACT::acquire::ImageRequestControl. More...
 
enum  TImageRequestParam {
  irpPixelFormat = 0 ,
  irpResult = 1 ,
  irpState = 2 ,
  irpCameraOutputUsed = 3
}
 Defines valid image request parameters. More...
 
enum  TImpactBufferFlag {
  ibfNone = 0x0 ,
  ibfUseRequestMemory = 0x1 ,
  ibfRecycleBufHandle = 0x2
}
 Flags to define the way an mvIMPACT buffer is created and handled. More...
 
enum  TInterfaceEnumerationBehaviour {
  iebNotConfigured = 0 ,
  iebForceIgnore = 1 ,
  iebForceEnumerate = 2
}
 Defines the enumeration behaviour of a certain interface of a third party GenTL producer. More...
 
enum  TLibraryQuery {
  lqDeviceManager = 0 ,
  lqPropHandling = 1
}
 Defines valid libraries to query information from. More...
 
enum  TLUTGammaMode {
  LUTgmStandard ,
  LUTgmLinearStart
}
 Defines valid LUT(LookUp Table) gamma modes. More...
 
enum  TLUTImplementation {
  LUTiHardware ,
  LUTiSoftware
}
 Defines valid LUT(LookUp Table) implementations. More...
 
enum  TLUTInterpolationMode {
  LUTimThreshold ,
  LUTimLinear ,
  LUTimCubic
}
 Defines valid LUT(LookUp Table) interpolation modes. More...
 
enum  TLUTMapping {
  LUTm8To8 = ( 8 << 16 ) | 8 ,
  LUTm10To8 = ( 10 << 16 ) | 8 ,
  LUTm10To10 = ( 10 << 16 ) | 10 ,
  LUTm12To10 = ( 12 << 16 ) | 10 ,
  LUTm12To12 = ( 12 << 16 ) | 12 ,
  LUTm14To14 = ( 14 << 16 ) | 14 ,
  LUTm16To16 = ( 16 << 16 ) | 16
}
 Defines valid LUT(LookUp Table) mapping modes. More...
 
enum  TLUTMode {
  LUTmInterpolated ,
  LUTmGamma ,
  LUTmDirect
}
 Defines valid LUT(LookUp Table) modes. More...
 
enum  TMemoryManagerMode {
  mmmAuto = 0 ,
  mmmPool = 1
}
 Defines valid modes to operate the memory manager in. More...
 
enum  TMemoryManagerPoolMode {
  mmpmOff = 0 ,
  mmpmFixed = 1 ,
  mmpmAuto = 2
}
 Defines the pool mode of memory manager. More...
 
enum  TMirrorMode {
  mmOff = 0 ,
  mmTopDown = 0x1 ,
  mmLeftRight = 0x2 ,
  mmTopDownAndLeftRight = mmTopDown | mmLeftRight
}
 Defines valid mirror modes. More...
 
enum  TMirrorOperationMode {
  momGlobal ,
  momChannelBased
}
 Defines valid mirror operation modes. More...
 
enum  TPolarizedDataExtractionInterpolationMode {
  primOff ,
  primLinear
}
 Defines valid modes for the interpolation mode of polarization data extraction filters. More...
 
enum  TPolarizedDataExtractionMode {
  prmVertical ,
  prmHorizontal ,
  prmExtractSingle ,
  prmMinimumValue ,
  prmMeanValue ,
  prm2By2 ,
  prmExtractAngle ,
  prmExtractDegree ,
  prmPseudoColorRepresentation
}
 Defines valid modes for polarization data extraction filters. More...
 
enum  TPropertyLimits {
  plMaxValue = PROP_MAX_VAL ,
  plMinValue = PROP_MIN_VAL ,
  plStepWidth = PROP_STEP_WIDTH
}
 Defines valid limits which can be queried for a mvIMPACT::acquire::Property object. More...
 
enum  TPROPHANDLING_ERROR {
  PROPHANDLING_NO_ERROR = 0 ,
  PROPHANDLING_NOT_A_LIST = -2000 ,
  PROPHANDLING_NOT_A_PROPERTY = -2001 ,
  PROPHANDLING_NOT_A_METHOD = -2002 ,
  PROPHANDLING_NO_READ_RIGHTS = -2003 ,
  PROPHANDLING_NO_WRITE_RIGHTS = -2004 ,
  PROPHANDLING_NO_MODIFY_SIZE_RIGHTS = -2005 ,
  PROPHANDLING_INCOMPATIBLE_COMPONENTS = -2006 ,
  PROPHANDLING_UNSUPPORTED_PARAMETER = -2008 ,
  PROPHANDLING_SIZE_MISMATCH = -2009 ,
  PROPHANDLING_IMPLEMENTATION_MISSING = -2010 ,
  PROPHANDLING_ACCESSTOKEN_CREATION_FAILED = -2011 ,
  PROPHANDLING_INVALID_PROP_VALUE = -2012 ,
  PROPHANDLING_PROP_TRANSLATION_TABLE_CORRUPTED = -2013 ,
  PROPHANDLING_PROP_VAL_ID_OUT_OF_BOUNDS = -2014 ,
  PROPHANDLING_PROP_TRANSLATION_TABLE_NOT_DEFINED = -2015 ,
  PROPHANDLING_INVALID_PROP_VALUE_TYPE = -2016 ,
  PROPHANDLING_PROP_VAL_TOO_LARGE = -2017 ,
  PROPHANDLING_PROP_VAL_TOO_SMALL = -2018 ,
  PROPHANDLING_COMPONENT_NOT_FOUND = -2019 ,
  PROPHANDLING_LIST_ID_INVALID = -2020 ,
  PROPHANDLING_COMPONENT_ID_INVALID = -2021 ,
  PROPHANDLING_LIST_ENTRY_OCCUPIED = -2022 ,
  PROPHANDLING_COMPONENT_HAS_OWNER_ALREADY = -2023 ,
  PROPHANDLING_COMPONENT_ALREADY_REGISTERED = -2024 ,
  PROPHANDLING_LIST_CANT_ACCESS_DATA = -2025 ,
  PROPHANDLING_METHOD_PTR_INVALID = -2026 ,
  PROPHANDLING_METHOD_INVALID_PARAM_LIST = -2027 ,
  PROPHANDLING_SWIG_ERROR = -2028 ,
  PROPHANDLING_INVALID_INPUT_PARAMETER = -2029 ,
  PROPHANDLING_COMPONENT_NO_CALLBACK_REGISTERED = -2030 ,
  PROPHANDLING_INPUT_BUFFER_TOO_SMALL = -2031 ,
  PROPHANDLING_WRONG_PARAM_COUNT = -2032 ,
  PROPHANDLING_UNSUPPORTED_OPERATION = -2033 ,
  PROPHANDLING_CANT_SERIALIZE_DATA = -2034 ,
  PROPHANDLING_INVALID_FILE_CONTENT = -2035 ,
  PROPHANDLING_CANT_ALLOCATE_LIST = -2036 ,
  PROPHANDLING_CANT_REGISTER_COMPONENT = -2037 ,
  PROPHANDLING_PROP_VALIDATION_FAILED = -2038 ,
  PROPHANDLING_LAST_VALID_ERROR_CODE = -2099
}
 Error codes of the module handling everything related to properties. More...
 
enum  TRequestImageMemoryMode {
  rimmAuto ,
  rimmUser
}
 Defines valid image modes for request objects. More...
 
enum  TRequestResult {
  rrOK = 0 ,
  rrTimeout = 1 ,
  rrError = 2 ,
  rrRequestAborted = 3 ,
  rrFrameIncomplete = 4 ,
  rrDeviceAccessLost = 5 ,
  rrInconsistentBufferContent = 6 ,
  rrFrameCorrupt = 7 ,
  rrUnprocessibleRequest = 0x80000000 ,
  rrNoBufferAvailable = rrUnprocessibleRequest | 1 ,
  rrNotEnoughMemory = rrUnprocessibleRequest | 2 ,
  rrCameraNotSupported = rrUnprocessibleRequest | 5 ,
  rrDataAcquisitionNotSupported = rrUnprocessibleRequest | 7
}
 Defines valid result of an image request. More...
 
enum  TRequestState {
  rsIdle ,
  rsWaiting ,
  rsCapturing ,
  rsReady ,
  rsBeingConfigured
}
 Defines the current state of this mvIMPACT::acquire::Request. More...
 
enum  TScalerInterpolationMode {
  simNearestNeighbor ,
  simLinear ,
  simCubic
}
 Defines valid scaler interpolation modes. More...
 
enum  TScalerMode {
  smOff ,
  smOn
}
 Defines valid scaler modes. More...
 
enum  TScope {
  sGlobal = 0 ,
  sUser = 1
}
 Defines the scope for data import/export operations. More...
 
enum  TStorageFlag {
  sfDefault = 0x00000000 ,
  sfNative = 0x00000001 ,
  sfRaw = 0x00000002 ,
  sfVolatile = 0x00000004 ,
  sfProcessPropTranslationDict = 0x00000008 ,
  sfCreateMissingEntries = 0x00000010 ,
  sfProcessReadOnlyComponents = 0x00000020 ,
  sfIgnorePropData = 0x00000040 ,
  sfProcessDocString = 0x00000080 ,
  sfProcessPropConstantsDict = 0x00000100 ,
  sfProcessInheritance = 0x00000200 ,
  sfIgnoreBasicData = 0x00000400 ,
  sfIgnoreInvisible = 0x00000800 ,
  sfFile = 0x00001000 ,
  sfProcessDisplayName = 0x00002000 ,
  sfRAM = 0x4000 ,
  sfDontProcessDefault = 0x00020000 ,
  sfProcessGenICamSequencerData = 0x00040000 ,
  sfProcessGenICamUserSetData = 0x00080000
}
 Defines the way component lists are imported and exported. More...
 
enum  TStorageLocation {
  slNative = 0x1 ,
  slNative_Raw = 0x3 ,
  slFile = 0x1000 ,
  slRAM = 0x4000
}
 Defines valid storage locations for component list import, export and delete operations. More...
 
enum  TUserDataAccessRight {
  udarRead = 0x1 ,
  udarWrite = 0x2 ,
  udarRW = udarRead | udarWrite ,
  udarPassword = 0x4 ,
  udarFull = udarRW | udarPassword
}
 Defines valid flags for controlling the user access rights to the user data that can be stored in the devices non-volatile memory. More...
 
enum  TUserDataReconnectBehaviour {
  udrbKeepCachedData ,
  udrbUpdateFromDeviceData
}
 Defined valid values for the behaviour of the user data when a device has been disconnected and reconnected within a running process. More...
 
enum  TValueType {
  vtInt = 0x1 ,
  vtFloat ,
  vtPtr ,
  vtString ,
  vtInt64
}
 Allowed values types for property objects. More...
 
enum  TVideoCodec {
  vcMPEG2 = 2 ,
  vcH264 = 27 ,
  vcH265 = 173
}
 Defines valid video codecs that might be supported by the underlying video compression engine. More...
 
enum  TVideoStandard {
  vsCCIR ,
  vsRS170 ,
  vsPALBGH ,
  vsNTSCM ,
  vsSDI480i ,
  vsSDI576i ,
  vsSDI720p ,
  vsSDI1080i ,
  vsSDI1080p
}
 Defines valid video standards that might be supported by a video capture device. More...
 
enum  TWhiteBalanceCalibrationMode {
  wbcmOff = 0 ,
  wbcmNextFrame ,
  wbcmContinuous
}
 Defines valid white balance calibration modes. More...
 
enum  TWhiteBalanceParameter {
  wbpTungsten = 0 ,
  wbpHalogen ,
  wbpFluorescent ,
  wbpDayLight ,
  wbpPhotoFlash ,
  wbpBlueSky ,
  wbpUser1 ,
  wbpUser2 ,
  wbpUser3 ,
  wbpUser4
}
 Defines valid parameter sets selectable via the WhiteBalance property. More...
 

Variables

struct mvIMPACT::acquire::ChannelData ATTR_PACK
 

Detailed Description

Classes and functions that are available for all interface layouts.

This group contains classes and functions that are available for all interface layouts.


Class Documentation

◆ mvIMPACT::acquire::ChannelData

struct mvIMPACT::acquire::ChannelData

A structure for image buffer channel specific data.

Channel specific data in an image is data, that in e.g. and RGB image might differ for the color components red, green and blue.

Class Members
int iChannelOffset The offset (in bytes) to the next channel.
int iLinePitch The offset (in bytes) to the next line of this channel.
int iPixelPitch The offset (in bytes) to the next pixel of this channel.
char szChannelDesc[DEFAULT_STRING_SIZE_LIMIT] The string descriptor for this channel.

For an RGB image the string values of three mvIMPACT::acquire::ChannelData structures this might e.g. be "R", "G" and "B".

◆ mvIMPACT::acquire::EventData

struct mvIMPACT::acquire::EventData

A structure containing information about an event that has been reported by the device driver and has been successfully waited for.

Deprecated:
This structure has been declared deprecated. 'onChanged' callbacks can directly be registered on every feature now.
Class Members
unsigned int count A consecutive number telling the user how many times this event has occurred already.
unsigned int timestamp_highPart The higher part of the timestamp associated with this event.
Note
Not every device or event type will support this parameter. If the parameter is not supported, it will be 0.
unsigned int timestamp_lowPart The lower part of the timestamp associated with this event.

◆ mvIMPACT::acquire::ImageBuffer

struct mvIMPACT::acquire::ImageBuffer

Fully describes a captured image.

This class serves as a describing structure for captured images.

Class Members
int iBytesPerPixel The number of bytes per pixel.
int iChannelCount The number of channels this image consists of.

For an RGB image this value e.g. would be 3. This value defines how many mvIMPACT::acquire::ChannelData structures mvIMPACT::acquire::ImageBuffer::pChannels is pointing to once this structure has been allocated and filled with valid data.

int iHeight The height of the image in pixel or lines.
int iSize The size (in bytes) of the whole image.

This value in connection with mvIMPACT::acquire::ImageBuffer::vpData is sufficient to copy the complete image without having any additional information about it.

int iWidth The width of the image in pixel.
ChannelData * pChannels A pointer to an array of channel specific image data.
TImageBufferPixelFormat pixelFormat The pixel format of this image.

This might be important, when the image data needs to be processed or stored in a file or maybe even if the image shall be displayed.

void * vpData The starting address of the image.

This address in connection with mvIMPACT::acquire::ImageBuffer::iSize is sufficient to copy the complete image without having any additional information about it.

EXAMPLE:

const ImageBuffer* pib = getImageBufferFromSomewhere();
unsigned char* pTempBuf = new unsigned char[ib.iSize];
memcpy( pTempBuf, pib.vpData, pIB.iSize );
Note
It's not always necessary to copy the image data! Each mvIMPACT::acquire::ImageBuffer is an integral part of the mvIMPACT::acquire::Request object returned to the user by a call to the corresponding 'waitFor' function offered by the interface. The data in this mvIMPACT::acquire::ImageBuffer remains valid until the user either unlocks the request buffer or closes the mvIMPACT::acquire::Device again.
By unlocking the mvIMPACT::acquire::Request the user informs the driver, that this mvIMPACT::acquire::Request and the mvIMPACT::acquire::ImageBuffer belonging to that mvIMPACT::acquire::Request is not longer needed by the user. The driver then queues this mvIMPACT::acquire::Request for capturing image data into it once again. However once a mvIMPACT::acquire::Request has been returned to the user, its mvIMPACT::acquire::ImageBuffer can't be overwritten by the driver! Therefore the user can work with, modify, store or copy the data safely until he unlocks the mvIMPACT::acquire::Request again.

Macro Definition Documentation

◆ MVIMPACT_H_

#define MVIMPACT_H_

Typedef Documentation

◆ ComponentIterator

A class to iterate over component lists.

Deprecated:
These days this class is just a typedef mapping the class mvIMPACT::acquire::Component to this type for compatibility reasons. New applications should work with the mvIMPACT::acquire::Component class instead.

This object can be used to navigate through component lists of unknown content.

Consider the following structure:

LA
|-LB
|-LC
| |-PE
| |-PF
| |-PG
|-PD

Where the prefix 'L' means that this is a list, 'P' that this is a property. Assuming that we have and iterator referencing list 'C', calling mvIMPACT::acquire::ComponentIterator::firstChild e.g. would return a new iterator referencing object 'PE', while calling mvIMPACT::acquire::ComponentIterator::nextSibling would have returned a reference to 'PD' and mvIMPACT::acquire::ComponentIterator::parent would have returned a reference to object 'LA'.

"EXAMPLE 1":

A new mvIMPACT::acquire::ComponentIterator is created with the ID of list 'C':

ComponentIterator it(ID_of_list_C);
it = it.firstChild(); // now we are referencing 'PE'
it = it.lastSibling(); // moves to 'PG'
it = it.firstSibling(); // moves back to PE'
it = it.nextSibling(); // moves to 'PF'
it = it.firstSibling(); // moves back to PE'
it = it.parent(); // we are referencing 'LC' again
Component ComponentIterator
A class to iterate over component lists.
Definition: mvIMPACT_acquire.h:2572

"EXAMPLE 2":

Iterate over a complete list including sub lists. This will result in a list of all lists and properties that reside in the list the iterator currently is moving through to be written to the standard output. The name of the component and every parent component will be printed into the standard output:

//-----------------------------------------------------------------------------
void ParseList( ComponentIterator iter, const string& path = "" )
//-----------------------------------------------------------------------------
{
while( iter.isValid() )
{
if( iter.isVisible() )
{
if( iter.isList() )
{
// do some list specific stuff
cout << "List " << path << iter.name() << "/" << endl;
// move down into the list and append its name to the path
ParseList( iter.firstChild(), path + iter.name() + "/" );
}
else if( iter.isProp() )
{
// do property specific stuff e.g. read the value
Property prop(iter);
cout << "Property " << path << prop.name() << "(value(s): ";
unsigned int valCount = prop.valCount();
for( unsigned int i=0; i<valCount; i++ )
{
cout << prop.readS();
if( i < valCount - 1 )
{
cout << ", ";
}
}
cout << ")" << endl;
}
}
++iter;
}
}
//-----------------------------------------------------------------------------
int main( int argc, char* argv[] )
//-----------------------------------------------------------------------------
{
ComponentList baselist;
// ....
ComponentIterator it(baselist);
ParseList(it);
// ....
return 0;
}

◆ InfoBase

typedef Info InfoBase

deprecated. Use the class mvIMPACT::acquire::Info instead.

Deprecated:
This class has been declared deprecated and might not be available in future releases. All features of this class are available in mvIMPACT::acquire::Info as well, so please use this class instead.

◆ PropertyF

typedef EnumPropertyF<double> PropertyF

A type for floating point properties.

Provided for convenience only. This type represents a standard float property type.

◆ PropertyI

typedef EnumPropertyI<int> PropertyI

A type for integer properties.

Provided for convenience only. This type represents a standard integer property type.

◆ PropertyI64

typedef EnumPropertyI64<int64_type> PropertyI64

Provided for convenience only. This type represents a standard 64 bit integer property type.

Examples
ContinuousCaptureOnlyProcessLatest.cpp, and ContinuousCaptureOnlyProcessLatest.legacy.cpp.

◆ PropertyI64BufferPartDataType

Defines a property for values defined by mvIMPACT::acquire::TImageBufferPartType.

◆ PropertyI64DeviceTriggerOverlap

◆ PropertyIAcquisitionMode

◆ PropertyIAcquisitionStartStopBehaviour

◆ PropertyIAoiMode

Defines a property for values defined by mvIMPACT::acquire::TAoiMode.

◆ PropertyIBayerConversionMode

◆ PropertyIBayerMosaicParity

◆ PropertyIBayerWhiteBalanceResult

◆ PropertyIBoolean

Defines a property for values defined by mvIMPACT::acquire::TBoolean.

◆ PropertyICameraOutput

Defines a property for values defined by mvIMPACT::acquire::TCameraOutput.

◆ PropertyIChannelSplitMode

◆ PropertyIColorProcessingMode

◆ PropertyIColorTwistInputCorrectionMatrixMode

◆ PropertyIColorTwistOutputCorrectionMatrixMode

◆ PropertyIDarkCurrentFilterMode

◆ PropertyIDefectivePixelsFilterMode

◆ PropertyIDeviceAccessMode

◆ PropertyIDeviceAutoNegotiatePacketSizeMode

◆ PropertyIDeviceCapability

◆ PropertyIDeviceClass

Defines a property for values defined by mvIMPACT::acquire::TDeviceClass.

◆ PropertyIDeviceInterfaceLayout

◆ PropertyIDeviceLoadSettings

◆ PropertyIDeviceState

Defines a property for values defined by mvIMPACT::acquire::TDeviceState.

◆ PropertyIFlatFieldFilterCorrectionMode

◆ PropertyIFlatFieldFilterMode

◆ PropertyIHWUpdateResult

◆ PropertyIImageBufferFormatReinterpreterMode

◆ PropertyIImageBufferPixelFormat

◆ PropertyIImageDestinationPixelFormat

◆ PropertyIImageProcessingFilter

◆ PropertyIImageProcessingMode

◆ PropertyIImageProcessingOptimization

◆ PropertyIImageProcessingResult

◆ PropertyIImageRequestControlMode

◆ PropertyIInterfaceEnumerationBehaviour

◆ PropertyILUTGammaMode

Defines a property for values defined by mvIMPACT::acquire::TLUTGammaMode.

◆ PropertyILUTImplementation

◆ PropertyILUTInterpolationMode

◆ PropertyILUTMapping

Defines a property for values defined by mvIMPACT::acquire::TLUTMapping.

◆ PropertyILUTMode

Defines a property for values defined by mvIMPACT::acquire::TLUTMode.

◆ PropertyIMirrorMode

Defines a property for values defined by mvIMPACT::acquire::TMirrorMode.

◆ PropertyIMirrorOperationMode

◆ PropertyIPolarizedDataExtractionInterpolationMode

◆ PropertyIPolarizedDataExtractionMode

◆ PropertyIRequestImageMemoryMode

◆ PropertyIRequestResult

Defines a property for values defined by mvIMPACT::acquire::TRequestResult.

◆ PropertyIRequestState

Defines a property for values defined by mvIMPACT::acquire::TRequestState.

◆ PropertyIScalerInterpolationMode

◆ PropertyIScalerMode

Defines a property for values defined by mvIMPACT::acquire::TScalerMode.

◆ PropertyIUserDataAccessRight

◆ PropertyIUserDataReconnectBehaviour

◆ PropertyIWhiteBalanceCalibrationMode

◆ PropertyIWhiteBalanceParameter

◆ StatisticsBase

deprecated. Use the class mvIMPACT::acquire::Statistics instead

Deprecated:
This class has been declared deprecated and might not be available in future releases. All features of this class are available in mvIMPACT::acquire::Statistics as well, so please use this class instead.

◆ SystemBase

deprecated. Use the class mvIMPACT::acquire::SystemSettings instead

Deprecated:
This class has been declared deprecated and might not be available in future releases. All features of this class are available in mvIMPACT::acquire::SystemSettings as well, so please use this class instead.

Enumeration Type Documentation

◆ TAcquisitionMode

Defines valid acquisition modes.

Enumerator
amContinuous 

Continuous mode. This is the recommended mode when image data shall either be transferred constantly or when working with an externally triggered setup.

amMultiFrame 

In this mode AcquisitionFrameCount images will transferred by the device.

When AcquisitionFrameCount have been send by the device, it will automatically stop to send more data

amSingleFrame 

In this mode the device always will always just send a single image when a data stream is started.

This mode can be interesting, when the devices acquisition parameters change from image to image or when a lot of devices will be operated in the same system an bandwidth resources are limited.

◆ TAcquisitionStartStopBehaviour

Defines valid modes for acquisition start/stop behaviour.

Since
1.12.11
Enumerator
assbDefault 

The default behaviour for acquisition start and stop.

Most devices will only support this mode. When this mode is selected, the device driver will try to start and stop the transfer of data from the device automatically. Internally this will happen while image requests are being processed

assbUser 

The user can control the start and stop of the data transfer from the device.

In this mode, queuing of image request buffers and the actual streaming of data from the device is de-coupled. This can sometimes be favourable compared to the default behaviour e.g. when dealing with device drivers that do not accept new buffers while the acquisition engine is running. Also when working at very high frame rates, pre-queuing some buffer before starting the actual data transfer can help to avoid capture queue underruns and thus data loss.

◆ TAoiMode

enum TAoiMode

Defines valid Area Of Interest modes.

Enumerator
amCentered 

Use a small centered window for image processing.

In this mode, a device and processing function dependent window in the middle of the AOI captured from the device will be used for the processing function.

Since
2.37.0

Example:

  • Assume a device that can deliver 1280*960 pixels.

Now in the centered AOI mode a processing function will use a window smaller than the AOI in the middle of the image.

The starting point can be calculated by the formula:

offsetX = ( width - ( width / 2 ) ) / 2
offsetY = ( height - ( height / 2 ) ) / 2

The used AOI is just width / 2 * height / 2 thus takes up the center quarter of the selected AOI.

In case of an AOI defined by the user, the central AOI of the delivered image is used.

Deprecated:
Up to version 2.36.0 the AOI had just a size of 50*50 pixels. The behavior was the following:
  • Assume a device that can deliver 640*480 pixels.
  • The user selects to capture an rectangular AOI starting at 100/100 with a width of 200*200 Now in the centered AOI mode a processing function will use a window smaller than the AOI in the middle of the user defined AOI. This e.g. could be a rectangle starting at 150/150 with a width of 100*100.
amFull 

Use the complete image for image processing.

amUseAoi 

Use a user defined AOI window for image processing.

◆ TBayerConversionMode

Defines the Bayer conversion algorithm to use.

Enumerator
bcmLinearInterpolation 

Linear interpolation.

This mode is fast but especially sharp edges will appear slightly blurred in the resulting image.

bcmAdaptiveEdgeSensing 

Adaptive edge sensing.

This mode requires more CPU time than linear interpolation, but the resulting image more closely matches the original scene. Edges will be reconstructed with higher accuracy except for noisy images. For better results in noisy images mvIMPACT::acquire::bcmLinearInterpolation is the recommended mode.

bcmAuto 

Auto.

This mode automatically sets the Bayer conversion algorithm according to the format property of the camera description.

bcmPacked 

Packed.

In this mode the resulting image will have half the height of the source image. The following algorithm will be used for generating the resulting image:

1 2 3 4 ... n
1 R G R G ... R G
2 G B G B ... G B
| 1 | 2 | 3 | 4 | 5 |...| n |
1 |RGB|RGB|RGB|RGB|RGB|...|RGB|
R1(dest) = R11
G1(dest) = (G12 + G21) / 2
B1(dest) = B22
R2(dest) = (R11 + R13) / 2
G2(dest) = ((G12 + G21) / 2) + (G12 + G23)) / 2
B2(dest) = (B22 + B24) / 2
...
Rn(dest) = R1(n-1)
Gn(dest) = (G1(n) + G2(n-1)) / 2
Bn(dest) = B2(n)

This mode is mainly useful for line scan cameras as for area cameras this would modify the aspect ratio.

Since
2.5.9
bcmLinearPacked 

Linear Packed.

In this mode the resulting image will have half the height of the source image. The following algorithm will be used for generating the resulting image:

1 2 3 4 ... n
1 R G R G ... R G
2 G B G B ... G B
| 1 | 2 | 3 | 4 | 5 |...| n |
1 |RGB|RGB|RGB|RGB|RGB|...|RGB|
2 |RGB|RGB|RGB|RGB|RGB|...|RGB|
R1(dest) = R11
G1(dest) = G21
B1(dest) = B22
R2(dest) = (R11 + R13) / 2
G2(dest) = G12
B2(dest) = B22
R3(dest) = R13
G3(dest) = G23
B3(dest) = (B22 + B24) / 2
...
Rn(dest) = R1(n-1)
Gn(dest) = G1(n)
Bn(dest) = B2(n)

This mode is mainly useful for line scan cameras as for area cameras this would modify the aspect ratio.

Since
2.5.9
bcmAdaptiveEdgeSensingPlus 

Adaptive edge sensing plus.

This mode is even more demanding CPU-wise than adaptive edge sensing, but the resulting image is sharper and has fewer artifacts. The parameters of the sharpening filter can be set by the user, to fit specific needs.

Since
2.26.0
bcmAdaptiveHomogeneityDirected 

Adaptive edge sensing plus.

This mode is most demanding CPU-wise, but the resulting image will have the best possible quality. It is based on the following algorithm: K. Hirakawa, T.W. Parks, Adaptive Homogeneity-Directed Demosaicing Algorithm, IEEE Trans. Image Processing, March, 2005.

Since
2.27.0

◆ TBayerMosaicParity

Defines valid Bayer formats.

Enumerator
bmpUndefined 

It is not known whether the buffer or image contains raw Bayer data or the buffer or image does NOT contain raw Bayer data.

bmpGR 

The buffer or image starts with a green-red line starting with a green pixel.

bmpRG 

The buffer or image starts with a green-red line starting with a red pixel.

bmpBG 

The buffer or image starts with a green-blue line starting with a blue pixel.

bmpGB 

The buffer or image starts with a green-blue line starting with a green pixel.

◆ TBayerWhiteBalanceResult

Defines valid results of a white balance calibration.

Enumerator
bwbrUnknown 

No white balance calibration has been performed since start up.

bwbrOK 

The white balance calibration has been performed successfully for the selected setting.

bwbrErrorUnknown 

An unknown error occurred during the white balance calibration for the selected setting.

bwbrErrorTooDark 

The previous white balance calibration failed because the reference image used for the calibration was too dark.

bwbrErrorTooBright 

The previous white balance calibration failed because the reference image used for the calibration was too bright.

◆ TBoolean

enum TBoolean

Defines a Boolean value type.

Enumerator
bFalse 

Off, false or logical low.

bTrue 

On, true or logical high.

Examples
TimestampFeatures.cpp.

◆ TBufferPartDataType

Defines buffer part data types.

Since
2.20.0
Enumerator
bpdtUnknown 

The framework is not aware of the data type of the data in the provided buffer part.

From the application perspective this can be handled as raw data.

bpdt2DImage 

Color or monochrome (2D) image.

This part carries all the pixel data of given image (even if the image is represented by a single-plane pixel format).

bpdt2DPlaneBiplanar 

Single color plane of a planar (2D) image.

The data should be linked with the other color planes to get the complete image. The complete image consists of 2 planes. The planes of a given planar image must be placed as consecutive parts within the buffer.

bpdt2DPlaneTriplanar 

Single color plane of a planar (2D) image.

The data should be linked with the other color planes to get the complete image. The complete image consists of 3 planes. The planes of a given planar image must be placed as consecutive parts within the buffer.

bpdt2DPlaneQuadplanar 

Single color plane of a planar (2D) image.

The data should be linked with the other color planes to get the complete image. The complete image consists of 4 planes. The planes of a given planar image must be placed as consecutive parts within the buffer.

bpdt3DImage 

3D image (pixel coordinates).

This part carries all the pixel data of given image (even if the image is represented by a single-plane pixel format, for example when transferring the depth map only).

bpdt3DPlaneBiplanar 

Single color plane of a planar (3D) image.

The data should be linked with the other color planes to get the complete image. The complete image consists of 2 planes. The planes of a given planar image must be placed as consecutive parts within the buffer.

bpdt3DPlaneTriplanar 

Single color plane of a planar (3D) image.

The data should be linked with the other color planes to get the complete image. The complete image consists of 3 planes. The planes of a given planar image must be placed as consecutive parts within the buffer.

bpdt3DPlaneQuadplanar 

Single color plane of a planar (3D) image.

The data should be linked with the other color planes to get the complete image. The complete image consists of 4 planes. The planes of a given planar image must be placed as consecutive parts within the buffer.

bpdtConfidenceMap 

Confidence of the individual pixel values.

Expresses the level of validity of given pixel values. Confidence map is always used together with one or more additional image-based parts matching 1:1 dimension-wise. Each value in the confidence map expresses level of validity of the image pixel at matching position.

bpdtJPEG 

JPEG image data.

bpdtJPEG2000 

JPEG 2000 image data.

◆ TCallbackType

Defines the type of callback to register.

Enumerator
ctOnChanged 

Execute callback whenever this component has been modified.

ctOnReadData 

Executed when a property's value is read. The callback is executed before the value is returned to the user. This allows i.e. a driver to determine the value for this property only if the user is interested in its data.

ctOnWriteData 

Executed when a property's value is written. The callback is executed before the value is actually assigned. This allows i.e. a driver to validate if this is a valid value for the property.

ctOnRefreshCache 

Executed when a component is accessed (read or write) and some of the internal data needs to be refreshed from an external source. The callback is executed before the component data is accessed. This allows i.e. a driver to update the data before.

◆ TCameraDataFormat

Defines the data format the camera is sending.

Enumerator
cdfUnknown 

This is an unknown type.

cdfMono 

This is a mono data format.

cdfBayer 

This is a Bayer format.

cdfBayerPacked 

This is a Bayer Packed format. For each object line there is a red and a blue raw line to calculate the resulting color line.

cdfRGB 

This is a RGB format.

cdfYUV 

This is a YUV format.

◆ TCameraOutput

Defines valid ways a camera can offer image data to a capture device.

Enumerator
coUndefined 

Specifies an undefined output.

coAuto 

Auto mode. Here the capture device tries to guess how the data is transmitted.

coComposite 

The camera will offer an analogue composite video signal.

coBase 

The camera will offer CameraLink® Base compliant image data.

coDigital 

The camera will offer digital image data.

coSVideo 

The camera will offer an analogue SVideo signal.

coMedium 

The camera will offer CameraLink® Medium compliant image data.

coRGB 

The camera will offer an analogue RGB signal.

co2xComposite 

Two cameras will offer two synchronous analogue signals.

co3xComposite 

Three cameras will offer three synchronous analogue signals.

co4xComposite 

Four cameras will offer four synchronous analogue signals.

coFull 

The camera will offer CameraLink® Full compliant image data.

coSDSDI 

The camera will offer serial digital interface(SDI) SD signal.

coHDSDI 

The camera will offer serial digital interface(SDI) HD signal.

co3GSDI 

The camera will offer serial digital interface(SDI) 3G signal.

Examples
CameraDescriptions.cpp, and CameraDescriptions.win32.cpp.

◆ TChannelSplitMode

Defines valid modes for channel split filters.

Enumerator
csmVertical 

The channels will be re-arranged one after the other thus the resulting image will have the same width but 'channel count' times more lines than the input image.

csmHorizontal 

The channels will be re-arranged next to each other thus the resulting image will have the same height but 'channel count' times more pixels per line.

csmExtractSingle 

Only one selectable channel will be extracted and forwarded.

◆ TColorProcessingMode

Defines the color processing mode.

Enumerator
cpmAuto 

The driver decides (depending on the connected camera) what kind of color processing has to be applied.

cpmRaw 

No color processing will be performed.

cpmBayer 

A Bayer color conversion will be applied before the image is transferred to the user.

cpmBayerToMono 

A Bayer to mono conversion will be applied before the image is transferred to the user.

cpmRawToPlanes 

No color processing will be performed but the packed raw Bayer data will be re-arranged within the buffer.

In the resulting image the top left quarter of the image will contain the red pixels, the top right quarter the blue pixels, the lower left quarter the green pixels from the red line and the lower right quarter the green pixels from the blue line:

// w: width, h: height
R(0, 0)          R(0, 1), ...          R(0, (w-1)/2)          B(0, 0)          B(0, 1), ...          B(0, (w-1)/2)
R(1, 0)          R(1, 1), ...          R(1, (w-1)/2)          B(1, 0)          B(1, 1), ...          B(1, (w-1)/2)
          .
          .
          .
R((h-1/2), 0)    R((h-1/2), 1), ...    R((h-1/2), (w-1)/2)    B((h-1/2), 0)    B((h-1/2), 1), ...    B((h-1/2), (w-1)/2)
G(R)(0, 0)       G(R)(0, 1), ...       G(R)(0, (w-1)/2)       G(B)(0, 0)       G(B)(0, 1), ...       G(B)(0, (w-1)/2)
G(R)(1, 0)       G(R)(1, 1), ...       G(R)(1, (w-1)/2)       G(B)(1, 0)       G(B)(1, 1), ...       G(B)(1, (w-1)/2)
          .
          .
          .
G(R)((h-1/2), 0) G(R)((h-1/2), 1), ... G(R)((h-1/2), (w-1)/2) G(B)((h-1/2), 0) G(B)((h-1/2), 1), ... G(B)((h-1/2), (w-1)/2)

◆ TColorTwistInputCorrectionMatrixMode

Defines valid values for input color correction matrices.

Since
2.2.2
Enumerator
cticmmUser 

A user defined correction matrix.

cticmmDeviceSpecific 

A device specific internally defined correction matrix.

This will almost always be the best selection as then the driver internally uses the best matrix for known products.

◆ TColorTwistOutputCorrectionMatrixMode

Defines valid values for output color correction matrices.

Since
2.2.2
Enumerator
ctocmmUser 

A user defined correction matrix.

ctocmmXYZToAdobeRGB_D50 

Will apply the XYZ to Adobe RGB matrix with a D50 white reference.

The following matrix will be applied:

Row 0Row 1Row 2
1.9624274-0.6105343-0.3413404
-0.97876841.91614150.0334540
0.0286869-0.14067521.3487655
ctocmmXYZTosRGB_D50 

Will apply the XYZ to sRGB matrix with a D50 white reference.

The following matrix will be applied:

Row 0Row 1Row 2
3.1338561-1.6168667-0.4906146
-0.97876841.91614150.0334540
0.0719453-0.22899141.4052427
ctocmmXYZToWideGamutRGB_D50 

Will apply the XYZ to White Gamut RGB matrix with a D50 white reference.

The following matrix will be applied:

Row 0Row 1Row 2
1.4628067-0.1840623-0.2743606
-0.5217933,1.44723810.0677227
0.0349342-0.09689301.2884099
ctocmmXYZToAdobeRGB_D65 

Will apply the XYZ to Adobe RGB matrix with a D65 white reference.

The following matrix will be applied:

Row 0Row 1Row 2
2.0413690-0.5649464-0.3446944
-0.96926601.87601080.0415560
0.0134474-0.11838971.0154096
ctocmmXYZTosRGB_D65 

Will apply the XYZ to sRGB matrix with a D65 white reference.

The following matrix will be applied:

Row 0Row 1Row 2
3.2404542-1.5371385-0.4985314
-0.96926601.87601080.0415560
0.0556434-0.20402591.0572252

◆ TComponentFlag

Flags defining access rights and other component properties.

Flags defining access rights and other component properties

Enumerator
cfUndefined 

This is used to define an inconsistent/invalid flag.

This e.g. can be used as a return value for a function, that could not calculate a valid flag mask.

cfReadAccess 

This component can be accessed for reading.

If this flag is set this component can be accessed for reading. This involves reading a property's data, reading a component list's elements reading the size of a component list and so on.

cfWriteAccess 

This component can be accessed for writing.

If this flag is set this component can be accessed for writing or modifying its data. This involves writing values to a property, adding components to a list and so on.

cfRWAccess 

This component can be accessed for both reading and writing.

This just combines mvIMPACT::acquire::cfReadAccess and mvIMPACT::acquire::cfWriteAccess

cfFixedSize 

This components element count can be modified.

If this flag is set this components element count can't be modified. For a list this would mean, that the number of elements stored in this list can't be modified. For a property this means, that the number of values stored in the property can't be modified.

cfInvisible 

The component is shadowed by other settings currently if set.

This flag is used to specify that this component currently has no effect on the behaviour of the system. This flag is just meant as a hint for the user. The property module itself does NOT use this flag for anything.

cfAllowValueCombinations 

Allows combinations of translation dictionary entry as valid values.

If this flag is set for a property that defines a translation dictionary not only values, which are registered in the translation dictionary are allowed values for this property, but also values logical OR-ed together with values from the translation dictionary (these obviously can't be set as strings).

A property defines two entries ("one", 1) and ("two", 2) then 1 | 2 = 3 will be a valid value as well, but "three" obviously won't.

In a GUI application a property specifying this flag should be displayed as a set of check-box controls (one for each dictionary entry) or something similar.

Note
If this flag is specified for a component, which is not a property, it will have no effect on the behaviour of the component. Only integer properties can use this feature
cfShouldBeDisplayedAsList 

Informs a displaying GUI that this component should be displayed as a list.

This flag e.g. can be set for an array property to inform a displaying GUI, that this property is best displayed as a list with a entry for each element. This flag is just meant as a hint for the user. The property module itself does NOT use this flag for anything.

cfDisallowSerialize 

If set this component or derived components can't be stored as external data.

cfAlwaysForceClone 

If set this component is always cloned completely.

This results in the component being completely independent from its parent no matter whether it has been built while deriving or cloning a list and thus the components within this list and its sub-lists.

This will change the behaviour to that effect that changing the parent component will no longer affect the 'derived' component. So different default values, constants and translation dictionaries for properties within an inheritance hierarchy can be defined.

Note
This feature is currently only supported for components of type mvIMPACT::acquire::ctPropInt, mvIMPACT::acquire::ctPropInt64 and mvIMPACT::acquire::ctPropFloat.
cfNotAvailable 

If set, this component is currently not available due to the setting of another feature.

In this case this feature can't be written to nor can it be read.

cfNotImplemented 

If set, this feature has been defined, but so far has not been implemented.

cfContainsBinaryData 

Specifies a property, which contains binary data.

This flag is used to specify a property that contains data in binary format

cfShouldBeDisplayedAsEnumeration 

Informs a displaying GUI that this component should be displayed as an enumeration(e.g. with a combo box).

This flag e.g. can be set for a property to inform a displaying GUI, that this property is best displayed as a combo box or something similar. This flag is just meant as a hint for the user. The property module itself does NOT use this flag for anything.

Since
1.12.57
cfAlwaysForceUpdate 

This feature will ALWAYS execute internal update callbacks and will treat each write attempt to this feature as a value different from the current one.

◆ TComponentRepresentation

Defines valid recommended representations for features.

These representations can be used to create a suitable GUI editor for a features.

Since
2.14.0
Enumerator
crUndefined 
crLinear 

Defines a feature with linear behaviour. One possible editor would be a slider with linear behaviour.

crLogarithmic 

Defines a feature with logarithmic behaviour. One possible editor would be a slider with logarithmic behaviour.

crBoolean 

Defines a boolean feature. This could be displayed to the user as a check box.

crPureNumber 

Defines a feature representing a pure number. This could be displayed to the user as an edit control.

crHexNumber 

Defines a feature representing a hexadecimal number.

crIPv4Address 

Defines a feature representing an IPv4 address. This could be displayed to the user as a custom IPv4 edit control.

crMACAddress 

Defines a feature representing a MAC address. This could be displayed to the user as a custom MAC address edit control.

crFileName 

Defines a feature representing a file name. This could be displayed to the user as a file selection dialog.

crDirectoryName 

Defines a feature representing a directory name. This could be displayed to the user as a directory selection dialog.

◆ TComponentType

Allowed components handled by this module.

This module can handle the types listed in this enumeration only.

Enumerator
ctProp 

A property type.

This type will never occur in a real world application. It's just used to build up the other types. Properties can be used to store user specific data in a structured way.

ctList 

A list object.

Lists can contain other components like lists, methods and properties. Thus lists can be used to build up hierarchical structures of different components.

ctMeth 

A method object.

Method objects provide the possibility to organize functions in lists.

ctPropInt 

Defines a property for 32 bit integer values.

ctPropFloat 

Defines a property for floating point values.

ctPropString 

Defines a property for string values.

ctPropPtr 

Defines a property for pointer values.

ctPropInt64 

Defines a property for 64 bit integer values.

◆ TComponentVisibility

Defines valid recommended visibilities for features.

These visibilities can be used to create GUIs in which the user can select the amount of features he wants to access.

Enumerator
cvBeginner 

Defines a feature that should be visible for all users via the GUI and API. This is the default visibility if no visibility has been specified for a particular component.

cvExpert 

Defines a feature that requires a more in-depth knowledge of the functionality. This is the preferred visibility level for all advanced features.

cvGuru 

Defines an advanced feature that if not configured correctly might result in unexpected behaviour.

cvInvisible 

Defines a feature that should not be displayed in a GUI but is still accessible via API function calls.

◆ TDarkCurrentFilterMode

Defines valid modes for the dark current filter.

Enumerator
dcfmOff 

The filter is switched off.

dcfmOn 

The filter is switched on.

dcfmCalibrateDarkCurrent 

The next selected number of images will be taken for calculating the dark current correction image.

In this mode after the correction image has been calculated the mode will automatically switch back to mvIMPACT::acquire::dcfmOff

dcfmTransmitCorrectionImage 

In this mode whenever reaching this filter, the captured image will be replaced by the last correction image, that has been created as a result of the filter being calibrated.

Since
2.5.9

◆ TDefectivePixelsFilterMode

Defines valid modes for defective pixels filter.

Enumerator
dpfmOff 

This filter is switched off.

dpfm3x1Average 

The filter is active, detected defective pixels will be replaced with the average value from the left and right neighbor pixel.

dpfm3x3Median 

The filter is active, detected defective pixels will be replaced with the median value calculated from the nearest neighbors (3x3).

dpfmResetCalibration 

reset the calibration, delete all internal lists.

dpfmCalibrateLeakyPixel 

Detect defective leaky pixels within the next frame captured.

These are pixels that produce a higher read out value than the average when the sensor is not exposed.

dpfmCalibrateColdPixel 

Detect defective cold pixels within the next frame captured.

These are pixels that produce a lower read out code than the average when the sensor is exposed to light.

dpfmCalibrateHotPixel 

Detect defective hot pixels within the next frame captured.

These are pixels that produce a higher read out code than the average when the sensor is exposed to light.

Since
2.31.0
dpfmCalibrateHotAndColdPixel 

Detect defective hot and cold pixels within the next frame captured.

These are pixels that produce either a higher or a lower read out code than the average when the sensor is exposed to light. This effectively combines mvIMPACT::acquire::dpfmCalibrateColdPixel and mvIMPACT::acquire::dpfmCalibrateHotPixel

Since
2.31.0
dpfmReplaceDefectivePixelAfter3x3Filter 

The filter is active, detected defective pixel will be replaced and treated as being fed into a 3x3 de-Bayer algorithm before reaching the filter.

This is a rather special mode that only makes sense for very specific use cases:

  • Defective pixel data has been obtained by the filter from a device that did carry this data within it's non-volatile memory, the device itself does NOT provide a defective pixel replacement functionality and the device is operated in RGB or YUV mode using a 3 by 3 filter kernel. This will introduce artifacts in the pixels surrounding the defective pixel then and to compensate that a special handling is needed.
  • To reduce CPU load another use case might be to detect defective pixels on a device in Bayer mode using the defective pixel filter of this SDK and then switch the device into RGB mode if supported. Again this is only needed if the device itself does not offer a defective pixel compensation.

A far better way to tackle this of course would be (in that order):

  • Compensate the defective pixels on the device BEFORE feeding the data into the Bayer filter
  • Switch the device to a Bayer format, compensate the defective pixels on the host and THEN feed the data into a host-based Bayer filter
  • Select a device with less defective pixels if these are causing harm to the application

This mode will only operate on packed RGB or packed YUV444 data! It will assume that when given a pixel p all the surrounding pixels marked with a d in the following section need to be replaced as well(- stands for other pixels NOT affected by the replacement operation):

---------------
---------------
----ddd--------
----dpd--------
----ddd--------
---------------
Since
2.33.0

◆ TDeviceAccessMode

Defines valid device access modes.

Enumerator
damUnknown 

Unknown device access mode.

damNone 

No access to the device.

damRead 

Requested or obtained read access to the device.

Properties can be read but can't be changed.

damControl 

Requested or obtained control access to the device.

Properties can be read and changed, other applications might establish read access.

damExclusive 

Requested or obtained exclusive access to the device.

Properties can be read and changed, other applications can't establish access to the device.

◆ TDeviceAutoNegotiatePacketSizeMode

Defines the way the packet size auto negotiation is handled for GigE Vision devices.

All modes will eventually result in the optimal packet value. However depending on the network setup one method might be faster than another.

Enumerator
danpsmHighToLow 

Start with the maximum possible packet size.

If set to mvIMPACT::acquire::danpsmHighToLow the packet size auto negotiation starts with the NICs current MTU value. If this value is too large (in terms of not all network components support it) decreasing sizes will be tried until the optimal (thus highest value supported by all network components) has been found.

Note
This mode is optimal when working with network interfaces where Jumbo frames are enabled.
danpsmLowToHigh 

Start with the minimal possible packet size.

If set to mvIMPACT::acquire::danpsmLowToHigh the packet size auto negotiation starts with the smallest possible MTU. Afterwards increasing sizes will be tried until the optimal (thus highest value supported by all network components) has been found.

Note
This mode is optimal when nothing is known about the network configuration.

◆ TDeviceCapability

Defines valid device capabilities.

Values of these enum type may be 'OR'ed together.

Enumerator
dcNone 

A dummy constant to indicate, that this device does not have any capabilities defined by other constants belonging to this enumeration.

dcHotplugable 

This is a device that supports hot plugging.

dcSelectableVideoInputs 

This is a device, that has more than one video input channel.

dcNonVolatileUserMemory 

This device has non volatile memory, the user can write to and read from.

dcCameraDescriptionSupport 

This device supports camera descriptions.

This is a feature mainly interesting for frame grabbers.

dcEventSupport 

This device supports events.

◆ TDeviceClass

Defines valid generic device classes.

Enumerator
dcGeneric 

A generic device.

dcCamera 

A plain camera device.

dcIntelligentCamera 

An intelligent camera device.

dcFrameGrabber 

A frame grabber device.

dc3DCamera 

A 3D camera.

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

Enumerator
demIgnore 

This event won't be signaled in this state even if the underlying event has been noticed by the device driver.

demNotify 

This event will be notified whenever the underlying event has been detected by the device driver.

◆ TDeviceEventType

Defines valid device event types.

Note
Not every device will support every event.
Deprecated:
This enumeration belongs to a set of functions and data types that have been declared deprecated and will be removed in future versions of this interface. A more flexible way of getting informed about changes in driver features has been added to the interface and should be used instead. Look for an example called Callback to find out how to use it.
Enumerator
detNone 

A dummy constant to specify no event where an event type must be specified.

detPnPArrival 

An event of this type will be signaled (if desired) each time a hotplug compliant device recognized by the mvIMPACT acquire device manager has been connected to the system(deprecated).

Deprecated:
This event has been declared deprecated. An application should register a callback to the state property instead.
detPnPRemoval 

An event of this type will be signaled (if desired) each time a hotplug compliant device recognized by the mvIMPACT acquire device manager has been disconnected to the system(deprecated).

Deprecated:
This event has been declared deprecated. An application should register a callback to the state property instead.
detFrameStart 

An event of this type will be signaled (if desired) each time the start of a new image has been detected by the device.

Note
This is currently only supported by mvTITAN/mvGAMMA devices.
detHistogramReady 

An event of this type will be signaled (if desired) each time the histogram is calculated.

Note
This is currently only supported by OEM devices.
detAll 

A combination of all event types, which can be used as a mask.

◆ TDeviceInterfaceLayout

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. Apart from that the interface layout also has impact at what time property values will be buffered for buffer captures.

Enumerator
dilDeviceSpecific 

A device specific interface shall be used(deprecated for all GenICam compliant devices).

For most devices supported by this SDK this will be the only interface 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 any third party hardware which might be usable with a certain device driver.

In contrast to the other interface layouts, this layout will use a buffered property approach. This means that consecutive buffers can be requested each using defined but different settings. At the time of requesting a buffer, the driver will internally store the current property settings and will re-program the hardware later at the time of processing this request if the current settings differ from the settings that shall be used for this request.

Deprecated:
This interface layout has been declared deprecated for GenICam compliant devices(mvBlueCOUGAR-S, mvBlueCOUGAR-X and mvBlueCOUGAR-XD). For these products please use mvIMPACT::acquire::dilGenICam instead. Newer devices like the mvBlueFOX3 will not support this interface layout at all.
See also
The Differences Between The Interface Layouts.
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.

In this interface layout property value changes will always have immediate effect, thus when changing the exposure time directly after requesting a buffer this buffer might be captured with the new exposure time already depending on the time the buffer request is actually be processed.

Note
This interface layout will allow to access third party devices as well.
See also
'GenICam' vs. 'DeviceSpecific' Interface Layout
The Differences Between The Interface Layouts.

◆ TDeviceListType

Defines valid interface list types, which can be located using an instance of mvIMPACT::acquire::DeviceComponentLocator.

Enumerator
dltUndefined 

A placeholder for an undefined list type.

dltSetting 

Specifies a certain setting.

An additional string defines the name of the setting to look for.

dltRequest 

Specifies the list of driver owned image request objects.

dltRequestCtrl 

Specifies a certain image request control.

An additional string defines the name of the setting to look for.

dltInfo 

Specifies the driver interfaces list containing general information.

This e.g. can be properties containing the driver version, the current state of the device and stuff like that.

dltStatistics 

Specifies the driver interface list containing statistical information.

This list e.g. might contain the current frame rate, the total number of images captured, etc.

dltSystemSettings 

Specifies the driver interface list containing properties, which influence the overall operation of the device.

This list e.g. might contain the priority of the drivers internal worker thread, the number of request objects the driver shall work with, etc.

dltIOSubSystem 

Specifies the driver interface list containing properties to work with any kind of I/O pin belonging to that device.

Here properties addressing the digital inputs and outputs and other I/O related properties can be found.

dltRTCtr 

Specifies the driver interface list providing access to the drivers Hardware Real-Time Controller (HRTC).

Here properties to control the behaviour of the HRTCs can be found.

Note
This feature might not be available for every device.
dltCameraDescriptions 

Specifies the driver interface list providing access to the recognized camera description lists.

Within this list all recognized camera descriptions can be found, each forming a sub list containing the properties describing the camera.

Note
This feature is only available for frame grabber devices currently.
dltDeviceSpecificData 

Specifies the driver interface list providing access to the device specific settings lists.

Note
This feature currently is only available for frame grabber devices.
dltEventSubSystemSettings 

Specifies the driver interface list providing access to the device specific event type settings lists(deprecated).

Note
Every device will support a different set of events that can be waited for by the user.

This list will contain a sublist for each event type recognized for this device. Within this sublist all properties that can be describe the current mode an event is operated in user can be found.

Deprecated:
This value has been declared deprecated and will be removed in future versions of this interface. A more flexible way of getting informed about changes in driver features has been added to the interface and should be used instead. An example for this new method is Callback.cpp.
dltEventSubSystemResults 

Specifies the driver interface list providing access to the device specific event type results lists(deprecated).

Note
Every device will support a different set of events that can be waited for by the user.

This list will contain a sublist for each event type recognized for this device. Within this sublist all result properties that can be queried by the user can be found.

Deprecated:
This value has been declared deprecated and will be removed in future versions of this interface. A more flexible way of getting informed about changes in driver features has been added to the interface and should be used instead. An example for this new method is Callback.cpp.
dltImageMemoryManager 

Specifies the driver interface list providing access to the devices memory manager list.

Note
This feature currently is only available for frame grabber devices.

This list will contain properties and lists providing access to settings related to the memory handling used by the device. E.g. the buffer size for individual DMA blocks can be configured here.

Note
Properties in this list should only be modified by advanced users.
dltLast 

Defines the last entry in this enumeration.

This is always equal to the last 'real' enum value.

◆ TDeviceLoadSettings

Defines valid modes for the loading of settings during initialization.

Whenever a mvIMPACT::acquire::Device is initialized this enumeration type defines the mode the mvIMPACT::acquire::Device tries to restore settings from a previously stored session.

Enumerator
dlsAuto 

Tries to load settings automatically following an internal procedure.

The load cycle at initialization time is like this:

look for a setting for this particular device (via serial number)
if not found
look for a setting for this device type (via string in property 'Product' )
if not found
look for a setting for this device family (via string in property 'Family' )
if not found
use the default settings

Under Linux® the current directory will be searched for files named <serialNumber>.xml, <productString>.xml and <familyString.xml> while under Windows® the registry will be searched for keys with these names. This only happens once (when the device is opened)

dlsNoLoad 

No stored settings will be loaded at start-up. The device will be initialized with the drivers default values.

◆ TDeviceState

Defines valid Device states.

Enumerator
dsAbsent 

The mvIMPACT::acquire::Device has been unplugged.

The mvIMPACT::acquire::Device has present been since the mvIMPACT::acquire::DeviceManager has been initialized, but has been unplugged now and the driver has detected the unplugging of the device. Automatic detection of unplugging events is only possible for devices that support plug and play, other device drivers will only check if a device is still present if an application triggered this check.

dsPresent 

The mvIMPACT::acquire::Device is currently connected and initialized.

dsInitializing 

The mvIMPACT::acquire::Device is connected and is currently initializing.

dsUnreachable 

This device is recognized, but can't be accessed currently.

This e.g. can be the case, if this is a device connected via a network and the device does not respond to one of the recognized network protocols or if another client is already connected to this device and the device does not support multiple clients.

dsPowerDown 

This device is present, but currently switched into a low power consumption mode.

◆ TDMR_ERROR

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
DMR_NO_ERROR 

The function call was executed successfully.


[0]

DMR_DEV_NOT_FOUND 

The specified device can't be found.

This error occurs either if an invalid device ID has been passed to the device manager or if the caller tried to close a device which currently isn't initialized.


[-2100]

DMR_INIT_FAILED 

The device manager couldn't be initialized.

This is an internal error.


[-2101]

DMR_DRV_ALREADY_IN_USE 

The device is already in use.

This error e.g. will occur if this or another process has initialized this device already and an application tries to open the device once more or if a certain resource is available only once but shall be used twice.


[-2102]

DMR_DEV_CANNOT_OPEN 

The specified device couldn't be initialized.


[-2103]

DMR_NOT_INITIALIZED 

The device manager or another module hasn't been initialized properly.

This error occurs if the user tries e.g. to close the device manager without having initialized it before or if a library used internally or a module or device associated with that library has not been initialized properly or if


[-2104]

DMR_DRV_CANNOT_OPEN 

A device could not be initialized.

In this case the log-file will contain detailed information about the source of the problem.


[-2105]

DMR_DEV_REQUEST_QUEUE_EMPTY 

The devices request queue is empty.

This error e.g. occurs if the user waits for an image request to become available at a result queue without having send an image request to the device before.

It might also arise when trying to trigger an image with a software trigger mechanism before the acquisition engine has been completely started. In this case a small delay and then again calling the software trigger function will succeed.


[-2106]

DMR_DEV_REQUEST_CREATION_FAILED 

A request object couldn't be created.

The creation of a request object failed. This might e.g. happen, if the system runs extremely low on memory.


[-2107]

DMR_INVALID_PARAMETER 

An invalid parameter has been passed to a function.

This might e.g. happen if a function requiring a pointer to a structure has been passed an unassigned pointer or if a value has been passed, that is either too large or too small in that context.


[-2108]

DMR_EXPORTED_SYMBOL_NOT_FOUND 

One or more symbols needed in a detected driver library couldn't be resolved.

In most cases this is an error handled internally. So the user will not receive this error code as a result of a call to an API function. However when the user tries to get access to an IMPACT buffer type while the needed IMPACT Base libraries are not installed on the target system this error code also might be returned to the user.


[-2109]

DEV_UNKNOWN_ERROR 

An unknown error occurred while processing a user called driver function.


[-2110]

DEV_HANDLE_INVALID 

A driver function has been called with an invalid device handle.


[-2111]

DEV_INPUT_PARAM_INVALID 

A driver function has been called but one or more of the input parameters are invalid.

There are several possible reasons for this error:

  • an unassigned pointer has been passed to a function, that requires a valid pointer
  • one or more of the passed parameters are of an incorrect type
  • one or more parameters contain an invalid value (e.g. a filename that points to a file that can't be found, a value, that is larger or smaller than the allowed values.


[-2112]

DEV_WRONG_INPUT_PARAM_COUNT 

A function has been called with an invalid number of input parameters.


[-2113]

DEV_CREATE_SETTING_FAILED 

The creation of a setting failed.

This can either happen, when a setting with the same name as the one the user tried to create already exists or if the system can't allocate memory for the new setting.


[-2114]

DEV_REQUEST_CANT_BE_UNLOCKED 

The unlock for a mvIMPACT::acquire::Request object failed.

This might happen, if the mvIMPACT::acquire::Request is not locked at the time of calling the unlock function. It either has been unlocked by the user already or this request has never been locked as the request so far has not been used to capture image data into its buffer. Another reason for this error might be that the user tries to unlock a request that is currently processed by the device driver.


[-2115]

DEV_INVALID_REQUEST_NUMBER 

The number for the mvIMPACT::acquire::Request object is invalid.

The max. number for a mvIMPACT::acquire::Request object is the value of the property RequestCount in the mvIMPACT::acquire::SystemSettings list - 1.


[-2116]

DEV_LOCKED_REQUEST_IN_QUEUE 

A Request that hasn't been unlocked has been passed back to the driver.

This error might occur if the user requested an image from the driver but hasn't unlocked the mvIMPACT::acquire::Request that will be used for this new image.


[-2117]

DEV_NO_FREE_REQUEST_AVAILABLE 

The user requested a new image, but no free mvIMPACT::acquire::Request object is available to process this request.


[-2118]

DEV_WAIT_FOR_REQUEST_FAILED 

The wait for a request failed.

This might have several reasons:

• The user waited for an image, but no image has been requested before.

• The user waited for a requested image, but the image is still not ready(e.g. because of a short timeout and a long exposure time).

• A triggered image has been requested but no trigger signal has been detected within the wait period.

• A plug and play device(e.g. an USB device) has been unplugged and therefore can't deliver images anymore. In this case the 'state' property should be checked to find out if the device is still present or not.


[-2119]

DEV_UNSUPPORTED_PARAMETER 

The user tried to get/set a parameter, which is not supported by this device.


[-2120]

DEV_INVALID_RTC_NUMBER 

The requested real time controller is not available for this device.


[-2121]

DMR_INTERNAL_ERROR 

Some kind of internal error occurred.

More information can be found in the *.log-file or the debug output.


[-2122]

DMR_INPUT_BUFFER_TOO_SMALL 

The user allocated input buffer is too small to accommodate the result.


[-2123]

DEV_INTERNAL_ERROR 

Some kind of internal error occurred in the device driver.

More information can be found in the *.log-file or the debug output.


[-2124]

DMR_LIBRARY_NOT_FOUND 

One or more needed libraries are not installed on the system.


[-2125]

DMR_FUNCTION_NOT_IMPLEMENTED 

A called function or accessed feature is not available for this device.


[-2126]

DMR_FEATURE_NOT_AVAILABLE 

The feature in question is (currently) not available for this device or driver.

This might be because another feature currently blocks the one in question from being accessible. More information can be found in the *.log-file or the debug output.


[-2127]

DMR_EXECUTION_PROHIBITED 

The user is not permitted to perform the requested operation.

This e.g. might happen if the user tried to delete user data without specifying the required password.


[-2128]

DMR_FILE_NOT_FOUND 

The specified file can't be found.

This might e.g. happen if the current working directory doesn't contain the file specified.


[-2129]

DMR_INVALID_LICENCE 

The licence doesn't match the device it has been assigned to.

When e.g. upgrading a device feature each licence file is bound to a certain device. If the device this file has been assigned to has a different serial number then the one used to create the licence this error will occur.


[-2130]

DEV_SENSOR_TYPE_ERROR 

There is no sensor found or the found sensor type is wrong or not supported.


[-2131]

DMR_CAMERA_DESCRIPTION_INVALID 

A function call was associated with a camera description, that is invalid.

One possible reason might be, that the camera description has been deleted(driver closed?).

Since
1.5.0


[-2132]

DMR_NEWER_LIBRARY_REQUIRED 

A suitable driver library to work with the device manager has been detected, but it is too old to work with this version of the mvDeviceManager library.

This might happen if two different drivers have been installed on the target system and one introduces a newer version of the device manager that is not compatible with the older driver installed on the system. In this case this error message will be written into the log-file together with the name of the library that is considered to be too old.

The latest drivers will always be available online under www.matrix-vision.de. There will always be an updated version of the library considered to be too old for download from here.

Since
1.6.6


[-2133]

DMR_TIMEOUT 

A general timeout occurred.

This is the typical result of functions that wait for some condition to be met with a timeout among their parameters.

More information can be found in the *.log-file or the debug output.

Since
1.7.2


[-2134]

DMR_WAIT_ABANDONED 

A wait operation has been aborted.

This e.g. might occur if the user waited for some message to be returned by the driver and the device driver has been closed within another thread. In order to inform the user that this waiting operation terminated in an unusual wait, mvIMPACT::acquire::DMR_WAIT_ABANDONED will be returned then.

Since
1.7.2


[-2135]

DMR_EXECUTION_FAILED 

The execution of a method object or reading/writing to a feature failed.

More information can be found in the log-file.

Since
1.9.0


[-2136]

DEV_REQUEST_ALREADY_IN_USE 

This request is currently used by the driver.

This error may occur if the user tries to send a certain request object to the driver by a call to the corresponding image request function.

Since
1.10.31


[-2137]

DEV_REQUEST_BUFFER_INVALID 

A request has been configured to use a user supplied buffer, but the buffer pointer associated with the request is invalid.

Since
1.10.31


[-2138]

DEV_REQUEST_BUFFER_MISALIGNED 

A request has been configured to use a user supplied buffer, but the buffer pointer associated with the request has an incorrect alignment.

Certain devices need aligned memory to perform efficiently thus when a user supplied buffer shall be used to capture data into this buffer must follow these alignment constraints

Since
1.10.31


[-2139]

DEV_ACCESS_DENIED 

The requested access to a device could not be granted.

There are multiple reasons for this error code. Detailed information can be found in the *.log-file.

POSSIBLE CAUSES:

• an application tries to access a device exclusively that is already open in another process

• a network device has already been opened with control access from another system and the current system also tries to establish control access to the device

• an application tried to execute a function that is currently not available

• an application tries to write to a read-only location.

Since
1.10.39


[-2140]

DMR_PRELOAD_CHECK_FAILED 

A pre-load condition for loading a device driver failed.

Certain device drivers may depend on certain changes applied to the system in order to operate correctly. E.g. a device driver might need a certain environment variable to exist. When the device manager tries to load a device driver it performs some basic checks to detect problems like this. When one of these checks fails the device manager will not try to load the device driver and an error message will be written to the selected log outputs.

Since
1.10.52


[-2141]

DMR_CAMERA_DESCRIPTION_INVALID_PARAMETER 

One or more of the camera descriptions parameters are invalid for the grabber it is used with.

There are multiple reasons for this error code. Detailed information can be found in the *.log-file.

POSSIBLE CAUSES:

• The TapsXGeometry or TapsYGeometry parameter of the selected camera description cannot be used with a user defined AOI.

• A scan standard has been selected, that is not supported by this device.

• An invalid scan rate has been selected.

• ...

This error code will be returned by frame grabbers only.

Since
1.10.57


[-2142]

DMR_FILE_ACCESS_ERROR 

A general error returned whenever there has been a problem with accessing a file.

There can be multiple reasons for this error and a detailed error message will be sent to the log-output whenever this error code is returned.

POSSIBLE CAUSES:

• The driver tried to modify a file, for which it has no write access.

• The driver tried to read from a file, for which it has no read access.

• ...

Since
1.10.87


[-2143]

DMR_INVALID_QUEUE_SELECTION 

An error returned when the user application attempts to operate on an invalid queue.

Since
1.11.0


[-2144]

DMR_ACQUISITION_ENGINE_BUSY 

An error returned when the user application attempts to start the acquisition engine at a time, where it is already running.

Since
2.5.3


[-2145]

DMR_BUSY 

An error returned when the user application attempts to perform any operation that currently for any reason cannot be started because something else already running.

The log-output will provide additional information.

Since
2.32.0


[-2146]

DMR_OUT_OF_MEMORY 

An error returned when for any reason internal resources (memory, handles, ...) cannot be allocated.

The log-output will provide additional information.

Since
2.32.0


[-2147]

DMR_LAST_VALID_ERROR_CODE 

Defines the last valid error code value for device and device manager related errors.


[-2199]

Examples
CameraDescriptions.win32.cpp, CaptureToMegaBuffer.cpp, CaptureToOpenGLMemory.cpp, CaptureToUserMemory.cpp, CaptureToUserMemory.legacy.cpp, ContinuousCapture.linux.cpp, ContinuousCapture.win32.cpp, ContinuousCaptureAllDevices.cpp, ContinuousCaptureAllDevices.win32.cpp, ContinuousCaptureAllFormats.win32.cpp, ContinuousCaptureMultiPart.legacy.cpp, ContinuousCaptureOnlyProcessLatest.cpp, ContinuousCaptureOnlyProcessLatest.legacy.cpp, ContinuousCaptureToAVIFile.cpp, GenICamCallbackOnEvent.cpp, GenICamCommonSettingsUsage.legacy.cpp, GenICamInterfaceLayout.legacy.cpp, GenICamSequencerParameterChangeAtRuntime.cpp, GenICamSequencerUsage.cpp, GenICamSequencerUsage.legacy.cpp, GenICamSequencerUsageWithPaths.cpp, GenICamSequencerUsageWithPaths.legacy.cpp, GenICamSmartFrameRecallUsage.cpp, GenICamSmartFrameRecallUsage.legacy.cpp, SequenceCapture.win32.cpp, SingleCaptureMasterSlave.cpp, SingleCaptureMasterSlave.legacy.cpp, and TimestampFeatures.cpp.

◆ TFlatFieldFilterCorrectionMode

Defines valid modes for the flat field correction.

Enumerator
ffcmDefault 

The default flat field correction is used.

ffcmBrightPreserving 

The flat field correction with clipping compensation is used. This mode prevents clipping artifacts when overexposing the image, but may cause missing codes in the histogram and a brighter image.

◆ TFlatFieldFilterMode

Defines valid modes for the flat field filter.

Enumerator
fffmOff 

The filter is switched off.

fffmOn 

The filter is switched on.

fffmCalibrateFlatField 

The next selected number of images will be taken for calculating the flat field correction image.

In this mode after the correction image has been calculated the mode will automatically switch back to mvIMPACT::acquire::fffmOff

fffmTransmitCorrectionImage 

In this mode whenever reaching this filter, the captured image will be replaced by the last correction image, that has been created as a result of the filter being calibrated.

Since
2.5.9

◆ THWUpdateResult

Defines valid Device HW update results.

This defines valid result e.g. of a user executed firmware update.

Enumerator
urNoUpdatePerformed 

No update has been performed for this mvIMPACT::acquire::Device.

No update has been performed in the current process since this device driver has been loaded in the current process address space.

urUpdateFW 

The mvIMPACT::acquire::Device is currently updating firmware.

urUpdateFWError 

The mvIMPACT::acquire::Device indicates an error during updating firmware.

urDevAlreadyInUse 

The requested update couldn't be performed as the device is already in use.

If another (or even the same) process uses the device, this hardware update can't be performed. To perform the requested update this device needs to be closed.

urUpdateFWOK 

The mvIMPACT::acquire::Device indicates that the firmware has been updated successfully.

urSetDevID 

The mvIMPACT::acquire::Device is currently setting device ID.

urSetDevIDError 

The mvIMPACT::acquire::Device signaled an error when setting device ID.

urSetDevIDInvalidID 

An invalid device ID has been specified.

Valid device IDs are within 0 and 250 including the upper and lower limit.

urSetDevIDOK 

The mvIMPACT::acquire::Device has successfully been assigned a new ID.

urSetUserDataSizeError 

Size Error in writing User Data to mvIMPACT::acquire::Device .

urSetUserDataWriteError 

Write Error in writing User Data to mvIMPACT::acquire::Device .

urSetUserDataWriteOK 

Writing user data to mvIMPACT::acquire::Device was successful.

urGetUserDataReadError 

Reading user data from an mvIMPACT::acquire::Device failed.

urVerifyFWError 

The mvIMPACT::acquire::Device indicates an error during verifying firmware.

urVerifyFWOK 

The mvIMPACT::acquire::Device indicates that the firmware has been verified successfully.

◆ TImageBufferFormatReinterpreterMode

Valid image buffer format reinterpreter modes.

Since
2.10.1
Enumerator
ibfrmMono8_To_Mono8 

Attach or remove a mvIMPACT::acquire::TBayerMosaicParity attribute to a mvIMPACT::acquire::ibpfMono8 buffer OR change the existing Bayer attribute to a different value.

The new mvIMPACT::acquire::TBayerMosaicParity value for the buffer can be selected by the property FormatReinterpreterBayerMosaicParity.

ibfrmMono8_To_RGB888Packed 

Reinterpret mvIMPACT::acquire::ibpfMono8 as mvIMPACT::acquire::ibpfRGB888Packed.

This will effectively divide the width by 3 but preserve the original line pitch.

ibfrmMono8_To_BGR888Packed 

Reinterpret mvIMPACT::acquire::ibpfMono8 as mvIMPACT::acquire::ibpfBGR888Packed.

This will effectively divide the width by 3 but preserve the original line pitch.

ibfrmMono10_To_Mono10 

Attach or remove a mvIMPACT::acquire::TBayerMosaicParity attribute to a mvIMPACT::acquire::ibpfMono8 buffer OR change the existing Bayer attribute to a different value.

The new mvIMPACT::acquire::TBayerMosaicParity value for the buffer can be selected by the property FormatReinterpreterBayerMosaicParity.

ibfrmMono10_To_RGB101010Packed 

Reinterpret mvIMPACT::acquire::ibpfMono10 as mvIMPACT::acquire::ibpfRGB101010Packed.

This will effectively divide the width by 3 but preserve the original line pitch.

ibfrmMono12_To_Mono12 

Attach or remove a mvIMPACT::acquire::TBayerMosaicParity attribute to a mvIMPACT::acquire::ibpfMono8 buffer OR change the existing Bayer attribute to a different value.

The new mvIMPACT::acquire::TBayerMosaicParity value for the buffer can be selected by the property FormatReinterpreterBayerMosaicParity.

ibfrmMono12_To_RGB121212Packed 

Reinterpret mvIMPACT::acquire::ibpfMono12 as mvIMPACT::acquire::ibpfRGB121212Packed.

This will effectively divide the width by 3 but preserve the original line pitch.

ibfrmMono14_To_Mono14 

Attach or remove a mvIMPACT::acquire::TBayerMosaicParity attribute to a mvIMPACT::acquire::ibpfMono8 buffer OR change the existing Bayer attribute to a different value.

The new mvIMPACT::acquire::TBayerMosaicParity value for the buffer can be selected by the property FormatReinterpreterBayerMosaicParity.

ibfrmMono14_To_RGB141414Packed 

Reinterpret mvIMPACT::acquire::ibpfMono14 as mvIMPACT::acquire::ibpfRGB141414Packed.

This will effectively divide the width by 3 but preserve the original line pitch.

ibfrmMono16_To_Mono16 

Attach or remove a mvIMPACT::acquire::TBayerMosaicParity attribute to a mvIMPACT::acquire::ibpfMono8 buffer OR change the existing Bayer attribute to a different value.

The new mvIMPACT::acquire::TBayerMosaicParity value for the buffer can be selected by the property FormatReinterpreterBayerMosaicParity.

ibfrmMono16_To_RGB161616Packed 

Reinterpret mvIMPACT::acquire::ibpfMono16 as mvIMPACT::acquire::ibpfRGB161616Packed.

This will effectively divide the width by 3 but preserve the original line pitch.

◆ TImageBufferPixelFormat

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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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 color 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 color 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.

See also
Converting packed data to planar formats
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 color 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 color 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.

See also
Converting packed data to planar formats
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 color 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 color 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.

See also
Converting packed data to planar formats
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 color 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 color 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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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 a 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 (pseudo code assuming 'pointerToStartOfTheBuffer' is a 'byte pointer'):
GetMono12Packed_V1Pixel( pointerToStartOfTheBuffer, pixelIndex )
const int offsetFromStartOfTheBuffer = (3*pixel)/2
if pixel divisible by 2
return (pointerToStartOfTheBuffer[offset+1] << shift) | (pointerToStartOfTheBuffer[offset] >> 4)
return pointerToStartOfTheBuffer[offset] << shift) | (pointerToStartOfTheBuffer[offset+1] & 0xF)
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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
ibpfBGR101010Packed_V2 

A 10 bit per color component RGB packed format.

This format will use 4 bytes to store one 10 bit per color 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:
//-----------------------------------------------------------------------------
// slow version
inline void GetBGR101010Packed_V2Pixel( void* p, const int pitch, int x, int y, unsigned short& red, unsigned short& green, unsigned short& blue )
//-----------------------------------------------------------------------------
{
unsigned int* pSrc = reinterpret_cast<unsigned int*>(static_cast<unsigned char*>(p) + y * pitch) + x;
red = static_cast<unsigned short>( (*pSrc) & 0x3FF);
green = static_cast<unsigned short>(((*pSrc) >> 10 ) & 0x3FF);
blue = static_cast<unsigned short>(((*pSrc) >> 20 ) & 0x3FF);
}
//-----------------------------------------------------------------------------
// faster version
inline void GetBGR101010Packed_V2Pixel( unsigned int pixel, unsigned short& red, unsigned short& green, unsigned short& blue )
//-----------------------------------------------------------------------------
{
red = static_cast<unsigned short>( pixel & 0x3FF);
green = static_cast<unsigned short>(( pixel >> 10 ) & 0x3FF);
blue = static_cast<unsigned short>(( pixel >> 20 ) & 0x3FF);
}
See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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 color 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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
ibpfMono12Packed_V1 

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 0..7(1) bits 8..11(1) bits 0..3(2) bits 4..11(2) bits 0..7(3) bits 8..11(3) bits 0..3(4) bits 4..11(4) etc.
Note
When the width is not divisible by 2 the line pitch of a 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 (pseudo code assuming 'pointerToStartOfTheBuffer' is a 'byte pointer'):
GetMono12Packed_V1Pixel( pointerToStartOfTheBuffer, pixelIndex )
const int offsetFromStartOfTheBuffer = pixel + pixel/2
if pixel divisible by 2
return (pointerToStartOfTheBuffer[offset] >> 4) | (pointerToStartOfTheBuffer[offset+1] << 4)
return pointerToStartOfTheBuffer[offset]) | (pointerToStartOfTheBuffer[offset+1] & 0xF) << 8)
Since
2.5.0
ibpfYUV411_UYYVYY_Packed 

This is a YUV411 packed image with 48 bits for four pixels.

This format uses 4:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 4 pixels in horizontal direction. If each component takes 8 bits, four pixels require 48 bits.

Four consecutive pixels (48 bit, 0xaabbccddeeff ) contain 8 bit chrominance blue of pixels 1, 2, 3 and 4(aa), 8 bit luminance of pixel 1(bb),8 bit luminance of pixel 2(cc), 8 bit chrominance red of pixels 1, 2, 3 and 4(dd), 8 bit luminance of pixel 3(ee) and finally 8 bit luminance of pixel 4(ff).

Thus in memory the data will be stored like this:

6 bytes 6 bytes etc.
Cb(1,2,3,4) Y(1) Y(2) Cr(1,2,3,4) Y(3) Y(4) Cb(5,6,7,8) Y(5) Y(6) Cr(5,6,7,8) Y(7) Y(8) etc.
.................. Cb(n,n+1,n+2,n+3) Y(n) Y(n+1) Cr(n,n+1,n+2,n+3) Y(n+2) Y(n+3)

So the first byte in memory is the chrominance blue component. ImageBuffer::vpData will therefore point to Cb when using a byte pointer.

See also
Converting packed data to planar formats
Since
2.13.0
ibpfRGB888Planar 

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 3 planes(a plane for each color component).

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)

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.

Since
2.17.0
ibpfAuto 

The driver will decide which format will be used.

Examples
CaptureToOpenGLMemory.cpp.

◆ TImageDestinationPixelFormat

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

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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 color 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 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 blue component. ImageBuffer::vpData will therefore point to B(1) when using a 16 bit pointer.

See also
Converting packed data to planar formats
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 color 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 color 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.

See also
Converting packed data to planar formats
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 color 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 color 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.

See also
Converting packed data to planar formats
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 color 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 color 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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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 a 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 (pseudo code assuming 'pointerToStartOfTheBuffer' is a 'byte pointer'):
GetMono12Packed_V1Pixel( pointerToStartOfTheBuffer, pixelIndex )
const int offsetFromStartOfTheBuffer = (3*pixel)/2
if pixel divisible by 2
return (pointerToStartOfTheBuffer[offset+1] << shift) | (pointerToStartOfTheBuffer[offset] >> 4)
return pointerToStartOfTheBuffer[offset] << shift) | (pointerToStartOfTheBuffer[offset+1] & 0xF)
}
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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
idpfBGR101010Packed_V2 

A 10 bit per color component RGB packed format.

This format will use 4 bytes to store one 10 bit per color 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:
//-----------------------------------------------------------------------------
// slow version
inline void GetBGR101010Packed_V2Pixel( void* p, const int pitch, int x, int y, unsigned short& red, unsigned short& green, unsigned short& blue )
//-----------------------------------------------------------------------------
{
unsigned int* pSrc = reinterpret_cast<unsigned int*>(static_cast<unsigned char*>(p) + y * pitch) + x;
red = static_cast<unsigned short>( (*pSrc) & 0x3FF);
green = static_cast<unsigned short>(((*pSrc) >> 10 ) & 0x3FF);
blue = static_cast<unsigned short>(((*pSrc) >> 20 ) & 0x3FF);
}
//-----------------------------------------------------------------------------
// faster version
inline void GetBGR101010Packed_V2Pixel( unsigned int pixel, unsigned short& red, unsigned short& green, unsigned short& blue )
//-----------------------------------------------------------------------------
{
red = static_cast<unsigned short>( pixel & 0x3FF);
green = static_cast<unsigned short>(( pixel >> 10 ) & 0x3FF);
blue = static_cast<unsigned short>(( pixel >> 20 ) & 0x3FF);
}
See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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 color 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.

See also
Converting packed data to planar formats
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.

See also
Converting packed data to planar formats
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 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.

See also
Converting packed data to planar formats
idpfMono12Packed_V1 

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 0..7(1) bits 8..11(1) bits 0..3(2) bits 4..11(2) bits 0..7(3) bits 8..11(3) bits 0..3(4) bits 4..11(4) etc.
Note
When the width is not divisible by 2 the line pitch of a 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 (pseudo code assuming 'pointerToStartOfTheBuffer' is a 'byte pointer'):
GetMono12Packed_V1Pixel( pointerToStartOfTheBuffer, pixelIndex )
const int offsetFromStartOfTheBuffer = pixel + pixel/2
if pixel divisible by 2
return (pointerToStartOfTheBuffer[offset] >> 4) | (pointerToStartOfTheBuffer[offset+1] << 4)
return pointerToStartOfTheBuffer[offset]) | (pointerToStartOfTheBuffer[offset+1] & 0xF) << 8)
Since
2.5.0
idpfYUV411_UYYVYY_Packed 

This is a YUV411 packed image with 48 bits for four pixels.

This format uses 4:1 horizontal downsampling, which means that the Y component is sampled at each pixel, while U(Cb) and V(Cr) components are sampled every 4 pixels in horizontal direction. If each component takes 8 bits, four pixels require 48 bits.

Four consecutive pixels (48 bit, 0xaabbccddeeff ) contain 8 bit chrominance blue of pixels 1, 2, 3 and 4(aa), 8 bit luminance of pixel 1(bb),8 bit luminance of pixel 2(cc), 8 bit chrominance red of pixels 1, 2, 3 and 4(dd), 8 bit luminance of pixel 3(ee) and finally 8 bit luminance of pixel 4(ff).

Thus in memory the data will be stored like this:

6 bytes 6 bytes etc.
Cb(1,2,3,4) Y(1) Y(2) Cr(1,2,3,4) Y(3) Y(4) Cb(5,6,7,8) Y(5) Y(6) Cr(5,6,7,8) Y(7) Y(8) etc.
.................. Cb(n,n+1,n+2,n+3) Y(n) Y(n+1) Cr(n,n+1,n+2,n+3) Y(n+2) Y(n+3)

So the first byte in memory is the chrominance blue component. ImageBuffer::vpData will therefore point to Cb when using a byte pointer.

See also
Converting packed data to planar formats
Since
2.13.0
idpfRGB888Planar 

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 3 planes(a plane for each color component).

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)

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.

Since
2.17.0
Examples
SequenceCapture.cpp, and SequenceCapture.win32.cpp.

◆ TImageFileFormat

Defines valid image file formats.

Since
2.23.0
Enumerator
iffAuto 

Automatically tries to select the file format e.g. from the file extension.

iffBMP 

The BMP format.

iffJPEG 

The JPEG format.

iffPNG 

The PNG format.

iffTIFF 

The TIFF format.

◆ TImageProcessingFilter

Defines valid filters which can be applied to the captured image before it is transferred to the user.

Enumerator
ipfOff 

No filter function will be applied to the image.

ipfSharpen 

A sharpen filter will be applied to the image.

◆ TImageProcessingMode

Defines valid modes the internal image processing pipeline can be operated in.

Since
2.14.0
Enumerator
ipmDefault 

The default mode where every image is processed in the order they have been acquired.

ipmProcessLatestOnly 

This mode can be useful for applications where processing on the host takes longer than the average time between two consecutive frames transmitted by the device.

This might be useful for applications that display the processed result but that also want to capture data at the highest possible frame rate and is not important that EVERY image gets processed.

Attention
This mode might result in images being returned without the expected processing on the host.
See also
mvIMPACT::acquire::Device::userControlledImageProcessingEnable,
mvIMPACT::acquire::Request::hasProcessingBeenSkipped,
mvIMPACT::acquire::Request::getImageProcessingResultsIterator

◆ TImageProcessingOptimization

Defines valid modes the internal image processing algorithms can be operated in.

See also
General.
Since
2.12.2
Enumerator
ipoMaximizeSpeed 

Will maximize the execution speed. This might result in a higher memory consumption.

ipoMinimizeMemoryUsage 

Will minimize the memory footprint. This might result in a higher CPU load.

Attention
This mode will also result in a higher amount of memory allocation and freeing operations thus if the application itself is working with heap memory a lot the long term effects of heap fragmentation should be considered!

◆ TImageProcessingResult

Defines valid values for the result of a certain image processing algorithm applied to a request.

Since
2.14.0
Enumerator
iprNotActive 

This algorithm was either switched off or not needed when applied to this request object.

When an algorithm is switched on and this result is returned this can indicate e.g. that for a format conversion the input and output format where identical.

iprApplied 

This algorithm has been applied to this request object.

iprFailure 

A problem was encountered when this algorithm has been applied to this request object.

One reason for this result might be that an unsupported pixel format was fed into this algorithm. The log-file will provide additional information then.

iprSkipped 

This algorithm has NOT been applied because of a lack of processing time.

In most cases the acquisition frame rate(thus the frame rate generated on the device) was higher than the processing frame rate the host can handle and the user has explicitly configured the image processing mode to skip images then.

iprNotApplicable 

This algorithm has NOT been applied because it was not applicable.

This result will be reported whenever a buffer was fed into a filter that was not applicable. An example for such a situation would be a JPEG image that has been fed into a de-Bayer algorithm.

Since
2.22.1

◆ TImageRequestControlMode

Defines the behaviour of an mvIMPACT::acquire::ImageRequestControl.

Enumerator
ircmManual 

The standard mode for image requests.

In this mode one image will be captured from the hardware for each request that is send to the device driver. The image will be taken with respect to the current parameters as defined in the setting selected in the corresponding image request control.

ircmLive 

Reserved. Currently not implemented.

ircmCounting 

Reserved. Currently not implemented.

ircmTrial 

In this mode no 'real' image will be captured, but the whole processing chain will be traversed once.

This mode can be used either to find out what the image format and parameters after an image capture would be with the current settings or to prepare the hardware before starting the first image acquisition to save time when real image data is processed.

When requesting an image in this mode, the corresponding wait function will return a complete request object with pixel format, dimensions and image buffer that contains some dummy data.

ircmUpdateBufferLayout 

In this mode no 'real' image will be captured, but the whole processing chain will be traversed once.

This mode can be used either to find out what the image format and parameters after an image capture would be with the current settings or to prepare the hardware before starting the first image acquisition to save time when real image data is processed.

In this mode, no wait function must be called. When the image request function has returned successfully, the current destination buffer layout will be available as part of the general information properties.

◆ TImageRequestParam

Defines valid image request parameters.

Some functions accept this type as the input for certain parameter related functions such as obtaining a string representation of the parameter specified.

Enumerator
irpPixelFormat 

The pixel format of an image request buffer.

irpResult 

The Result associated with an image request.

irpState 

The current state of an image request.

irpCameraOutputUsed 

The camera output used to transmit the image from the imaging device to the capture device.

◆ TImpactBufferFlag

Flags to define the way an mvIMPACT buffer is created and handled.

Enumerator
ibfNone 

A dummy constant to state that none of the flags shall be specified.

This flag can be used instead of writing code like this: TImpactBufferFlag(0) or static_cast<TImpactBufferFlag>(0).

ibfUseRequestMemory 

If set no new memory will be allocated for the creation of the mvIMPACT buffer.

This way of creating the images is fast, but modifying the image data with an image processing function will always modify the image data associated with the underlying request object.

Note
Once the underlying request object has been unlocked, working with the image is no longer save when this flag was set during creation of the mvIMPACT buffer, as the memory might be freed by the driver. If you want to keep the created image do NOT specify this flag during creation.
Whenever a new image is acquired from a device the device might be using the memory already associated with another image thus you might end up with to IMPACT images that internally reference the same buffer. However a large DMA memory will (at least twice the size of one image) will allow to work with a double buffering scheme.
ibfRecycleBufHandle 

If an existing IPL_BUFHANDLE is passed to a function it will try to copy data in this buffer instead of freeing it.

This flag can be used to allow the continuous usage of the same mvIMPACT buffer. If this flag is NOT specified whenever a valid mvIMPACT buffer handle is passed to a function accepting this type of flags it might free the existing buffer and create a new one.

If this flag is specified and the new buffer doesn't match the existing one in terms of the number of bands, size, etc. the function will fail and return an error code. Thus this flag can be used to optimize performance if the buffer layout will remain constant during application runtime.

◆ TInterfaceEnumerationBehaviour

Defines the enumeration behaviour of a certain interface of a third party GenTL producer.

Since
2.34.0
Enumerator
iebNotConfigured 

The interface will enumerate devices or not according to the general enumeration behavior of this interface type(according to EnumerateEnable setting).

iebForceIgnore 

The interface will not enumerate devices, regardless of the general enumeration behavior of this interface type(overrides EnumerateEnable setting).

iebForceEnumerate 

The interface will forcefully enumerate devices, regardless of the general enumeration behavior of this interface type(overrides EnumerateEnable setting).

◆ TLibraryQuery

Defines valid libraries to query information from.

Enumerator
lqDeviceManager 

Specifies the mvDeviceManager library.

lqPropHandling 

Specifies the mvPropHandling library.

◆ TLUTGammaMode

Defines valid LUT(LookUp Table) gamma modes.

Enumerator
LUTgmStandard 

Default gamma mode.

Maps an image by applying intensity transformation with gamma correction to the complete intensity range of the LUT.

LUTgmLinearStart 

Maps an image by applying a linear interpolation in the lower intensity range of the LUT and an intensity transformation with gamma correction to the upper intensity range of the LUT.

◆ TLUTImplementation

Defines valid LUT(LookUp Table) implementations.

Enumerator
LUTiHardware 

The mapping of the image data will be done in hardware.

When set to 'Hardware' the LUT operation will NOT introduce additional CPU load. This feature will no be available for every device.

LUTiSoftware 

The mapping of the image data will be done with an optimized software algorithm.

◆ TLUTInterpolationMode

Defines valid LUT(LookUp Table) interpolation modes.

Enumerator
LUTimThreshold 

Maps an image by applying intensity transformation based on a set of given threshold values.

LUTimLinear 

Maps an image by applying intensity transformation with linear interpolation.

LUTimCubic 

Maps an image by applying intensity transformation with cubic interpolation.

◆ TLUTMapping

Defines valid LUT(LookUp Table) mapping modes.

Enumerator
LUTm8To8 

8 bit input data will be mapped to 8 bit output data.

LUTm10To8 

10 bit input data will be mapped to 8 bit output data.

LUTm10To10 

10 bit input data will be mapped to 10 bit output data.

LUTm12To10 

12 bit input data will be mapped to 10 bit output data.

LUTm12To12 

12 bit input data will be mapped to 12 bit output data.

LUTm14To14 

14 bit input data will be mapped to 14 bit output data.

Since
2.0.2
LUTm16To16 

16 bit input data will be mapped to 16 bit output data.

Since
2.0.2

◆ TLUTMode

enum TLUTMode

Defines valid LUT(LookUp Table) modes.

Enumerator
LUTmInterpolated 

Maps an image by applying interpolated intensity transformation between a set of given sampling points.

LUTmGamma 

Maps an image by applying intensity transformation with gamma correction.

Since the human eye perceives light similar to a logarithm of real light intensity it's characteristic curve is non-linear. It follows the rule of (intensity ^ gamma) with a gamma value between 0.3-0.5. To provide as much useful information as possible, the image is converted from 12-bit acquired by the sensor to 8-bit utilizing this characteristic curve. The result is a linearized image optimized for the human eye's non-linear behavior which allows to perceive as much intensity differences as possible.

Conversion from 12- to 8-bit utilizing the gamma function
LUTmDirect 

Maps an image by applying intensity transformation.

◆ TMemoryManagerMode

Defines valid modes to operate the memory manager in.

Enumerator
mmmAuto 

Automatic mode.

In this mode the DMA memory is only used as intermediate buffer. The user has no direct access to it instead he get always a copy of the image that resides on the heap. Internally the DMA memory is organized as ring buffer. It decouples the autonomous grabbing of the board from the application. The size of the memory should be big enough to hold as many images as requests are used in the application.

mmmPool 

Pool Mode.

This mode allows direct access to the DMA memory. So its not necessary for the driver to make copies of the images. This improves the performance of the system. But there is one disadvantage: The partitioning of the DMA memory is fixed and has to be done by the user. The block size must be set to the image size in bytes. Additional the block count must be set. Before these parameters can be changed it must be sure that all ImageBuffers are returned and the grabber is stopped.

◆ TMemoryManagerPoolMode

Defines the pool mode of memory manager.

Enumerator
mmpmOff 

Dont use Pool.

mmpmFixed 

Use Pool in Manual Mode.

mmpmAuto 

Use Pool in Automatic Mode.

◆ TMirrorMode

Defines valid mirror modes.

These enumeration values may be 'ored' together.

Enumerator
mmOff 

No Mirroring.

mmTopDown 

The resulting image will be flipped around a horizontal axis.

mmLeftRight 

The resulting image will be flipped around a vertical axis.

mmTopDownAndLeftRight 

The resulting image will be both around a horizontal and vertical axis.

◆ TMirrorOperationMode

Defines valid mirror operation modes.

Enumerator
momGlobal 

There will be a single mode option only and this mode will be applied to all channels of the image.

momChannelBased 

The mirror mode can be selected for differently for each channel of the image.

◆ TPolarizedDataExtractionInterpolationMode

Defines valid modes for the interpolation mode of polarization data extraction filters.

Since
2.29.0
Enumerator
primOff 

No interpolation.

The resulting image therefore will have the same amount of pixels for horizontal or vertical polarization data extraction modes or a reduced number of pixels for all other modes.

Since
2.29.0
primLinear 

Linear interpolation.

The resulting image therefore will have either 4 times the number of pixels for horizontal or vertical polarization data extraction modes or the same dimensions as the input image for single extraction mode. The additional pixel data will be generated using linear interpolation algorithm

Since
2.29.0

◆ TPolarizedDataExtractionMode

Defines valid modes for polarization data extraction filters.

Since
2.29.0
Enumerator
prmVertical 

The pixels will be re-arranged one after the other thus the resulting image will have a width of 'input image width / 2' and a height of 'input image height * 2'.

The resulting image will consist of several small images sitting on top of each other. The first image will contain all the upper left pixels from each extraction ROI, the last image all the lower right pixels. The images in between will be extracted line by line and then row by row.

Since
2.29.0
prmHorizontal 

The pixels will be re-arranged one after the other thus the resulting image will have a width of 'input image width * 2' and a height of 'input image height / 2'.

The resulting image will consist of several small images sitting next each other. The first image will contain all the upper left pixels from each extraction ROI, the last image all the lower right pixels. The images in between will be extracted line by line and then row by row.

Since
2.29.0
prmExtractSingle 

The pixel selected by 'PolarizedDataExtractionChannelIndex' will be extracted and forwarded from each region defined by '2 * 2'.

The resulting image therefore will have a width equal to 'input image width / 2' and a height equal to 'input image height / 2'

Since
2.29.0
prmMinimumValue 

The pixel with the minimum value will be extracted and forwarded from each region defined by '2 * 2'.

The resulting image therefore will have a width equal to 'input image width / 2' and a height equal to 'input image height / 2'

Since
2.29.0
prmMeanValue 

The mean value of all pixels whose value ranges from 'PolarizedDataExtractionLowerLimit' to 'PolarizedDataExtractionUpperLimit' will be calculated within each region defined by '2 * 2' in the source image and will be forwarded as a single new pixel in the destination image.

The resulting image therefore will have a width equal to 'input image width / 2' and a height equal to 'input image height / 2'

Since
2.29.0
prm2By2 

The pixels will be re-arranged in a way the image keeps its original dimension but each polarization angle will afterwards occupy a certain section in the image.

The upper left quarter of the resulting image will contain all the upper left pixels from each 2 by 2 pixel region etc.

Since
2.29.1
prmExtractAngle 

The angle of the maximum polarization for every '2 * 2' region in the image will be calculated and the resulting value will then be mapped to the value range of the source pixel format.

The resulting image therefore will have a width equal to 'input image width / 2' and a height equal to 'input image height / 2'. From each 2 by 2 region (thus 4 input values) a single output value will be calculated and placed into the resulting image. In this mode the output pixel format will be the same as the input pixel format and the resulting value will be mapped to this pixel formats value range thus the maximum angle (180 degree) will correspond the maximum pixel value in this format (e.g. 1023 for mvIMPACT::acquire::ibpfMono10).

The angle of the maximum polarization is calculated based the formula:

\[\Theta = \frac{1}{2}*atan\left (\left ( P45-P135 \right ); \left (P0 - P90\right )\right ) \]

Attention
Pixels which are saturated or which don't show a signal at all will cause incorrect polarization data. This happens as a result of wrong relations between the different polarization directions which causes wrong values for the different stokes parameters resulting in incorrect pixel data. Different exposure settings might improve the result.
Since
2.38.0
prmExtractDegree 

The degree of the polarization for every '2 * 2' region in the image will be calculated and the resulting value will then be mapped to the value range of the source pixel format.

The resulting image therefore will have a width equal to 'input image width / 2' and a height equal to 'input image height / 2'. From each 2 by 2 region (thus 4 input values) a single output value will be calculated and placed into the resulting image. In this mode the output pixel format will be the same as the input pixel format and the resulting value will be mapped to this pixel formats value range thus the maximum polarization will correspond the maximum pixel value in this format (e.g. 1023 for mvIMPACT::acquire::ibpfMono10).

The calculation of the degree of the maximum polarization is based the formula:

\[\Pi = \frac{\sqrt{\left(P0-P90\right)^{2}+\left(P45-P135\right)^{2}}}{\left(P0+P90\right)}\]

Attention
Pixels which are saturated or which don't show a signal at all will cause incorrect polarization data. This happens as a result of wrong relations between the different polarization directions which causes wrong values for the different stokes parameters resulting in incorrect pixel data. Different exposure settings might improve the result.
Since
2.38.0
prmPseudoColorRepresentation 

The angle of the maximum polarization and the degree of the polarization for every '2 * 2' region in the image will be calculated and the resulting value will then be mapped to the value range of and 8-bit HSL image.

The angle and the degree are calculated as described in mvIMPACT::acquire::prmExtractDegree and mvIMPACT::acquire::prmExtractAngle mode. Afterwards the angle is used as hue and the degree is used as saturation value in the HSL color representation and converted to RGB color representation.

The resulting image therefore will have a width equal to 'input image width / 2' and a height equal to 'input image height / 2'. From each 2 by 2 region (thus 4 input values) 2 output values will be calculated and placed into the resulting temporary HSL image. Afterwards this HSL image will transformed back to RGB to generate a pseudo-color image in mvIMPACT::acquire::ibpfRGB888Planar format.

Attention
Pixels which are saturated or which don't show a signal at all will cause incorrect polarization data. This happens as a result of wrong relations between the different polarization directions which causes wrong values for the different stokes parameters resulting in incorrect pixel data. Different exposure settings might improve the result.
Since
2.38.0

◆ TPropertyLimits

Defines valid limits which can be queried for a mvIMPACT::acquire::Property object.

Enumerator
plMaxValue 

Set/Get the maximum value for this mvIMPACT::acquire::Property.

Pass this as the index to set or get the maximum number of values this property can store with a call to the mvIMPACT::acquire::Property object's corresponding read or write method.

plMinValue 

Set/Get the minimum value for this mvIMPACT::acquire::Property.

Pass this as the index to set or get the maximum number of values this property can store with a call to the mvIMPACT::acquire::Property object's corresponding read or write method.

plStepWidth 

Set/Get the step width value for this mvIMPACT::acquire::Property.

Pass this as the index to set or get the maximum number of values this property can store with a call to the mvIMPACT::acquire::Property object's corresponding read or write method.

◆ TPROPHANDLING_ERROR

Error codes of the module handling everything related to properties.

Enumerator
PROPHANDLING_NO_ERROR 

The operation has been executed successfully.

[0]

PROPHANDLING_NOT_A_LIST 

This component is not a list.

A list operation for this component has been called but this component does not reference a list.


[-2000]

PROPHANDLING_NOT_A_PROPERTY 

This component is not a property.

A property operation for this component has been called but this component does not reference a property.


[-2001]

PROPHANDLING_NOT_A_METHOD 

This component is not a method.

A method operation for this component has been called but this component does not reference a method.


[-2002]

PROPHANDLING_NO_READ_RIGHTS 

The caller has no read rights for this component.

It has been tried to read data from this component, but the caller has no read rights for this component.


[-2003]

PROPHANDLING_NO_WRITE_RIGHTS 

The caller has no write rights for this component.

It has been tried to modify data of this component, but the caller has no write rights for this component.


[-2004]

PROPHANDLING_NO_MODIFY_SIZE_RIGHTS 

The caller can't modify the size of this component.

It has been tried to modify the size of this list or the number of values stored by a property, but the caller doesn't have the required right to do this.

This error will also be reported if the user tried to increase the number of values handled by a property above the maximum number of values it can handle. Therefore before resizing a property check if the new size might exceeds this maximum value by calling the appropriate function.


[-2005]

PROPHANDLING_INCOMPATIBLE_COMPONENTS 

The two involved components are not compatible.

An operation requiring two compatible components has been called with two components, which are not compatible.


[-2006]

PROPHANDLING_UNSUPPORTED_PARAMETER 

One or more of the specified parameters are not supported by the function.

This error might also be generated if a certain feature is not available on the current platform.


[-2008]

PROPHANDLING_SIZE_MISMATCH 

Different sized value buffers have been passed.

While trying to read value pairs the caller passed two different sized value buffers to a function while one is too small to hold all the information.


[-2009]

PROPHANDLING_IMPLEMENTATION_MISSING 

A feature that is not implemented so far has been requested.

The caller requested a feature, that hasn't been implemented so far. This error code is only provided for compatibility and will be set in very rare cases only.


[-2010]

PROPHANDLING_ACCESSTOKEN_CREATION_FAILED 

An access token object couldn't be created.

This can either happen, because the caller has not the rights required to create an access token or because the system runs very low on memory.

Deprecated:
This error code currently is not used anywhere within this framework. It might be removed in a future version.


[-2011]

PROPHANDLING_INVALID_PROP_VALUE 

It has been tried to assign an invalid value to a property.

This can either happen if the value lies above or below the min. or max. value for a property or when it has been tried to write a value to a property, which is not in the properties translation dictionary (if it defines one).

To find out, which values are allowed for the property in question the user should

• Check if the property defines a translation dictionary.

• Check the allowed values within a translation dictionary if one is defined.

• Check the min and max value for properties, that define limits.


[-2012]

PROPHANDLING_PROP_TRANSLATION_TABLE_CORRUPTED 

The properties translation table has been corrupted.

The properties translation table has been corrupted for an unknown reason and can't be used anymore.


[-2013]

PROPHANDLING_PROP_VAL_ID_OUT_OF_BOUNDS 

Invalid value index.

The caller tried to read a value from an invalid index from a property. Most properties store one value only, thus the only valid positive value index will be 0 (some negative index values are reserved for special values like e.g. the min/max value of a property). However some properties might store more than one value, thus the max. allowed index might be higher. The highest index allowed will always be the value count of a property minus one for properties with the mvIMPACT::acquire::cfFixedSize flag set. Other properties will automatically adjust the size once the user writes to an index out of bounds.


[-2014]

PROPHANDLING_PROP_TRANSLATION_TABLE_NOT_DEFINED 

This property doesn't define a translation table.

The caller tried to modify a translation table, that hasn't been defined for this property.


[-2015]

PROPHANDLING_INVALID_PROP_VALUE_TYPE 

An invalid value has been passed to the property.

Although properties are quite tolerant regarding the allowed assignment for them some value types can't be used to write all properties. As an example assigning a float value to an integer property would result in this error.

Another reason for this error might be when a user tried to access e.g. a float property with functions meant to be used for int properties.


[-2016]

PROPHANDLING_PROP_VAL_TOO_LARGE 

A too large value has been passed.

One or more of the values the caller tried to write to the property are larger than the max. allowed value for this property.


[-2017]

PROPHANDLING_PROP_VAL_TOO_SMALL 

A too small value has been passed.

One or more of the values the caller tried to write to the property are smaller than the min. allowed value for this property.


[-2018]

PROPHANDLING_COMPONENT_NOT_FOUND 

The specified component could not be found.


[-2019]

PROPHANDLING_LIST_ID_INVALID 

An invalid list has been referenced.


[-2020]

PROPHANDLING_COMPONENT_ID_INVALID 

An invalid component within a list has been referenced.


[-2021]

PROPHANDLING_LIST_ENTRY_OCCUPIED 

The specified list index is occupied.

During the creation of a new component the caller tried the insert the newly created component into a list at a position already used to store another component.


[-2022]

PROPHANDLING_COMPONENT_HAS_OWNER_ALREADY 

The specified component already has an owner.

The caller tried to assign an owner to a component that already has an owner. An owner once defined can't be modified anymore.


[-2023]

PROPHANDLING_COMPONENT_ALREADY_REGISTERED 

It has been tried to register the same component at twice in the same list.


[-2024]

PROPHANDLING_LIST_CANT_ACCESS_DATA 

The desired data can't be accessed or found.

During loading or saving data this error can occur e.g. if it has been tried to import a setting from a location where the desired setting couldn't be found. Another reason for this error might be that the current user is not allowed to perform a certain operation on the desired data (e.g. a user tries to delete a setting that is stored with global scope but does not have elevated access rights).


[-2025]

PROPHANDLING_METHOD_PTR_INVALID 

The function pointer of the referenced method object is invalid.


[-2026]

PROPHANDLING_METHOD_INVALID_PARAM_LIST 

A method object has an invalid parameter list.


[-2027]

PROPHANDLING_SWIG_ERROR 

This indicates an internal error occurred within the SWIG generated wrapper code, when working under Python.


[-2028]

PROPHANDLING_INVALID_INPUT_PARAMETER 

A invalid input parameter has been passed to a function of this module.

In most cases this might be a unassigned pointer, where a valid pointer to a user defined storage location was expected.


[-2029]

PROPHANDLING_COMPONENT_NO_CALLBACK_REGISTERED 

The user tried to modify a registered callback, but no callback has been registered for this component.


[-2030]

PROPHANDLING_INPUT_BUFFER_TOO_SMALL 

The user tried to read data into a user supplied storage location, but the buffer was too small to accommodate the result.


[-2031]

PROPHANDLING_WRONG_PARAM_COUNT 

The number of parameters is incorrect.

This error might occur if the user called a function with a variable number of input or output parameters and the number of parameters passed to the function does not match the number of required parameters.


[-2032]

PROPHANDLING_UNSUPPORTED_OPERATION 

The user tried to execute an operation, which is not supported by the component he is referring to.


[-2033]

PROPHANDLING_CANT_SERIALIZE_DATA 

The user tried to save(serialize) a property list without having the right to do this.


[-2034]

PROPHANDLING_INVALID_FILE_CONTENT 

The user tried to use a file to update or create a component list, that does not contain valid data for this operation.

This e.g. might happen, if the file does not contain valid XML data or XML data that is not well formed.


[-2035]

PROPHANDLING_CANT_ALLOCATE_LIST 

This error will occur when the modules internal representation of the tree structure does not allow the allocation of a new list.

In this case either new list can't be allocated. The only way to solve this problem is to delete another list.


[-2036]

PROPHANDLING_CANT_REGISTER_COMPONENT 

The referenced list has no space left to register this component at the desired position.

There might however be an empty space within the list where this element could be registered, but no more components can be registered at the end of this list.


[-2037]

PROPHANDLING_PROP_VALIDATION_FAILED 

The user tried to assign a value to a property, that is invalid.

This will result in a detailed error message in the log-file. This error might arise e.g. when a string property doesn't allow the string to contain numbers. In this case trying to set the properties value to 'blabla7bla' would cause this error.


[-2038]

PROPHANDLING_LAST_VALID_ERROR_CODE 

Defines the last valid error code value for the property module.


[-2099]

◆ TRequestImageMemoryMode

Defines valid image modes for request objects.

Enumerator
rimmAuto 

Automatic mode.

In this mode the driver will decide what kind of memory will be used, when it will be allocated and when it will be freed.

rimmUser 

User supplied memory mode.

A request in this mode can capture data directly into a user supplied buffer.

The user can assign a buffer to each request that has been set into this mode. However some devices require the capture memory to be aligned thus then the buffer supplied by the user must be aligned to the requirements of the driver as well. To find out, which alignment is needed, the property captureBufferAlignment must be queried.

◆ 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
rrOK 

This image request has been processed successfully.

rrTimeout 

This image request resulted in a timeout. No image has been captured during the allowed period of time.

rrError 

An error occurred during the processing of this request.

mvBlueFOX specific: This error typically results in some kind of USB transmission problem. The log-file will contain more information in that case.

rrRequestAborted 

This request has been aborted either because there are no free internal buffers or the user itself caused this abort e.g. by clearing the request queue.

rrFrameIncomplete 

An incomplete frame was transferred.

This can have several reasons, however the one most likely is that the transfer channel couldn't cope with the amount of data that was transmitted resulting in parts of the frame or in the worst case the complete frame being lost.

This e.g. might happen if several network devices transmit at the same time or a single device (e.g. connected to a PCI bus transfers more data than the PCI bus can pass to the receiving end until a temporary buffer on the device runs full. The log output will contain additional information.

If the information is available the property 'MissingData_pc' belonging to that request will contain information about the amount of data missing. Also some of the statistical properties will provide hints about how much data is lost. E.g. the properties 'MissingPacktesRecovered', 'RetransmitCount' and 'MissingDataAverage_pc' might be of interest here. Please note that not every property is supported by every device.

rrDeviceAccessLost 

The access to the device has been lost.

In this case no further access to the device will succeed. Only closing and re-opening the device will fix this problem. There can be numerous reasons for this error to occur, however the most likely one is that a device, that a timeout register inside the device, that needs to be refreshed constantly by the driver hasn't been refreshed during the timeout period. In this case the device will disconnect itself from the driver. This e.g. can happen if a network device is used and the application is operated in debug mode. For debugging the corresponding timeout register must be set to an appropriate value.

rrInconsistentBufferContent 

A complete buffer has been delivered, but it did fail to pass the internal validation check.

This e.g. might happen with drivers that transmit buffers that contain more than a pure block of pixel data. Examples for this might be run-length encoded images, or buffers with additional information somewhere in the buffer that will be interpreted by the device driver. This error is most likely a result of a device that doesn't transfer data in the requested format. The log output will contain additional information.

rrFrameCorrupt 

The device has reported that an image acquisition did fail on the device side thus BEFORE the data transfer.

This e.g. might happen if a device is running low on local memory or because of some other problem detected on the device itself. This result status is just meant for information. The associated buffer will not contain valid image data.

rrUnprocessibleRequest 

This request is not processible.

If this flag (the MSB) is set this either indicates that the current input parameters can't be used to capture an image (in that case the result will not be the MSB alone) or that an internal error occurred during the process of this request.

rrNoBufferAvailable 

No free buffer available to process this request.

To get more memory either some old requests should be unlocked or the size of the DMA memory (frame grabbers only) could be increased using the tools provided.

rrNotEnoughMemory 

There is not enough memory available to the driver to process the current image request.

To get more memory either some old requests should be unlocked or the size of the DMA memory (frame grabbers only) could be increased using the tools provided.

Another possibility might be, that the process currently hosting the application cannot map all the capture memory requested by the application. In this case adding more memory to the system might solve the problem. Please note that when running on a 32 bit system no more than 2 GB of RAM can be used by a single process, thus applications demanding a lot of memory might still not run then. In this case only reducing the number of request buffers will help.

rrCameraNotSupported 

The current camera description is not supported by the capture device.

This error code currently is relevant for frame grabbers only and might occur e.g. when selecting a MEDIUM CameraLink® camera description for a grabber, that only supports BASE cameras.

rrDataAcquisitionNotSupported 

The device does not support capturing data in the current configuration.

This error code will occur if a request has been sent to a device that does not support the acquisition of data. This can e.g. be the case

  • for GEV or U3V devices that do NOT support at least 1 streaming channel
  • for U3V devices that have been opened with mvIMPACT::acquire::damRead access
Since
2.5.0

◆ TRequestState

Defines the current state of this mvIMPACT::acquire::Request.

Enumerator
rsIdle 

This mvIMPACT::acquire::Request is currently unused.

rsWaiting 

This mvIMPACT::acquire::Request has been sent into the drivers image request queue and currently awaits processing.

rsCapturing 

This mvIMPACT::acquire::Request is currently being processed.

rsReady 

This mvIMPACT::acquire::Request has been processed.

The user is now responsible for this request. Before this mvIMPACT::acquire::Request is not unlocked again it can't be used by the driver. A mvIMPACT::acquire::Request in this state can safely be processed by the user. Its data will remain valid until either the mvIMPACT::acquire::Request is unlocked by the user or the device is closed.

rsBeingConfigured 

This mvIMPACT::acquire::Request is currently in configuration mode.

Within this mode certain properties of the request object will become writeable, which e.g. will allow the user to pass a capture buffer to the request object.

◆ TScalerInterpolationMode

Defines valid scaler interpolation modes.

Enumerator
simNearestNeighbor 

Nearest neighbor interpolation (default).

simLinear 

Linear interpolation.

simCubic 

Cubic interpolation.

◆ TScalerMode

Defines valid scaler modes.

Enumerator
smOff 

The scaler is switched off (default).

smOn 

The scaler is switched on.

◆ TScope

enum TScope

Defines the scope for data import/export operations.

Enumerator
sGlobal 

Save the setting as global as possible.

sUser 

Save the setting in a user specific location.

◆ TStorageFlag

Defines the way component lists are imported and exported.

Component lists can be imported and exported from/to XML files and (under Windows©) from/into the Registry. These flags define how this is done.

Enumerator
sfDefault 

A dummy flag to specify the default behaviour.

Store/load operations will done in XML format in this case.

sfNative 

Stores/loads the setting in/from a platform dependent location.

Under Windows© the Registry will be used to as a platform dependent location, while under other platforms an XML file will be processed in the path specified as the settings name.

Note
Please note, that using this flag will introduce platform dependency. E.g. specifying this flag under Linux will process XML data, while under Windows© the Registry will be used. This is why A call to a load function with this flag with the corresponding XML file in the applications directory might succeed under Linux while it fails under Windows©.
sfRaw 

Stores/loads the setting in raw mode.

Note
Under Windows© this mode only works in connection with the mvIMPACT::acquire::sfNative flag. In that case an arbitrary hive from the registry can be used to create a tree of lists and properties. This only makes sense for very special applications and therefore is not needed to write applications, that load and store current settings.
sfVolatile 

Stores lists volatile.

under Windows© when the mvIMPACT::acquire::sfNative flag is set this will store the component list as a volatile key in the Registry. This means that the data will remain in the Registry until the system is shut down.

sfProcessPropTranslationDict 

If set properties translation dictionaries will be processed for this import/export operation.

This option forces the function to process the translation dictionaries, which might be assigned to properties.

sfCreateMissingEntries 

If set ALL entries in the store data will be created.

When loading a setting not only the current lists data will be updated, but also properties, lists or data, which is found in the storage location but not in the setting to update will be added to the setting as well.

sfProcessReadOnlyComponents 

If set read-only components will be processed for this import/export operation.

When importing, exporting or updating a component list components with the mvIMPACT::acquire::cfWriteAccess not set will be ignored.

sfIgnorePropData 

If set data for properties will no be updated.

If this flag is set the values stored by the property will be ignored for this import/export operation.

Note
This flag is ignored, if mvIMPACT::acquire::sfNative is specified.
sfProcessDocString 

If set the documentation string will be processed.

If this flag is set the documentation string will be processed for this import/export operation.

Note
This flag is ignored, if mvIMPACT::acquire::sfNative is specified.
sfProcessPropConstantsDict 

If set the defined constants for properties will be processed.

If this flag is set the defined constants for properties will be processed for this import/export operation.

sfProcessInheritance 

If set the lists inheritance relationship will be processed.

If this flag is set the inheritance relationship between lists will be processed for the current import/export operation.

Note
Limitations:
  • derived lists must appear in a list after the parent list. So if a list is derived from another list, it has to be registered with a higher index either in the same list as the parent or in a list with a higher index then the list holding the parent in a top level list.

    Example for a legal structure:
    A
    |-B
    | |-parent
    | |-child
    |-C
    | |-child
    |-child


    Example for illegal structures:
    A
    |-child
    |-parent
    or
    A
    |-B
    | |-child
    |-parent
  • this feature is not available when mvIMPACT::acquire::sfNative is specified.
sfIgnoreBasicData 

Specifies if basic data shall be processed.

For e.g. settings it's not necessary to import/export information about the value type for properties or the size of lists etc. as this information is available internally anyway. So interface functions dealing with settings should specify this flag in any case.

sfIgnoreInvisible 

Specifies if invisible components shall be processed.

When invisible data doesn't need to be processed this flag can be specified. Invisible components do not influence the current systems behaviour.

Note
This feature is currently only supported for output operations and is ignored for input operations.
sfFile 

Stores/loads the setting in/from an XML file.

If this flag is specified the data will be imported/exported from/to an XML file.

sfProcessDisplayName 

If set the display name will be processed.

If this flag is set the display name will be processed for this import/export operation.

Note
This flag is ignored, if mvIMPACT::acquire::sfNative is specified.
sfRAM 

Stores/loads the setting in/from RAM file.

If this flag is specified the data will be imported/exported from/to RAM. Data stored this way should be freed when no longer needed to avoid a waste of memory. However when shutting down mvIMPACT Acquire completely (e.g. when unloading the mvPropHandling library from memory all memory allocated by settings stored this way will be freed automatically).

Note
This flag must not be combined with mvIMPACT::acquire::sfNative or mvIMPACT::acquire::sfFile.
Since
2.19.0
sfDontProcessDefault 

Specifies if the 'is-default' flag for components shall be ignored during import/export operations.

If this flag is set the 'is-default' flag will not be processed during this import/export operation.

Note
This flag is ignored, if mvIMPACT::acquire::sfNative is specified.
sfProcessGenICamSequencerData 

Processes GenICam sequencer set related data during a storage operation.

Note
This flag will affect devices operated in GenICam interface layout only!
Attention
Settings stored this way cannot be loaded on systems running mvIMPACT Acquire versions smaller than 2.28.0.
Since
2.28.0
sfProcessGenICamUserSetData 

Processes GenICam user set related data during a storage operation.

Note
This flag will affect devices operated in GenICam interface layout only!
Attention
Settings stored this way cannot be loaded on systems running mvIMPACT Acquire versions smaller than 2.28.0.
Since
2.28.0

◆ TStorageLocation

Defines valid storage locations for component list import, export and delete operations.

Component lists can be imported and exported from/to XML files, process RAM and (under Windows©) from/into the Registry.

Since
2.19.0
Enumerator
slNative 

Stores/loads the setting in/from a platform dependent location.

Under Windows© the Registry will be used to as a platform dependent location, while under other platforms an XML file will be processed in the path specified as the settings name.

Note
Please note, that using this mode will introduce platform dependency. E.g. specifying this mode under Linux will process XML data, while under Windows© the Registry will be used. This is why A call to a load function with this mode with the corresponding XML file in the applications directory might succeed under Linux while it fails under Windows©.
slNative_Raw 

Stores/loads the setting in/from a platform dependent location.

Under Windows© the Registry will be used to as a platform dependent location, while under other platforms an XML file will be processed in the path specified as the settings name.

Note
Please note, that using this mode will introduce platform dependency. E.g. specifying this mode under Linux will process XML data, while under Windows© the Registry will be used. This is why A call to a load function with this mode with the corresponding XML file in the applications directory might succeed under Linux while it fails under Windows©.
Under Windows© with this mode an arbitrary hive from the registry can be used to create a tree of lists and properties. This only makes sense for very special applications and therefore is not needed to write applications, that load and store current settings.
slFile 

Stores/loads the setting in/from an XML file.

Setting data will be imported/exported from/to an XML file.

slRAM 

Stores/loads the setting in/from RAM file.

Setting data will be stored in the RAM of the current process. Data stored this way should be freed when no longer needed to avoid a waste of memory. However when shutting down mvIMPACT Acquire completely (e.g. when unloading the mvPropHandling library from memory all memory allocated by settings stored this way will be freed automatically).

◆ 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
udarRead 

The user has read rights for this entry.

udarWrite 

The user has principle write rights for this entry.

If mvIMPACT::acquire::udarPassword is not set for this entry or the corresponding password has been set correctly, the user can modify the corresponding entry.

udarRW 

Just combines mvIMPACT::acquire::udarRead and mvIMPACT::acquire::udarWrite.

udarPassword 

A password is needed to modify this entry.

Even if mvIMPACT::acquire::udarWrite is specified the user can only modify this entry if the correct password has been set.

udarFull 

Combines all other flags.

◆ TUserDataReconnectBehaviour

Defined valid values for the behaviour of the user data when a device has been disconnected and reconnected within a running process.

Enumerator
udrbKeepCachedData 

Keep the data currently buffered in the properties describing the user data.

When the user data has been modified on another machine this will result in a loss of that data once this buffered data is written back to the devices non-volatile memory.

udrbUpdateFromDeviceData 

Updates the properties describing the user data with the fresh data as read from the devices non-volatile memory.

This might result in the loss of data that has been edited but NOT written to the devices non-volatile memory if this data differs from the current data stored in the devices non-volatile memory.

◆ TValueType

enum TValueType

Allowed values types for property objects.

Enumerator
vtInt 

Defines a property for 32 bit integer types.

vtFloat 

Defines a property for float types.

vtPtr 

Defines a property for pointer types.

vtString 

Defines a property for strings.

vtInt64 

Defines a property for 64 bit integer types.

◆ TVideoCodec

Defines valid video codecs that might be supported by the underlying video compression engine.

Enumerator
vcMPEG2 

MPEG2.

Recommend file extension for this codec: .m2v

Supported input pixel formats for this video codec:

vcH264 

H264.

Recommend file extension for this codec: .mp4

Supported input pixel formats for this video codec:

vcH265 

H265.

Recommend file extension for this codec: .mp4

Supported input pixel formats for this video codec:

◆ TVideoStandard

Defines valid video standards that might be supported by a video capture device.

Enumerator
vsCCIR 

CCIR video signal: Grey, 50 fields per second, 625 lines.

vsRS170 

RS 170 video signal: Grey, 60 fields per second, 525 lines.

vsPALBGH 

PAL video signal: Color, 50 fields per second, 625 lines.

vsNTSCM 

NTSC video signal: Color, 60 fields per second, 525 lines.

vsSDI480i 

SDI video signal: 60 fields per second, 480 lines, interlaced.

vsSDI576i 

SDI video signal: 50 fields per second, 576 lines, interlaced.

vsSDI720p 

SDI video signal: Different frame rates, 720 lines, progressive.

vsSDI1080i 

SDI video signal: Different frame rates, 1080 lines, interlaced.

vsSDI1080p 

SDI video signal: Different frame rates, 1080 lines, progressive.

◆ TWhiteBalanceCalibrationMode

Defines valid white balance calibration modes.

Enumerator
wbcmOff 

Do not perform calibration, current values will be used.

wbcmNextFrame 

Use the next image to perform the white balance calibration.

This is defined for bayer color sensors only.

wbcmContinuous 

Do a continuous white balance calibration.

◆ TWhiteBalanceParameter

Defines valid parameter sets selectable via the WhiteBalance property.

Enumerator
wbpTungsten 

A set of constant parameters optimised for scenes illuminated by tungsten light sources.

wbpHalogen 

A set of constant parameters optimised for scenes illuminated by halogen light sources.

wbpFluorescent 

A set of constant parameters optimised for scenes illuminated by fluorescent light sources.

wbpDayLight 

A set of constant parameters optimised for scenes illuminated by day light.

wbpPhotoFlash 

A set of constant parameters optimised for scenes illuminated by photo flash light sources.

wbpBlueSky 

A set of constant parameters optimised for scenes illuminated by day light and perfect weather.

wbpUser1 

A parameter set which can be modified by the user.

wbpUser2 

A parameter set which can be modified by the user.

wbpUser3 

A parameter set which can be modified by the user.

wbpUser4 

A parameter set which can be modified by the user.

Variable Documentation

◆ ATTR_PACK

struct mvIMPACT::acquire::EventData ATTR_PACK