Better JPEG quantization tables?
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
Dear Reader,
I've found some very interesting aspect due to RGB => YPbPr here:
http://sas-origin.onstreammedia.com/ori ... 1/Chan.pdf
sRGB should have been linearized (think photons) first before matrix conversion to YPbPr.
EDIT: this can't be done with jpeg, as far as I know.
Kind regards,
Jochen
I've found some very interesting aspect due to RGB => YPbPr here:
http://sas-origin.onstreammedia.com/ori ... 1/Chan.pdf
sRGB should have been linearized (think photons) first before matrix conversion to YPbPr.
EDIT: this can't be done with jpeg, as far as I know.
Kind regards,
Jochen
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
According to "YPbPr conversion should be done from linear RGB-Space instead of sRGB":
I've compared this manually this way (if someone else wants to try):
#!/bin/bash
# JPEG: Still Image Data Compression Standard
# von William B. Pennebaker,Joan L. Mitchell
# Sec. J.1.1.2: Bi-linear ... upsampling
# Sec. K.5: weighting of neighboring samples ...
wh=`identify -format "%w x %h!" "$1"`
convert "$1" -depth 16 -colorspace YPbPr -separate x%d.pgm
convert x1.pgm -filter Box -resize 50% -resize "$wh" x1b.pgm && mv x1b.pgm x1.pgm
convert x2.pgm -filter Box -resize 50% -resize "$wh" x2b.pgm && mv x2b.pgm x2.pgm
convert x?.pgm -combine -set colorspace YPbPr -colorspace sRGB -depth 8 wronger.ppm
# edit: the -gamma in the next line should be replaced by "-set colorspace sRGB -colorspace RGB -set colorspace sRGB" of course (the first -set is cosmetic)
convert "$1" -depth 16 -gamma 0.454545 -colorspace YPbPr -separate x%d.pgm
convert x1.pgm -filter Box -resize 50% -resize "$wh" x1b.pgm && mv x1b.pgm x1.pgm
convert x2.pgm -filter Box -resize 50% -resize "$wh" x2b.pgm && mv x2b.pgm x2.pgm
# edit: and the next -gamma should be replaced by "-set colorspace RGB -colorspace sRGB". Nice series, very easily understandable
convert x?.pgm -combine -set colorspace YPbPr -colorspace sRGB -gamma 2.2 -depth 8 righter.ppm
convert wronger.ppm righter.ppm -fx '15*(u-v)+0.5' diff.ppm
convert "$1" righter.ppm wronger.ppm diff.ppm v.tif
I'll find the differences on portraits more subtle than quantization errors, so this is Prio II.
Perhaps we can defeat this error by "do subsampling the righter way, and then do righterYPbPr -> sRGB" before feeding into the jpeg library.
N.B.: Has anybody some scientific references on how much the sampling factor (Chroma / Luma) should be?
I've compared this manually this way (if someone else wants to try):
#!/bin/bash
# JPEG: Still Image Data Compression Standard
# von William B. Pennebaker,Joan L. Mitchell
# Sec. J.1.1.2: Bi-linear ... upsampling
# Sec. K.5: weighting of neighboring samples ...
wh=`identify -format "%w x %h!" "$1"`
convert "$1" -depth 16 -colorspace YPbPr -separate x%d.pgm
convert x1.pgm -filter Box -resize 50% -resize "$wh" x1b.pgm && mv x1b.pgm x1.pgm
convert x2.pgm -filter Box -resize 50% -resize "$wh" x2b.pgm && mv x2b.pgm x2.pgm
convert x?.pgm -combine -set colorspace YPbPr -colorspace sRGB -depth 8 wronger.ppm
# edit: the -gamma in the next line should be replaced by "-set colorspace sRGB -colorspace RGB -set colorspace sRGB" of course (the first -set is cosmetic)
convert "$1" -depth 16 -gamma 0.454545 -colorspace YPbPr -separate x%d.pgm
convert x1.pgm -filter Box -resize 50% -resize "$wh" x1b.pgm && mv x1b.pgm x1.pgm
convert x2.pgm -filter Box -resize 50% -resize "$wh" x2b.pgm && mv x2b.pgm x2.pgm
# edit: and the next -gamma should be replaced by "-set colorspace RGB -colorspace sRGB". Nice series, very easily understandable
convert x?.pgm -combine -set colorspace YPbPr -colorspace sRGB -gamma 2.2 -depth 8 righter.ppm
convert wronger.ppm righter.ppm -fx '15*(u-v)+0.5' diff.ppm
convert "$1" righter.ppm wronger.ppm diff.ppm v.tif
I'll find the differences on portraits more subtle than quantization errors, so this is Prio II.
Perhaps we can defeat this error by "do subsampling the righter way, and then do righterYPbPr -> sRGB" before feeding into the jpeg library.
N.B.: Has anybody some scientific references on how much the sampling factor (Chroma / Luma) should be?
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
Yes, this way seems to work:
Do LinearRGB->YPbPr, subsampling chroma manually, ubsampling, reconstruction of sRGB,
Feed this into convert/cjpeg.
EDIT: perhaps chroma subsampling should be done in the C,h of the ciecam02 (think polar coordinates -> cartesian, this to subsample) insted of YPbPr (which is perhaps not-so-perceptual-uniform)
When subsampling, you have the chance of changing any ratio above 2x2 Subsampling, you could e.g. -scale 33.3333%, to subsample even more.
And, if you already splitted the linear Y channel off, here's time to -unsharp 0x1+0.5 -- without getting noisy areas brighter, because unsharp is here done in linear Y.
(I had a case with a dark bush wich went brighter after regular -unsharp)
But to my eyes ... prio II.
EDIT2: and tested with a black/green striped pattern... the result is very *not* clear (much less contrast?!) better than "wrong"
Kind regards,
Jochen
Do LinearRGB->YPbPr, subsampling chroma manually, ubsampling, reconstruction of sRGB,
Feed this into convert/cjpeg.
EDIT: perhaps chroma subsampling should be done in the C,h of the ciecam02 (think polar coordinates -> cartesian, this to subsample) insted of YPbPr (which is perhaps not-so-perceptual-uniform)
When subsampling, you have the chance of changing any ratio above 2x2 Subsampling, you could e.g. -scale 33.3333%, to subsample even more.
And, if you already splitted the linear Y channel off, here's time to -unsharp 0x1+0.5 -- without getting noisy areas brighter, because unsharp is here done in linear Y.
(I had a case with a dark bush wich went brighter after regular -unsharp)
But to my eyes ... prio II.
EDIT2: and tested with a black/green striped pattern... the result is very *not* clear (much less contrast?!) better than "wrong"
Kind regards,
Jochen
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
Subsampling: Tried ciecam02, forget about it, you would have to create rgb values, that after the "wrong" RGB -> YPbPr and back - would still be "fitting".
For the interested:
DCtune2.0 produces some interesting results, but still has problems with skin colors (reddish spots etc.) in my opinion.
If you wanna read something, look e. g. here:
A. J. Ahumada Jr.and A. B. Watson "A visual detection model for DCT coefficient quantization"
and
Andrew B. Watson "PERCEPTUAL OPTIMIZATION OF DCT COLOR QUANTIZATION MATRICES"
EDIT: and
RD-OPT by Ratnakar and Livny,
EDIT2: and
S. Battiato, M. Mancuso, A. Bosco, M. Guarnera - "Psychovisual and Statistical Optimization of Quantization Tables for DCT Compression Engines" [but on the luminance channel only]
For the interested:
DCtune2.0 produces some interesting results, but still has problems with skin colors (reddish spots etc.) in my opinion.
If you wanna read something, look e. g. here:
A. J. Ahumada Jr.and A. B. Watson "A visual detection model for DCT coefficient quantization"
and
Andrew B. Watson "PERCEPTUAL OPTIMIZATION OF DCT COLOR QUANTIZATION MATRICES"
EDIT: and
RD-OPT by Ratnakar and Livny,
EDIT2: and
S. Battiato, M. Mancuso, A. Bosco, M. Guarnera - "Psychovisual and Statistical Optimization of Quantization Tables for DCT Compression Engines" [but on the luminance channel only]
Last edited by Rumpelstielzchen on 2014-04-05T04:37:19-07:00, edited 2 times in total.
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
Still comparing with "state of the art" (?) dctune2.0 and my opinion is still that dctune2.0 - even with correct dpi and viewing distance - produces, using the previous mentioned http://www.dpreview.com/PrinterReviews/ ... k-sRGB.jpg scaled down to 1600x... at 250 KB filesize - signitficantly more color shifts+spots than my generated tables.
dctune2.0 produces somewhat more detail, but especially for portraits this is not satisfactory.
Ahumada-Watson has even more color errors.
dctune2.0 produces somewhat more detail, but especially for portraits this is not satisfactory.
Ahumada-Watson has even more color errors.
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
Well, here an example, to illustrate "what I'm talking about".
Original image from Petr Kratochvil, http://www.publicdomainpictures.net/ sized down using
Original (cjpeg -quality 100):
Target size: 26809 bytes.
My quantization Tables:
was wrong, see next post.
cjpeg -quality 28 -optimize -dct float ori.ppm :
wine dctune2.0.exe -f ori.ppm -p 4 -dpi 96
Original image from Petr Kratochvil, http://www.publicdomainpictures.net/ sized down using
Code: Select all
convert kratochvil.jpg -resize 535x800 ori.ppm
Target size: 26809 bytes.
My quantization Tables:
was wrong, see next post.
cjpeg -quality 28 -optimize -dct float ori.ppm :
wine dctune2.0.exe -f ori.ppm -p 4 -dpi 96
Last edited by Rumpelstielzchen on 2014-10-23T13:19:29-07:00, edited 1 time in total.
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
Mea culpa... the "my quantization tables" was using (x^2+y^2+10) as base formula ...
here now the right one with (x+y+1) (slightly better than above formula)
Difference between original vs cjpeg -q 28, my quantization tables
, optically enhanced:
Ok, here are the quantization tables:
10 20 29 40 49 59 69 78
20 30 39 49 59 69 78 89
30 39 49 59 69 79 88 98
40 49 59 69 79 89 98 108
49 59 68 78 88 98 108 118
59 69 78 88 98 108 118 128
69 79 88 98 108 118 128 138
78 89 99 108 118 128 138 147
7 13 20 26 32 39 45 52
13 19 26 33 39 46 52 59
20 26 32 39 45 52 59 65
26 32 39 46 52 59 65 71
33 39 46 52 59 65 71 77
39 46 52 59 65 71 78 85
45 52 58 65 71 78 84 91
52 59 65 71 78 84 91 97
7 14 21 28 35 43 49 57
14 21 28 36 42 49 56 64
21 28 35 42 49 56 63 70
28 35 43 49 57 63 71 78
35 42 49 57 63 71 77 85
42 50 57 63 70 78 85 92
49 56 64 71 78 85 92 98
56 63 70 78 85 91 99 106
use
cjpeg -qslots 0,1,2 -qtables q.txt -sample 2x2,1x1,1x1 -dct float -optimize ... > ...
Yes, Y component is more coarse quantized than Cb+Cr. Not good for hard contours like photos of text, but for portraits...
here now the right one with (x+y+1) (slightly better than above formula)
Difference between original vs cjpeg -q 28, my quantization tables
, optically enhanced:
Ok, here are the quantization tables:
10 20 29 40 49 59 69 78
20 30 39 49 59 69 78 89
30 39 49 59 69 79 88 98
40 49 59 69 79 89 98 108
49 59 68 78 88 98 108 118
59 69 78 88 98 108 118 128
69 79 88 98 108 118 128 138
78 89 99 108 118 128 138 147
7 13 20 26 32 39 45 52
13 19 26 33 39 46 52 59
20 26 32 39 45 52 59 65
26 32 39 46 52 59 65 71
33 39 46 52 59 65 71 77
39 46 52 59 65 71 78 85
45 52 58 65 71 78 84 91
52 59 65 71 78 84 91 97
7 14 21 28 35 43 49 57
14 21 28 36 42 49 56 64
21 28 35 42 49 56 63 70
28 35 43 49 57 63 71 78
35 42 49 57 63 71 77 85
42 50 57 63 70 78 85 92
49 56 64 71 78 85 92 98
56 63 70 78 85 91 99 106
use
cjpeg -qslots 0,1,2 -qtables q.txt -sample 2x2,1x1,1x1 -dct float -optimize ... > ...
Yes, Y component is more coarse quantized than Cb+Cr. Not good for hard contours like photos of text, but for portraits...
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
For the interested:
I've compared the original with
1. my quant. tables with
2. kakadu jpeg2000 (commercial)
3. openjpeg 2000 2.1.0
4. jasper (ubuntu 14.04)
Here the result (the less colourful stripes: myquant + kakadu)
I've compared the original with
1. my quant. tables with
2. kakadu jpeg2000 (commercial)
3. openjpeg 2000 2.1.0
4. jasper (ubuntu 14.04)
Here the result (the less colourful stripes: myquant + kakadu)
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: Better JPEG quantization tables?
It is not clear to me how to read your resulting image? What parts correspond to what methods?
-
- Posts: 22
- Joined: 2014-03-30T05:04:26-07:00
- Authentication code: 6789
Re: Better JPEG quantization tables?
top left triangle: my (jpeg) quantization tables,
stripe below: kakadu jpeg2000
stripe below: openjpeg(2000)
stripe below: jasper
and then the same sequence down again.
I've made some tests with irfanview jp2-Plugin (luratech) export (max. 640x480): kakadu is better - but luratech is still far better than openjpeg + jasper in terms of color stability.
Perhaps this is just one thing to adjust in openjpeg/jasper, but I did not find such settings quickly.
stripe below: kakadu jpeg2000
stripe below: openjpeg(2000)
stripe below: jasper
and then the same sequence down again.
I've made some tests with irfanview jp2-Plugin (luratech) export (max. 640x480): kakadu is better - but luratech is still far better than openjpeg + jasper in terms of color stability.
Perhaps this is just one thing to adjust in openjpeg/jasper, but I did not find such settings quickly.