Opened 23 months ago

Last modified 23 months 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 Llyw)

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 Llyw, 23 months ago

Description: modified (diff)

comment:2 by Llyw, 23 months ago

Cc: Llyw added
Description: modified (diff)

comment:3 by Balling, 23 months ago

You need to use zscale or swscale, not colorspace filter.

comment:4 by Llyw, 23 months 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 Llyw, 23 months 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 Llyw, 23 months ago

Summary: colorspace filter fails on trc=linearcolorspace filter fails on trc=linear (and scale always assumes a gamma of 2.2)
Note: See TracTickets for help on using tickets.