Linear Memory Representations

<< Click to Display Table of Contents >>

Navigation:  Image Manager > CVB Technology > Common Image Model >

Linear Memory Representations

 

Linear memory representations

Problem of representation of the image model in memory raises the question of compatibility.
To make the software useful it has to be compatible with existing memory representations for restricted types of images, at least DIBs (because we work under Windows) and various image acquisition devices.
If we disregard 1-bit and 4-bit DIBs we are still left with gray scale and color DIBs, which may or may not be upside down.
The situation is worse when we look at image acquisition device with conceivable combinations of interlaced, noninterlaced, 8-10-12-24-32 bit pixels, various schemes for color representations or possibly separate memory pages for the different color planes.

 

One solution is to fix some standard memory representation (e.g. DIB) and copy/translate an incoming image to this format whenever necessary.
We reject this idea because it introduces redundant information involving additional memory and computation time (the argument that relative to processing, the copying time is negligible on modern systems is not acceptable, what if we just want to monitor the gray values of a few pixels ?).

 

Instead, we propose to exploit the fact that most (flat) memory representations of image planes have a property of linearity:

If the value for pixel location (X, Y) resides at address M(X, Y) then

M(X, Y)  = M(0, 0) + X*DeltaX + Y*DeltaY

for some DeltaX, DeltaY.

These, together with the base M(0, 0) can be regarded as properties of the image plane in question.

 

By communicating DeltaX and DeltaY together with M(0, 0) and some fundamental base offset for every image plane, we could augment the image model above with a description of how the pixels are placed in memory.

This description would serve as a basis for a more rapid computation of the function v.

 

This is the starting point of the old MINOS driver model. Essentially the driver model replaced the idea of »image data« with »knowledge about image data«.
Rather than communicating the data itself, the driver only communicated information about the organization and location of the data.

 

The linearity formula above has three disadvantages:

First of all computation of the address (essential in computation of the function v) involves two time-consuming multiplications (at least in the case of random access).

The second problem is that linear representation, although it includes all kinds of DIBs and simple memory representations, is not sufficiently general to cover some slightly more pathological cases which occur frequently with frame grabbers. It excludes interlacing for example.

The third problem is that it determines the geometry of an image completely in terms of the underlying memory representation, however the memory representation may have undesirable properties.
Consider for example a frame grabber with non-square pixels.
We would like to be able to port an algorithm for a square pixel image acquisition device to such a device without having to make major modifications or including additional image transformations.

The current version of Common Vision Blox resolves these three problems internally.
By publishing the underlying mechanism, and simplifying and streamlining the definitions, the method can be made the basis of an image description format that is suitable for the purposes of high-speed machine vision.