[FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

[Michael Niedermayer]

On Fri, Aug 03, 2018 at 10:33:00PM +0300, Sergey Lavrushkin wrote:
> 2018-08-03 16:07 GMT+03:00 Michael Niedermayer <michael at niedermayer.cc>:
> 
> > On Thu, Aug 02, 2018 at 09:52:45PM +0300, Sergey Lavrushkin wrote:
> > > This patch adds two floating-point gray formats to use them in sr filter
> > for
> > > conversion with libswscale. I added conversion from uint gray to float
> > and
> > > backwards in swscale_unscaled.c, that is enough for sr filter. But for
> > > proper format addition, should I add anything else?
> > >
> > > ---
> > >  libavutil/pixdesc.c           | 22 ++++++++++++++++++
> > >  libavutil/pixfmt.h            |  5 ++++
> > >  libswscale/swscale_internal.h |  7 ++++++
> > >  libswscale/swscale_unscaled.c | 54 ++++++++++++++++++++++++++++++
> > +++++++++++--
> > >  libswscale/utils.c            |  5 +++-
> >
> > please split this in a patch or libavutil and one for libswscale
> > they also need some version.h bump
> >
> 
> Ok.
> 
> also fate tests need an update, (make fate) fails otherwise, the update
> > should
> > be part of the patch that causes the failure otherwise
> 
> 
> In one test for these formats I get:
> 
> filter-pixfmts-scale
> grayf32be           grayf32le           monob
>  f01cb0b623357387827902d9d0963435
> 
> I guess, it is because I only implemented conversion in swscale_unscaled.
> What can I do to fix it? Should I implement conversion for scaling or maybe
> change something in the test, so it would not check these formats (if it is
> possible).
> Anyway, I need to know what changes should I do and where.

well, swscale shouldnt really have formats only half supported
so for any supported format in and out it should work with any
width / height in / out

Theres a wide range of possibilities how to implement this.
The correct / ideal way is of course to implement a full floating point path
for scaling along side the integer code.
a simpler aprouch would be to convert from/to float to/from  integers and use
the existing code. (this of course has the disadvantage of loosing precission)


[...]
> > +    const uint8_t *srcPtr = src[0];
> > > +    float *dstPtr = (float *)(dst[0] + dstStride[0] * srcSliceY);
> > > +
> > > +    for (y = 0; y < srcSliceH; ++y){
> > > +        for (x = 0; x < c->srcW; ++x){
> > > +            dstPtr[x] = (float)srcPtr[x] / 255.0f;
> >
> > division is slow. This should either be a multiplication with the
> > inverse or a LUT with 8bit index changing to float.
> >
> > The faster of them should be used
> >
> 
> LUT seems to be faster. Can I place it in SwsContext and initialize it in
> sws_init_context when necessary?

yes of course

thanks

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180803/1da09678/attachment.sig>