Unoptimizing? a JPEG file

[Mangix]

I did some experiments with packJPG and jpegtran. It turns out that if you process the JPEG file prior to compressing it with packJPG, you can get a smaller file size.

jpegtran stock: 6579826 bytes
jpegtran -optimize: 6405337 bytes
jpegtran -progressive: 6072106 bytes
jpegrescan: 6010238 bytes

packJPG results:

jpegtran stock: 4864661 bytes
jpegtran -optimize: 4864828 bytes
jpegtran -progressive: 4865008 bytes
jpegrescan: 4865027 bytes

In other words, the larger the input JPEG file, the smaller packJPG will compress it. Which begs the question. Is there a way to do JPEG compression in a way which is worse than jpegtran?

[Piotr Tarsa]

Those are very small differences. Have you tested on more files to confirm the trend?

[Biozynotiker]

Im not 100% sure, but i think you can do it with jpegtrans also. Just don't use the "-optimize" switch, just jpegtrans.exe in.jpg out.jpg.
Edit: ah, just overlooked you do this already with "jpgtrans stock".

[Mangix]

Those are very small differences. Have you tested on more files to confirm the trend?

The differences are not that small. And yes, I have tested multiple files and all show the same pattern. I would also try arithmetic coding but that is not supported by packJPG.

I mean I understand why progressive images compress worse but not stock vs. -optimize.

edit: I should mention that compressors like TANGELO show a smaller size with -optimize than without.

[Matt Mahoney]

I don't think tangelo has a JPEG model. Have you tried paq8pxd_v7?

[Mangix]

TANGELO 2.4 has a JPEG model according to the changelog. It produces files marginally larger than packJPG. I've tried paq8px version 6.9 which produced smaller files but was slow. Otherwise, it behaves identically to TANGELO in that -optimize produces smaller files when compressed than stock.

A few numbers with TANGELO:

stock: 5017858 bytes
-optimize: 5009029 bytes

PAQ8PX_v69:

stock: 4782509 bytes
-optimize: 4774838 bytes

progressive testing was omitted as the JPEG model in PAQ does not seem to support progressive images.

[caveman]

The differences are not that small. And yes, I have tested multiple files and all show the same pattern. I would also try arithmetic coding but that is not supported by packJPG.

I mean I understand why progressive images compress worse but not stock vs. -optimize.

edit: I should mention that compressors like TANGELO show a smaller size with -optimize than without.

I have a possible explanation, to my knowledge "stock" uses the universal Huffman tables that are described in the annex K.3 "Typical Huffman tables for 8-bit precision luminance and chrominance" of the specs, since these are wellknown packJPG has probably a very effective way to signal that these specific tables are used. In the other hand "optimize" builds Huffman tables that fits to the current image needs hense better compression but in this case packJPG has to record the tables in question in the file it produces.

Have you tried to build different sequential scans using the -scans option?
For instance if you put:
0;
1;
2;
in a file called "scn012"
and call jpegtran this way:
jpegtran -scan scn012
It will put each component (Y, Cb, Cr) in a separate scan (there will be 3 SOS markers in the file) whereas they are all in the same scan (1 SOS, MCUs are used) by default.

There are 13 different ways to produce sequential JPEGs this way (but only 5 will produce different file size, since individual scan orders has actually no impact on the file size), I've added the 13 scans files you could try in the scans.zip archive.

[Mangix]

I tried all of your scans. Results are below. Basically, stock(or scan0) remains the smallest.


Original Sizes:


6579826 0.jpg
6579649 1.jpg
6579643 2.jpg
6579752 3.jpg
6579649 4.jpg
6579643 5.jpg
6579752 6.jpg
6579748 7.jpg
6579748 8.jpg
6579748 9.jpg
6579748 10.jpg
6579748 11.jpg
6579748 12.jpg


After packJPG:


4864661 0.pjg
4864666 1.pjg
4864667 2.pjg
4864667 3.pjg
4864666 4.pjg
4864667 5.pjg
4864668 6.pjg
4864669 7.pjg
4864669 8.pjg
4864669 9.pjg
4864669 10.pjg
4864668 11.pjg
4864668 12.pjg