Better JPEG quantization tables?

[NicolasRobidoux]

... Just rotate your head a bit and you'll see what I say is correct

Totally! Thank you much for this snippet of wisdom.

[NicolasRobidoux]

Bummer! It appears that using three tables with cjpeg produces unnecessarily large files.

P.S. Totally! Back to two tables, and a slightly different syntax for the cjpeg call:

Code: Select all

cjpeg -optimize -baseline -quality 75 -qtables robidoux.txt -qslots 0,1 -sample 1x1 -dct float -outfile test.jpg original.ppm

P.S.2 One way to look at it is that I can use a higher quality Cb table for free. But not noticing this quirk certainly made my sets of three tables produce larger files than necessary Which means that now that I'm back to two tables things are looking up

Moral of the story: With cjpeg, only use three tables if you really really need to.

[NicolasRobidoux]

My earlier comment about very high and very low quality was apparently from a side effect of this "three tables make jpegs larger".

[NicolasRobidoux]

So, here are my current best in two-table versions.

First, the version for -sample 2x2:

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v2012.02.21.14
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Chroma table recommended for use with cjpeg -sample 2x2 (values too small for 1x1)
# Luma
16 12 14 17 22 30 45 72
12 13 14 17 22 31 46 74
14 14 16 19 25 35 52 83
17 17 19 23 30 41 62 100
22 22 25 30 39 54 80 129
30 31 35 41 54 74 111 178
45 46 52 62 80 111 166 267
72 74 83 100 129 178 267 428
# Chroma
17   18   22   31   50   92    193   465
18   19   24   33   54   98    207   498
22   24   29   41   66   120   253   609
31   33   41   57   92   169   355   854
50   54   66   92   148  271   570   1370
92   98   120  169  271  498   1046  2516
193  207  253  355  570  1046  2198  5289
465  498  609  854  1370 2516  5289  12725

Second, the version for -sample 1x1, which is starting to look like the better deal.

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v2012.02.21.15
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Chroma table recommended for use with cjpeg -sample 1x1 (values too big for 2x2)
# Luma
16 11 13 16 20 29 44 73
11 12 13 16 21 30 46 76
13 13 15 18 24 34 52 85
16 16 18 22 29 41 63 103
20 21 24 29 38 54 82 135
29 30 34 41 54 76 116 192
44 46 52 63 82 116 177 293
73 76 85 103 135 192 293 484
# Chroma
17   18   25   43   92    245   813   3358
18   20   28   48   102   273   907   3745
25   28   38   66   142   379   1258  5195
43   48   66   114  245   654   2170  8965
92   102  142  245  525   1403  4658  12725
245  273  379  654  1403  3745  12436 12725
813  907  1258 2170 4658  12436 12725 12725
3358 3745 5195 8965 12725 12725 12725 12725

[NicolasRobidoux]

@rnbc: I still see room for improvement. So, I suggest you stay postpone testing.

[rnbc]

Ok, I'll wait

[NicolasRobidoux]

Conjecture: At fairly high quality levels (above 70 using the cjpeg convention, say), artifacts are relatively few, and the quantized values are fairly dense, which means that rounding is unlikely to make too many land on the same value. For this reason, artifacts are, in a sense, somewhat isolated. Consequently, JND (just noticeable difference) is a powerful measure of the noticeability of artifacts, and for this reason it is difficult to improve much on the standard tables, which were derived by way of a JND experiment.

Conjecture: At lower quality levels, there are artifacts all over the place, and consequently, it is not "isolated" noticeability which matters, but "combination" noticeability. In addition, because quantization is stronger, coefficients which would be slightly different at high quality are more likely to collapse to the same value after rounding, leading to more zero differences in the zig zag scan. It makes sense to make sure that the tables are smooth, because in smooth regions the DCT coefficients will be smooth, and smoother quantization tables will lead to truncated values which are more likely to be equal.

[NicolasRobidoux]

@rnbc: If you don't want to wait a few weeks, try this:

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v2012.02.22
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Chroma table recommended for use with cjpeg -sample 1x1
# Luma
6   11  12  15  20  27  36  47
11  12  15  20  27  36  47  60
12  15  20  27  36  47  60  75
15  20  27  36  47  60  75  92
20  27  36  47  60  75  92  111
27  36  47  60  75  92  111 132
36  47  60  75  92  111 132 155
47  60  75  92  111 132 155 180
# Chroma
6   18  24  37  56  78  106 139 
18  24  37  56  78  106 139 177 
24  37  56  78  106 139 177 219 
37  56  78  106 139 177 219 268 
56  78  106 139 177 219 268 321 
78  106 139 177 219 268 321 379
106 139 177 219 268 321 379 442
139 177 219 268 321 379 442 510

Use with something like

Code: Select all

cjpeg -optimize -baseline -quality 75 -qtables robidoux.txt -qslots 0,1 -sample 1x1 -dct float -outfile b.jpg original.ppm

after having pasted the above in the text file robidoux.txt.

I was aiming this table for use with low -quality (45 to 60), but it appears to work well at -quality 75 anyway (to my surprise).

I can't vouch for every single entry (not totally sure about the switch to 10 for the very first entry, esp. when using somewhat high quality levels, for which it's probably wasteful), but it's as good as it's going to get for a while. P.S. I changed it to an even lower value (namely 6), given that my target -quality level is about 60. See following posts. 6 is giving a lot of file size to "flat block" colour accuracy. 10 would be enough, I guess, for many, at -quality 60, and larger values (16 and 17) pretty much correspond to the standard tables.

As you can see, I pushed the "smoothness/symmetry" conjecture rather far. I'm not sure it's much better than the standard tables, but I'm pretty sure it's no worse, and it's synthetic. In my very limited testing, it appears that it produces smaller files than stock when the image is locally smooth most everywhere (at least within an 8x8 block), and larger ones otherwise (lots of noise or "jumpy" pixels). (Of course, what matters is quality at roughly equal file size...) This is fine by me B/C my target use involves images which are downsized using -distort resize -filter Robidoux or Quadratic, so I know they'll be smooth.

[NicolasRobidoux]

The "10" replacement in the very first entry is because I do not like blockyness in blue skies.

[NicolasRobidoux]

I wish I had seen this three weeks ago: http://doom10.org/index.php?topic=711.30

[NicolasRobidoux]

The other thing I do to make files smaller is I customize jpegrescan taking my quantization tables into account, and I use it in a lossy way (which definitely was not it's intended use).

The original jpegrescan: http://pastebin.com/f78dbc4bc

[NicolasRobidoux]

The image shown here http://filmicgames.com/archives/778 makes it clear that at lower quality levels, the baseline values (very first entries of each table) has a huge impact.

I'm going to lower them and see.

[NicolasRobidoux]

Yeah: The baseline (first) Chroma value benefits from being pushed down (to 9 or 10 or so). It costs a lot of file size, but if you don't want the ugly reddish/greenish tinge to indoor shots, and blocks in the sky, the baseline values have to go down.

[NicolasRobidoux]

... actually, at -quality 60 or so, there is a payoff to pushing the luma and chroma baseline values down to about 6.

[NicolasRobidoux]

Setting both baseline values to 6 for my use (changing the values in the above table). Setting the baseline values depending to the target quality (less quality -> smaller baseline values, which goes against the way cjpeg adjusts the qtables for quality) appears to be a worthwhile qtable tweak.

I probably could figure out a formula which would make the effective baseline values more or less constant across "all" quality values (above 50, say).

Getting the colours reasonably right matters for images of food. If the colours are not vivid enough, it does not look appetizing.