1 2 Signature bfType Must always be set to 'BM' to declare that this is a .bmp-file.
3 4 FileSize bfSize Specifies the size of the file in bytes.
7 2 Reserved1 bfReserved1 Unused. Must be set to zero.
9 2 Reserved2 bfReserved2 Unused. Must be set to zero.
11 4 DataOffset bfOffBits Specifies the offset from the beginning of the file to the bitmap (raster) data.
Start Size Name
Description
Generic MS API
• RGBQUAD array (ColorTable):
• Pixel data:
The interpretation of the pixel data depends on the BITMAPINFOHEADER structure. It is important to know that the rows of a .bmp are stored upside down meaning that the uppermost row which appears on the screen is actually the lowermost row stored in the bitmap. Another important thing is that the number of bytes in one row must always be adjusted by appending zero bytes to fit into the border of a multiple of four (16-bit or 32-bit rows).
3.3.1.2 BMP Raster Data Encoding
Depending on the image BitCount and on the Compression flag there are 6 different encoding schemes. In all of them,
• Pixels are stored bottom-up, left-to-right.
• Pixel lines are padded with zeros to end on a 32-bit boundary.
15 4 Size biSize Specifies the size of the BITMAPINFOHEADER structure, in
bytes (= 40 bytes).
19 4 Width biWidth Specifies the width of the image, in pixels.
23 4 Height biHeight Specifies the height of the image, in pixels.
27 2 Planes biPlanes Specifies the number of planes of the target device, must be set to zero or 1.
29 2 BitCount biBitCount
Specifies the number of bits per pixel.
1 = monochrome pallete. # of colours = 1 4 = 4-bit palletized. # of colours = 16 8 = 8-bit palletized. # of colours = 256 16 = 16-bit palletized. # of colours = 65536
24 = 24-bit palletized. # of colours = 16M
31 4 Compression biCompression
Specifies the type of compression, usually set to zero.
0 = BI_RGB no compression 1 = BI_RLE8 8-bit RLE encoding 2 = BI_RLE4 4-bit RLE encoding
35 4 ImageSize biSizeImage Specifies the size of the image data, in bytes. If there is no compression, it is valid to set this element to zero.
39 4 XpixelsPerM biXPelsPerMeter Specifies the the horizontal pixels per meter.
43 4 YpixelsPerM biYPelsPerMeter Specifies the the vertical pixels per meter.
47 4 ColoursUsed biClrUsed
Specifies the number of colours actually used in the bitmap. If set to zero the number of colours is calculated using the
biBitCount element.
51 4 ColoursImportant biClrImportant Specifies the number of colour that are 'important' for the bitmap. If set to zero, all colours are considered important.
Note:
• biBitCount actually specifies the colour resolution of the bitmap. It also decides if there is a colour table in the file and how it looks like.
- In 1-bit mode the colour table has to contain 2 entries (usually white and black). If a bit in the image data is clear, it points to the first palette entry. If the bit is set, it points to the second.
- In 4-bit mode the colour table must contain 16 colours. Every byte in the image data represents two pixels. The byte is split into the higher 4 bits and the lower 4 bits and each value of them points to a palette entry.
- In 8-bit mode every byte represents a pixel. The value points to an entry in the colour table which contains 256 entries.
- In 24-bit mode three bytes represent one pixel. The first byte represents the red part, the second the green and the third the blue part. There is no need for a palette because every pixel contains a literal RGB-value, so the palette is omitted.
Start Size Name
Description Generic MS API
1 1 Blue rgbBlue Specifies the blue part of the colour.
2 1 Green rgbGreen Specifies the green part of the colour.
3 1 Red rgbRed Specifies the red part of the colour.
4 1 Reserved rgbReserved Must always be set to zero.
Note:
• In a colour table (RGBQUAD), the specification for a colour starts with the blue byte, while in a palette a colour always starts with the red byte.
• For uncompressed formats every line will have the same number of bytes.
• Colour indices are zero based, meaning a pixel colour of 0 represents the first colour table entry, a pixel colour of 255 (if there are that many) represents the 256th entry. For images with more than 256 colours there is no colour table.
3.3.1.2.1 Raster Data Compression Descriptions
• 4-bit / 16 colour images
• 8-bit / 256 colour images
Encoding type BitCoun
Every byte holds 8 pixels, its highest order bit representing the leftmost pixel of these 8. There are 2 colour table entries. Some readers assume that 0 is black and 1 is white. If you are storing black and white pictures you should stick to this, with any other 2 colours this is not an issue. Remember padding with zeros up to a
32-bit boundary.
4-bit
16 colour images 4 0
Every byte holds 2 pixels, its high order 4 bits representing the left of those. There are 16 colour table entries. These colours do not have to be the 16 MS-Windows standard colours. Padding each line with zeros up to a 32-bit boundary will result in up to 28 zeros = 7 'wasted
pixels'.
8-bit
256 colour images 8 0
Every byte holds 1 pixel. There are 256 colour table entries.
Padding each line with zeros up to a 32-bit boundary will result in up to 3 bytes of zeros = 3 'wasted pixels'.
16-bit
High colour images 16 0
Every 2 bytes hold 1 pixel. There are no colour table entries.
Padding each line with zeros up to a 16-bit boundary will result in up to 2 zero bytes.
24-bit
True colour images 24 0
Every 4 bytes hold 1 pixel. The first holds its red, the second its green, and the third its blue intensity. The fourth byte is reserved
and should be zero. There are no colour table entries. No zero padding necessary.
4-bit
16 colour images 4 2
Pixel data is stored in 2-byte chunks. The first byte specifies the number of consecutive pixels with the same pair of colour. The second byte defines two colour indices. The resulting pixel pattern
will have interleaved high-order 4-bits and low order 4 bits (ABABA...). If the first byte is zero, the second defines an escape
code. The End-of-Bitmap is zero padded to end on a 32-bit boundary. Due to the 16bit-ness of this structure this will always be
either two zero bytes or none.
8-bit
256 colour images 8 1
The pixel data is stored in 2-byte chunks. The first byte specifies the number of consecutive pixels with the same colour. The second byte
defines their colour indices. If the first byte is zero, the second defines an escape code. The End-of-Bitmap is zero padded to end on a 32-bit boundary. Due to the 16bit-ness of this structure this will
always be either two zero bytes or none.
n (Byte 1) c (Byte 2) Description
>0 any
n pixels to be drawn. The 1st, 3rd, 5th, ... pixels' colour is in c's high-order 4 bits, the even pixels' colour is in c's low-order 4 bits. If both colour indices are the same, it
results in just n pixels of colour c.
0 0 End-of-line
0 1 End-of-Bitmap
0 2 Delta. The following 2 bytes define an unsigned offset in x and y direction (y being up).
The skipped pixels should get a colour zero.
0 >=3 The following c bytes will be read as single pixel colours just as in uncompressed files.
Up to 12 bits of zeros follow, to put the file/memory pointer on a 16-bit boundary again.
n (Byte 1) c (Byte 2) Description
>0 any n pixels of colour number c
0 0 End-of-line
0 1 End-of-Bitmap
0 2 Delta. The following 2 bytes define an unsigned offset in x and y direction (y being up).
The skipped pixels should get a colour zero.
3.3.2 BPW/BMW Header File Description
The header file is a text file that describes how data are organised in the .bmp file. The header file is made of rows, each row having the following description:
Atoll supports .bpw and .bmw header file extensions for Import, but exports headers with .bpw file extensions.
3.3.3 Sample
3.3.3.1 Clutter Classes File
3.4 PNG Format
Portable Network Graphics (PNG) is a bitmapped image format that employs lossless data compression. PNG supports palette-based (palettes of 24-bit RGB or 32-bit RGBA colors), greyscale, RGB, or RGBA images. PNG was designed for transferring images on the Internet, not professional graphics, and so does not support other color spaces (such as CMYK). PNG files nearly always use file extension .PNG or .png.
When exporting (saving) a .png file, an associated file with .pgw extension is created with the same name and in the same directory as the .png file it refers to. Atoll stores the georeferencing information in this file for future imports of the .png so that the .pgw file can be used during the import procedure for automatic geo-referencing.
For more information on the PNG file format, see www.w3.org/TR/PNG/.
3.4.1 PGW Header File Description
A PNG World file (.pgw file extension) is a plain text file used by geographic information systems (GIS) to provide georeferencing information for raster map images in .png format. The world file parameters are:
3.5 Generic Raster Header File (.wld)
.wld is a new Atoll specific header format that can be used for any raster data file for georeferencing. At the time of import of any raster data file, Atoll can use the corresponding .wld file to read the georeferencing information related to the raster data file. The .wld file contains the spatial reference data of any associated raster data file. The .wld file structure is simple;
it is an ASCII text file containing six lines. You can open a .wld file using any ASCII text editor.
0 >=3 The following c bytes will be read as single pixel colours just as in uncompressed files.
A zero follows, if c is odd, putting the file/memory pointer on a 16-bit boundary again.
Line Description
1 x dimension of a pixel in map units 2 amount of translation
3 amount of rotation
4 negative of the y dimension of a pixel in map units 5 x-axis map coordinate of the centre of the upper-left pixel 6 y-axis map coordinate of the centre of the upper-left pixel
100.00 0.00 0.00 -100.00 60000.00 2679900.00
Line Description
1 x dimension of a pixel in map units 2 amount of translation
3 amount of rotation
4 negative of the y dimension of a pixel in map units 5 x-axis map coordinate of the centre of the upper-left pixel 6 y-axis map coordinate of the centre of the upper-left pixel
3.5.1 WLD File Description
The .wld file is a text file that describes how data are organised in the associated raster data file. The header file is made of rows, each row having the following description:
3.5.2 Sample
3.5.2.1 Clutter Classes File
3.6 DXF Format
Atoll is capable of importing and working with AutoCAD® drawings in the Drawing Interchange Format (DXF). .dxf files can have ASCII or binary formats. But only the ASCII .dxf files can be used in Atoll.
.dxf files are composed of pairs of codes and associated values. The codes, known as group codes, indicate the type of value that follows. .dxf files are organized into sections of records containing the group codes and their values. Each group code and value is a separate line.
Each section starts with a group code 0 followed by the string, SECTION. This is followed by a group code 2 and a string indicating the name of the section (for example, HEADER). Each section ends with a 0 followed by the string ENDSEC.
3.7 SHP Format
ESRI (Environmental Systems Research Institute, Inc.) ArcView® GIS Shapefiles have a simple, non-topological format for storing geometric locations and attribute information of geographic features. A shapefile is one of the spatial data formats that you can work with in ArcExplorer. .shp data files usually have associated .shx and .dbf files.
Among these three files:
• The .shp file stores the feature geometry
• The .shx file stores the index of the feature geometry.
• The .dbf (dBASE) file stores the attribute information of features. When a shapefile is added as a theme to a view, this file is displayed as a feature table.
You can define mappings between the coordinate system used for the ESRI vector files, defined in the corresponding .prj files, and Atoll. In this way, when you import a vector file, Atoll can detect the correct coordinate system automatically.
For more information about defining the mapping between coordinate systems, please refer to the Administrator Manual.
3.8 MIF Format
MapInfo Interchange Format (.mif) allows various types of data to be attached to a variety of graphical items. These ASCII files are editable, easy to generate, and work on all platforms supported by MapInfo. Vector objects with a .mif extension may be imported in Atoll.
Two files, a .mif and a .mid, contain MapInfo data. Graphics reside in the .mif file while the text contents are stored in the .mid file. The text data is delimited with one row per record, and Carriage Return, Carriage Return plus Line Feed, or Line Feed between lines. The .mif file has two sections, the file header and the data section. The .mid file is optional. When there is no .mid file, all fields are blank.
You can find more information at http://www.mapinfo.com.
Line Description
1 x dimension of a pixel in map units 2 amount of translation
3 amount of rotation
4 negative of the y dimension of a pixel in map units 5 x-axis map coordinate of the centre of the upper-left pixel 6 y-axis map coordinate of the centre of the upper-left pixel
100.00
0.00
0.00
-100.00
60000.00
2679900.00
You can define mappings between the coordinate system used for the MapInfo vector files, defined in the corresponding .mif files, and Atoll. In this way, when you import a vector file, Atoll can detect the correct coordinate system automatically.
For more information about defining the mapping between coordinate systems, please refer to the Administrator Manual.
3.9 TAB Format
TAB files (MapInfo Tables) are the native format of MapInfo. They actually consist of a number of files with extensions such as .TAB, .DAT and .MAP. All of these files need to be present and kept together for the table to work. These are defined as follows:
• .TAB: table structure in ASCII format
• .DAT: table data storage in binary format
• .MAP: storage of map objects in binary format
• .ID: index to the MapInfo graphical objects (.MAP) file
• .IND: index to the MapInfo tabular (DAT) file You can find more information at http://www.mapinfo.com.
You can define mappings between the coordinate system used for the MapInfo vector files, defined in the corresponding .mif files, and Atoll. In this way, when you import a vector file, Atoll can detect the correct coordinate system automatically.
For more information about defining the mapping between coordinate systems, please refer to the Administrator Manual.
TAB files are also supported as georeference information files for raster files (.bmp and .tif). The .TAB file must have the following format:
The fields in bold are described below:
3.10 ECW Format
The Enhanced Compressed Wavelet file format is supported in Atoll. .ecw files are geo-referenced image files, which can be imported in Atoll. This is an Open Standard wavelet compression technology, developed by Earth Resource Mapping, which can compress images with up to a 100-to-1 compression ratio. Each compressed image file contains a header carrying the following information about the image:
• The image size expressed as the number of cells across and down
• The number of bands (RGB images have three bands)
• The image compression rate
• The cell measurement units (meters, degrees or feet)
• The size of each cell in measurement units
• Coordinate space information (Projection, Datum etc.)