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

[Michael Niedermayer]

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 écrit :
> > > > 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

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171108/2b4b8098/attachment.sig>