[FFmpeg-devel] [PATCH] avutil/csp: create public API for colorspace structs

[Michael Niedermayer]

On Sun, May 15, 2022 at 12:49:51PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, May 13, 2022 at 5:22 PM Michael Niedermayer <michael at niedermayer.cc>
> wrote:
> 
> > On Fri, May 13, 2022 at 11:42:08AM -0400, Leo Izen wrote:
> > > This commit moves some of the functionality from avfilter/colorspace
> > > into avutil/csp and exposes it as a public API so it can be used by
> > > libavcodec and/or libavformat.
> > [...]
> > > diff --git a/libavutil/csp.h b/libavutil/csp.h
> > > new file mode 100644
> > > index 0000000000..1bcde7ddd3
> > > --- /dev/null
> > > +++ b/libavutil/csp.h
> > > @@ -0,0 +1,49 @@
> > > +/*
> > > + * Copyright (c) 2016 Ronald S. Bultje <rsbultje at gmail.com>
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation; either
> > > + * version 2.1 of the License, or (at your option) any later version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General Public
> > > + * License along with FFmpeg; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > > + */
> > > +
> > > +#ifndef AVUTIL_CSP_H
> > > +#define AVUTIL_CSP_H
> > > +
> > > +#include "libavutil/frame.h"
> > > +#include "libavutil/pixfmt.h"
> > > +
> > > +struct LumaCoefficients {
> > > +    double cr, cg, cb;
> > > +};
> > > +
> > > +struct PrimaryCoefficients {
> > > +    double xr, yr, xg, yg, xb, yb;
> > > +};
> > > +
> > > +struct WhitepointCoefficients {
> > > +    double xw, yw;
> > > +};
> >
> > I think we should avoid floating point so as to ensure reproduceable
> > results and simplify regerssion testing
> >
> 
> To explain: when I designed this stuff, I chose to keep them in float so
> that we can use the literal values from the specs, which are themselves in
> floating point. That would not be possible anymore, and would therefore
> make it slightly harder to read for a casual observer.
> 
> (Otherwise no opinion, I'm typically used to fixed-point rather than
> floating-point myself also.)

I looked at Rec. ITU-T H.264 (02/2016) (was the first thing laying around,
i assume but did not check that this matches the specs these numbers came from)

(randomly picking "whitepoints")
the whitepoints for "10" contain some 1/3 values
but if i just look at "1" the values are
0.3127, 0.3290
i dont think these can be represented as m*2^E either
3127/10000 = m*2^E
3127 * 2^-E = m * 10000
both sides would be all integers
the right side contains 5 as factor, the left doesnt

of course i may be missing something

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220515/388554c8/attachment.sig>