On 11/8/17, Michael Niedermayer <mich...@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 <geo...@nsup.org> wrote: >> > >> > > Le sextidi 16 brumaire, an CCXXVI, Rostislav Pehlivanov a ecrit : >> > > > Signed-off-by: Rostislav Pehlivanov <atomnu...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
