[FFmpeg-devel] [PATCH] Port FFT domain filter.

Michael Niedermayer michaelni at gmx.at
Tue Mar 3 19:42:46 CET 2015


On Tue, Mar 03, 2015 at 10:50:09PM +0530, arwa arif wrote:
> On Tue, Mar 3, 2015 at 6:11 PM, Michael Niedermayer <michaelni at gmx.at>
> wrote:
> 
> > On Tue, Mar 03, 2015 at 12:06:09PM +0530, arwa arif wrote:
> > > I tried to change the name to fft, but it is conflicting with
> > > libavcodec/fft. So, I am unable to change that. I have updated the patch,
> > > adding support to coloured images.
> >
> > yes, the names could conflict in configure indeed
> >
> >
> > [...]
> > > +
> > > +#include "libavfilter/internal.h"
> > > +#include "libavutil/common.h"
> > > +#include "libavutil/imgutils.h"
> > > +#include "libavutil/opt.h"
> > > +#include "libavutil/pixdesc.h"
> > > +#include "libavcodec/avfft.h"
> > > +#include "libavutil/eval.h"
> > > +
> > > +typedef struct {
> > > +    const AVClass *class;
> > > +
> > > +    RDFTContext *rdft;
> > > +    int rdft_hbits[3];
> > > +    int rdft_vbits[3];
> > > +    size_t rdft_hlen[3];
> > > +    size_t rdft_vlen[3];
> > > +    FFTSample *rdft_hdata[3];
> > > +    FFTSample *rdft_vdata[3];
> > > +
> > > +    int dc;
> > > +    char *lum_str;
> > > +    AVExpr *lum_expr;
> > > +    double *lum_data;
> > > +
> > > +} FFTFILTContext;
> > > +
> > > +static const char *const var_names[] = {   "X",   "Y",   "W",   "H",
> >  NULL    };
> > > +enum                                   { VAR_X, VAR_Y, VAR_W, VAR_H,
> > VAR_VARS_NB };
> > > +
> > > +#define OFFSET(x) offsetof(FFTFILTContext, x)
> > > +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> > > +
> >
> > > +static const AVOption fftfilt_options[] = {
> > > +    { "dc",  "adjust gain",              OFFSET(dc),
> > AV_OPT_TYPE_INT,    {.i64 = 0},      0,     1000,     FLAGS },
> > > +    { "lum", "set luminance expression", OFFSET(lum_str),
> > AV_OPT_TYPE_STRING, {.str = "1"}, CHAR_MIN, CHAR_MAX, FLAGS },
> > > +    {NULL},
> >
> > The user should be able to set seperate dc / "lum" for teh 3 planes
> > that is if only the first dc and first exression is set then they
> > should be used for all 3 planes
> > otherwise, if teh user set 3 dc values and 3 expressions then each
> > plane should use the specific expression
> >
> >
> >
> > [...]
> > > +
> > > +        memset(fftfilt->rdft_hdata[plane] + i *
> > fftfilt->rdft_hlen[plane], 0,
> > > +               fftfilt->rdft_hlen[plane] *
> > sizeof(*fftfilt->rdft_hdata[plane]));
> >
> > the memseting should ideally be replaced by mirroring, this leads
> > to better quality
> >
> > for example
> > matrixbench_mpeg2.mpg -vf fftfilt=dc=128:lum="'(1 / (1 +
> > exp(-(Y+X)/10.0+H/100.0)))'"
> > results in a pink border due to this
> >
> > that is instead of for each line
> > 1 2 3 3 7 9 10 11 23
> > it should not be changed to:
> > 1 2 3 3 7 9 10 11 23  0  0  0  0  0  0  0
> > but
> > 1 2 3 3 7 9 10 11 23 23 11 10  x  3  2  1
> >
> >
> But, we want to clear the block of memory. Why do we want to mirror it?

The idea is to clear it with the same data as is in the input picture
not with 0 bytes

so instead of

9999999999999999999000000
99999........999999000000
99999..9..9..999999000000
99999........999999000000
99999.9....9.999999000000
99999..9999..999999000000
99999........999999000000
9999999999999999999000000

it is

9999999999999999999999999
99999........999999999999
99999..9..9..999999999999
99999........999999999999
99999.9....9.999999999999
99999..9999..999999999999
99999........999999999999
9999999999999999999999999

because when the image is filtered the additional outside padding
will affect the vissible area
consider:
999999000000   -> 9999865100
vs
999999999999   -> 9999999999
the vissible part is:
999986
vs
999999

or said differently the 0 padding gets "smeared" into the vissible
image, so the more similar it is to the input image the less artifacts
this creates

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150303/9ab93de2/attachment.asc>


More information about the ffmpeg-devel mailing list