[FFmpeg-devel] [PATCH v3] lavu: add an AV_FRAME_DATA_GAMMA side data type

Paul B Mahol onemda at gmail.com
Wed Nov 8 13:15:27 EET 2017


On 11/8/17, Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Wed, Nov 08, 2017 at 11:50:34AM +0100, Michael Niedermayer wrote:
>> On Tue, Nov 07, 2017 at 08:13:57PM +0000, Rostislav Pehlivanov wrote:
>> > On 6 November 2017 at 18:03, Nicolas George <george at nsup.org> wrote:
>> >
>> > > Le sextidi 16 brumaire, an CCXXVI, Rostislav Pehlivanov a ecrit :
>> > > > Signed-off-by: Rostislav Pehlivanov <atomnuker at gmail.com>
>> > > > ---
>> > > >  doc/APIchanges      | 3 +++
>> > > >  libavutil/frame.h   | 6 ++++++
>> > > >  libavutil/version.h | 2 +-
>> > > >  3 files changed, 10 insertions(+), 1 deletion(-)
>> > >
>> > > Sorry if it has come up before, but why not just add
>> > >
>> > >         AVRational gamma;
>> > >
>> > > with 0/0 meaning unspecified? It seems like a relevant information,
>> > > at
>> > > least as much as AVColor*. And overall much simpler.
>> > >
>> > > Regards,
>> > >
>> > > --
>> > >   Nicolas George
>> > >
>> >
>> > Gamma info is related to mastering info so API users expect to get both
>> > using the same API rather than look for new fields in avframe and
>> > evaluate
>> > whether they're different on a per-frame basis.
>> > Also, it prevents from adding more fields to avframe and making a
>> > bigger
>> > mess.
>>
>> If a filter changes gamma, it will then have to update the side data
>> if its in side data
>>
>> I think i understand that you may see gamma more as a input device
>> characteristic. But really its part of the mapping of the physical
>> worlds light spectrum shape for each pixel to the 3 element vector
>> used to represent pixels.
>>
>> As such if the representation of pixels change, gamma may change
>>
>> Take a very simple example, simple rescaling or similar filtering,
>> all these filters should be performed with a flat 1.0 gamma to be
>> physically correct. So often a whole filter chain would be more
>> correct by converting the gamma != 1.0 8bit per sample to a gamma = 1.0
>> bps > 8bit first and at the end of the chain convert back to a more
>> commonly used gamma != 1.0.
>> We dont do this but we should support it at least optionally and
>> having gamma only in side data would make it a bit unwieldy
>
> we also could have a set of recoding device parameters in side data
> (mastering info)
>
> and the current frames data[] gamma in avframe.
> not sure thats a good idea or too confusing but it would allow
> a filter to convert back to the input devices gamma without its value
> being given to the filter as its in side data still

No, no and no. Gamma is not always available and polluting AVFrame is big no.
I vote and veto against your and Nicolas idea.


More information about the ffmpeg-devel mailing list