Compressed image size is bigger than original one

[h-alk]

Hi Clinton,

Have a simple method for compressing the JPG images:

public void CompressImage(Stream input, Stream output)
{
    var settings = new ProcessImageSettings
    {
        ResizeMode = CropScaleMode.Max,
        EncoderOptions = new JpegEncoderOptions(75, ChromaSubsampleMode.Subsample420, true)
    };

    MagicImageProcessor.ProcessImage(input, output, settings);
}

During the testing I mentioned that my input test file size is around 110KB and the output one is 140KB.
Do you have any idea why it may happen?
Thank you.

[saucecontrol]

Hi Alex,

Without the source image, I can't say for sure, but it's likely the source image is encoded with optimized huffman dictionaries, which is something the built-in Windows JPEG codec doesn't do. In short, JPEG compression is done in two parts:

1. Quantization of DCT coefficients. This is the part that is controlled by the Quality setting in JPEG -- lower qualities use higher quantization divisors, which "throw away" more of the source image data, making it a lossy format.
2. Lossless entropy coding. This is more similar to Deflate/Zip compression where common patterns are compressed to shorter codes. JPEG can be compressed with either a standard dictionary that works reasonably well for all images or an image-specific dictionary fully optimized for the content of that image. Additionally, JPEG allows progressive scan encoding, which can improve compression further by separating out bits from each block that are more likely to be similar and therefor easier to compress with entropy coding.

The Windows JPEG codec only supports entropy coding with the standard dictionary, so it can't match other encoders for file size if they use per-image optimized dictionaries or progressive scan. I have, however, recently added a libjpeg-turbo-based plugin, which does support those capabilities. You can find nightly builds in the CI NuGet feed.

You'll find JpegOptimizedEncoderOptions under PhotoSauce.NativeCodecs.Libjpeg, which should compress as well as any other encoder except possibly mozjpeg which does some additional work to improve the lossless compression step (at the cost of slower encoding and higher memory use).