|
|
|
DIMF FORMAT |
DIMF is the acronym for DTA IMage Format and it is the DTA's proprietary file format for images, as you can easily understand.
The decision to define a new file format, besides the hundreds of formats already present on the market was very difficult. But it was necessary since we didn't find a format allowing both a fast reading of the contents of the image and the possibility to write all the info of our interest, without any kind of limit.
To read the image/s present in the file is very easy and fast from C/C++, in fact, there is a file header of constant dimension where you can find all the basic info to read it. Logically, the file header is divided in four fundamental blocks:
HEADER
IMAGE/S
INFO
PALETTE
The blocks INFO and PALETTE can be present or not.
HEADER
All the stored info are little-endian (LSB -> MSB) and the header has a 16 bytes fixed dimension.
|
OFFSET |
FIELD |
DATA TYPE |
DATA LENGTH |
DESCRIPTION |
|
0 |
INFO |
unsigned long |
4 |
Offset of the 32 bit file (usable in "fseek") where the INFO starts. If this value is 0, there is not any info |
|
4 |
PALETTE |
unsigned long |
4 |
Offset of the 32 bit file (usable in "fseek") where the PALETTE starts. If this value is 0, there is not any PALETTE. |
|
8 |
X DIM |
short unsigned |
2 |
Horizontal dimension of the image in pixel (1-65535). |
|
10 |
Y DIM |
short unsigned |
2 |
Vertical dimension of the image in pixel (1-65535). |
|
12 |
NUM |
short unsigned |
2 |
Number of images presentsi (1-65535) |
|
14 |
TYPE |
short unsigned |
2 |
Type of data utilized in the image |
After the HEADER, the first stored image is present. To read it, first of all it is necessary to intepret the field TYPE.
ViSTA can manage 10 different image formats; thanks to this big format variety it is possible to control the memory consumption and the precision of the stored data.
|
FORMAT |
CODED |
TYPE |
MEMORY COST (bytes x pixel) |
VALUE RANGE |
|
U8 |
0x0000 |
Monochrome |
1 |
0 255 |
|
S8 |
0x0001 |
Monochrome |
1 |
-128+127 |
|
U16 |
0x0002 |
Monochrome |
2 |
0 65535 |
|
S16 |
0x0003 |
Monochrome |
2 |
-32767+32767 |
|
U32 |
0x0004 |
Monochrome |
4 |
0 4294967296 |
|
S32 |
0x0005 |
Monochrome |
4 |
-2147483647 +2147483647 |
|
F32 |
0x0006 |
Monochrome |
4 |
-3.402823466E38 +3.402823466E38 |
|
F64 |
0x0007 |
Monochrome |
8 |
-1.7E308 +1.7E308 |
|
RGB8 |
0x8000 |
Color |
3 |
0 255 |
|
RGB16 |
0x8002 |
Color |
6 |
0 65535 |
|
i64 |
0x0008 |
FFT |
16 |
-1.7E308 +1.7E308 |
The image is stored pixel rows by pixel rows. For example, a 512x512 pixels image is stored as follows:
Pixel 0,0 ... Pixel 0,511
Pixel 1,0 ... Pixel 1,511
...
Pixel 511,0 ... Pixel 511,511
In case of colour image, it is codified as follows:
Pixel RED 0,0 ... Pixel RED 0,511
Pixel GREEN 0,0 ... Pixel GREEN 0,511
Pixel BLUE 0,0 ... Pixel BLUE 0,511
Pixel RED 1,0 ... Pixel RED 1,511
Pixel GREEN 1,0 ... Pixel GREEN 1,511
Pixel BLUE 1,0 ... Pixel BLUE 1,511
...
Pixel RED 511,0 ... Pixel RED 511,511
Pixel GREEN 511,0 ... Pixel GREEN 511,511
Pixel BLUE 511,0 ... Pixel BLUE 511,511
For a 512x512 pixels monochrome image, U16 data type, in C the reading can be maden in the following way:
// fs is the file descriptor
// uMat is the pointer to the image matrix
fseek(fs, 16, 0); // Skip the file header
fread(uMat, 2, 65536, fs); // Read the image
The images are in sequence, so it is very easy to take the one you want in case of many images.
The palette is codified as a sequence of 256 32 bit words compliant with the QRgb code of the Qt; that is:
Q_EXPORT inline QRgb qRgb( int r, int g, int b )// set RGB value
{ return (0xff << 24) | ((r & 0xff) << 16) | ((g & 0xff) << 8) | (b & 0xff); }
The block relative to the info is more complex since it consists of compressed data originally codified in XML! If someone needs to interpret them, we can provide the C++ source able to codify them on request.
|
|
