High-Bit-Depth TIFF Compression in GIMP

When exporting 16-bit or 32-bit TIFF images in GIMP, selecting the right compression scheme is essential for balancing storage efficiency, processing speed, and cross-application compatibility. High-bit-depth images contain significantly more color data than standard 8-bit files, making uncompressed exports exceptionally large. This article outlines the specific compression algorithms available in GIMP's TIFF export dialog that support high-bit-depth precision, explaining how each functions and which to choose for your workflow.

Available Compression Schemes for High-Bit-Depth TIFFs

GIMP supports several compression algorithms during TIFF export, but high-bit-depth workflows (16-bit integer, 32-bit integer, and 32-bit floating-point) require lossless methods to prevent data clipping or precision loss.

1. None (Uncompressed)

  • Type: No compression
  • Mechanism: Writes raw pixel values directly to the file without altering or packing data.
  • Best Used For: Maximum compatibility with legacy software and fast export/import operations. Because high-bit-depth files hold two to four times the data of 8-bit images, this produces the largest file sizes.

2. LZW (Lempel-Ziv-Welch)

  • Type: Lossless dictionary-based compression
  • Mechanism: Identifies repeating byte sequences and replaces them with shorter codes.
  • Behavior with High-Bit-Depth: Widely supported across virtually all image viewers, RAW processors, and print software. However, because 16-bit and 32-bit images contain subtle noise variations in the lower-order bits, LZW may achieve lower compression ratios than it does on 8-bit files, and can occasionally produce files slightly larger than uncompressed data if the image is extremely noisy.

3. Deflate (ZIP)

  • Type: Lossless LZ77 and Huffman coding
  • Mechanism: Uses the standard zlib/deflate algorithm to compress data streams.
  • Behavior with High-Bit-Depth: Deflate typically achieves better compression ratios on 16-bit and 32-bit image data compared to LZW. While encoding and decoding require slightly more CPU overhead, it is generally the most space-efficient lossless choice for high-dynamic-range photography and digital painting archives.

4. PackBits

  • Type: Lossless run-length encoding (RLE)
  • Mechanism: Replaces consecutive identical bytes with a count and a single value.
  • Behavior with High-Bit-Depth: PackBits is ineffective on continuous-tone high-bit-depth images. Because 16-bit and 32-bit values rarely have identical consecutive bytes across image gradients, PackBits yields negligible compression and is mostly present for backward compatibility.

Incompatible Schemes for High-Bit-Depth

  • JPEG Compression: While GIMP offers JPEG compression within TIFF wrappers, standard TIFF specifications restrict JPEG encoding to 8-bit channels. It cannot be used to store genuine 16-bit or 32-bit dynamic range.
  • CCITT Group 3 / Group 4: These bilevel algorithms are restricted strictly to 1-bit monochrome images (pure black and white) and are unavailable for high-bit-depth color or grayscale exports.

Best Practices

  • For Archiving and Storage: Choose Deflate to minimize disk usage while maintaining full bit precision.
  • For Broadest Compatibility: Choose LZW, as nearly every modern and legacy image manipulation program can parse LZW-compressed TIFFs reliably.
  • For Fast Intermediate Caching: Choose None if you are moving files between applications on fast local NVMe drives and want to eliminate compression overhead.