2009-12-31 18:25:35 +00:00
|
|
|
/*
|
|
|
|
* Common code related to colorspaces and conversion
|
|
|
|
*
|
|
|
|
* Copyleft (C) 2009 Reimar Döffinger <Reimar.Doeffinger@gmx.de>
|
|
|
|
*
|
2016-09-30 15:07:40 +00:00
|
|
|
* mp_invert_cmat based on DarkPlaces engine (relicensed from GPL to LGPL)
|
2012-10-24 18:20:13 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2009-12-31 18:25:35 +00:00
|
|
|
*
|
2016-01-19 17:36:34 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2009-12-31 18:25:35 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2009-12-31 18:25:35 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
2016-01-19 17:36:34 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2010-06-13 10:42:32 +00:00
|
|
|
*
|
2016-01-19 17:36:34 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2009-12-31 18:25:35 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <math.h>
|
2011-08-29 02:38:44 +00:00
|
|
|
#include <assert.h>
|
|
|
|
#include <libavutil/common.h>
|
2013-06-28 19:14:43 +00:00
|
|
|
#include <libavcodec/avcodec.h>
|
2011-08-29 02:38:44 +00:00
|
|
|
|
2015-01-06 14:21:26 +00:00
|
|
|
#include "mp_image.h"
|
2009-12-31 18:25:35 +00:00
|
|
|
#include "csputils.h"
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
#include "options/m_config.h"
|
2015-03-30 21:52:28 +00:00
|
|
|
#include "options/m_option.h"
|
2009-12-31 18:25:35 +00:00
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_csp_names[] = {
|
|
|
|
{"auto", MP_CSP_AUTO},
|
|
|
|
{"bt.601", MP_CSP_BT_601},
|
|
|
|
{"bt.709", MP_CSP_BT_709},
|
|
|
|
{"smpte-240m", MP_CSP_SMPTE_240M},
|
|
|
|
{"bt.2020-ncl", MP_CSP_BT_2020_NC},
|
|
|
|
{"bt.2020-cl", MP_CSP_BT_2020_C},
|
|
|
|
{"rgb", MP_CSP_RGB},
|
|
|
|
{"xyz", MP_CSP_XYZ},
|
|
|
|
{"ycgco", MP_CSP_YCGCO},
|
|
|
|
{0}
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
};
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_csp_levels_names[] = {
|
|
|
|
{"auto", MP_CSP_LEVELS_AUTO},
|
|
|
|
{"limited", MP_CSP_LEVELS_TV},
|
|
|
|
{"full", MP_CSP_LEVELS_PC},
|
|
|
|
{0}
|
2013-07-14 23:48:25 +00:00
|
|
|
};
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_csp_prim_names[] = {
|
|
|
|
{"auto", MP_CSP_PRIM_AUTO},
|
|
|
|
{"bt.601-525", MP_CSP_PRIM_BT_601_525},
|
|
|
|
{"bt.601-625", MP_CSP_PRIM_BT_601_625},
|
|
|
|
{"bt.709", MP_CSP_PRIM_BT_709},
|
|
|
|
{"bt.2020", MP_CSP_PRIM_BT_2020},
|
|
|
|
{"bt.470m", MP_CSP_PRIM_BT_470M},
|
2015-03-30 12:54:52 +00:00
|
|
|
{"apple", MP_CSP_PRIM_APPLE},
|
|
|
|
{"adobe", MP_CSP_PRIM_ADOBE},
|
|
|
|
{"prophoto", MP_CSP_PRIM_PRO_PHOTO},
|
|
|
|
{"cie1931", MP_CSP_PRIM_CIE_1931},
|
2016-03-19 01:27:46 +00:00
|
|
|
{"dci-p3", MP_CSP_PRIM_DCI_P3},
|
2017-12-14 21:19:54 +00:00
|
|
|
{"display-p3", MP_CSP_PRIM_DISPLAY_P3},
|
2016-06-26 17:57:29 +00:00
|
|
|
{"v-gamut", MP_CSP_PRIM_V_GAMUT},
|
2017-06-10 00:10:41 +00:00
|
|
|
{"s-gamut", MP_CSP_PRIM_S_GAMUT},
|
2023-02-27 15:39:33 +00:00
|
|
|
{"ebu3213", MP_CSP_PRIM_EBU_3213},
|
|
|
|
{"film-c", MP_CSP_PRIM_FILM_C},
|
|
|
|
{"aces-ap0", MP_CSP_PRIM_ACES_AP0},
|
|
|
|
{"aces-ap1", MP_CSP_PRIM_ACES_AP1},
|
2015-03-30 21:52:28 +00:00
|
|
|
{0}
|
2014-03-26 00:46:38 +00:00
|
|
|
};
|
|
|
|
|
2015-03-30 12:54:52 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_csp_trc_names[] = {
|
|
|
|
{"auto", MP_CSP_TRC_AUTO},
|
|
|
|
{"bt.1886", MP_CSP_TRC_BT_1886},
|
|
|
|
{"srgb", MP_CSP_TRC_SRGB},
|
|
|
|
{"linear", MP_CSP_TRC_LINEAR},
|
|
|
|
{"gamma1.8", MP_CSP_TRC_GAMMA18},
|
2018-08-22 12:39:40 +00:00
|
|
|
{"gamma2.0", MP_CSP_TRC_GAMMA20},
|
2015-03-30 12:54:52 +00:00
|
|
|
{"gamma2.2", MP_CSP_TRC_GAMMA22},
|
2018-08-22 12:39:40 +00:00
|
|
|
{"gamma2.4", MP_CSP_TRC_GAMMA24},
|
|
|
|
{"gamma2.6", MP_CSP_TRC_GAMMA26},
|
2015-03-30 12:54:52 +00:00
|
|
|
{"gamma2.8", MP_CSP_TRC_GAMMA28},
|
|
|
|
{"prophoto", MP_CSP_TRC_PRO_PHOTO},
|
2017-06-13 15:09:02 +00:00
|
|
|
{"pq", MP_CSP_TRC_PQ},
|
|
|
|
{"hlg", MP_CSP_TRC_HLG},
|
2016-06-26 17:28:06 +00:00
|
|
|
{"v-log", MP_CSP_TRC_V_LOG},
|
2017-06-10 00:05:28 +00:00
|
|
|
{"s-log1", MP_CSP_TRC_S_LOG1},
|
2017-06-10 00:51:32 +00:00
|
|
|
{"s-log2", MP_CSP_TRC_S_LOG2},
|
2023-01-24 06:54:01 +00:00
|
|
|
{"st428", MP_CSP_TRC_ST428},
|
2015-03-30 12:54:52 +00:00
|
|
|
{0}
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
};
|
|
|
|
|
2017-06-14 18:06:56 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_csp_light_names[] = {
|
|
|
|
{"auto", MP_CSP_LIGHT_AUTO},
|
|
|
|
{"display", MP_CSP_LIGHT_DISPLAY},
|
|
|
|
{"hlg", MP_CSP_LIGHT_SCENE_HLG},
|
|
|
|
{"709-1886", MP_CSP_LIGHT_SCENE_709_1886},
|
|
|
|
{"gamma1.2", MP_CSP_LIGHT_SCENE_1_2},
|
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_chroma_names[] = {
|
|
|
|
{"unknown", MP_CHROMA_AUTO},
|
2020-12-02 00:34:42 +00:00
|
|
|
{"uhd", MP_CHROMA_TOPLEFT},
|
2015-03-30 21:52:28 +00:00
|
|
|
{"mpeg2/4/h264",MP_CHROMA_LEFT},
|
|
|
|
{"mpeg1/jpeg", MP_CHROMA_CENTER},
|
|
|
|
{0}
|
2014-02-15 15:28:39 +00:00
|
|
|
};
|
|
|
|
|
2020-04-24 12:41:50 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_alpha_names[] = {
|
|
|
|
{"auto", MP_ALPHA_AUTO},
|
|
|
|
{"straight", MP_ALPHA_STRAIGHT},
|
|
|
|
{"premul", MP_ALPHA_PREMUL},
|
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
2016-11-08 16:53:55 +00:00
|
|
|
void mp_colorspace_merge(struct mp_colorspace *orig, struct mp_colorspace *new)
|
|
|
|
{
|
|
|
|
if (!orig->space)
|
|
|
|
orig->space = new->space;
|
|
|
|
if (!orig->levels)
|
|
|
|
orig->levels = new->levels;
|
|
|
|
if (!orig->primaries)
|
|
|
|
orig->primaries = new->primaries;
|
|
|
|
if (!orig->gamma)
|
|
|
|
orig->gamma = new->gamma;
|
|
|
|
if (!orig->sig_peak)
|
|
|
|
orig->sig_peak = new->sig_peak;
|
2017-06-14 18:06:56 +00:00
|
|
|
if (!orig->light)
|
|
|
|
orig->light = new->light;
|
2016-11-08 16:53:55 +00:00
|
|
|
}
|
|
|
|
|
2014-08-30 21:24:46 +00:00
|
|
|
// The short name _must_ match with what vf_stereo3d accepts (if supported).
|
2015-04-02 21:54:08 +00:00
|
|
|
// The long name in comments is closer to the Matroska spec (StereoMode element).
|
2014-08-30 21:54:19 +00:00
|
|
|
// The numeric index matches the Matroska StereoMode value. If you add entries
|
|
|
|
// that don't match Matroska, make sure demux_mkv.c rejects them properly.
|
2015-04-02 21:54:08 +00:00
|
|
|
const struct m_opt_choice_alternatives mp_stereo3d_names[] = {
|
2015-07-10 16:04:34 +00:00
|
|
|
{"no", -1}, // disable/invalid
|
2015-04-02 21:54:08 +00:00
|
|
|
{"mono", 0},
|
|
|
|
{"sbs2l", 1}, // "side_by_side_left"
|
|
|
|
{"ab2r", 2}, // "top_bottom_right"
|
|
|
|
{"ab2l", 3}, // "top_bottom_left"
|
|
|
|
{"checkr", 4}, // "checkboard_right" (unsupported by vf_stereo3d)
|
|
|
|
{"checkl", 5}, // "checkboard_left" (unsupported by vf_stereo3d)
|
|
|
|
{"irr", 6}, // "row_interleaved_right"
|
|
|
|
{"irl", 7}, // "row_interleaved_left"
|
|
|
|
{"icr", 8}, // "column_interleaved_right" (unsupported by vf_stereo3d)
|
|
|
|
{"icl", 9}, // "column_interleaved_left" (unsupported by vf_stereo3d)
|
|
|
|
{"arcc", 10}, // "anaglyph_cyan_red" (Matroska: unclear which mode)
|
|
|
|
{"sbs2r", 11}, // "side_by_side_right"
|
|
|
|
{"agmc", 12}, // "anaglyph_green_magenta" (Matroska: unclear which mode)
|
2015-12-18 15:06:09 +00:00
|
|
|
{"al", 13}, // "alternating frames left first"
|
|
|
|
{"ar", 14}, // "alternating frames right first"
|
2015-04-02 21:54:08 +00:00
|
|
|
{0}
|
2014-08-30 21:24:46 +00:00
|
|
|
};
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
enum mp_csp avcol_spc_to_mp_csp(int avcolorspace)
|
2012-08-20 21:03:59 +00:00
|
|
|
{
|
2013-06-28 19:14:43 +00:00
|
|
|
switch (avcolorspace) {
|
2015-01-06 12:46:08 +00:00
|
|
|
case AVCOL_SPC_BT709: return MP_CSP_BT_709;
|
|
|
|
case AVCOL_SPC_BT470BG: return MP_CSP_BT_601;
|
|
|
|
case AVCOL_SPC_BT2020_NCL: return MP_CSP_BT_2020_NC;
|
|
|
|
case AVCOL_SPC_BT2020_CL: return MP_CSP_BT_2020_C;
|
|
|
|
case AVCOL_SPC_SMPTE170M: return MP_CSP_BT_601;
|
|
|
|
case AVCOL_SPC_SMPTE240M: return MP_CSP_SMPTE_240M;
|
|
|
|
case AVCOL_SPC_RGB: return MP_CSP_RGB;
|
|
|
|
case AVCOL_SPC_YCOCG: return MP_CSP_YCGCO;
|
|
|
|
default: return MP_CSP_AUTO;
|
2012-08-20 21:03:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
enum mp_csp_levels avcol_range_to_mp_csp_levels(int avrange)
|
2012-08-20 21:03:59 +00:00
|
|
|
{
|
2013-06-28 19:14:43 +00:00
|
|
|
switch (avrange) {
|
2015-01-06 12:46:08 +00:00
|
|
|
case AVCOL_RANGE_MPEG: return MP_CSP_LEVELS_TV;
|
|
|
|
case AVCOL_RANGE_JPEG: return MP_CSP_LEVELS_PC;
|
|
|
|
default: return MP_CSP_LEVELS_AUTO;
|
2012-09-14 15:51:26 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-26 00:46:38 +00:00
|
|
|
enum mp_csp_prim avcol_pri_to_mp_csp_prim(int avpri)
|
|
|
|
{
|
|
|
|
switch (avpri) {
|
2015-01-06 12:46:08 +00:00
|
|
|
case AVCOL_PRI_SMPTE240M: // Same as below
|
|
|
|
case AVCOL_PRI_SMPTE170M: return MP_CSP_PRIM_BT_601_525;
|
|
|
|
case AVCOL_PRI_BT470BG: return MP_CSP_PRIM_BT_601_625;
|
|
|
|
case AVCOL_PRI_BT709: return MP_CSP_PRIM_BT_709;
|
|
|
|
case AVCOL_PRI_BT2020: return MP_CSP_PRIM_BT_2020;
|
2015-02-27 20:10:09 +00:00
|
|
|
case AVCOL_PRI_BT470M: return MP_CSP_PRIM_BT_470M;
|
2020-12-30 16:29:26 +00:00
|
|
|
case AVCOL_PRI_SMPTE431: return MP_CSP_PRIM_DCI_P3;
|
|
|
|
case AVCOL_PRI_SMPTE432: return MP_CSP_PRIM_DISPLAY_P3;
|
2015-01-06 12:46:08 +00:00
|
|
|
default: return MP_CSP_PRIM_AUTO;
|
2014-03-26 00:46:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
enum mp_csp_trc avcol_trc_to_mp_csp_trc(int avtrc)
|
|
|
|
{
|
|
|
|
switch (avtrc) {
|
|
|
|
case AVCOL_TRC_BT709:
|
|
|
|
case AVCOL_TRC_SMPTE170M:
|
|
|
|
case AVCOL_TRC_SMPTE240M:
|
|
|
|
case AVCOL_TRC_BT1361_ECG:
|
|
|
|
case AVCOL_TRC_BT2020_10:
|
|
|
|
case AVCOL_TRC_BT2020_12: return MP_CSP_TRC_BT_1886;
|
|
|
|
case AVCOL_TRC_IEC61966_2_1: return MP_CSP_TRC_SRGB;
|
|
|
|
case AVCOL_TRC_LINEAR: return MP_CSP_TRC_LINEAR;
|
vo_opengl: refactor shader generation (part 2)
This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL,
etc, as well as color management. Also adds a new gamma function (gamma22).
This adds new parameters to configure the CMS settings, in particular
letting us target simple colorspaces without requiring usage of a 3DLUT.
This adds smoothmotion. Mostly working, but it's still sensitive to
timing issues. It's based on an actual queue now, but the queue size
is kept small to avoid larger amounts of latency.
Also makes “upscale before blending” the default strategy.
This is justified because the "render after blending" thing doesn't seme
to work consistently any way (introduces stutter due to the way vsync
timing works, or something), so this behavior is a bit closer to master
and makes pausing/unpausing less weird/jumpy.
This adds the remaining scalers, including bicubic_fast, sharpen3,
sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also
consult scale-param1, which was undocumented in master.
This also implements cropping and chroma transformation, plus
rotation/flipping. These are inherently part of the same logic, although
it's a bit rough around the edges in some case, mainly due to the fallback
code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
|
|
|
case AVCOL_TRC_GAMMA22: return MP_CSP_TRC_GAMMA22;
|
2015-03-30 12:54:52 +00:00
|
|
|
case AVCOL_TRC_GAMMA28: return MP_CSP_TRC_GAMMA28;
|
2017-06-13 15:09:02 +00:00
|
|
|
case AVCOL_TRC_SMPTEST2084: return MP_CSP_TRC_PQ;
|
|
|
|
case AVCOL_TRC_ARIB_STD_B67: return MP_CSP_TRC_HLG;
|
2023-01-24 06:54:01 +00:00
|
|
|
case AVCOL_TRC_SMPTE428: return MP_CSP_TRC_ST428;
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
default: return MP_CSP_TRC_AUTO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
int mp_csp_to_avcol_spc(enum mp_csp colorspace)
|
2012-09-14 15:51:26 +00:00
|
|
|
{
|
|
|
|
switch (colorspace) {
|
2015-01-06 12:46:08 +00:00
|
|
|
case MP_CSP_BT_709: return AVCOL_SPC_BT709;
|
|
|
|
case MP_CSP_BT_601: return AVCOL_SPC_BT470BG;
|
|
|
|
case MP_CSP_BT_2020_NC: return AVCOL_SPC_BT2020_NCL;
|
|
|
|
case MP_CSP_BT_2020_C: return AVCOL_SPC_BT2020_CL;
|
|
|
|
case MP_CSP_SMPTE_240M: return AVCOL_SPC_SMPTE240M;
|
|
|
|
case MP_CSP_RGB: return AVCOL_SPC_RGB;
|
|
|
|
case MP_CSP_YCGCO: return AVCOL_SPC_YCOCG;
|
|
|
|
default: return AVCOL_SPC_UNSPECIFIED;
|
2012-09-14 15:51:26 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
int mp_csp_levels_to_avcol_range(enum mp_csp_levels range)
|
2012-09-14 15:51:26 +00:00
|
|
|
{
|
|
|
|
switch (range) {
|
2015-01-06 12:46:08 +00:00
|
|
|
case MP_CSP_LEVELS_TV: return AVCOL_RANGE_MPEG;
|
|
|
|
case MP_CSP_LEVELS_PC: return AVCOL_RANGE_JPEG;
|
|
|
|
default: return AVCOL_RANGE_UNSPECIFIED;
|
2012-08-20 21:03:59 +00:00
|
|
|
}
|
|
|
|
}
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
|
2014-03-26 00:46:38 +00:00
|
|
|
int mp_csp_prim_to_avcol_pri(enum mp_csp_prim prim)
|
|
|
|
{
|
|
|
|
switch (prim) {
|
2015-01-06 12:46:08 +00:00
|
|
|
case MP_CSP_PRIM_BT_601_525: return AVCOL_PRI_SMPTE170M;
|
|
|
|
case MP_CSP_PRIM_BT_601_625: return AVCOL_PRI_BT470BG;
|
|
|
|
case MP_CSP_PRIM_BT_709: return AVCOL_PRI_BT709;
|
|
|
|
case MP_CSP_PRIM_BT_2020: return AVCOL_PRI_BT2020;
|
2015-02-27 20:10:09 +00:00
|
|
|
case MP_CSP_PRIM_BT_470M: return AVCOL_PRI_BT470M;
|
2020-12-30 16:29:26 +00:00
|
|
|
case MP_CSP_PRIM_DCI_P3: return AVCOL_PRI_SMPTE431;
|
|
|
|
case MP_CSP_PRIM_DISPLAY_P3: return AVCOL_PRI_SMPTE432;
|
2015-01-06 12:46:08 +00:00
|
|
|
default: return AVCOL_PRI_UNSPECIFIED;
|
2014-03-26 00:46:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
int mp_csp_trc_to_avcol_trc(enum mp_csp_trc trc)
|
|
|
|
{
|
|
|
|
switch (trc) {
|
|
|
|
// We just call it BT.1886 since we're decoding, but it's still BT.709
|
2016-05-16 11:58:14 +00:00
|
|
|
case MP_CSP_TRC_BT_1886: return AVCOL_TRC_BT709;
|
|
|
|
case MP_CSP_TRC_SRGB: return AVCOL_TRC_IEC61966_2_1;
|
|
|
|
case MP_CSP_TRC_LINEAR: return AVCOL_TRC_LINEAR;
|
|
|
|
case MP_CSP_TRC_GAMMA22: return AVCOL_TRC_GAMMA22;
|
|
|
|
case MP_CSP_TRC_GAMMA28: return AVCOL_TRC_GAMMA28;
|
2017-06-13 15:09:02 +00:00
|
|
|
case MP_CSP_TRC_PQ: return AVCOL_TRC_SMPTEST2084;
|
|
|
|
case MP_CSP_TRC_HLG: return AVCOL_TRC_ARIB_STD_B67;
|
2023-01-24 06:54:01 +00:00
|
|
|
case MP_CSP_TRC_ST428: return AVCOL_TRC_SMPTE428;
|
2016-05-16 11:58:14 +00:00
|
|
|
default: return AVCOL_TRC_UNSPECIFIED;
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
enum mp_csp mp_csp_guess_colorspace(int width, int height)
|
|
|
|
{
|
|
|
|
return width >= 1280 || height > 576 ? MP_CSP_BT_709 : MP_CSP_BT_601;
|
|
|
|
}
|
|
|
|
|
2014-04-01 22:40:36 +00:00
|
|
|
enum mp_csp_prim mp_csp_guess_primaries(int width, int height)
|
|
|
|
{
|
|
|
|
// HD content
|
|
|
|
if (width >= 1280 || height > 576)
|
|
|
|
return MP_CSP_PRIM_BT_709;
|
|
|
|
|
|
|
|
switch (height) {
|
|
|
|
case 576: // Typical PAL content, including anamorphic/squared
|
|
|
|
return MP_CSP_PRIM_BT_601_625;
|
|
|
|
|
|
|
|
case 480: // Typical NTSC content, including squared
|
|
|
|
case 486: // NTSC Pro or anamorphic NTSC
|
|
|
|
return MP_CSP_PRIM_BT_601_525;
|
|
|
|
|
|
|
|
default: // No good metric, just pick BT.709 to minimize damage
|
|
|
|
return MP_CSP_PRIM_BT_709;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
enum mp_chroma_location avchroma_location_to_mp(int avloc)
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
{
|
2013-06-28 19:14:43 +00:00
|
|
|
switch (avloc) {
|
2020-12-02 00:34:42 +00:00
|
|
|
case AVCHROMA_LOC_TOPLEFT: return MP_CHROMA_TOPLEFT;
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
case AVCHROMA_LOC_LEFT: return MP_CHROMA_LEFT;
|
|
|
|
case AVCHROMA_LOC_CENTER: return MP_CHROMA_CENTER;
|
|
|
|
default: return MP_CHROMA_AUTO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-25 21:02:23 +00:00
|
|
|
int mp_chroma_location_to_av(enum mp_chroma_location mploc)
|
|
|
|
{
|
|
|
|
switch (mploc) {
|
2020-12-02 00:34:42 +00:00
|
|
|
case MP_CHROMA_TOPLEFT: return AVCHROMA_LOC_TOPLEFT;
|
2013-07-25 21:02:23 +00:00
|
|
|
case MP_CHROMA_LEFT: return AVCHROMA_LOC_LEFT;
|
|
|
|
case MP_CHROMA_CENTER: return AVCHROMA_LOC_CENTER;
|
|
|
|
default: return AVCHROMA_LOC_UNSPECIFIED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
// Return location of chroma samples relative to luma samples. 0/0 means
|
|
|
|
// centered. Other possible values are -1 (top/left) and +1 (right/bottom).
|
|
|
|
void mp_get_chroma_location(enum mp_chroma_location loc, int *x, int *y)
|
|
|
|
{
|
|
|
|
*x = 0;
|
|
|
|
*y = 0;
|
2020-12-02 00:34:42 +00:00
|
|
|
if (loc == MP_CHROMA_LEFT || loc == MP_CHROMA_TOPLEFT)
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
*x = -1;
|
2020-12-02 00:34:42 +00:00
|
|
|
if (loc == MP_CHROMA_TOPLEFT)
|
|
|
|
*y = -1;
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
}
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
void mp_invert_matrix3x3(float m[3][3])
|
|
|
|
{
|
|
|
|
float m00 = m[0][0], m01 = m[0][1], m02 = m[0][2],
|
|
|
|
m10 = m[1][0], m11 = m[1][1], m12 = m[1][2],
|
|
|
|
m20 = m[2][0], m21 = m[2][1], m22 = m[2][2];
|
|
|
|
|
|
|
|
// calculate the adjoint
|
|
|
|
m[0][0] = (m11 * m22 - m21 * m12);
|
|
|
|
m[0][1] = -(m01 * m22 - m21 * m02);
|
|
|
|
m[0][2] = (m01 * m12 - m11 * m02);
|
|
|
|
m[1][0] = -(m10 * m22 - m20 * m12);
|
|
|
|
m[1][1] = (m00 * m22 - m20 * m02);
|
|
|
|
m[1][2] = -(m00 * m12 - m10 * m02);
|
|
|
|
m[2][0] = (m10 * m21 - m20 * m11);
|
|
|
|
m[2][1] = -(m00 * m21 - m20 * m01);
|
|
|
|
m[2][2] = (m00 * m11 - m10 * m01);
|
|
|
|
|
|
|
|
// calculate the determinant (as inverse == 1/det * adjoint,
|
|
|
|
// adjoint * m == identity * det, so this calculates the det)
|
|
|
|
float det = m00 * m[0][0] + m10 * m[0][1] + m20 * m[0][2];
|
|
|
|
det = 1.0f / det;
|
|
|
|
|
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
for (int j = 0; j < 3; j++)
|
|
|
|
m[i][j] *= det;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// A := A * B
|
2015-02-03 15:38:38 +00:00
|
|
|
static void mp_mul_matrix3x3(float a[3][3], float b[3][3])
|
2014-06-22 06:33:43 +00:00
|
|
|
{
|
|
|
|
float a00 = a[0][0], a01 = a[0][1], a02 = a[0][2],
|
|
|
|
a10 = a[1][0], a11 = a[1][1], a12 = a[1][2],
|
|
|
|
a20 = a[2][0], a21 = a[2][1], a22 = a[2][2];
|
|
|
|
|
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
a[0][i] = a00 * b[0][i] + a01 * b[1][i] + a02 * b[2][i];
|
|
|
|
a[1][i] = a10 * b[0][i] + a11 * b[1][i] + a12 * b[2][i];
|
|
|
|
a[2][i] = a20 * b[0][i] + a21 * b[1][i] + a22 * b[2][i];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-06 12:46:08 +00:00
|
|
|
// return the primaries associated with a certain mp_csp_primaries val
|
2014-06-22 06:33:43 +00:00
|
|
|
struct mp_csp_primaries mp_get_csp_primaries(enum mp_csp_prim spc)
|
|
|
|
{
|
|
|
|
/*
|
2015-02-27 20:10:09 +00:00
|
|
|
Values from: ITU-R Recommendations BT.470-6, BT.601-7, BT.709-5, BT.2020-0
|
2014-06-22 06:33:43 +00:00
|
|
|
|
2015-02-27 20:10:09 +00:00
|
|
|
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-6-199811-S!!PDF-E.pdf
|
2014-06-22 06:33:43 +00:00
|
|
|
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf
|
|
|
|
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-5-200204-I!!PDF-E.pdf
|
|
|
|
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-0-201208-I!!PDF-E.pdf
|
2015-03-30 12:54:52 +00:00
|
|
|
|
|
|
|
Other colorspaces from https://en.wikipedia.org/wiki/RGB_color_space#Specifications
|
2014-06-22 06:33:43 +00:00
|
|
|
*/
|
|
|
|
|
2015-03-30 12:54:52 +00:00
|
|
|
// CIE standard illuminant series
|
|
|
|
static const struct mp_csp_col_xy
|
|
|
|
d50 = {0.34577, 0.35850},
|
|
|
|
d65 = {0.31271, 0.32902},
|
|
|
|
c = {0.31006, 0.31616},
|
2017-12-14 21:18:17 +00:00
|
|
|
dci = {0.31400, 0.35100},
|
2015-03-30 12:54:52 +00:00
|
|
|
e = {1.0/3.0, 1.0/3.0};
|
2014-06-22 06:33:43 +00:00
|
|
|
|
|
|
|
switch (spc) {
|
2015-02-27 20:10:09 +00:00
|
|
|
case MP_CSP_PRIM_BT_470M:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.670, 0.330},
|
|
|
|
.green = {0.210, 0.710},
|
|
|
|
.blue = {0.140, 0.080},
|
2015-03-30 12:54:52 +00:00
|
|
|
.white = c
|
2015-02-27 20:10:09 +00:00
|
|
|
};
|
2015-01-06 12:46:08 +00:00
|
|
|
case MP_CSP_PRIM_BT_601_525:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.630, 0.340},
|
|
|
|
.green = {0.310, 0.595},
|
|
|
|
.blue = {0.155, 0.070},
|
|
|
|
.white = d65
|
|
|
|
};
|
|
|
|
case MP_CSP_PRIM_BT_601_625:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.640, 0.330},
|
|
|
|
.green = {0.290, 0.600},
|
|
|
|
.blue = {0.150, 0.060},
|
|
|
|
.white = d65
|
|
|
|
};
|
|
|
|
// This is the default assumption if no colorspace information could
|
|
|
|
// be determined, eg. for files which have no video channel.
|
|
|
|
case MP_CSP_PRIM_AUTO:
|
|
|
|
case MP_CSP_PRIM_BT_709:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.640, 0.330},
|
|
|
|
.green = {0.300, 0.600},
|
|
|
|
.blue = {0.150, 0.060},
|
|
|
|
.white = d65
|
|
|
|
};
|
|
|
|
case MP_CSP_PRIM_BT_2020:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.708, 0.292},
|
|
|
|
.green = {0.170, 0.797},
|
|
|
|
.blue = {0.131, 0.046},
|
|
|
|
.white = d65
|
|
|
|
};
|
2015-03-30 12:54:52 +00:00
|
|
|
case MP_CSP_PRIM_APPLE:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.625, 0.340},
|
|
|
|
.green = {0.280, 0.595},
|
|
|
|
.blue = {0.115, 0.070},
|
|
|
|
.white = d65
|
|
|
|
};
|
|
|
|
case MP_CSP_PRIM_ADOBE:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.640, 0.330},
|
|
|
|
.green = {0.210, 0.710},
|
|
|
|
.blue = {0.150, 0.060},
|
|
|
|
.white = d65
|
|
|
|
};
|
|
|
|
case MP_CSP_PRIM_PRO_PHOTO:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.7347, 0.2653},
|
|
|
|
.green = {0.1596, 0.8404},
|
|
|
|
.blue = {0.0366, 0.0001},
|
|
|
|
.white = d50
|
|
|
|
};
|
|
|
|
case MP_CSP_PRIM_CIE_1931:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.7347, 0.2653},
|
|
|
|
.green = {0.2738, 0.7174},
|
|
|
|
.blue = {0.1666, 0.0089},
|
|
|
|
.white = e
|
|
|
|
};
|
2017-12-14 21:19:54 +00:00
|
|
|
// From SMPTE RP 431-2 and 432-1
|
2016-03-19 01:27:46 +00:00
|
|
|
case MP_CSP_PRIM_DCI_P3:
|
2017-12-14 21:19:54 +00:00
|
|
|
case MP_CSP_PRIM_DISPLAY_P3:
|
2016-03-19 01:27:46 +00:00
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.680, 0.320},
|
|
|
|
.green = {0.265, 0.690},
|
|
|
|
.blue = {0.150, 0.060},
|
2017-12-14 21:19:54 +00:00
|
|
|
.white = spc == MP_CSP_PRIM_DCI_P3 ? dci : d65
|
2016-03-19 01:27:46 +00:00
|
|
|
};
|
2016-06-26 17:57:29 +00:00
|
|
|
// From Panasonic VARICAM reference manual
|
|
|
|
case MP_CSP_PRIM_V_GAMUT:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.730, 0.280},
|
|
|
|
.green = {0.165, 0.840},
|
|
|
|
.blue = {0.100, -0.03},
|
|
|
|
.white = d65
|
|
|
|
};
|
2017-06-10 00:10:41 +00:00
|
|
|
// From Sony S-Log reference manual
|
|
|
|
case MP_CSP_PRIM_S_GAMUT:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.730, 0.280},
|
|
|
|
.green = {0.140, 0.855},
|
|
|
|
.blue = {0.100, -0.05},
|
|
|
|
.white = d65
|
|
|
|
};
|
2023-02-27 15:39:33 +00:00
|
|
|
// from EBU Tech. 3213-E
|
|
|
|
case MP_CSP_PRIM_EBU_3213:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.630, 0.340},
|
|
|
|
.green = {0.295, 0.605},
|
|
|
|
.blue = {0.155, 0.077},
|
|
|
|
.white = d65
|
|
|
|
};
|
|
|
|
// From H.273, traditional film with Illuminant C
|
|
|
|
case MP_CSP_PRIM_FILM_C:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.681, 0.319},
|
|
|
|
.green = {0.243, 0.692},
|
|
|
|
.blue = {0.145, 0.049},
|
|
|
|
.white = c
|
|
|
|
};
|
|
|
|
// From libplacebo source code
|
|
|
|
case MP_CSP_PRIM_ACES_AP0:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.7347, 0.2653},
|
|
|
|
.green = {0.0000, 1.0000},
|
|
|
|
.blue = {0.0001, -0.0770},
|
|
|
|
.white = {0.32168, 0.33767},
|
|
|
|
};
|
|
|
|
// From libplacebo source code
|
|
|
|
case MP_CSP_PRIM_ACES_AP1:
|
|
|
|
return (struct mp_csp_primaries) {
|
|
|
|
.red = {0.713, 0.293},
|
|
|
|
.green = {0.165, 0.830},
|
|
|
|
.blue = {0.128, 0.044},
|
|
|
|
.white = {0.32168, 0.33767},
|
|
|
|
};
|
2015-01-06 12:46:08 +00:00
|
|
|
default:
|
|
|
|
return (struct mp_csp_primaries) {{0}};
|
2014-06-22 06:33:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-10 12:01:25 +00:00
|
|
|
// Get the nominal peak for a given colorspace, relative to the reference white
|
|
|
|
// level. In other words, this returns the brightest encodable value that can
|
|
|
|
// be represented by a given transfer curve.
|
|
|
|
float mp_trc_nom_peak(enum mp_csp_trc trc)
|
2016-06-28 12:28:32 +00:00
|
|
|
{
|
|
|
|
switch (trc) {
|
2017-06-13 15:09:02 +00:00
|
|
|
case MP_CSP_TRC_PQ: return 10000.0 / MP_REF_WHITE;
|
2020-05-17 01:17:28 +00:00
|
|
|
case MP_CSP_TRC_HLG: return 12.0 / MP_REF_WHITE_HLG;
|
2017-06-10 12:01:25 +00:00
|
|
|
case MP_CSP_TRC_V_LOG: return 46.0855;
|
2017-06-10 00:05:28 +00:00
|
|
|
case MP_CSP_TRC_S_LOG1: return 6.52;
|
2017-06-10 00:51:32 +00:00
|
|
|
case MP_CSP_TRC_S_LOG2: return 9.212;
|
2016-06-28 12:28:32 +00:00
|
|
|
}
|
|
|
|
|
2017-06-10 12:01:25 +00:00
|
|
|
return 1.0;
|
2016-06-28 12:28:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool mp_trc_is_hdr(enum mp_csp_trc trc)
|
|
|
|
{
|
2017-06-10 12:01:25 +00:00
|
|
|
return mp_trc_nom_peak(trc) > 1.0;
|
2016-06-28 12:28:32 +00:00
|
|
|
}
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
// Compute the RGB/XYZ matrix as described here:
|
|
|
|
// http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
|
2017-06-16 23:55:08 +00:00
|
|
|
void mp_get_rgb2xyz_matrix(struct mp_csp_primaries space, float m[3][3])
|
2014-06-22 06:33:43 +00:00
|
|
|
{
|
|
|
|
float S[3], X[4], Z[4];
|
|
|
|
|
|
|
|
// Convert from CIE xyY to XYZ. Note that Y=1 holds true for all primaries
|
|
|
|
X[0] = space.red.x / space.red.y;
|
|
|
|
X[1] = space.green.x / space.green.y;
|
|
|
|
X[2] = space.blue.x / space.blue.y;
|
|
|
|
X[3] = space.white.x / space.white.y;
|
|
|
|
|
|
|
|
Z[0] = (1 - space.red.x - space.red.y) / space.red.y;
|
|
|
|
Z[1] = (1 - space.green.x - space.green.y) / space.green.y;
|
|
|
|
Z[2] = (1 - space.blue.x - space.blue.y) / space.blue.y;
|
|
|
|
Z[3] = (1 - space.white.x - space.white.y) / space.white.y;
|
|
|
|
|
|
|
|
// S = XYZ^-1 * W
|
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
m[0][i] = X[i];
|
|
|
|
m[1][i] = 1;
|
|
|
|
m[2][i] = Z[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
mp_invert_matrix3x3(m);
|
|
|
|
|
|
|
|
for (int i = 0; i < 3; i++)
|
|
|
|
S[i] = m[i][0] * X[3] + m[i][1] * 1 + m[i][2] * Z[3];
|
|
|
|
|
|
|
|
// M = [Sc * XYZc]
|
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
m[0][i] = S[i] * X[i];
|
|
|
|
m[1][i] = S[i] * 1;
|
|
|
|
m[2][i] = S[i] * Z[i];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-31 22:17:07 +00:00
|
|
|
// M := M * XYZd<-XYZs
|
2015-02-03 15:38:38 +00:00
|
|
|
static void mp_apply_chromatic_adaptation(struct mp_csp_col_xy src,
|
|
|
|
struct mp_csp_col_xy dest, float m[3][3])
|
2014-03-31 22:17:07 +00:00
|
|
|
{
|
|
|
|
// If the white points are nearly identical, this is a wasteful identity
|
|
|
|
// operation.
|
|
|
|
if (fabs(src.x - dest.x) < 1e-6 && fabs(src.y - dest.y) < 1e-6)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// XYZd<-XYZs = Ma^-1 * (I*[Cd/Cs]) * Ma
|
|
|
|
// http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html
|
|
|
|
float C[3][2], tmp[3][3] = {{0}};
|
|
|
|
|
|
|
|
// Ma = Bradford matrix, arguably most popular method in use today.
|
|
|
|
// This is derived experimentally and thus hard-coded.
|
|
|
|
float bradford[3][3] = {
|
|
|
|
{ 0.8951, 0.2664, -0.1614 },
|
|
|
|
{ -0.7502, 1.7135, 0.0367 },
|
|
|
|
{ 0.0389, -0.0685, 1.0296 },
|
|
|
|
};
|
|
|
|
|
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
// source cone
|
2017-06-16 23:55:08 +00:00
|
|
|
C[i][0] = bradford[i][0] * mp_xy_X(src)
|
2014-03-31 22:17:07 +00:00
|
|
|
+ bradford[i][1] * 1
|
2017-06-16 23:55:08 +00:00
|
|
|
+ bradford[i][2] * mp_xy_Z(src);
|
2014-03-31 22:17:07 +00:00
|
|
|
|
|
|
|
// dest cone
|
2017-06-16 23:55:08 +00:00
|
|
|
C[i][1] = bradford[i][0] * mp_xy_X(dest)
|
2014-03-31 22:17:07 +00:00
|
|
|
+ bradford[i][1] * 1
|
2017-06-16 23:55:08 +00:00
|
|
|
+ bradford[i][2] * mp_xy_Z(dest);
|
2014-03-31 22:17:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// tmp := I * [Cd/Cs] * Ma
|
|
|
|
for (int i = 0; i < 3; i++)
|
|
|
|
tmp[i][i] = C[i][1] / C[i][0];
|
|
|
|
|
|
|
|
mp_mul_matrix3x3(tmp, bradford);
|
|
|
|
|
|
|
|
// M := M * Ma^-1 * tmp
|
|
|
|
mp_invert_matrix3x3(bradford);
|
|
|
|
mp_mul_matrix3x3(m, bradford);
|
|
|
|
mp_mul_matrix3x3(m, tmp);
|
|
|
|
}
|
|
|
|
|
2016-07-05 16:03:19 +00:00
|
|
|
// get the coefficients of the source -> dest cms matrix
|
2015-01-06 12:46:08 +00:00
|
|
|
void mp_get_cms_matrix(struct mp_csp_primaries src, struct mp_csp_primaries dest,
|
|
|
|
enum mp_render_intent intent, float m[3][3])
|
2014-06-22 06:33:43 +00:00
|
|
|
{
|
2014-03-31 22:17:07 +00:00
|
|
|
float tmp[3][3];
|
|
|
|
|
|
|
|
// In saturation mapping, we don't care about accuracy and just want
|
|
|
|
// primaries to map to primaries, making this an identity transformation.
|
|
|
|
if (intent == MP_INTENT_SATURATION) {
|
|
|
|
for (int i = 0; i < 3; i++)
|
|
|
|
m[i][i] = 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
// RGBd<-RGBs = RGBd<-XYZd * XYZd<-XYZs * XYZs<-RGBs
|
|
|
|
// Equations from: http://www.brucelindbloom.com/index.html?Math.html
|
2014-03-31 22:17:07 +00:00
|
|
|
// Note: Perceptual is treated like relative colorimetric. There's no
|
|
|
|
// definition for perceptual other than "make it look good".
|
2014-06-22 06:33:43 +00:00
|
|
|
|
|
|
|
// RGBd<-XYZd, inverted from XYZd<-RGBd
|
|
|
|
mp_get_rgb2xyz_matrix(dest, m);
|
|
|
|
mp_invert_matrix3x3(m);
|
|
|
|
|
2014-03-31 22:17:07 +00:00
|
|
|
// Chromatic adaptation, except in absolute colorimetric intent
|
|
|
|
if (intent != MP_INTENT_ABSOLUTE_COLORIMETRIC)
|
|
|
|
mp_apply_chromatic_adaptation(src.white, dest.white, m);
|
2014-06-22 06:33:43 +00:00
|
|
|
|
|
|
|
// XYZs<-RGBs
|
|
|
|
mp_get_rgb2xyz_matrix(src, tmp);
|
|
|
|
mp_mul_matrix3x3(m, tmp);
|
|
|
|
}
|
|
|
|
|
2023-01-22 13:02:11 +00:00
|
|
|
// get the coefficients of an ST 428-1 xyz -> rgb conversion matrix
|
2015-01-06 12:46:08 +00:00
|
|
|
// intent = the rendering intent used to convert to the target primaries
|
2015-12-08 23:16:51 +00:00
|
|
|
static void mp_get_xyz2rgb_coeffs(struct mp_csp_params *params,
|
|
|
|
enum mp_render_intent intent, struct mp_cmat *m)
|
2015-01-06 12:46:08 +00:00
|
|
|
{
|
2023-01-22 13:02:11 +00:00
|
|
|
// Convert to DCI-P3
|
|
|
|
struct mp_csp_primaries prim = mp_get_csp_primaries(MP_CSP_PRIM_DCI_P3);
|
2015-01-06 15:49:53 +00:00
|
|
|
float brightness = params->brightness;
|
|
|
|
mp_get_rgb2xyz_matrix(prim, m->m);
|
|
|
|
mp_invert_matrix3x3(m->m);
|
2015-01-06 12:46:08 +00:00
|
|
|
|
|
|
|
// All non-absolute mappings want to map source white to target white
|
|
|
|
if (intent != MP_INTENT_ABSOLUTE_COLORIMETRIC) {
|
2023-01-22 13:02:11 +00:00
|
|
|
// SMPTE EG 432-1 Annex H defines the white point as equal energy
|
|
|
|
static const struct mp_csp_col_xy smpte432 = {1.0/3.0, 1.0/3.0};
|
|
|
|
mp_apply_chromatic_adaptation(smpte432, prim.white, m->m);
|
2015-01-06 12:46:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Since this outputs linear RGB rather than companded RGB, we
|
|
|
|
// want to linearize any brightness additions. 2 is a reasonable
|
|
|
|
// approximation for any sort of gamma function that could be in use.
|
|
|
|
// As this is an aesthetic setting only, any exact values do not matter.
|
2015-01-07 07:25:22 +00:00
|
|
|
brightness *= fabs(brightness);
|
2015-01-06 12:46:08 +00:00
|
|
|
|
2015-01-06 15:49:53 +00:00
|
|
|
for (int i = 0; i < 3; i++)
|
|
|
|
m->c[i] = brightness;
|
2015-01-06 12:46:08 +00:00
|
|
|
}
|
|
|
|
|
2015-12-07 22:41:29 +00:00
|
|
|
// Get multiplication factor required if image data is fit within the LSBs of a
|
2020-05-09 16:00:15 +00:00
|
|
|
// higher smaller bit depth fixed-point texture data.
|
|
|
|
// This is broken. Use mp_get_csp_uint_mul().
|
2015-12-07 22:41:29 +00:00
|
|
|
double mp_get_csp_mul(enum mp_csp csp, int input_bits, int texture_bits)
|
|
|
|
{
|
|
|
|
assert(texture_bits >= input_bits);
|
|
|
|
|
|
|
|
// Convenience for some irrelevant cases, e.g. rgb565 or disabling expansion.
|
|
|
|
if (!input_bits)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
// RGB always uses the full range available.
|
|
|
|
if (csp == MP_CSP_RGB)
|
|
|
|
return ((1LL << input_bits) - 1.) / ((1LL << texture_bits) - 1.);
|
|
|
|
|
|
|
|
if (csp == MP_CSP_XYZ)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
// High bit depth YUV uses a range shifted from 8 bit.
|
|
|
|
return (1LL << input_bits) / ((1LL << texture_bits) - 1.) * 255 / 256;
|
|
|
|
}
|
|
|
|
|
2020-05-09 16:00:15 +00:00
|
|
|
// Return information about color fixed point representation.his is needed for
|
|
|
|
// converting color from integer formats to or from float. Use as follows:
|
|
|
|
// float_val = uint_val * m + o
|
|
|
|
// uint_val = clamp(round((float_val - o) / m))
|
|
|
|
// See H.264/5 Annex E.
|
|
|
|
// csp: colorspace
|
|
|
|
// levels: full range flag
|
|
|
|
// component: ID of the channel, as in mp_regular_imgfmt:
|
|
|
|
// 1 is red/luminance/gray, 2 is green/Cb, 3 is blue/Cr, 4 is alpha.
|
|
|
|
// bits: number of significant bits, e.g. 10 for yuv420p10, 16 for p010
|
|
|
|
// out_m: returns factor to multiply the uint number with
|
|
|
|
// out_o: returns offset to add after multiplication
|
|
|
|
void mp_get_csp_uint_mul(enum mp_csp csp, enum mp_csp_levels levels,
|
|
|
|
int bits, int component, double *out_m, double *out_o)
|
|
|
|
{
|
|
|
|
uint16_t i_min = 0;
|
|
|
|
uint16_t i_max = (1u << bits) - 1;
|
|
|
|
double f_min = 0; // min. float value
|
|
|
|
|
|
|
|
if (csp != MP_CSP_RGB && component != 4) {
|
|
|
|
if (component == 2 || component == 3) {
|
|
|
|
f_min = (1u << (bits - 1)) / -(double)i_max; // force center => 0
|
|
|
|
|
|
|
|
if (levels != MP_CSP_LEVELS_PC && bits >= 8) {
|
|
|
|
i_min = 16 << (bits - 8); // => -0.5
|
|
|
|
i_max = 240 << (bits - 8); // => 0.5
|
|
|
|
f_min = -0.5;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (levels != MP_CSP_LEVELS_PC && bits >= 8) {
|
|
|
|
i_min = 16 << (bits - 8); // => 0
|
|
|
|
i_max = 235 << (bits - 8); // => 1
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
*out_m = 1.0 / (i_max - i_min);
|
|
|
|
*out_o = (1 + f_min) - i_max * *out_m;
|
|
|
|
}
|
|
|
|
|
2015-12-08 23:22:12 +00:00
|
|
|
/* Fill in the Y, U, V vectors of a yuv-to-rgb conversion matrix
|
2011-08-29 02:38:44 +00:00
|
|
|
* based on the given luma weights of the R, G and B components (lr, lg, lb).
|
|
|
|
* lr+lg+lb is assumed to equal 1.
|
|
|
|
* This function is meant for colorspaces satisfying the following
|
|
|
|
* conditions (which are true for common YUV colorspaces):
|
|
|
|
* - The mapping from input [Y, U, V] to output [R, G, B] is linear.
|
|
|
|
* - Y is the vector [1, 1, 1]. (meaning input Y component maps to 1R+1G+1B)
|
|
|
|
* - U maps to a value with zero R and positive B ([0, x, y], y > 0;
|
|
|
|
* i.e. blue and green only).
|
|
|
|
* - V maps to a value with zero B and positive R ([x, y, 0], x > 0;
|
|
|
|
* i.e. red and green only).
|
|
|
|
* - U and V are orthogonal to the luma vector [lr, lg, lb].
|
|
|
|
* - The magnitudes of the vectors U and V are the minimal ones for which
|
|
|
|
* the image of the set Y=[0...1],U=[-0.5...0.5],V=[-0.5...0.5] under the
|
|
|
|
* conversion function will cover the set R=[0...1],G=[0...1],B=[0...1]
|
|
|
|
* (the resulting matrix can be converted for other input/output ranges
|
|
|
|
* outside this function).
|
|
|
|
* Under these conditions the given parameters lr, lg, lb uniquely
|
|
|
|
* determine the mapping of Y, U, V to R, G, B.
|
|
|
|
*/
|
2015-01-06 15:49:53 +00:00
|
|
|
static void luma_coeffs(struct mp_cmat *mat, float lr, float lg, float lb)
|
2011-08-29 02:38:44 +00:00
|
|
|
{
|
|
|
|
assert(fabs(lr+lg+lb - 1) < 1e-6);
|
2015-01-06 15:49:53 +00:00
|
|
|
*mat = (struct mp_cmat) {
|
|
|
|
{ {1, 0, 2 * (1-lr) },
|
|
|
|
{1, -2 * (1-lb) * lb/lg, -2 * (1-lr) * lr/lg },
|
|
|
|
{1, 2 * (1-lb), 0 } },
|
|
|
|
// Constant coefficients (mat->c) not set here
|
|
|
|
};
|
2011-08-29 02:38:44 +00:00
|
|
|
}
|
|
|
|
|
2015-01-06 12:46:08 +00:00
|
|
|
// get the coefficients of the yuv -> rgb conversion matrix
|
2015-12-08 23:22:12 +00:00
|
|
|
void mp_get_csp_matrix(struct mp_csp_params *params, struct mp_cmat *m)
|
2011-08-28 02:52:46 +00:00
|
|
|
{
|
2016-06-29 07:16:13 +00:00
|
|
|
enum mp_csp colorspace = params->color.space;
|
2015-01-06 14:04:29 +00:00
|
|
|
if (colorspace <= MP_CSP_AUTO || colorspace >= MP_CSP_COUNT)
|
|
|
|
colorspace = MP_CSP_BT_601;
|
2016-06-29 07:16:13 +00:00
|
|
|
enum mp_csp_levels levels_in = params->color.levels;
|
2013-05-01 21:59:00 +00:00
|
|
|
if (levels_in <= MP_CSP_LEVELS_AUTO || levels_in >= MP_CSP_LEVELS_COUNT)
|
|
|
|
levels_in = MP_CSP_LEVELS_TV;
|
|
|
|
|
2015-01-06 14:04:29 +00:00
|
|
|
switch (colorspace) {
|
2011-08-29 02:38:44 +00:00
|
|
|
case MP_CSP_BT_601: luma_coeffs(m, 0.299, 0.587, 0.114 ); break;
|
|
|
|
case MP_CSP_BT_709: luma_coeffs(m, 0.2126, 0.7152, 0.0722); break;
|
|
|
|
case MP_CSP_SMPTE_240M: luma_coeffs(m, 0.2122, 0.7013, 0.0865); break;
|
2014-03-25 17:45:08 +00:00
|
|
|
case MP_CSP_BT_2020_NC: luma_coeffs(m, 0.2627, 0.6780, 0.0593); break;
|
2014-03-26 22:00:09 +00:00
|
|
|
case MP_CSP_BT_2020_C: {
|
|
|
|
// Note: This outputs into the [-0.5,0.5] range for chroma information.
|
|
|
|
// If this clips on any VO, a constant 0.5 coefficient can be added
|
|
|
|
// to the chroma channels to normalize them into [0,1]. This is not
|
|
|
|
// currently needed by anything, though.
|
2015-01-06 15:49:53 +00:00
|
|
|
*m = (struct mp_cmat){{{0, 0, 1}, {1, 0, 0}, {0, 1, 0}}};
|
2014-03-26 22:00:09 +00:00
|
|
|
break;
|
|
|
|
}
|
2013-05-01 21:59:00 +00:00
|
|
|
case MP_CSP_RGB: {
|
2015-01-06 15:49:53 +00:00
|
|
|
*m = (struct mp_cmat){{{1, 0, 0}, {0, 1, 0}, {0, 0, 1}}};
|
2013-05-01 21:59:00 +00:00
|
|
|
levels_in = -1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MP_CSP_XYZ: {
|
2014-06-22 06:33:43 +00:00
|
|
|
// The vo should probably not be using a matrix generated by this
|
2019-10-20 14:00:32 +00:00
|
|
|
// function for XYZ sources, but if it does, let's just convert it to
|
|
|
|
// an equivalent RGB space based on the colorimetry metadata it
|
|
|
|
// provided in mp_csp_params. (At the risk of clipping, if the
|
|
|
|
// chosen primaries are too small to fit the actual data)
|
2015-12-08 23:16:51 +00:00
|
|
|
mp_get_xyz2rgb_coeffs(params, MP_INTENT_RELATIVE_COLORIMETRIC, m);
|
2013-05-01 21:59:00 +00:00
|
|
|
levels_in = -1;
|
|
|
|
break;
|
|
|
|
}
|
2013-05-02 23:37:13 +00:00
|
|
|
case MP_CSP_YCGCO: {
|
2015-01-06 15:49:53 +00:00
|
|
|
*m = (struct mp_cmat) {
|
|
|
|
{{1, -1, 1},
|
|
|
|
{1, 1, 0},
|
|
|
|
{1, -1, -1}},
|
2013-05-02 23:37:13 +00:00
|
|
|
};
|
|
|
|
break;
|
|
|
|
}
|
2011-08-29 02:38:44 +00:00
|
|
|
default:
|
2023-01-10 18:26:51 +00:00
|
|
|
MP_ASSERT_UNREACHABLE();
|
2011-08-28 02:52:46 +00:00
|
|
|
};
|
2009-12-31 19:59:58 +00:00
|
|
|
|
2020-05-09 15:57:48 +00:00
|
|
|
if (params->is_float)
|
|
|
|
levels_in = -1;
|
|
|
|
|
2015-12-12 13:47:30 +00:00
|
|
|
if ((colorspace == MP_CSP_BT_601 || colorspace == MP_CSP_BT_709 ||
|
2015-12-26 17:36:55 +00:00
|
|
|
colorspace == MP_CSP_SMPTE_240M || colorspace == MP_CSP_BT_2020_NC))
|
2015-12-12 13:47:30 +00:00
|
|
|
{
|
|
|
|
// Hue is equivalent to rotating input [U, V] subvector around the origin.
|
|
|
|
// Saturation scales [U, V].
|
2015-12-26 17:36:55 +00:00
|
|
|
float huecos = params->gray ? 0 : params->saturation * cos(params->hue);
|
|
|
|
float huesin = params->gray ? 0 : params->saturation * sin(params->hue);
|
2015-12-12 13:47:30 +00:00
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
float u = m->m[i][1], v = m->m[i][2];
|
|
|
|
m->m[i][1] = huecos * u - huesin * v;
|
|
|
|
m->m[i][2] = huesin * u + huecos * v;
|
|
|
|
}
|
2011-08-29 02:38:44 +00:00
|
|
|
}
|
|
|
|
|
2015-12-07 22:41:29 +00:00
|
|
|
// 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;
|
2016-07-05 16:03:19 +00:00
|
|
|
// 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.
|
2017-05-13 15:20:28 +00:00
|
|
|
struct yuvlevels { double ymin, ymax, cmax, cmid; }
|
|
|
|
yuvlim = { 16*s, 235*s, 240*s, 128*s },
|
|
|
|
yuvfull = { 0*s, 255*s, 255*s, 128*s },
|
|
|
|
anyfull = { 0*s, 255*s, 255*s/2, 0 }, // cmax picked to make cmul=ymul
|
2011-08-29 02:38:44 +00:00
|
|
|
yuvlev;
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
switch (levels_in) {
|
|
|
|
case MP_CSP_LEVELS_TV: yuvlev = yuvlim; break;
|
|
|
|
case MP_CSP_LEVELS_PC: yuvlev = yuvfull; break;
|
2013-05-01 21:59:00 +00:00
|
|
|
case -1: yuvlev = anyfull; break;
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
default:
|
2023-01-10 18:26:51 +00:00
|
|
|
MP_ASSERT_UNREACHABLE();
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
}
|
|
|
|
|
2015-01-06 14:04:29 +00:00
|
|
|
int levels_out = params->levels_out;
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
if (levels_out <= MP_CSP_LEVELS_AUTO || levels_out >= MP_CSP_LEVELS_COUNT)
|
|
|
|
levels_out = MP_CSP_LEVELS_PC;
|
2011-08-29 02:38:44 +00:00
|
|
|
struct rgblevels { double min, max; }
|
2012-03-08 03:25:33 +00:00
|
|
|
rgblim = { 16/255., 235/255. },
|
|
|
|
rgbfull = { 0, 1 },
|
2011-08-29 02:38:44 +00:00
|
|
|
rgblev;
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
switch (levels_out) {
|
|
|
|
case MP_CSP_LEVELS_TV: rgblev = rgblim; break;
|
|
|
|
case MP_CSP_LEVELS_PC: rgblev = rgbfull; break;
|
2011-08-29 02:38:44 +00:00
|
|
|
default:
|
2023-01-10 18:26:51 +00:00
|
|
|
MP_ASSERT_UNREACHABLE();
|
2011-08-29 02:38:44 +00:00
|
|
|
}
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
|
2011-08-29 02:38:44 +00:00
|
|
|
double ymul = (rgblev.max - rgblev.min) / (yuvlev.ymax - yuvlev.ymin);
|
2017-05-13 15:20:28 +00:00
|
|
|
double cmul = (rgblev.max - rgblev.min) / (yuvlev.cmax - yuvlev.cmid) / 2;
|
2015-04-29 20:04:11 +00:00
|
|
|
|
|
|
|
// Contrast scales the output value range (gain)
|
|
|
|
ymul *= params->contrast;
|
|
|
|
cmul *= params->contrast;
|
|
|
|
|
2011-08-29 02:38:44 +00:00
|
|
|
for (int i = 0; i < 3; i++) {
|
2015-01-06 15:49:53 +00:00
|
|
|
m->m[i][0] *= ymul;
|
|
|
|
m->m[i][1] *= cmul;
|
|
|
|
m->m[i][2] *= cmul;
|
2015-04-29 20:04:11 +00:00
|
|
|
// Set c so that Y=umin,UV=cmid maps to RGB=min (black to black),
|
|
|
|
// also add brightness offset (black lift)
|
2015-01-06 15:49:53 +00:00
|
|
|
m->c[i] = rgblev.min - m->m[i][0] * yuvlev.ymin
|
2015-04-29 20:04:11 +00:00
|
|
|
- (m->m[i][1] + m->m[i][2]) * yuvlev.cmid
|
|
|
|
+ params->brightness;
|
2011-08-29 02:38:44 +00:00
|
|
|
}
|
2009-12-31 18:25:35 +00:00
|
|
|
}
|
|
|
|
|
2015-01-06 14:21:26 +00:00
|
|
|
// Set colorspace related fields in p from f. Don't touch other fields.
|
|
|
|
void mp_csp_set_image_params(struct mp_csp_params *params,
|
|
|
|
const struct mp_image_params *imgparams)
|
|
|
|
{
|
|
|
|
struct mp_image_params p = *imgparams;
|
|
|
|
mp_image_params_guess_csp(&p); // ensure consistency
|
2016-06-29 07:16:13 +00:00
|
|
|
params->color = p.color;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool mp_colorspace_equal(struct mp_colorspace c1, struct mp_colorspace c2)
|
|
|
|
{
|
|
|
|
return c1.space == c2.space &&
|
|
|
|
c1.levels == c2.levels &&
|
|
|
|
c1.primaries == c2.primaries &&
|
|
|
|
c1.gamma == c2.gamma &&
|
2017-07-18 00:20:50 +00:00
|
|
|
c1.light == c2.light &&
|
2017-06-10 12:01:25 +00:00
|
|
|
c1.sig_peak == c2.sig_peak;
|
2015-01-06 14:21:26 +00:00
|
|
|
}
|
|
|
|
|
2023-02-15 21:08:51 +00:00
|
|
|
enum mp_csp_equalizer_param {
|
|
|
|
MP_CSP_EQ_BRIGHTNESS,
|
|
|
|
MP_CSP_EQ_CONTRAST,
|
|
|
|
MP_CSP_EQ_HUE,
|
|
|
|
MP_CSP_EQ_SATURATION,
|
|
|
|
MP_CSP_EQ_GAMMA,
|
|
|
|
MP_CSP_EQ_COUNT,
|
|
|
|
};
|
|
|
|
|
|
|
|
// Default initialization with 0 is enough, except for the capabilities field
|
|
|
|
struct mp_csp_equalizer_opts {
|
|
|
|
// Value for each property is in the range [-100.0, 100.0].
|
|
|
|
// 0.0 is default, meaning neutral or no change.
|
|
|
|
float values[MP_CSP_EQ_COUNT];
|
|
|
|
int output_levels;
|
|
|
|
};
|
|
|
|
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
#define OPT_BASE_STRUCT struct mp_csp_equalizer_opts
|
|
|
|
|
|
|
|
const struct m_sub_options mp_csp_equalizer_conf = {
|
|
|
|
.opts = (const m_option_t[]) {
|
2023-02-15 21:01:50 +00:00
|
|
|
{"brightness", OPT_FLOAT(values[MP_CSP_EQ_BRIGHTNESS]),
|
options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-14 20:28:01 +00:00
|
|
|
M_RANGE(-100, 100)},
|
2023-02-15 21:01:50 +00:00
|
|
|
{"saturation", OPT_FLOAT(values[MP_CSP_EQ_SATURATION]),
|
options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-14 20:28:01 +00:00
|
|
|
M_RANGE(-100, 100)},
|
2023-02-15 21:01:50 +00:00
|
|
|
{"contrast", OPT_FLOAT(values[MP_CSP_EQ_CONTRAST]),
|
options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-14 20:28:01 +00:00
|
|
|
M_RANGE(-100, 100)},
|
2023-02-15 21:01:50 +00:00
|
|
|
{"hue", OPT_FLOAT(values[MP_CSP_EQ_HUE]),
|
options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-14 20:28:01 +00:00
|
|
|
M_RANGE(-100, 100)},
|
2023-02-15 21:01:50 +00:00
|
|
|
{"gamma", OPT_FLOAT(values[MP_CSP_EQ_GAMMA]),
|
options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-14 20:28:01 +00:00
|
|
|
M_RANGE(-100, 100)},
|
|
|
|
{"video-output-levels",
|
2023-02-15 21:01:50 +00:00
|
|
|
OPT_CHOICE_C(output_levels, mp_csp_levels_names)},
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
{0}
|
|
|
|
},
|
|
|
|
.size = sizeof(struct mp_csp_equalizer_opts),
|
|
|
|
};
|
|
|
|
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
// Copy settings from eq into params.
|
2023-02-15 21:08:51 +00:00
|
|
|
static void mp_csp_copy_equalizer_values(struct mp_csp_params *params,
|
|
|
|
const struct mp_csp_equalizer_opts *eq)
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
{
|
|
|
|
params->brightness = eq->values[MP_CSP_EQ_BRIGHTNESS] / 100.0;
|
|
|
|
params->contrast = (eq->values[MP_CSP_EQ_CONTRAST] + 100) / 100.0;
|
2015-01-06 15:50:33 +00:00
|
|
|
params->hue = eq->values[MP_CSP_EQ_HUE] / 100.0 * M_PI;
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
params->saturation = (eq->values[MP_CSP_EQ_SATURATION] + 100) / 100.0;
|
2015-02-03 15:52:44 +00:00
|
|
|
params->gamma = exp(log(8.0) * eq->values[MP_CSP_EQ_GAMMA] / 100.0);
|
2023-02-15 21:01:50 +00:00
|
|
|
params->levels_out = eq->output_levels;
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
}
|
|
|
|
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
struct mp_csp_equalizer_state *mp_csp_equalizer_create(void *ta_parent,
|
|
|
|
struct mpv_global *global)
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
{
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
struct m_config_cache *c = m_config_cache_alloc(ta_parent, global,
|
|
|
|
&mp_csp_equalizer_conf);
|
|
|
|
// The terrible, terrible truth.
|
|
|
|
return (struct mp_csp_equalizer_state *)c;
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
}
|
|
|
|
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
bool mp_csp_equalizer_state_changed(struct mp_csp_equalizer_state *state)
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
{
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
struct m_config_cache *c = (struct m_config_cache *)state;
|
|
|
|
return m_config_cache_update(c);
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
}
|
|
|
|
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
void mp_csp_equalizer_state_get(struct mp_csp_equalizer_state *state,
|
|
|
|
struct mp_csp_params *params)
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
{
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
struct m_config_cache *c = (struct m_config_cache *)state;
|
|
|
|
m_config_cache_update(c);
|
|
|
|
struct mp_csp_equalizer_opts *opts = c->opts;
|
|
|
|
mp_csp_copy_equalizer_values(params, opts);
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
}
|
2012-10-24 17:11:42 +00:00
|
|
|
|
2015-12-08 23:22:12 +00:00
|
|
|
void mp_invert_cmat(struct mp_cmat *out, struct mp_cmat *in)
|
2012-10-24 17:11:42 +00:00
|
|
|
{
|
2015-01-06 15:49:53 +00:00
|
|
|
*out = *in;
|
|
|
|
mp_invert_matrix3x3(out->m);
|
2012-10-24 17:11:42 +00:00
|
|
|
|
|
|
|
// fix the constant coefficient
|
|
|
|
// rgb = M * yuv + C
|
|
|
|
// M^-1 * rgb = yuv + M^-1 * C
|
|
|
|
// yuv = M^-1 * rgb - M^-1 * C
|
|
|
|
// ^^^^^^^^^^
|
2015-01-06 15:49:53 +00:00
|
|
|
out->c[0] = -(out->m[0][0] * in->c[0] + out->m[0][1] * in->c[1] + out->m[0][2] * in->c[2]);
|
|
|
|
out->c[1] = -(out->m[1][0] * in->c[0] + out->m[1][1] * in->c[1] + out->m[1][2] * in->c[2]);
|
|
|
|
out->c[2] = -(out->m[2][0] * in->c[0] + out->m[2][1] * in->c[1] + out->m[2][2] * in->c[2]);
|
2012-10-24 17:11:42 +00:00
|
|
|
}
|
2012-10-07 22:14:51 +00:00
|
|
|
|
|
|
|
// Multiply the color in c with the given matrix.
|
2015-12-08 23:08:00 +00:00
|
|
|
// i/o is {R, G, B} or {Y, U, V} (depending on input/output and matrix), using
|
|
|
|
// a fixed point representation with the given number of bits (so for bits==8,
|
|
|
|
// [0,255] maps to [0,1]). The output is clipped to the range as needed.
|
|
|
|
void mp_map_fixp_color(struct mp_cmat *matrix, int ibits, int in[3],
|
|
|
|
int obits, int out[3])
|
2012-10-07 22:14:51 +00:00
|
|
|
{
|
|
|
|
for (int i = 0; i < 3; i++) {
|
2015-01-06 15:49:53 +00:00
|
|
|
double val = matrix->c[i];
|
2012-10-07 22:14:51 +00:00
|
|
|
for (int x = 0; x < 3; x++)
|
2015-12-08 23:08:00 +00:00
|
|
|
val += matrix->m[i][x] * in[x] / ((1 << ibits) - 1);
|
|
|
|
int ival = lrint(val * ((1 << obits) - 1));
|
|
|
|
out[i] = av_clip(ival, 0, (1 << obits) - 1);
|
2012-10-07 22:14:51 +00:00
|
|
|
}
|
|
|
|
}
|