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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3999 bytes --]

On Sun, May 15, 2022 at 08:55:49PM +0200, Michael Niedermayer wrote:
> 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@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@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

Also for extra entertainment try this:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    float exact_tenth = 0.1;
    double done = 1.0;
    float fone = 1.0;
    int i;

    for(i= 0; i<100000000; i++) {
        done *= exact_tenth * 10.0;
        fone *= exact_tenth * 10.0;
    }

    printf("float one is %f double one is %f\n", fone, done);

    return 0;
}


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".