Legacy ImageMagick Discussions Archive

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

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?

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

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]

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.

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

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...

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)

It is not clear to me how to read your resulting image? What parts correspond to what methods?

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.