Opened 3 years ago
Last modified 3 years ago
#9772 new defect
colorspace filter fails on trc=linear (and scale always assumes a gamma of 2.2)
Reported by: | Llyw | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avfilter |
Version: | unspecified | Keywords: | colorspace conversion linear gamma resampling |
Cc: | Llyw | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
I am currently trying to get a filter graph running that converts to linear gamma prior to resampling the video and then re-apply a transfer curve. So my -filter:v
option essentially looks like this:
'[...],colorspace=primaries=smpte170m:trc=linear,scale=[...],colorspace=all=smpte170m'
(And I am using FFmpeg 5.0.1, which I can't yet select from the Version drop-down list.)
Unfortunately, attempting to process videos this way results in an error as the trc option of the first colorspace
filter is parsed but apparently ignored:
[Parsed_colorspace_1 @ ...] Setting 'primaries' to value 'smpte170m' [Parsed_colorspace_1 @ ...] Setting 'trc' to value 'linear' [...] [Parsed_colorspace_1 @ ...] Please specify output transfer characteristics Error while filtering: Invalid argument Failed to inject frame into filter network: Invalid argument Error while processing the decoded data for stream #0:0
I have noted that the linear
option for trc
is currently not documented but it is certainly part of the code. I wish to resample in a space with linear gamma, so it would be kind of important to me if this is fixed. (I don't get an error if I am using colorspace=all=smpte170m:trc=linear
but I am assuming that this then ignores the trc=linear
part and still works with the SMPTE 170M transfer curve applied, which is absolutely not what I want.)
I would also like to know why I explicitly have to specify the primary colors of the output color space? (I would get an error similar to the one above if I try to omit it.) Can't this just default to the input's properties? I hope I am not missing something here and still doing the resampling in the wrong color space?
I understand that zscale
can also be used (and it doesn't force me to specify the output primaries if I only care about the transfer curve), but I have found that color space conversion in combination with resampling using zscale
is at least 2x slower than using native filters on my system, contradicting their claims on GitHub. In addition, I am still not sure whether zscale automatically converts to linear gamma before resampling or whether I have to do that manually, i.e. use three filters instead of one. Add that to that the fact that there seems to be less debug output with zscale
and you'll probably understand why I prefer using the native filters.
Change History (6)
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
comment:2 by , 3 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
comment:3 by , 3 years ago
comment:4 by , 3 years ago
Could you please elaborate? From what I understand, the scale
filter won't convert to linear gamma before computing the resampled pixel value and that's why I am explicitly trying to convert to a linear transfer curve before the scale
filter. And reapply a gamma function afterwards. (From what I understood, people are generally suggesting zscale
because it is better at handling color space information, but I have given my reasons for not wanting to use it.) Are you suggesting that the scale
filter can indeed convert to linear gamma internally? If so, what parameters do I have to specify for it to do so? Are in_color_matrix
and out_color_matrix
sufficient? And would that require git master or is the 5.0 release branch sufficient?
Note that the original issue that I reported, namely colorspace
failing when trying to use trc=linear
, still remains, but if I don't need the colorspace
filters for the task at hand that would at least provide a solution for me, if not fixing the bug itself.
comment:5 by , 3 years ago
I did some more digging around on my own and please correct me if I'm wrong, but it seems that the current situation regarding gamma-aware resampling is as follows:
swscale's scale
filter is apparently hard-coded to assume a gamma of 2.2, see, https://github.com/FFmpeg/FFmpeg/blob/n5.0.1/libswscale/utils.c#L1614, so my above colorspace=[...],scale=[...],colorspace=[...]
filter chain would absolutely not do what I want and it's probably a good thing that the bug reported in this issue prevents me from using such a filter chain.
z.lib/zimg's zscale
filter can do resampling in a linear gamma domain but requires explicit conversion to a linear transfer characteristic using up to three zscale filters, see comments in https://github.com/sekrit-twc/zimg/issues/141. While the performance is not as good as the scale filter in the release/5.0 branch, there seems to have been significant improvements in git-master.
So while I still think that you will probably want to investigate the colorspace
issue with trc=linear
, it seems that for gamma-aware resampling my best bet is to wait for the performance improvements for zscale
being available in a release branch and using that instead, with one zscale
instance converting to a linear transfer characteristic, the next one doing the resamling, and the final one converting to the output color encoding.
comment:6 by , 3 years ago
Summary: | colorspace filter fails on trc=linear → colorspace filter fails on trc=linear (and scale always assumes a gamma of 2.2) |
---|
You need to use zscale or swscale, not colorspace filter.