From 329a7147d003f70a017ad6560a1b671b66ae2b62 Mon Sep 17 00:00:00 2001 From: Niklas Haas Date: Tue, 5 Jul 2016 18:03:19 +0200 Subject: csp: document deviations from the references where they occur These mostly happen in situations where the correct behavior is relatively new and not found in the wild (therefore not worth implementing) and/or extremely complicated (and thus not worth worrying about the potential edge cases and UI changes). Still, it's best to document these where they happen to guide the poor souls maintaining these files in the future. --- video/csputils.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'video/csputils.c') diff --git a/video/csputils.c b/video/csputils.c index 8ed3b289b1..ea55d4ddbe 100644 --- a/video/csputils.c +++ b/video/csputils.c @@ -545,7 +545,7 @@ static void mp_apply_chromatic_adaptation(struct mp_csp_col_xy src, mp_mul_matrix3x3(m, tmp); } -// get the coefficients of the source -> bt2020 cms matrix +// get the coefficients of the source -> dest cms matrix void mp_get_cms_matrix(struct mp_csp_primaries src, struct mp_csp_primaries dest, enum mp_render_intent intent, float m[3][3]) { @@ -721,6 +721,10 @@ void mp_get_csp_matrix(struct mp_csp_params *params, struct mp_cmat *m) // The values below are written in 0-255 scale - thus bring s into range. double s = mp_get_csp_mul(colorspace, params->input_bits, params->texture_bits) / 255; + // NOTE: The yuvfull ranges as presented here are arguably ambiguous, + // and conflict with at least the full-range YCbCr/ICtCp values as defined + // by ITU-R BT.2100. If somebody ever complains about full-range YUV looking + // different from their reference display, this comment is probably why. struct yuvlevels { double ymin, ymax, cmin, cmid; } yuvlim = { 16*s, 235*s, 16*s, 128*s }, yuvfull = { 0*s, 255*s, 1*s, 128*s }, // '1' for symmetry around 128 -- cgit v1.2.3