|
<< Click to Display Table of Contents >> Navigation: Image Manager > CVB Technology > The Image Object |
It is important to understand that the Image Object is considerably more than simply image data.
It should be considered as a
•powerful three-dimensional object that contains a very flexible coordinate system,
•can support any number of interfaces for different processing tasks and
•can contain images with almost any format.
The images have width, height and the third dimension is depth, this third dimension can be used for colour images, stereo images, image sequences and many other image processing techniques.
The data type for each plane can be set separately and can contain data with up to 250 bits per plane, signed, unsigned, fixed or floating point.
This section contains very detailed information about the Image Object.
It is important to understand that the Common Vision Blox concept allows users full control over very powerful objects without the need for this detailed information, this information is provided primarily for tool developers who require more in-depth knowledge.
Image data can be accessed via a base address and a pixel offset, this offset information is stored in a virtual pixel access table (VPAT) which contains the offsets for a line, y, and for a pixel, x.
Every plane in an image object contains a separate VPAT and base address.
Using this powerful approach to data access, zoomed, expanded, rotated and geometrically shifted images can be created very quickly without the need to copy or manipulate data but by simply rewriting the VPAT.
In addition, the base library provides some optimised functions for accessing image data, these can be used by users who do not need background information on the structure of the image object.
The Image Object is a Microsoft compatible COM object (For further information on COM objects can be found in ”Inside OLE Second Edition” written by Kraig Brockschmidt and published by Microsoft Press).
The important aspect of the Image Object is that it is NOT a Microsoft COM object but a Microsoft COMPATIBLE COM Object, this means that no Microsoft header files or libraries and no Microsoft compilers are needed to generate an image object.
The only condition is that the compiler must be able to process object-oriented code.
The COM standard allows an object to be accessed via interfaces.
Once defined, interface functions are not allowed to be changed, however new interfaces permitting access to the actual object data are allowed to be created.
The Common Vision Blox Image Object has implemented a number of interfaces including the IImageVPA interface.
Images which have been acquired by an image acquisition device like a frame grabber are a special case within this concept, an image acquisition device driver has other interfaces in addition to the IImageVPA interface.
As an absolute minimum for a driver, the IGrabber interface must have been implemented.
This interface provides the Grab, Snap and ShowDialog functions with which images can be acquired from a camera, they are the absolute minimum for the device functionality.
Other interfaces can be attached to the image object to support special hardware features such as display, trigger or digital I/O.
The image object itself is the handle for the IImageVPA-Interface, this handle can be used to query whether other interfaces have been implemented and are available.
The result of the query is a handle for the queried interface, this handle can be used to access all the functions in that interface.
Providing an image is not reassigned and therefore the handle defines a different image object, the query for the interfaces only has to be performed once when the application starts.
One element of the Image Object is the coordinate system, image data is accessed through the coordinate system and it consists of the origin and a 2 x 2 transformation matrix. Linear transformations can be implemented using the matrix which effects all the image data accessed through the coordinate system.
The coordinate system can be used for many different functions, for example, a frame grabber delivers an image with non-square pixels, the aspect ratio can be corrected by means of the transformation matrix.
NOTE
Not every tool supports the coordinate system (CS), for example CVB Minos, CVB Edge support the CS but CVB Barcode and CVB Manto do not.
As a general rule if a tool requires a region of interest in Area Mode (X0, Y0, X1, Y1, X2, Y2) then is does support the CS, if the region of interest is required in Rectangle Mode (Top, Left, Bottom, Right) then is does not support the CS.
These examples offer 2 ways in which the driver interface can be used, there are many many possible options, these are offered as examples to stimulate the user's imagination to consider other uses.
•Consider an 8-bit image with a size of 512 x 512 pixels and a dimension of 2.
The VPAT for the first dimension is programmed in such a way that the pixels are accessed normally, the second table can be allocated in such a way that access to the image data displays a zoomed image.
If the same base address is used for the two planes the image data only has to be read into memory once, the user can then access the entire image plane or the zoomed image plane with very little processor overhead.
•Consider a 24-bit True Color image. For some tasks it is necesssary to read all three color planes into a 32-bit value with one access, other procedures however benefit from a 32-bit access to four adjacent pixels on a plane. Both of these approaches are easy with Common Vision Blox.
The number of planes is set to 4, the data type for planes 0, 1 and 2 is 8 bits, the base address of the red channel is ADDRESS and those of the green and blue channels are ADDRESS+1 and ADDRESS+2 respectively. The data type for the 4th plane is 32 bits with ADDRESS as the base address. Planes 0, 1 and 2 can thus be accessed separately with 8 bits, whereas plane 3 offers 32-bit access to a color pixel.
This driver model differs from many other driver models in commercially available software, the two main aspects are :
1.No image data is exchanged between the driver layer and user layer, only information about the position and orientation of the image data.
This has a considerable increase in speed compared with interfaces based on ReadLine or ReadRect concepts that copy data internally.
2.The interface can be extended dynamically without giving rise to compatibility problems. Existing interfaces are not allowed to be changed and if an application uses an interface named MyInterface and other interfaces are added to the driver (possibly years later), then the application can still work with the driver because MyInterface has not been changed and its address is ascertained at program runtime.
Please see the section 'Proposal for a Common Image Model' for more detailed information on the components of the Image Object.