Why JPEG Encoders Produce Different File Sizes
When compressing the exact same uncompressed pixel data, different JPEG encoding libraries often yield noticeably different file sizes, even when configured with the same numerical "quality" value. This discrepancy occurs because the JPEG specification (ITU-T T.81) standardizes the decoding process rather than enforcing a rigid encoding implementation. As a result, libraries such as libjpeg, libjpeg-turbo, MozJPEG, and image framework encoders make distinct algorithmic choices regarding quantization tables, chroma subsampling, discrete cosine transform (DCT) precision, and entropy coding.
The Quality Scale is Arbitrary
The most common reason for size discrepancies is that the standard JPEG specification does not define a standard "Quality 1–100" scale. Each encoding library maps quality numbers to internal quantization tables differently.
For instance, libjpeg uses a formula devised by the Independent JPEG Group (IJG) to scale a baseline quantization matrix. MozJPEG, while based on libjpeg, modifies these tables to prioritize human visual perception, selectively discarding more high-frequency detail. A quality setting of "80" in one library can produce an entirely different set of divisors than "80" in another, leading to different amounts of data loss and varying output sizes.
Non-Standardized Quantization Matrices
Quantization is the lossy step of JPEG compression where high-frequency color and brightness details are divided and rounded to zero. Beyond arbitrary quality scaling, different encoders use fundamentally different quantization matrices for luminance (brightness) and chrominance (color). Some libraries tune their matrices using psychoacoustic and psychovisual models to remove imperceptible details more aggressively, which directly reduces the final byte count.
Chroma Subsampling Differences
The human eye is more sensitive to variations in brightness (luminance) than color (chrominance). Encoders exploit this through chroma subsampling:
- 4:4:4: No subsampling (maximum detail, larger file size).
- 4:2:2: Color resolution halved horizontally.
- 4:2:0: Color resolution halved horizontally and vertically (standard for web and video).
Different libraries have different default behaviors. One library might automatically switch from 4:4:4 to 4:2:0 when the quality drops below 90, whereas another may keep 4:4:4 until quality drops below 75, or default to 4:2:0 across all quality levels unless manually overridden.
Discrete Cosine Transform (DCT) Precision
Before quantization, the image is converted from spatial data into frequency data using the Discrete Cosine Transform. The standard allows multiple mathematical approaches for calculating the DCT:
- Integer DCT (ISlow / IFast): Uses fixed-point arithmetic for speed. Faster variants introduce minor rounding approximations that alter the final coefficients.
- Floating-point DCT (Float): Produces mathematically precise results at the cost of computation time.
Even a difference of \(\pm1\) in a rounded coefficient can determine whether that value compresses to a zero run-length or requires extra bits to store.
Huffman Coding and Entropy Optimization
After quantization, the remaining data is compressed using lossless Huffman coding. Encoders handle this step using different strategies:
- Standard Huffman Tables: Fast encoders often use fixed, pre-computed Huffman tables defined in the JPEG specification annex. This saves processing time but produces larger files.
- Optimized Huffman Tables: Advanced encoders scan the quantized data in a second pass to construct custom Huffman tables tailored specifically to the image's actual data distribution.
- Trellis Quantization: Modern encoders like MozJPEG employ Trellis quantization, an optimization technique adapted from video encoding. It evaluates the exact bit-cost of rounding quantized coefficients up or down, choosing the value that yields the best visual-quality-to-filesize ratio.
Metadata and Markers
File overhead differences also stem from structural metadata:
- Restart Markers: Some encoders insert restart markers to allow parallel decoding or error recovery, adding a small byte overhead.
- ICC Profiles and EXIF: Encoders can automatically
strip or embed color space profiles, EXIF metadata, and
application-specific marker segments (like Adobe
APP14markers). Even a standard sRGB profile can add several kilobytes to an image.