Legacy ImageMagick Discussions Archive

I had another hunch: The standard luma table is not very smooth: Coefficients jump around quite a bit. Yet, in areas in which the image is reasonably smooth, one would expect the DCT coefficients to vary smoothly. Clearly, rough quantization coefficients will make reconstructed DCT coefficients even rougher than they need be. Hence the idea of making the luma table smoother.

A simple way of making the luma table smoother is to symmetrize by taking geometric averages of symmetric entries. Of course, this does not give integers. I chose ceiling as a casting operator. (Yes, I know that this makes the quantization table ignore the different perception of horizontal and vertical features. I find it hard to believe that the experiment was so precise that it nailed this anisotropy to a significant degree in the general situation, given that it specifically concerned 2x horizontal chroma subsampling in an interlaced set up. Of course I may be wrong, but I actually trust symmetrized values with -sample 2x2 more than the original, unsymmetrized, ones.)

The following luma table will produce, on average, JPEG files which are very slightly smaller (if generated from a reasonably high quality image). It will, also, produce JPEG images which are slightly smoother. I attach my current attempt at improving the chroma table (it is not, in practice, that different from the standard one). If you try it, you should see that my hunch was correct. I'm actually pretty confident in stating that this is a better set of quantization tables.

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v.2012.02.16.17
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Recommended for use with cjpeg -sample 2x2
# Luma
16 12 12 15 21 31 50 67
12 12 14 18 24 46 62 72
12 14 16 23 39 56 74 73
15 18 23 29 54 75 84 78
21 24 39 54 68 94 103 93
31 46 56 75 94 104 117 96
50 62 74 84 103 117 120 102
67 72 73 78 93 96 102 99
# Chroma
17  18  24  47   99   128  192  256
18  21  26  66   99   128  192  256
24  26  56  99   128  192  256  512 
47  66  99  128  192  256  512  1024 
99  99  128 192  256  512  1024 2048
128 128 192 256  512  1024 3072 4096
192 192 256 512  1024 3072 6144 7168
256 256 512 1024 2048 4096 7168 8192

Of course, there are other ways of smoothing or symmetrizing a matrix of DCT multipliers. If you can think of a better one, please let me know. If I have time, I may actually try something like a five point smoothing stencil.

There are two other reasons why I think the "ideal" quantization matrix should be smoother than the one given in an Annex to the standard:

I don't have the details of the experiment that determined the coefficients of the standard table, but I assume that they only considered the DCT modes in isolation. The higher modes, almost invariably, appear in combination. Consequently, it is reasonable to think that the experiment only gives the drift, not the detail. Given that it is a reasonable assumption that smoother quantization leads to smoother JPEGs when the image is locally smooth. Otherwise, the jumpiness in the quantization will trigger modes in a jumpy way even when the unquantized coefficients are smooth, leading to artifacts.
Conceivably, a smoother quantization matrix leads to smoother quantized coefficients, and smoother coefficients should be easier to compress.

If I was still an academic (or had more time on my hands), I could set up experiments to verify these hypotheses. But I'm a consultant, so I am satisfied with proof in the pudding.

There is another thing which makes me think that, esp. with the high modes (quantization values below the main diagonal, that is, above the 36th in the usual zig zag scan), something is up with the standard quantization table. Taking a hint from the way, if I remember correctly, medical ultrasound images are stored, I tried "chopping off" diagonals (I believe that in medical ultrasound images everything below the main diagonal is simply dropped). To my eye, one diagonal down (that is, chopping everything below the 43rd zig zag entry) is the point at which more diagonals generally adds about as many artifacts as they remove.

For this reason, I do not take the high mode standard quantization values as gospel.

There is also the "obvious" taking the floor/round/ceiling of the symmetric part of the Luma table. Using the floor, this gives

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v.2012.02.17
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Recommended for use with cjpeg -sample 2x2
# Luma
16 11 12 15 21 32 50 66
11 12 13 18 24 46 62 73
12 13 16 23 38 56 73 75
15 18 23 29 53 75 83 80
21 24 38 53 68 95 103 94
32 46 56 75 95 104 117 96
50 62 73 83 103 117 120 102
66 73 75 80 94 96 102 87
# Chroma
17  18  24  47  99   99   128  192
18  21  26  66  99   99   128  192
24  26  56  99  99   128  192  256
47  66  99  99  128  192  256  512
99  99  99  128 192  256  512  1024
99  99  128 192 256  512  1024 2048
128 128 192 256 512  1024 2048 4096
192 192 256 512 1024 2048 4096 8192

Using these quantization tables instead of the standard ones produces, almost invariably, a slightly smaller file (even though I used floor, which means that, on average, the coefficients of the "new" Luma table are smaller than those of the standard one, which all things being equal---and they're not---should lead to larger files) which is basically impossible to distinguish quality wise. The one exception to "almost invariably" was a very poor quality incoming jpeg: standard tables produced a file with size 26434, the above tables, 26746.

Latest attempt. The small Luma savings I use to track Chroma better. Blue skylines matter.

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v.2012.02.18
# 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 11 12 15 21  32  50  66
11 12 13 18 24  46  62  73
12 13 16 23 38  56  73  75
15 18 23 29 53  75  83  84
21 24 38 53 68  95  103 105
32 46 56 75 95  104 117 120
50 62 73 83 103 117 120 124
66 73 75 84 105 120 124 129
# Chroma
18  13  17   33   67   128  256   512
13  15  19   45   99   128  256   512
17  19  39   67   128  256  512   1024
33  45  67   128  256  512  1024  2048
67  99  128  256  512  1024 2048  4096 
128 128 256  512  1024 2048 4096  8192
256 256 512  1024 2048 4096 8192  16384
512 512 1024 2048 4096 8192 16384 32768

(Of course the large values get clamped down to 255 with -baseline after the usual cjpeg quality rescaling. At quality 75, everything above 510 is clamped down, for example. At quality 99, it's everything above 12725

)

My latest chroma table killed off the high modes too quickly. Will fix.

I'm pretty happy with the following set, which has separate tables for Cb ("blue") and Cr ("red").

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v2012.02.19
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Chroma table recommended for use with cjpeg -sample 2x2 (values too small for 1x1)
# Y (luma)
16  11  11  15  21  34  50  65
11  12  13  18  24  48  62  69
13  13  16  23  38  56  72  71
15  18  23  29  53  77  83  80
21  24  38  53  68  98  104 100
30  44  56  73  92  105 117 117
50  62  74  83  104 119 121 122
67  77  79  88  108 119 122 122
# Cb (chroma #1)
17   19   24   37   68   148   384   1186
19   20   26   40   74   162   419   1293
24   26   34   52   96   210   544   1676
37   40   52   81   148  323   838   2585
68   74   96   148  272  593   1537  4741
148  162  210  323  593  1293  3353  10338
384  419  544  838  1537 3353  8694  12725
1186 1293 1676 2585 4741 10338 12725 12725
# Cr (chroma #2)
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

The one thing they do well is prevent wide chroma ringing near sharp interfaces. This is esp. important with -sample 2x2.

These tables work well at all quality levels.

Nicolas, why don't you post to a page a set of images compressed with different tables (in png perhaps?) so that we can easily evaluate the results.

Anyway, I'll try to evaluate your tables today or tomorrow. No guarantees, but I'll try.

Is there a standard set of images used for evaluation we could standardize on? I'm not speaking of Lena, Mandrill, etc... something modern, perhaps

@rnbc:

I'm still tweaking. I'll try to put a stable one up ASAP, and indicate so in the post. (May take me more than a week.)

The floor of the symmetric part luma is stable, and it's there to make a point. But it's probably not, by itself, worth switching.

Again, if I learned something, it is how good the standard ones are.

Here is the set I use now. I think that it still squashes chroma a little too quickly, it still slavishly resembles the standard tables more than I would guess is necessary, but resulting images look pretty good to me at comparable file size.

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v2012.02.20
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Chroma tables recommended for use with cjpeg -sample 2x2 (values too small for 1x1)
# Y (luma)
16  11  10  15  20  32  50  62
12  12  14  18  24  46  61  67
13  13  16  23  38  57  73  71
14  17  22  29  52  82  87  83
18  22  37  55  70  107 112 111
24  35  56  72  93  113 128 129
49  63  77  89  112 130 135 138
68  84  89  101 119 134 138 141
# Cb (chroma 1)
17   19   24   37   68   148   384   1186
19   20   26   40   74   162   419   1293
24   26   34   52   96   210   544   1676
37   40   52   81   148  323   838   2585
68   74   96   148  272  593   1537  4741
148  162  210  323  593  1293  3353  10338
384  419  544  838  1537 3353  8694  12725
1186 1293 1676 2585 4741 10338 12725 12725
# Cr (chroma 2)
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

When I have a minute, I'll see if I can post image results. (Busy with Masters supervision this week.) I can't use my standard test images (proprietary). I'll use high quality public domain ones (like http://upload.wikimedia.org/wikipedia/c ... walk_1.jpg). And I'll make sure that the new tables examples are always with a (slightly, ideally) smaller file.

Here is another set to make a point. I've not had time to fully test these, and they were derived very quickly. However, they (or related ones) may be even better than my last tweaked ones above.

The following set is (almost) completely synthetic. All three tables have all entries but to the very first (baseline) computed by applying Gaussian blur to the very first non-baseline entry. That is: They represent (except possibly for baseline: I've not taken the time to figure out the scaling between baseline and non-baseline) very crude approximations of Gaussian blur. Despite the lack of tweaking (although I've been toying with variants of this for a few weeks now, it only became really transparent to me what I was after late yesterday), these synthetic sets appear to actually be quite good.

The simple recipe corresponds to a 3x3 = 9-parameter (8, actually, because one can factor out of common factor) family of quantization tables, characterized by three baseline values, three non-baseline values, and three blur sigmas. It exploits the fact that Gaussian blur is Gaussian blur in the Fourier domain. I imagine I could reduce the number of free parameters with a little algebra (to relate the non-baseline to baseline within each table) and a lit search (to relate the baselines and sigmas across tables).

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v2012.02.20.22
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Chroma tables recommended for use with cjpeg -sample 2x2 (values too small for 1x1)
# Y (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
# Cb (chroma #1)
17   19   24   37   68   148   384   1186
19   20   26   40   74   162   419   1293
24   26   34   52   96   210   544   1676
37   40   52   81   148  323   838   2585
68   74   96   148  272  593   1537  4741
148  162  210  323  593  1293  3353  10338
384  419  544  838  1537 3353  8694  12725
1186 1293 1676 2585 4741 10338 12725 12725
# Cr (chroma #2)
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

@rnbc: If you want to check out something, try these synthetic ones first, even though they are very fresh.

I think that I blur away the chroma values too fast in the above. Will get back to this next week.

Again, forgive me for drawing conclusions based on very quickly done tests, but it appears to me that the purely synthetic ones fail to account for the fact that the human vision system is more sensitive to purely vertical/horizontal features (and, consequently, defects), or that the pixel arrangements make that more obvious (?), than diagonal ones.

This is not an "in your face" defect, but it appears to me to be there.

This, of course, can be fixed with three (one?) additional parameters.

Human visual system is more sensitive to defects in linear features, but not specifically horizontal or vertical. It just happens monitors are poor at displaying such features at an angle, so it happens horizontal/vertical gets better representation and is better seen and evaluated.

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

Here is a quick attempt at improving the tables for use with -sample 1x1 (which is so much better keeping colours bright, but which eats up more space, with given luma quality, than -sample 2x2 (of course)). They are synthetic, meaning that they do not (really) come from symmetrizing or smoothing or tweaking the standard tables. All three tables are based on a crude approximation of Gaussian blur in the spectral domain.

Code: Select all

# Nicolas Robidoux's better (?) JPEG quantization tables v2012.02.21
# Remix of ISO-IEC 10918-1 : 1993(E) Annex K
# Chroma tables recommended for use with cjpeg -sample 1x1 (values too big for 2x2)
# Y (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
# Cb (chroma #1)
17   18   27    51    124   395   1617  8563
18   21   30    58    141   449   1838  9734
27   30   45    85    208   659   2701  12725
51   58   85    161   395   1251  5127  12725
124  141  208   395   968   3070  12580 12725
395  449  659   1251  3070  9734  12725 12725
1617 1838 2701  5127  12580 12725 12725 12725
8563 9734 12725 12725 12725 12725 12725 12725
# Cr (chroma #2)
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

Use with a command like

Code: Select all

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

P.S. I'm pretty happy with these, even though I am far from certain that they are a significant improvement over the standard ones, esp. at very high quality and very low quality. Clearly, I have more to figure out. Manana.

The amazing thing (and certainly something useable if I had a lot of time to make this better) is that one can SEE the impact of changes in the table values. The ones near the top left corner, in particular, you better mess with carefully. (And I was not always as careful as I should have been.)

Legacy ImageMagick Discussions Archive

Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?

Re: Better JPEG quantization tables?