Why does an 32-bit FGDB raster have a smaller file size than 8-bit?

Question

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.

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.