The HFA .img format was designed by ERDAS in the early 1990’s. At that time, Microsoft’s operating system file size limit on disk of 2,147,483,648 bytes (2.1GB) was considered huge. Today, 2.1GB is not considered huge.
In 1999, before Microsoft upgraded their OS to support a true 32-bit file size on disk (2^32 - 1) or 4.2GB), ERDAS released a work-around (tricking the OS) using the .ige spill-over image files (an uncompressible 64-bit offset data file). ERDAS has plans (but no time-table at present) to move to a 64-bit offset .img file, eliminating the need for the .ige files (and allowing DR-RLE compresssion of .img files >2.1GB).
Until the time when a 64-bit offset .img file with DR-RLE support is supported, the mapping community must deal with the question, "when will this file spill-over to a .ige file?" To help the ERDAS IMAGINE community with this challenge, I want to take a moment to explain when spill-over to the .ige file occurs. This will allow you to plan for the transition from a .img to a .ige file when creating new files.
One major thing to understand, when determining if an image needs a .ige file ERDAS counts pixels, not bytes. This is done because when using the DR-RLE compression ERDAS cannot know prior to writing out the image the size of the final compressed image. Therefore, counting pixels rather than bytes is a safe method.
Below are helpful calculations for understanding the transition zone…
Nevertheless, these calculations do not account for all the elements contributing to the final file size. The number of data blocks (determined by the block size) and metadata such as stats, histogram, projection, and attributes (thematic data) will also play into the final file size of a .img file. Therefore, you are not likely to store the full pixel numbers noted below before the rollover.
The formula for calculating the total number of pixels is:
Total bytes allowed / bytes per pixel = total # pixels
For 1-bit data: 2^31 / 0.125 = 17,179,869,184 pixels (17.180 gigapixels)
For 2-bit data: 2^31 / 0.25 = 8,589,934,592 pixels (8.590 gigapixels)
For 4-bit data: 2^31 / 0.5 = 4,294,967,296 pixels (4.294 gigapixels)
For 8-bit data: 2^31 / 1 = 2,147,483,648 pixels (2.147 gigapixels)
For 16-bit data: 2^31 / 2 = 1,073,741,824 pixels (1.073 gigapixels)
Take the square root to get an approximate square array size for the 1-band panchromatic or thematic (color palette) image:
Sqrt of 17,179,869,184 gives a 131,072 X 131,072 x 1-band x 1-bit image
Sqrt of 8,589,934,592 gives a 92,681 x 92,681 x 1-band x 2-bit image
Sqrt of 4,294,967,296 gives a 65,536 x 65,536 x 1-band x 4-bit image
Sqrt of 2,147,483,648 gives a 46,341 x 46,341 x 1-band x 8-bit image
Sqrt of 1,073,741,824 gives a 32,768 x 32,768 x 1-band x 16-bit image
For a 3-band image, the formula is (less than 8-bit not used for multi-layer files):
(Total bytes allowed / # bands) / bytes per pixel = pixels in each band
For 8-bit data: (2^31 / 3) / 1 = 715,827,883 pixels
For 16-bit data: (2^31 / 3) / 2 = 357,913,941 pixels
Take the square root to get an approximate array size for the 3-band image:
Sqrt of 715,827,883 gives a 26,755 x 26,755 x 3-band x 8-bit image
Sqrt of 357,913,941 gives a 18,919 x 18,919 x 3-band x 16-bit image
For a 4-band images:
For 8-bit data: sqrt ((2^31 / 4) / 1) gives a 23,170 x 23,170 x 4-band x 8-bit image
For 16-bit data: sqrt ((2^31 / 4) / 2) gives a 16,384 x 16,384 x 3-band x 16-bit image
Related Blog Post, Fast and Lossless Compression
No comments:
Post a Comment