Totally! Thank you much for this snippet of wisdom.rnbc wrote:... Just rotate your head a bit and you'll see what I say is correct
Better JPEG quantization tables?
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
Last edited by NicolasRobidoux on 2012-02-21T12:28:28-07:00, edited 1 time in total.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
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:
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 ![Smile :-)](./images/smilies/icon_smile.gif)
Moral of the story: With cjpeg, only use three tables if you really really need to.
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
![Sad :-(](./images/smilies/icon_sad.gif)
![Smile :-)](./images/smilies/icon_smile.gif)
Moral of the story: With cjpeg, only use three tables if you really really need to.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
My earlier comment about very high and very low quality was apparently from a side effect of this "three tables make jpegs larger".
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
So, here are my current best in two-table versions.
First, the version for -sample 2x2:
Second, the version for -sample 1x1, which is starting to look like the better deal.
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
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
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
@rnbc: I still see room for improvement. So, I suggest you stay postpone testing.
Re: Better JPEG quantization tables?
Ok, I'll wait ![Very Happy :D](./images/smilies/icon_biggrin.gif)
![Very Happy :D](./images/smilies/icon_biggrin.gif)
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
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.
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.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
@rnbc: If you don't want to wait a few weeks, try this:Use with something likeafter 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.
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
Code: Select all
cjpeg -optimize -baseline -quality 75 -qtables robidoux.txt -qslots 0,1 -sample 1x1 -dct float -outfile b.jpg original.ppm
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.
Last edited by NicolasRobidoux on 2012-02-22T12:32:00-07:00, edited 6 times in total.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
The "10" replacement in the very first entry is because I do not like blockyness in blue skies.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
I wish I had seen this three weeks ago: http://doom10.org/index.php?topic=711.30
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
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
The original jpegrescan: http://pastebin.com/f78dbc4bc
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
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.
I'm going to lower them and see.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
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.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
... actually, at -quality 60 or so, there is a payoff to pushing the luma and chroma baseline values down to about 6.
-
- Posts: 1944
- Joined: 2010-08-28T11:16:00-07:00
- Authentication code: 8675308
- Location: Montreal, Canada
Re: Better JPEG quantization tables?
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.
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.