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 écrit : > > > 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel