FFmpeg eq filter complex: Contrast
I am playing with the eq filter in FFmpeg:
https://ffmpeg.org/ffmpeg-filters.html#eq
Using a command like:
ffmpeg -y -loop 1 -i input.jpg -filter_complex "[0:v]eq=1:0:1:1:1:1:1:1[outv]" -map [outv] -c:v libx264 -t 3 -pix_fmt yuv420p out.mp4 # does nothing
The documentation suggests that the first component of the filter is contrast:
Set the contrast expression. The value must be a float value in range -2.0 to 2.0. The default value is "0".
However, I found that for no change in contrast to happen, the value should be "1". Shouldn't this be the default?
Anyway, I am confused if this first value is even contrast. It doesn't behave as I would expect contrast to. I am comparing it to e.g. css -webkit-filter: contrast(x)
. In CSS, contrast(0)
makes the entire image grey. However, in FFmpeg, the image appears to be part yellow and part grey (presumably dependent on my image:
CSS contrast(-1)
is invalid. However, in FFmpeg, contrast -1 is almost an inverted contrast. I understand the two things were implemented completely separately, but I would have expected an approximate relation. Am I misunderstanding the eq filters contrast value?
ffmpeg colors contrast
add a comment |
I am playing with the eq filter in FFmpeg:
https://ffmpeg.org/ffmpeg-filters.html#eq
Using a command like:
ffmpeg -y -loop 1 -i input.jpg -filter_complex "[0:v]eq=1:0:1:1:1:1:1:1[outv]" -map [outv] -c:v libx264 -t 3 -pix_fmt yuv420p out.mp4 # does nothing
The documentation suggests that the first component of the filter is contrast:
Set the contrast expression. The value must be a float value in range -2.0 to 2.0. The default value is "0".
However, I found that for no change in contrast to happen, the value should be "1". Shouldn't this be the default?
Anyway, I am confused if this first value is even contrast. It doesn't behave as I would expect contrast to. I am comparing it to e.g. css -webkit-filter: contrast(x)
. In CSS, contrast(0)
makes the entire image grey. However, in FFmpeg, the image appears to be part yellow and part grey (presumably dependent on my image:
CSS contrast(-1)
is invalid. However, in FFmpeg, contrast -1 is almost an inverted contrast. I understand the two things were implemented completely separately, but I would have expected an approximate relation. Am I misunderstanding the eq filters contrast value?
ffmpeg colors contrast
Maybe this helps? github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_eq.c#L77
– slhck
Jun 16 '15 at 7:30
add a comment |
I am playing with the eq filter in FFmpeg:
https://ffmpeg.org/ffmpeg-filters.html#eq
Using a command like:
ffmpeg -y -loop 1 -i input.jpg -filter_complex "[0:v]eq=1:0:1:1:1:1:1:1[outv]" -map [outv] -c:v libx264 -t 3 -pix_fmt yuv420p out.mp4 # does nothing
The documentation suggests that the first component of the filter is contrast:
Set the contrast expression. The value must be a float value in range -2.0 to 2.0. The default value is "0".
However, I found that for no change in contrast to happen, the value should be "1". Shouldn't this be the default?
Anyway, I am confused if this first value is even contrast. It doesn't behave as I would expect contrast to. I am comparing it to e.g. css -webkit-filter: contrast(x)
. In CSS, contrast(0)
makes the entire image grey. However, in FFmpeg, the image appears to be part yellow and part grey (presumably dependent on my image:
CSS contrast(-1)
is invalid. However, in FFmpeg, contrast -1 is almost an inverted contrast. I understand the two things were implemented completely separately, but I would have expected an approximate relation. Am I misunderstanding the eq filters contrast value?
ffmpeg colors contrast
I am playing with the eq filter in FFmpeg:
https://ffmpeg.org/ffmpeg-filters.html#eq
Using a command like:
ffmpeg -y -loop 1 -i input.jpg -filter_complex "[0:v]eq=1:0:1:1:1:1:1:1[outv]" -map [outv] -c:v libx264 -t 3 -pix_fmt yuv420p out.mp4 # does nothing
The documentation suggests that the first component of the filter is contrast:
Set the contrast expression. The value must be a float value in range -2.0 to 2.0. The default value is "0".
However, I found that for no change in contrast to happen, the value should be "1". Shouldn't this be the default?
Anyway, I am confused if this first value is even contrast. It doesn't behave as I would expect contrast to. I am comparing it to e.g. css -webkit-filter: contrast(x)
. In CSS, contrast(0)
makes the entire image grey. However, in FFmpeg, the image appears to be part yellow and part grey (presumably dependent on my image:
CSS contrast(-1)
is invalid. However, in FFmpeg, contrast -1 is almost an inverted contrast. I understand the two things were implemented completely separately, but I would have expected an approximate relation. Am I misunderstanding the eq filters contrast value?
ffmpeg colors contrast
ffmpeg colors contrast
edited Nov 2 '16 at 14:48
3498DB
15.7k114762
15.7k114762
asked Jun 15 '15 at 13:30
Jon GJon G
157139
157139
Maybe this helps? github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_eq.c#L77
– slhck
Jun 16 '15 at 7:30
add a comment |
Maybe this helps? github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_eq.c#L77
– slhck
Jun 16 '15 at 7:30
Maybe this helps? github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_eq.c#L77
– slhck
Jun 16 '15 at 7:30
Maybe this helps? github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_eq.c#L77
– slhck
Jun 16 '15 at 7:30
add a comment |
2 Answers
2
active
oldest
votes
You need to specify the options in the filter by name, so your original filter settings would need to be changed to...
-filter_complex "[0:v]eq=contrast=1:brightness=0:saturation=1:gamma=1:
gamma_r=1:gamma_g=1:gamma_b=1:gamma_weight=1[outv]"
...if you wanted set all of those parameters. Otherwise, the filter is going to ignore your settings and apply the default values, or it could possibly misinterpret one intended option's value for another (it shouldn't, but stranger things have happened with FFmpeg's filters).
As far as the selected values vs. end results go, the code slhck pointed out shows that the value one sets per option are run through a series of internal calculations, then the results are used to evaluate and make pixel-level adjustments. It appears that the "base" calculation for contrast
is...
(param->contrast * 256 * 16)
...so the default value of 0
would result in 0, a specified value of 1
would result in 4096, a value of -0.00275
would result in -11.264, etc, and these base values are used in further calculations down the line. In other words, it would be best to consider the filter's handling of these parameters as unique, so spend some time playing around with them to see how they work. To get a true idea of the effects, you can tweak and survey the output of the eq
settings using FFplay, e.g.:
ffplay -i input.jpg -vf "eq=contrast=1.5:brightness=-0.05:saturation=0.75"
As far as your original script goes, since you were using only one input (your jpeg), one filter (eq), and all options except contrast
were carrying default values, you can reduce the script down to the following to get your 3-second MP4, providing that eq=contrast=1
produces desirable results:
ffmpeg -y -loop 1 -i input.jpg -vf "eq=contrast=1" -c:v libx264
-pix_fmt yuv420p -t 3 out.mp4
full disclosure: post edited 2016/06/19 for greater clarification and extended info
add a comment |
To answer your original question about contrast in FFmpeg vs. CSS, the code fragment below seems to suggest that contrast
in FFmpeg only applies to luminance/luma (brightness), while saturation
only applies to chrominance/chroma (colors).
static void set_contrast(EQContext *eq)
{
eq->contrast = av_clipf(av_expr_eval(eq->contrast_pexpr, eq->var_values, eq), -1000.0, 1000.0);
eq->param[0].contrast = eq->contrast;
eq->param[0].lut_clean = 0;
check_values(&eq->param[0], eq);
}
// ...
static void set_saturation(EQContext *eq)
{
int i;
eq->saturation = av_clipf(av_expr_eval(eq->saturation_pexpr, eq->var_values, eq), 0.0, 3.0);
for (i = 1; i < 3; i++) {
eq->param[i].contrast = eq->saturation;
eq->param[i].lut_clean = 0;
check_values(&eq->param[i], eq);
}
}
Notice how in set_contrast
, only param[0]
(denoting the first color component, which in YUV is Y, the luma) is changed, while in set_saturation
only param[1]
and param[2]
(denoting yellow and magenta, the chroma) are changed. This should account for the fact that you are seeing yellow and magenta, two chroma color components, when you decrease contrast to 0 in FFmpeg. When you set saturation to 0 also, I'm seeing a plain gray image similar to the one produced by CSS.
The relationship between CSS's contrast
and saturate
versus FFmpeg's contrast
and saturation
can be established as:
filter: contrast(c) saturate(s);
is equivalent to
eq=contrast=c:saturation=c*s
Obligatory screenshots showing c = 0.6 and s = 1.3:
Wow, thank you so much. This saved me.
– justswim
Jan 18 '18 at 20:12
1
Weirdly, after playing with this longer, when contrast is set to 0 with FFMPEG, the gray color I get is different from the gray I get with CSS. In CSS, I'm getting #808080 (pure gray). But with ffmpeg, I'm getting a video with background #898B89 when contrast is 0. Any idea why this might be the case?
– justswim
Jan 19 '18 at 0:19
In your screenshots above, the image colors are actually slightly off. You can notice it if you look at the sky and clouds. It seems that there is something else at play here .. do you have any ideas on how to adjust this?
– justswim
Jan 19 '18 at 21:37
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f928151%2fffmpeg-eq-filter-complex-contrast%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You need to specify the options in the filter by name, so your original filter settings would need to be changed to...
-filter_complex "[0:v]eq=contrast=1:brightness=0:saturation=1:gamma=1:
gamma_r=1:gamma_g=1:gamma_b=1:gamma_weight=1[outv]"
...if you wanted set all of those parameters. Otherwise, the filter is going to ignore your settings and apply the default values, or it could possibly misinterpret one intended option's value for another (it shouldn't, but stranger things have happened with FFmpeg's filters).
As far as the selected values vs. end results go, the code slhck pointed out shows that the value one sets per option are run through a series of internal calculations, then the results are used to evaluate and make pixel-level adjustments. It appears that the "base" calculation for contrast
is...
(param->contrast * 256 * 16)
...so the default value of 0
would result in 0, a specified value of 1
would result in 4096, a value of -0.00275
would result in -11.264, etc, and these base values are used in further calculations down the line. In other words, it would be best to consider the filter's handling of these parameters as unique, so spend some time playing around with them to see how they work. To get a true idea of the effects, you can tweak and survey the output of the eq
settings using FFplay, e.g.:
ffplay -i input.jpg -vf "eq=contrast=1.5:brightness=-0.05:saturation=0.75"
As far as your original script goes, since you were using only one input (your jpeg), one filter (eq), and all options except contrast
were carrying default values, you can reduce the script down to the following to get your 3-second MP4, providing that eq=contrast=1
produces desirable results:
ffmpeg -y -loop 1 -i input.jpg -vf "eq=contrast=1" -c:v libx264
-pix_fmt yuv420p -t 3 out.mp4
full disclosure: post edited 2016/06/19 for greater clarification and extended info
add a comment |
You need to specify the options in the filter by name, so your original filter settings would need to be changed to...
-filter_complex "[0:v]eq=contrast=1:brightness=0:saturation=1:gamma=1:
gamma_r=1:gamma_g=1:gamma_b=1:gamma_weight=1[outv]"
...if you wanted set all of those parameters. Otherwise, the filter is going to ignore your settings and apply the default values, or it could possibly misinterpret one intended option's value for another (it shouldn't, but stranger things have happened with FFmpeg's filters).
As far as the selected values vs. end results go, the code slhck pointed out shows that the value one sets per option are run through a series of internal calculations, then the results are used to evaluate and make pixel-level adjustments. It appears that the "base" calculation for contrast
is...
(param->contrast * 256 * 16)
...so the default value of 0
would result in 0, a specified value of 1
would result in 4096, a value of -0.00275
would result in -11.264, etc, and these base values are used in further calculations down the line. In other words, it would be best to consider the filter's handling of these parameters as unique, so spend some time playing around with them to see how they work. To get a true idea of the effects, you can tweak and survey the output of the eq
settings using FFplay, e.g.:
ffplay -i input.jpg -vf "eq=contrast=1.5:brightness=-0.05:saturation=0.75"
As far as your original script goes, since you were using only one input (your jpeg), one filter (eq), and all options except contrast
were carrying default values, you can reduce the script down to the following to get your 3-second MP4, providing that eq=contrast=1
produces desirable results:
ffmpeg -y -loop 1 -i input.jpg -vf "eq=contrast=1" -c:v libx264
-pix_fmt yuv420p -t 3 out.mp4
full disclosure: post edited 2016/06/19 for greater clarification and extended info
add a comment |
You need to specify the options in the filter by name, so your original filter settings would need to be changed to...
-filter_complex "[0:v]eq=contrast=1:brightness=0:saturation=1:gamma=1:
gamma_r=1:gamma_g=1:gamma_b=1:gamma_weight=1[outv]"
...if you wanted set all of those parameters. Otherwise, the filter is going to ignore your settings and apply the default values, or it could possibly misinterpret one intended option's value for another (it shouldn't, but stranger things have happened with FFmpeg's filters).
As far as the selected values vs. end results go, the code slhck pointed out shows that the value one sets per option are run through a series of internal calculations, then the results are used to evaluate and make pixel-level adjustments. It appears that the "base" calculation for contrast
is...
(param->contrast * 256 * 16)
...so the default value of 0
would result in 0, a specified value of 1
would result in 4096, a value of -0.00275
would result in -11.264, etc, and these base values are used in further calculations down the line. In other words, it would be best to consider the filter's handling of these parameters as unique, so spend some time playing around with them to see how they work. To get a true idea of the effects, you can tweak and survey the output of the eq
settings using FFplay, e.g.:
ffplay -i input.jpg -vf "eq=contrast=1.5:brightness=-0.05:saturation=0.75"
As far as your original script goes, since you were using only one input (your jpeg), one filter (eq), and all options except contrast
were carrying default values, you can reduce the script down to the following to get your 3-second MP4, providing that eq=contrast=1
produces desirable results:
ffmpeg -y -loop 1 -i input.jpg -vf "eq=contrast=1" -c:v libx264
-pix_fmt yuv420p -t 3 out.mp4
full disclosure: post edited 2016/06/19 for greater clarification and extended info
You need to specify the options in the filter by name, so your original filter settings would need to be changed to...
-filter_complex "[0:v]eq=contrast=1:brightness=0:saturation=1:gamma=1:
gamma_r=1:gamma_g=1:gamma_b=1:gamma_weight=1[outv]"
...if you wanted set all of those parameters. Otherwise, the filter is going to ignore your settings and apply the default values, or it could possibly misinterpret one intended option's value for another (it shouldn't, but stranger things have happened with FFmpeg's filters).
As far as the selected values vs. end results go, the code slhck pointed out shows that the value one sets per option are run through a series of internal calculations, then the results are used to evaluate and make pixel-level adjustments. It appears that the "base" calculation for contrast
is...
(param->contrast * 256 * 16)
...so the default value of 0
would result in 0, a specified value of 1
would result in 4096, a value of -0.00275
would result in -11.264, etc, and these base values are used in further calculations down the line. In other words, it would be best to consider the filter's handling of these parameters as unique, so spend some time playing around with them to see how they work. To get a true idea of the effects, you can tweak and survey the output of the eq
settings using FFplay, e.g.:
ffplay -i input.jpg -vf "eq=contrast=1.5:brightness=-0.05:saturation=0.75"
As far as your original script goes, since you were using only one input (your jpeg), one filter (eq), and all options except contrast
were carrying default values, you can reduce the script down to the following to get your 3-second MP4, providing that eq=contrast=1
produces desirable results:
ffmpeg -y -loop 1 -i input.jpg -vf "eq=contrast=1" -c:v libx264
-pix_fmt yuv420p -t 3 out.mp4
full disclosure: post edited 2016/06/19 for greater clarification and extended info
edited Jun 20 '15 at 3:25
answered Jun 19 '15 at 7:52
Mr. WhatMr. What
1766
1766
add a comment |
add a comment |
To answer your original question about contrast in FFmpeg vs. CSS, the code fragment below seems to suggest that contrast
in FFmpeg only applies to luminance/luma (brightness), while saturation
only applies to chrominance/chroma (colors).
static void set_contrast(EQContext *eq)
{
eq->contrast = av_clipf(av_expr_eval(eq->contrast_pexpr, eq->var_values, eq), -1000.0, 1000.0);
eq->param[0].contrast = eq->contrast;
eq->param[0].lut_clean = 0;
check_values(&eq->param[0], eq);
}
// ...
static void set_saturation(EQContext *eq)
{
int i;
eq->saturation = av_clipf(av_expr_eval(eq->saturation_pexpr, eq->var_values, eq), 0.0, 3.0);
for (i = 1; i < 3; i++) {
eq->param[i].contrast = eq->saturation;
eq->param[i].lut_clean = 0;
check_values(&eq->param[i], eq);
}
}
Notice how in set_contrast
, only param[0]
(denoting the first color component, which in YUV is Y, the luma) is changed, while in set_saturation
only param[1]
and param[2]
(denoting yellow and magenta, the chroma) are changed. This should account for the fact that you are seeing yellow and magenta, two chroma color components, when you decrease contrast to 0 in FFmpeg. When you set saturation to 0 also, I'm seeing a plain gray image similar to the one produced by CSS.
The relationship between CSS's contrast
and saturate
versus FFmpeg's contrast
and saturation
can be established as:
filter: contrast(c) saturate(s);
is equivalent to
eq=contrast=c:saturation=c*s
Obligatory screenshots showing c = 0.6 and s = 1.3:
Wow, thank you so much. This saved me.
– justswim
Jan 18 '18 at 20:12
1
Weirdly, after playing with this longer, when contrast is set to 0 with FFMPEG, the gray color I get is different from the gray I get with CSS. In CSS, I'm getting #808080 (pure gray). But with ffmpeg, I'm getting a video with background #898B89 when contrast is 0. Any idea why this might be the case?
– justswim
Jan 19 '18 at 0:19
In your screenshots above, the image colors are actually slightly off. You can notice it if you look at the sky and clouds. It seems that there is something else at play here .. do you have any ideas on how to adjust this?
– justswim
Jan 19 '18 at 21:37
add a comment |
To answer your original question about contrast in FFmpeg vs. CSS, the code fragment below seems to suggest that contrast
in FFmpeg only applies to luminance/luma (brightness), while saturation
only applies to chrominance/chroma (colors).
static void set_contrast(EQContext *eq)
{
eq->contrast = av_clipf(av_expr_eval(eq->contrast_pexpr, eq->var_values, eq), -1000.0, 1000.0);
eq->param[0].contrast = eq->contrast;
eq->param[0].lut_clean = 0;
check_values(&eq->param[0], eq);
}
// ...
static void set_saturation(EQContext *eq)
{
int i;
eq->saturation = av_clipf(av_expr_eval(eq->saturation_pexpr, eq->var_values, eq), 0.0, 3.0);
for (i = 1; i < 3; i++) {
eq->param[i].contrast = eq->saturation;
eq->param[i].lut_clean = 0;
check_values(&eq->param[i], eq);
}
}
Notice how in set_contrast
, only param[0]
(denoting the first color component, which in YUV is Y, the luma) is changed, while in set_saturation
only param[1]
and param[2]
(denoting yellow and magenta, the chroma) are changed. This should account for the fact that you are seeing yellow and magenta, two chroma color components, when you decrease contrast to 0 in FFmpeg. When you set saturation to 0 also, I'm seeing a plain gray image similar to the one produced by CSS.
The relationship between CSS's contrast
and saturate
versus FFmpeg's contrast
and saturation
can be established as:
filter: contrast(c) saturate(s);
is equivalent to
eq=contrast=c:saturation=c*s
Obligatory screenshots showing c = 0.6 and s = 1.3:
Wow, thank you so much. This saved me.
– justswim
Jan 18 '18 at 20:12
1
Weirdly, after playing with this longer, when contrast is set to 0 with FFMPEG, the gray color I get is different from the gray I get with CSS. In CSS, I'm getting #808080 (pure gray). But with ffmpeg, I'm getting a video with background #898B89 when contrast is 0. Any idea why this might be the case?
– justswim
Jan 19 '18 at 0:19
In your screenshots above, the image colors are actually slightly off. You can notice it if you look at the sky and clouds. It seems that there is something else at play here .. do you have any ideas on how to adjust this?
– justswim
Jan 19 '18 at 21:37
add a comment |
To answer your original question about contrast in FFmpeg vs. CSS, the code fragment below seems to suggest that contrast
in FFmpeg only applies to luminance/luma (brightness), while saturation
only applies to chrominance/chroma (colors).
static void set_contrast(EQContext *eq)
{
eq->contrast = av_clipf(av_expr_eval(eq->contrast_pexpr, eq->var_values, eq), -1000.0, 1000.0);
eq->param[0].contrast = eq->contrast;
eq->param[0].lut_clean = 0;
check_values(&eq->param[0], eq);
}
// ...
static void set_saturation(EQContext *eq)
{
int i;
eq->saturation = av_clipf(av_expr_eval(eq->saturation_pexpr, eq->var_values, eq), 0.0, 3.0);
for (i = 1; i < 3; i++) {
eq->param[i].contrast = eq->saturation;
eq->param[i].lut_clean = 0;
check_values(&eq->param[i], eq);
}
}
Notice how in set_contrast
, only param[0]
(denoting the first color component, which in YUV is Y, the luma) is changed, while in set_saturation
only param[1]
and param[2]
(denoting yellow and magenta, the chroma) are changed. This should account for the fact that you are seeing yellow and magenta, two chroma color components, when you decrease contrast to 0 in FFmpeg. When you set saturation to 0 also, I'm seeing a plain gray image similar to the one produced by CSS.
The relationship between CSS's contrast
and saturate
versus FFmpeg's contrast
and saturation
can be established as:
filter: contrast(c) saturate(s);
is equivalent to
eq=contrast=c:saturation=c*s
Obligatory screenshots showing c = 0.6 and s = 1.3:
To answer your original question about contrast in FFmpeg vs. CSS, the code fragment below seems to suggest that contrast
in FFmpeg only applies to luminance/luma (brightness), while saturation
only applies to chrominance/chroma (colors).
static void set_contrast(EQContext *eq)
{
eq->contrast = av_clipf(av_expr_eval(eq->contrast_pexpr, eq->var_values, eq), -1000.0, 1000.0);
eq->param[0].contrast = eq->contrast;
eq->param[0].lut_clean = 0;
check_values(&eq->param[0], eq);
}
// ...
static void set_saturation(EQContext *eq)
{
int i;
eq->saturation = av_clipf(av_expr_eval(eq->saturation_pexpr, eq->var_values, eq), 0.0, 3.0);
for (i = 1; i < 3; i++) {
eq->param[i].contrast = eq->saturation;
eq->param[i].lut_clean = 0;
check_values(&eq->param[i], eq);
}
}
Notice how in set_contrast
, only param[0]
(denoting the first color component, which in YUV is Y, the luma) is changed, while in set_saturation
only param[1]
and param[2]
(denoting yellow and magenta, the chroma) are changed. This should account for the fact that you are seeing yellow and magenta, two chroma color components, when you decrease contrast to 0 in FFmpeg. When you set saturation to 0 also, I'm seeing a plain gray image similar to the one produced by CSS.
The relationship between CSS's contrast
and saturate
versus FFmpeg's contrast
and saturation
can be established as:
filter: contrast(c) saturate(s);
is equivalent to
eq=contrast=c:saturation=c*s
Obligatory screenshots showing c = 0.6 and s = 1.3:
answered Oct 6 '16 at 6:33
Timothy GuTimothy Gu
59348
59348
Wow, thank you so much. This saved me.
– justswim
Jan 18 '18 at 20:12
1
Weirdly, after playing with this longer, when contrast is set to 0 with FFMPEG, the gray color I get is different from the gray I get with CSS. In CSS, I'm getting #808080 (pure gray). But with ffmpeg, I'm getting a video with background #898B89 when contrast is 0. Any idea why this might be the case?
– justswim
Jan 19 '18 at 0:19
In your screenshots above, the image colors are actually slightly off. You can notice it if you look at the sky and clouds. It seems that there is something else at play here .. do you have any ideas on how to adjust this?
– justswim
Jan 19 '18 at 21:37
add a comment |
Wow, thank you so much. This saved me.
– justswim
Jan 18 '18 at 20:12
1
Weirdly, after playing with this longer, when contrast is set to 0 with FFMPEG, the gray color I get is different from the gray I get with CSS. In CSS, I'm getting #808080 (pure gray). But with ffmpeg, I'm getting a video with background #898B89 when contrast is 0. Any idea why this might be the case?
– justswim
Jan 19 '18 at 0:19
In your screenshots above, the image colors are actually slightly off. You can notice it if you look at the sky and clouds. It seems that there is something else at play here .. do you have any ideas on how to adjust this?
– justswim
Jan 19 '18 at 21:37
Wow, thank you so much. This saved me.
– justswim
Jan 18 '18 at 20:12
Wow, thank you so much. This saved me.
– justswim
Jan 18 '18 at 20:12
1
1
Weirdly, after playing with this longer, when contrast is set to 0 with FFMPEG, the gray color I get is different from the gray I get with CSS. In CSS, I'm getting #808080 (pure gray). But with ffmpeg, I'm getting a video with background #898B89 when contrast is 0. Any idea why this might be the case?
– justswim
Jan 19 '18 at 0:19
Weirdly, after playing with this longer, when contrast is set to 0 with FFMPEG, the gray color I get is different from the gray I get with CSS. In CSS, I'm getting #808080 (pure gray). But with ffmpeg, I'm getting a video with background #898B89 when contrast is 0. Any idea why this might be the case?
– justswim
Jan 19 '18 at 0:19
In your screenshots above, the image colors are actually slightly off. You can notice it if you look at the sky and clouds. It seems that there is something else at play here .. do you have any ideas on how to adjust this?
– justswim
Jan 19 '18 at 21:37
In your screenshots above, the image colors are actually slightly off. You can notice it if you look at the sky and clouds. It seems that there is something else at play here .. do you have any ideas on how to adjust this?
– justswim
Jan 19 '18 at 21:37
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f928151%2fffmpeg-eq-filter-complex-contrast%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Maybe this helps? github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_eq.c#L77
– slhck
Jun 16 '15 at 7:30