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 é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
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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
