[PATCH] Correct colour scaling for r6xx-r7xx Xv
This should fix the "video looks washed out" issue that some people have noticed. Applies to planar only at the moment. See commit comment for details. Also at 'better-xv' branch of http://yangman.ca/git/xf86-video-radeonhd -- Yang Zhao http://yangman.ca
2009/2/11 Yang Zhao
This should fix the "video looks washed out" issue that some people have noticed. Applies to planar only at the moment.
See commit comment for details.
Also at 'better-xv' branch of http://yangman.ca/git/xf86-video-radeonhd
It works great for me! Colors differ from x11 but difference is so small there is no way to say which one is better. I think difference may be something about +-3 in H or S or L (using HSL color space, Xv uses other probably) when comparing new (your) Xv to X11, so really nothing to think about. I use 34xx Mobility (M82) -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Feb 11, 09 11:28:56 -0800, Yang Zhao wrote:
static float ps_alu_consts[] = { - 1.0, 0.0, 1.13983, -1.13983/2, // r - c[0] - 1.0, -0.39465, -0.5806, (0.39465+0.5806)/2, // g - c[1] - 1.0, 2.03211, 0.0, -2.03211/2, // b - c[2] + 1.0, 0.0, 1.4020, 0, // r - c[0] + 1.0, -0.34414, -0.71414, 0, // g - c[1] + 1.0, 1.7720, 0.0, 0, // b - c[2] + /* Constants for undoing Y'CbCr scaling + * - Y' is scaled from 16:235 + * - Cb/Cr are scaled from 16:240 + * Unscaled value N' = N * N_mul + N_shift (N' in range [-0.5, 0.5]) + * Vector is [Y_mul, Y_shfit, C_mul, C_shift] + */ + 256.0/219.0, -16.0/219.0, 256.0/224.0, -128.0/224.0,
I don't understand this, Alex. You are changing *both* the color
conversion matrix *and* introducing scaling functions?!?
The scaling can be perfectly embedded in the color matrix.
Matthias
--
Matthias Hopf
2009/2/13 Matthias Hopf
On Feb 11, 09 11:28:56 -0800, Yang Zhao wrote:
static float ps_alu_consts[] = { - 1.0, 0.0, 1.13983, -1.13983/2, // r - c[0] - 1.0, -0.39465, -0.5806, (0.39465+0.5806)/2, // g - c[1] - 1.0, 2.03211, 0.0, -2.03211/2, // b - c[2] + 1.0, 0.0, 1.4020, 0, // r - c[0] + 1.0, -0.34414, -0.71414, 0, // g - c[1] + 1.0, 1.7720, 0.0, 0, // b - c[2] + /* Constants for undoing Y'CbCr scaling + * - Y' is scaled from 16:235 + * - Cb/Cr are scaled from 16:240 + * Unscaled value N' = N * N_mul + N_shift (N' in range [-0.5, 0.5]) + * Vector is [Y_mul, Y_shfit, C_mul, C_shift] + */ + 256.0/219.0, -16.0/219.0, 256.0/224.0, -128.0/224.0,
I don't understand this, Alex. You are changing *both* the color conversion matrix *and* introducing scaling functions?!?
The change to the conversion matrix is actually to make it follow BT.709 instead of BT.601. The former seemed like a better default, as it's what's used in HD media, and the difference between the two is claimed to be mostly negligible.
The scaling can be perfectly embedded in the color matrix.
My linear algebra is a little rusty, so I wasn't sure if was possible to fold the 2 sets scaling multiplier and offset into the conversion matrix when I made the patch. I can give this another look-over. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/2/13 Yang Zhao
2009/2/13 Matthias Hopf
: On Feb 11, 09 11:28:56 -0800, Yang Zhao wrote:
static float ps_alu_consts[] = { - 1.0, 0.0, 1.13983, -1.13983/2, // r - c[0] - 1.0, -0.39465, -0.5806, (0.39465+0.5806)/2, // g - c[1] - 1.0, 2.03211, 0.0, -2.03211/2, // b - c[2] + 1.0, 0.0, 1.4020, 0, // r - c[0] + 1.0, -0.34414, -0.71414, 0, // g - c[1] + 1.0, 1.7720, 0.0, 0, // b - c[2] + /* Constants for undoing Y'CbCr scaling + * - Y' is scaled from 16:235 + * - Cb/Cr are scaled from 16:240 + * Unscaled value N' = N * N_mul + N_shift (N' in range [-0.5, 0.5]) + * Vector is [Y_mul, Y_shfit, C_mul, C_shift] + */ + 256.0/219.0, -16.0/219.0, 256.0/224.0, -128.0/224.0,
I don't understand this, Alex. You are changing *both* the color conversion matrix *and* introducing scaling functions?!?
The change to the conversion matrix is actually to make it follow BT.709 instead of BT.601. The former seemed like a better default, as it's what's used in HD media, and the difference between the two is claimed to be mostly negligible.
Ops, that's not quite true either. What was there before was Y'UV to RGB. What we actually want for digital media is Y'CbCr to RGB, which is ambiguously (and somewhat incorrectly) labelled as "YUV" in Xv. The new version is with coefficients for BT.601. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Feb 13, 09 16:58:15 -0800, Yang Zhao wrote:
What was there before was Y'UV to RGB. What we actually want for
So it was the dead old NTSC color space?
digital media is Y'CbCr to RGB, which is ambiguously (and somewhat incorrectly) labelled as "YUV" in Xv.
I remember that :-]
Thanks
Matthias
--
Matthias Hopf
On Feb 13, 09 09:29:45 -0800, Yang Zhao wrote:
2009/2/13 Matthias Hopf
: I don't understand this, Alex. You are changing *both* the color conversion matrix *and* introducing scaling functions?!?
The change to the conversion matrix is actually to make it follow BT.709 instead of BT.601. The former seemed like a better default, as
Ah, I see. Then everything makes sense. Alex, Yang, sorry that I apparently mixed you both up.
it's what's used in HD media, and the difference between the two is claimed to be mostly negligible.
Which is interesting, because the coefficients are actually pretty different.
The scaling can be perfectly embedded in the color matrix.
My linear algebra is a little rusty, so I wasn't sure if was possible to fold the 2 sets scaling multiplier and offset into the conversion matrix when I made the patch. I can give this another look-over.
;-)
It's possible with 4x4 matrices, and input vectors (read: color) with a
1.0 in the forth component. Analogous to homogeneous coordinates.
Matthias
--
Matthias Hopf
participants (3)
-
Matthias Hopf
-
Rafał Miłecki
-
Yang Zhao