| Message ID | 20161030070746.37115-2-vittorio.giovara@gmail.com |
|---|---|
| State | Accepted |
| Commit | 2996604acda448fcba057ddc9259f95538fdb2b1 |
| Headers | show |
Hi, On Sun, Oct 30, 2016 at 3:07 AM, Vittorio Giovara < vittorio.giovara@gmail.com> wrote: > Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com> > --- > This is a little hackish, not sure how to represent the matrix otherwise. Haha :) I have to admit I hadn't put much thought into YCgCo yet. It's a little hacky but I guess it's OK... I think the primary reason some people - at some point in ancient history, certainly not today - might have cared about YCgCo is because the conversion between RGB and YCgCo is so trivial. For example, YCgCo to RGB is two butterflies (an interleaved add/sub pair), which is incredibly appealing from a performance point of view. But we're not using that property here... I'm not saying it's bad, and it's probably totally irrelevant, especially given how insignificant YCgCo is anyway, but it's worth noting. Ronald
Hi, On Sun, Oct 30, 2016 at 9:14 AM, Ronald S. Bultje <rsbultje@gmail.com> wrote: > Hi, > > On Sun, Oct 30, 2016 at 3:07 AM, Vittorio Giovara < > vittorio.giovara@gmail.com> wrote: > >> Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com> >> --- >> This is a little hackish, not sure how to represent the matrix otherwise. > > > Haha :) I have to admit I hadn't put much thought into YCgCo yet. It's a > little hacky but I guess it's OK... > > I think the primary reason some people - at some point in ancient history, > certainly not today - might have cared about YCgCo is because the > conversion between RGB and YCgCo is so trivial. For example, YCgCo to RGB > is two butterflies (an interleaved add/sub pair), which is incredibly > appealing from a performance point of view. But we're not using that > property here... > > I'm not saying it's bad, and it's probably totally irrelevant, especially > given how insignificant YCgCo is anyway, but it's worth noting. > Pushed. Ronald
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c index d26f658..7e0bafa 100644 --- a/libavfilter/vf_colorspace.c +++ b/libavfilter/vf_colorspace.c @@ -175,6 +175,13 @@ typedef struct ColorSpaceContext { // FIXME dithering if bitdepth goes down? // FIXME bitexact for fate integration? +static const double ycgco_matrix[3][3] = +{ + { 0.25, 0.5, 0.25 }, + { -0.25, 0.5, -0.25 }, + { 0.5, 0, -0.5 }, +}; + /* * All constants explained in e.g. https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html * The older ones (bt470bg/m) are also explained in their respective ITU docs @@ -187,6 +194,7 @@ static const struct LumaCoefficients luma_coefficients[AVCOL_SPC_NB] = { [AVCOL_SPC_SMPTE170M] = { 0.299, 0.587, 0.114 }, [AVCOL_SPC_BT709] = { 0.2126, 0.7152, 0.0722 }, [AVCOL_SPC_SMPTE240M] = { 0.212, 0.701, 0.087 }, + [AVCOL_SPC_YCOCG] = { 0.25, 0.5, 0.25 }, [AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 }, [AVCOL_SPC_BT2020_CL] = { 0.2627, 0.6780, 0.0593 }, }; @@ -209,6 +217,12 @@ static void fill_rgb2yuv_table(const struct LumaCoefficients *coeffs, { double bscale, rscale; + // special ycgco matrix + if (coeffs->cr == 0.25 && coeffs->cg == 0.5 && coeffs->cb == 0.25) { + memcpy(rgb2yuv, ycgco_matrix, sizeof(double) * 9); + return; + } + rgb2yuv[0][0] = coeffs->cr; rgb2yuv[0][1] = coeffs->cg; rgb2yuv[0][2] = coeffs->cb; @@ -1047,6 +1061,7 @@ static const AVOption colorspace_options[] = { ENUM("bt470bg", AVCOL_SPC_BT470BG, "csp"), ENUM("smpte170m", AVCOL_SPC_SMPTE170M, "csp"), ENUM("smpte240m", AVCOL_SPC_SMPTE240M, "csp"), + ENUM("ycgco", AVCOL_SPC_YCGCO, "csp"), ENUM("bt2020ncl", AVCOL_SPC_BT2020_NCL, "csp"), { "range", "Output color range",
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com> --- This is a little hackish, not sure how to represent the matrix otherwise. Please CC. Vittorio libavfilter/vf_colorspace.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)