Using Arc 10.0, I have a single band, 32-bit signed raster as the only item in a file geodatabase. Using ArcCatalog, I copy that raster to a new geodatabase with an 8-bit unsigned pixel type. As expected, Raster Properties shows that the 8-bit raster is smaller (438 MB) than the 32-bit raster (1.71 GB). However, when I measure the size of the two gdb folders using Windows File Explorer properties, the 32-bit folder is smaller(!) than the 8-bit folder (64 vs 83 MB, respectively). Both gdb folders contain 66 files.

Both rasters are 32,225 X 13,417, single band, 30 meter cell size, FGDBR format, continuous Source Type, no colormap or pyramids, with LZ77 compression. The only difference is the pixel depth and type: 32-bit signed integer vs 8-bit unsigned integer.

Why is the 32-bit gdb folder smaller than the 8-bit folder, as measured by Windows File Explorer? Why does Arc raster properties report such wildly inflated size (438 and 1,710 MB) compared to Window File Explorer (83 MB and 64 MB)?

In ArcMap, the 32-bit image takes about 9 seconds to display, while the 8-bit image loads almost instantly.

  • 3
    The run-length encoding in LZ77 probably eats the extra 24 bits. The slower performance is due to the added volume on decompression.
    – Vince
    Jan 23, 2016 at 23:20
  • @Vince, I think you're right on. Please consider turning your comments into an answer...
    – Aaron
    Jan 24, 2016 at 2:50
  • Makes sense. But what about the specific questions regarding file sizes?
    – Stu Smith
    Jan 24, 2016 at 4:54

1 Answer 1


Taking multiple questions out of order:

The size of a raster is just the product of bit-depth/8, bands, rows, and columns plus header metadata (statistics, etc.)

32/8 x 1 x 32225 x 13417 = 173079300 bytes ~= 1710Mb

 8/8 x 1 x 32225 x 13417 =  43269825 bytes ~=  438Mb

ArcGIS does not report the compressed file size.

Compression tools are very sensitive to input data, so there's no way to explain exactly why it compressed the way it did without the data and a few hours' study, but it's likely that the repeating pattern of the first 24 bits (zeros) allows the Lempel-Ziv encoding to construct a slightly better dictionary on the larger file, which allows it to compress a bit more tightly.

The 32-bit image is slower to render because it has to do four times as much decoding, which must then be re-encoded into byte for rendering.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.