Web de MiraMon

MiraMon raster formats description


Introduction Description of the data files of MiraMon raster format
Description of the documentation file of MiraMon raster format

MiraMon considers a raster to be any spatial representation made by dividing the cartographic space into a net of squares (called cells or pixels) contained in a rectangular space. So, a raster can hold satellite imagery, aerial photographs, digital elevation models (DEM), raster thematic maps (land cover classes, etc), etc. In any case, users can get information, in the metadata file, about if that kind of data refers to a global mean value for each cell (the case of radiance in electronic sensor imagery, or analogic aerial cameras), to a central cell value (the usual case for elevation in DEM), to a modal value (i.e., the more frequent class in that cell, like in many thematic maps), etc. Understanding the nature of the stored data in each cell involves differences in the treatment of different spatial operations (for instance, resolution changes, resampling by interpolation, etc).

The following description explains raster formats from a user point of view. Fore a more technical explanation (internal format, etc) and conceptually deeper (for programmers), the technical document MiraMon raster file format can be consulted.


Description of the data files of MiraMon raster format

The data files can be stored in several formats:

  • MiraMon own format
  • formats that can be directly opened with MiraMon
  • formats that can be imported into MiraMon

The MiraMon own format data files are:

  • Uncompressed IMG: A binary format without a header in which pixels are placed from left to right and from top to bottom, without any separation between image rows (except in bit files); moreover, in bit files, bits of each byte are numbered (0 to 7) starting with the least significant bit, and a byte never shares pixels from two rows: each row must start at bit 0 and may contain unused bits at the end of a row (if there are any, they must take a value of 0).
  • Compressed IMG: A binary format with or without a header (placed at the end) that uses several strategies to compress data, so it needs less disc space. Whatever the strategy used (classic RLE, RLE extracompressed, with indexation, etc) it always uses lossless compression (i.e., conservative), so it is always possible to go back to the uncompressed format with the original characteristics (use the IMGIMG application from "Tools | File maintenance | Raster conversion and compression/uncompression"). The compression used in IMG files is a variant of the Run Length Encoding, RLE. RLE is a lossless compression strategy that is very efficient for categorical images with many pixels repeated in the same row, but it doesn't work well when the image (or a part of it) displays areas without repetitions (like an aerial photography, or a DEM); in these cases, it is so inefficient that it can get to double the size of the image. A second disadvantage is that there is no way of going quickly to a certain pixel (it is necessary to uncompress the image dynamically until getting the requested pixel), and this makes accessing non-consecutive readings slow. MiraMon uses two improvements in conventional RLE strategy to avoid these disadvantages: the first one is called extra-compressed RLE, that avoids using the RLE counter in areas without repetitions in the raster; these zones are preceded by an RLE counter with a value of zero, which conventionally indicates that next byte expresses the number of uncompressed values (whatever they are byte, integer, etc) that follow; the second strategy is to generate RLE indexed files in which the offsets to the beginning of each row are added at the end of the file, so any point of the raster can be accessed quickly.

    Both files types, compressed and uncompressed IMG, use .img extension, have a little-endian byte order and have a companion I.rel file, created by MiraMon and located in the same directory. The I.rel file typically has the name of the .img file but appending the "I" to the name and using the .rel extension (e.g., raster.img + rasterI.rel), but in multiband raster files the name of one of the bands can be used (e.g., Blue.img + Green.img + Red.img + IR.img + BlueI.rel), or even a generic name (e.g., Blue.img + Green.img + Red.img + IR.img + FourBandsI.rel). The I.rel file can contain also in both cases, symbolization if needed (color palette, categorical or quantitative interpretation, etc), can contain relationships with databases if needed (typically a single table acting as a thesaurus of categories) and must contain basic metadata (e.g., data type, etc). Extended metadata (including radiometric properties, raster units, quality, platform and sensor, etc) can be fully documented inside the I.rel file by using the GeM+ . This file is of type text in Windows INI format, supporting hierarchy (section nesting, i.e., [section] --> [section:subsection]) when needed to express different color palettes for different .img files of the multiband set, etc). Because of its complexity, it is recommended to modify these I.rel files using GeM+ for metadata and relationships with alphanumeric tables ("Thematic info" tab), and to use the interactive visualization options of the MiraMon main module for symbolization purposes.

The data files that can be directly opened with MiraMon are:

  • TIFF/GeoTIFF: A binary format with header defined by Aldus/Adobe Systems. MiraMon supports 1-bit, 8-bit grayscale, 8-bit palette, 24-bit (3 bands) and multiband with more than 3 bands TIFF files; other common data types (integer, real) and variants as BigTIFF are also supported. The TIFF format can be uncompressed or use lossless compressions (as LZW). For georeferencing MiraMon accepts both the GeoTiff format (georeference embedded in the header), the presence of a World file (.tfw or .tifw) and the specification in the MiraMon metadata files. For more information regarding the order of priorities used by MiraMon when there is more than one georeferencing source, see the TIFIMG module. It uses the extension .tiff or .tif. This format can be directly open by MiraMon for visualization, query, etc, purposes, but some applications may not support it; in that case, it should be imported with the appropriate tool of the "File | Import menu" to one of the formats that the application supports.
  • JPEG: A binary format with a header defined by the Joint Photographic Experts Group and especially useful for containing photography-like imagery in a very small file size (aerial photography, orthophotos, remote sensing images, etc). MiraMon supports JPEG files with 24-bit pixel color (natural color) or 256 grey levels. However, JPEG is, in most cases, a lossy (unconservative) format, so it is useful for images devoted to visual analysis (like orthophotos), but not for rigorous digital analysis (like the applied to obtain categorical thematic maps or DEM). It uses a .jpg (or .jpeg) extension. Metadata can be fully documented with the GeM+ from the J.rel file created by MiraMon. This format can be directly open by MiraMon for visualization, query, etc, purposes, but some applications may not support it; in that case, it should be imported with the appropriate tool of the "File | Import menu" to one of the formats that the application supports.
  • JPEG2000: A binary format with a header defined by the Joint Photographic Experts Group. MiraMon supports JPEG2000 files with 24 bit pixel color (true color), 256 grey levels as well as RGBK (which is similar to the 24 bit files but with an additional band indicating transparency) and multispectral images in which any band name and description can be used. The JPEG2000 format can be lossy or lossless. It uses the extensions jp2, j2c (without header). A raster band selector has been implemented in JPEG2000 multispectral (of more than 3 bands) so the user can select between seeing one of the bands in gray scale or choosing 3 to make an RGB composite. This format can be directly open by MiraMon for visualization, query, etc, purposes, but some applications may not support it; in that case, it should be imported with the appropriate tool of the "File | Import menu" to one of the formats that the application supports.
  • ECW: A binary format using wavelet compression optimized for aerial and satellite imagery developed by Earth Resource Mapping/Leica Geosystems. Georeferencing can be embedded within the file. It uses the extension .ecw. The reading of ECW files of more than 3 bands has been implemented as well as the support to several spatial reference systems, including those based on ETRS89. This format can be directly open by MiraMon for visualization, query, etc, purposes, but some applications may not support it; in that case, it should be imported with the appropriate tool of the "File | Import menu" to one of the formats that the application supports.
  • MrSID: A binary format with a header defined by LizardTech, Inc. MiraMon supports MrSID files with 24-bit per pixel color (true color), with 256 grey levels as well as RBGK (which is similar to the 24-bit files but with an additional band indicating transparency) and multispectral images in which any band name and description can be used. The MrSID format can be lossy or lossless. It uses a .sid extension. This format can be directly open by MiraMon for visualization, query, etc, purposes, but some applications may not support it; in that case, it should be imported with the appropriate tool of the "File | Import menu" to one of the formats that the application supports.
  • BMP: A binary format (Device Independent Bitmap) with header defined by Microsoft that stores the values of the cells sorted from left to right and from bottom to top (except in some rare exceptions). Usually it has no compression, although lossless compression of RLE type can be applied. It uses the extension .bmp. Metadata can be fully documented with the GeM+ from the B.rel file created by MiraMon. This format can be directly open by MiraMon for visualization, query, etc, purposes, but some applications may not support it; in that case, it should be imported with the appropriate tool of the "File | Import menu" to one of the formats that the application supports.
  • DIB: A binary format analogous to BMP, without the file header (with BITMAPINFO, but without BITMAPFILEHEADER). This format can be directly open by MiraMon for visualization, query, etc, purposes, but some applications may not support it; in that case, it should be imported with the appropriate tool of the "File | Import menu" to one of the formats that the application supports.
  • Any format supported by the GDAL libraries. See details below.

An extensive number of other raster formats can also be incorporated into MiraMon, via import, as the aforementioned with direct opening, and the E00 raster, TXT, raw, RST (Idrisi32), HDF, LAN/GIS (Erdas 7.4), CEOS (Landsat), NDF (Landsat), JPEG2000 (Sentinel), SPOT, GRD (Surfer), PGM/PPM, CTL (Grad) and RF (Zebra). Starting with version 10 (2024), all formats supported by GDAL libraries can be read directly and also imported into IMG (using the GDALMM application). This not only allows dozens of additional formats to be used without a prior import operation, but also extends the usage of some variants of already supported formats. For more information refer to the Import option in the "File" menu.

The 13 subformats accepted by MiraMon for the own IMG format (6 compressed, 7 uncompressed) are in the following table; all of them, except bit, can be compressed (and, in that case, indexed for faster access speed):

subformat
bits per pixel
bytes per pixel
type of value
whole values (for integer numbers) or maximum and minimum values and number of significant figures (for real numbers)
examples of use
bit
1
1/8
integer
[0,1]
Mask image
byte
8
1
integer
[0,255]
Thematic cartography up to 256 categories, aerial or satellite imagery (black and white or color) up to 256 grey levels or 256
integer
16
2
integer
[-32768, 32767]
Thematic cartography of more than 256 categories, several types of DTM, aerial or satellite imagery (black and white or color) of more than 256 grey levels or 256 colors
unsigned integer
16
2
integer
[0, 65535]
Same as "integer", but without negative values and more possible positive values
long
32
4
integer
[-2147483648, 2147483647]
Thematic cartography with links to databases
real
32
4
real
(~-3.4Eħ38, ~3.4Eħ38) (6 guaranteed significant figures, and up to 9 in some numbers; minimum positive normal value is -1.18Eħ38)
Several types of DEM that need single real precision as temperature maps with a tenth of a degree accuracy
double
64
8
real
(~-1.7Eħ308, ~1.7Eħ308) (15 guaranteed significant figures, and up to 17 in some numbers; minimum positive normal value is -2.22Eħ308)
Several types of DEM that need double real precision. In practice, double format is only used to intermediate calculations in which a large precision is needed, and not for final layers (exception: raster files containing map projected coordinates (as UTM) in cm, needing up to 9 significant figures)

A note about NoData values: NoData values are always placed out of the [min,max] values of the raster data. It is not necessary to put them at the supported extremes of the data types (e.g., -32768 or 32767 in integer), so -9999 is adequate if all values are > -999. The same is true for real numbers. Nevertheless, if wishing a NoData value on a extreme in real numbers use ħ2.9x10+301 for the double (64-bit) data type (and 2.2x10+301 as a reasonable maximum [-2.2x10+301 as a reasonable minimum]); and use ħ5.3x10+37 for the real (float, 32-bit) data type (and 5.195x10+37 as a reasonable maximum [-5.195x10+37 as a reasonable minimum]). NoData values are properly recorded in the raster metadata file (I.rel), along with the desired description, which can be modified from the GeM+ Thematic Information tab.

A note about NAN, denormals, etc in real (float) and double data types: For performance reasons, files containing real numbers should not contain bits combined as Not-a-Number (NAN), infinites, denormals, etc. "Strange" bit combinations are neither needed nor welcomed, in MiraMon raster files.

MiraMon allows to visualize:

  • 24-bit pixel color, or 16 million colors, both combining 3 bands from one or several images (compressed or not, byte, integer, etc), as using other formats such as JPEG, JPEG2000, MrSID or BMP.
  • Using semi-transparency in any case.
  • Defining the type assignment from the pixel values to the palette values choosing from options: direct assignment of integers (1 to 1 correspondence between pixel values and the values of the palette), direct integers with displacement of origin, linear scaling or logarithmic scaling.
  • By dinamic classes.
  • Modifying the range of values to display.

As of version 4.0 (2000), MiraMon accepts multiband in the same raster file consisting of "n" value files (.img, .jpg, .jp2, .j2c, .sid, etc, extensions) and a metadata file which incorporates not only georeferencing but also default symbolization, relationships between tables and other metadata such as spatial and thematic quality indicators, etc (.rel extension).

As of version 5.5 (October 2005), MiraMon incorporates the possibility of opening several raster files in a single session (multiraster) without limiting the scope of other open layers. They can be opened directly from any of the formats described above and many others using the import option.


Description of the documentation file of MiraMon raster format

The documentation file I.rel that always goes with the data file (or files) is specific to MiraMon. It is a flat text file in Windows INI format, formed by sections and keys. This file can be edited with any text processor (Notepad, etc); however, because of its complexity, it is recommended to modify it using Universal Geospatial Metadata Manager (GeM+) for metadata and relationships with alphanumeric tables ("Thematic info" tab), and using the interactive Visualization/Symbolization options of the MiraMon main module. In each section there are keys followed by an equal sign and a value or chain of characters. These keys allow to define the information that the file has to contain.

The main supported sections in the metadata I.rel files are the following ones:

  • [VERSIO] -> Section that describes the version and subversion of the REL file.
  • [METADADES] -> Section that describes the general characteristics of the metadata, such as the language or languages in which the metadata is defined, the creation date, the character set, or the unique identifier of the file.
  • [METADADES:ORGANISME_#] -> Section describing the metadata publisher. The # symbol is the number of the participating organization.
  • [IDENTIFICATION] -> Section that describes the title of the raster, etc.
  • [OVERVIEW] -> Section that describes, among other things, the date when the dataset was created, the date of updating, a summary, etc.
  • [OVERVIEW:ORGANISME_#] -> Section that describes, among others, data about the coordinating organization, promoter, publisher and database distributor. The # symbol is the number of the participating organization. The first to appear is always the number 1 and the next ones carry consecutive numbers.
  • [OVERVIEW:ASPECTES_TECNICS] -> Section that describes, among other things, the file type, the data model, the number of rows and columns, comments, etc.
  • [OVERVIEW:ASPECTES_TECNICS:PLAT_INSTR_INFO] -> Section that describes the characteristics of the platform and the sensor.
  • [SPATIAL_REFERENCE_SYSTEM:HORIZONTAL] -> Section that indicates the type of horizontal reference system (cartographic or local) and its identifier, needs to know its description, units, projection, datum and ellipsoid, etc.
  • [SPATIAL_REFERENCE_SYSTEM:HORIZONTAL:QUALITY] -> Section that describes the quality of the horizontal reference system (with indicators such as positional accuracy - RMS in X, RMS in Y, RMS in the adjustment of the ground control points, etc).
  • [EXTENT] -> Section that describes, among other things, the extension of the dataset (bounding box coordinates), etc.
  • [QUALITY:LINEAGE:PROCESS_#] -> Sections that describe the different processes carried out in the base (radiometric correction, geometric correction, mosaicking between layers, transformation of raster formats [for example from CEOS to IMG], etc), and which entity has carried out the process and when. The symbol # is the number of the processes carried out in the dataset and indicates the order in which they were carried out. The first process always corresponds to number 1 and the next processes take consecutive numbers.
  • [ATTRIBUTE_DATA] -> Section that describes the attributes of the data in the dataset (raster units, value assigned to NoData, number of bands, etc).
  • [ATTRIBUTE_DATA:NOM_CAMP] -> Section that describes generic characteristics of the band, for example name, description or range of the spectral band, minimum and maximum value of the data in the image, etc.
  • [ATTRIBUTE_DATA:NOM_CAMP:BAND] -> Section that indicates the particular characteristics of a band in the base, for instance, the minimum and maximum radiance, minimum and maximum wavelength, scaling coefficients, etc.
  • [COLOR_TEXT] -> Section that indicates the raster display features, for example the definition of the palette to be open by default, the treatment of the variable (categorical, etc), semitransparency, the minimum and maximum display range, etc.
  • [VISU_LLEGENDA] -> Section that indicates the display characteristics of the legend with respect to the number and description of categories, etc.

The order of the sections within the file is not relevant. Also, the order of the keys within each section.

An example of the I.rel file format can be seen by opening, with Windows Notepad, any I.rel file provided with a raster corresponding to layer distributed with the MiraMon Favorite Collections. A more complete description can be found in the help of the Universal Geospatial Metadata Manager.

Prior to the version of 4.0 MiraMon, raster formats were inspired by the .img Idrisi binary format, using a .doc (not Word, but a .txt file) as brief documentation. This format can still be read and created from the GeM+ application for backward compatibility, but is completely discouraged. For more information about the formats and contents of the old documentation files please refer to Metadata file format and table relations file format.