|
Basic Image AlgorithmS Library
2.8.0
|
|
Basic Image AlgorithmS Library
2.8.0
|
The image class is divided in a Base class (BIAS::ImageBase) and a derived templated specialization BIAS::Image<>. In most cases you will instantiate objects of Image<PixelType>, as you know which kind of PixelType you will need, e.g. Image<unsigned char>.
The reasons for the division:
Dealing with image data:
A very important issue of the image class is to have fastest possible access to the image data and the possibility to modify the data as fast as possible. Therefore the image data is stored in a single 1D array, one row behind the other starting with the top row (most left pixel first). The fastest way to modify the data is to get the data pointer with GetImageData(), modify the pixel and increase the pointer until the end.
If random access to the pixel data is needed image.GetImageDataArray() should be used, as image.GetImageDataArray()[y] is the pointer to y-th row. image.GetImageDataArray()[y][x*ChannelCount+c] will result in the c-th channel of the pixel at image position (x,y), which is very fast for random access.
There are several functions which must only be applied to some part of the image, a so called ROI (region of interest). You can set such a ROI in an image object to tell filters and other functions only to work on that rectangular area. The upper left corner of the roi is (0,0) by default, it is also the upperleftmost pixel within the ROI, while the lower right corner is (Width, Height) by default. The lower right corner of the ROI does not lie within the ROI ! This seems unintuitive at first sight but simplifies work when dealing with expressions like SetROI(FilterMaskSize, GetWidth()-FilterMaskSize).
In order to identify an image within a sequence or when loading it several times from a disk we can assign a unique signature to each BIAS::Image, a so called UUID (universally unique identifier). We can then refer to the image itself or features of that image using the BIAS::UUID concept. In a somewhat human readable notation (string) this looks like
while internally a BIAS::UUID is stored as a 128 bit value.
The BIAS::UUID is computed from the MAC address of the network adapter (which means "spatial uniqueness") and a high resolution timestamp providing "temporal uniqueness", it is NOT related to the image content in any way. When an image does not yet have a valid ID when writing it to disk, a UUID is generated and assign to that image. However, since the generation of a unique id is an operating system call, at first each UUID object is empty by default. Only when a new id is really needed, one must manually call the GenerateUUID function to create a new valid UUID. This typically needed once for each image, while the resulting id may be assigned to thousands of objects and entities referring to that image, for which we only need the copy constructor, not the OS call.
If an image is manipulated, e.g. scaled, drawn in, ..., you should assign a new id to it, so that the manipulated image wont be confused with the original one. For that reason BIAS::ImageConvert does NOT copy the id into the converted image. Of course the concept of a UUID is not restricted to an image, you can use it to identify anything you like.
Additional information stored with each image is called a MetaDatum in the BIAS library. The mechanism provided by the BIAS::MetaData class and BIAS::Camera class should be used to handle these additional data. Meta datas are a basic component of the ImageBase class. In order to keep the dependencies of the ImageBase library small, it is not possible for the MetaData class to know about all the classes which might be stored in it. One might f.e. want to store a PMatrix as a meta datum with the image. Since the PMarix however is a memeber of the BIASGeomery library and the ImageBase library is not awary of the Geomery library, this is not possible in a straight forward way. In order to resolve this problem, only a pointer to the data (AppData::data) and the length of the expected data (AppData::length) are stored together with an identifier (AppData::tag) from the enumerator AppData::TAppData are stored in a class called AppData. This allows the storage of arbitrary data or classes while the structure of the data itself remains hidden to the Appdataclass and therfore also to the ImageBase library. Another advantage to this approach is the simplicity with which new meta data types can be introduced. All that needs to be done, is to amplify the identifier enumerator AppData::TAppData. The MetaData class itself now is derived from a vector of AppData and every ImageBase holds a pointer to a MetaData class. A number of convenient functions, like MetaData::Find, MetaData::Add and MetaData::Delete are made available by the MetaData class.
With the described aproach it is very simple to store data in a binary fassion. For simplicity, when handling AppData stored in strings, like in f.e. pgm images, the special identifier AppData::MD_USE_ASCXII exist. If this id is connected with a AppData, not the pointer to the data, but a string (AppData::sdata) and a special tag (AppData::stag) are used for storage. The tag AppData::MD_ASCII_DATA is deprecated and should not be used any longer. It will be removed in future versions of the library.
For a simple example on how to use the MetaData class in a very abstract way together with the ImageBase class see ExampleMetaData. For a more convenient way to use meta datas use our Camera class. See ?? and ExampleCamera for details.
The BIAS::Camera class is a convenient class for the work with additional information stored with each image in the BIAS::MetaData class.
In contrast to the ImageBase class, where the internal structure of the data stored in the MetaData class is not known, it is fully know in the Camera class. The Camera class now provides a convenient way of working with additional data belonging to images (f.e. PMatrix, TimeStamps, ...). Camera is derived from ImageBase (via Image<StorageType>) and all these additional classes, that can be stored in the MetaData class ar also members of the camera class. They can be easily accesed via Get and Set functions.
The two most important functions are:
See class documentation and ExampleCamera for details and example code.
gibt es 2x: Spezialisierung
The BIAS::ImageConvert classes are used to convert images between different storagetypes, such as float or unsigned char and to convert between different color models, such as Grey, RGB, or Bayer Patterns, specified in the class BIAS::ImageBase. BIAS::ImageConvert are a set of static functions which can be used without object instantiation.
The BIAS::ImageIO classes are used to read and write images to disk. If ImageMagick support is activated most common formats can be read and written (e.g. jpg, png, ppm, ...). If tiff support is activated tiff images can also be read and written. BIAS::ImageIO is a set of static functions which can be used without instantiation.
Use functions BIAS::ImageIO::Load and BIAS::ImageIO::Save to read and write images. The method to read a file is automatically chosen depending on the file ending.
The BIAS internal image format with suffix .mip can also be used to store images. It is a generic format which can hold multi channel images with all data-/storage- types and color models.
The BIAS::ImageDraw classes are used to draw points, lines, circles, rectangels and other primitives in images. It is a set of static classes to draw in images.
For image undistortion, rectification, resampling and interpolation we have BIAS::BackwardMapping as a base class. It provides functions to run over the pixel coordinates of a target image, look at the relevant (subpixel) position in the source image and compute the (interpolated) color (software implementation). Backward mapping avoids unfilled areas which occur in forward mapping, where you would run over the source image. The idea is that BIAS::BackwardMapping should handle common tasks like interpolation, border handling, anti-aliasing and all general mapping problems, so you dont have to care about that or even reinvent it for every mapping class. Simply derive your special mapping class and fill the coordinate-map function (see BIAS::HomographyMapping).
1.8.5
