Logical Cube Format Guide
Guide to core ISIS labels and a conceptual file structure for a cube
This basic guide focuses on core ISIS labels and a conceptual file structure for a cube. The intent is not to describe the complex nature of the physical file format or the meaning of every element of an ISIS label. There are other programmer-related documents that delve into this detailed information. They include, ISIS Physical Cube Format Guide and ISIS Label Reference. While this document is basic in nature, it is not intended to be an introduction to image processing. We assume the reader has a general understanding of common terminology such as pixels, lines, samples, bit-type, etc.
From our past experiences we know that a digital image is a two-dimensional array of pixels. The ISIS cube format expands an image into the third dimension.
The word "cube" may be somewhat misleading as it implies equal length along each dimension. The volume of course is a rectangular prism but for convenience sake we will continue to use cube. The origin of the cube is referred as coordinate (1,1,1) in order of (sample,line,band). Samples increase from left-to-right, lines from top-to-bottom, and bands from front-to-back. We refer to the sample-line axes as spatial planes. The sample-band and line-band axes are denoted as spectral planes.
As usual, each individual pixel contains a number representing some physical property (e.g., radiance, reflectance, elevation). As a user, these numbers should always be thought of as a floating-point number. That is, 15.397 or –1E15. The conversion from 8-bit or 16-bit pixels is handled behind the scene, thus presenting users (and application programmers) with real world values.
ISIS has the ability to deal with unique conditions within a cube. That is, there are reserved values that have special meaning and hence the name "special pixels". The following is a table of pixel value you may encounter when running programs or visually examining cubes:
|Null||A null pixel indicates no data was collected at the particular location|
|Lis||A low instrument saturation pixel occurred meaning the instrument readout was at its lowest possible value|
|His||A high instrument saturation pixel occurred meaning the instrument readout was at its highest possible value|
|Lrs||A low representation saturation pixel occurred meaning a program computed a new pixel value at this location that was lower than native bit-type for the file (e.g., less than zero for an 8-bit file).|
|Hrs||A high representation saturation pixel occurred meaning a program computed a new pixel value at this location that was greater than native bit-type for the file (e.g., greater than 255 for an 8-bit file).|
An ISIS cube consists of two parts, the labels and the pixel data. These can be stored together in one file (attached) or in two separate files (detached). As ISIS programs automatically enforce an extension of .cub on the output file you can expect to find the pixels in a file with an extension of .cub; if you decide detach your labels you will also have a file with an extension of .lbl. The following is an example of the minimum labels for a cube:
Object = IsisCube Object = Core StartByte = 65537 Format = Tile TileSamples = 128 TileLines = 128 Group = Dimensions Samples = 2468 Lines = 11499 Bands = 1 End_Group Group = Pixels Type = Real ByteOrder = Lsb Base = 0.0 Multiplier = 1.0 End_Group End_Object End_Object End
There are many other groups that you will find in the labels of a cube. For example, Instrument, Kernels, Archive, and Mapping, to name a few. Definitions of these groups and their keywords, as well as the IsisCube object presented above, can be found in the ISIS Label Dictionary.
|Deborah Lee Soltesz||2003-06-11||Converted Jeff Anderson's documentation to HTML and added to this file|