The original delogo algorithm interpolates both horizontally and
vertically and uses the average to compute the resulting sample. This
works reasonably well when the logo area is almost square. However
when the logo area is significantly larger than high or higher than
large, the result is largely suboptimal.
The issue can be clearly seen by testing the delogo filter with a fake
logo area that is 200 pixels large and 2 pixels high. Vertical
interpolation gives a very good result in that case, horizontal
interpolation gives a very bad result, and the overall result is poor,
because both are given the same weight.
Even when the logo is roughly square, the current algorithm gives poor
results on the borders of the logo area, because it always gives
horizontal and vertical interpolations an equal weight, and this is
suboptimal on borders. For example, in the middle of the left hand
side border of the logo, you want to trust the left known point much
more than the right known point (which the current algorithm already
does) but also much more than the top and bottom known points (which
the current algorithm doesn't do.)
By properly weighting each known point when computing the value of
each interpolated pixel, the visual result is much better, especially
on borders and/or for high or large logo areas.
The algorithm I implemented guarantees that the weight of each of the
4 known points directly depends on its distance to the interpolated
point. It is largely inspired from the original algorithm, the key
difference being that it computes the relative weights globally
instead of separating the vertical and horizontal interpolations and
combining them afterward.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
* 'drawbox_exprs' of https://github.com/mjmvisser/FFmpeg:
enabled expressions on x, y, w, h and t parameters for drawgrid and drawbox, added examples
Reviewed-by: Andrey Utkin
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'eeeb5c291d3f78eaade5b99c2614c7cab0e9be79':
vsrc_movie: do not free avoption variables in uninit()
Conflicts:
libavfilter/src_movie.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The algorithm works on src and writes to dst, not the other way
around.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Makes it easier to understand that there is no difference in init
callback for movie and amovie. Also saves a few lines of code.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
The drawbox video filter is drawing lines one pixel thinner than
requested. The default thickness is 4 pixel but in fact the lines
drawn by default are only 3 pixel wide.
Change the comparisons in the code to fix this off-by-one bug. Also
change the default thickness from 4 to 3 to minimize the unexpected
changes from the user's perspective.
As I was already touching these lines, I also removed the "maximum" in
the thickness parameter description, as I don't think it was adding
any value and I even found it confusing.
Reviewed-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Based on the libavfilter SOC filter by Vitor Sessak, with the following additions:
* integer arithmetic
* bilinear interpolation
* RGB path
* configurable parametric angle, output width and height
Address trac issue #1500.
See thread:
Subject: [FFmpeg-devel] [WIP] rotate filter(s)
Date: 2010-10-03 17:35:49 GMT
w/h from input frame are not copied in av_frame_copy_props(). This
commit avoids a mismatch between aligned_[wh] and outbuf->{width,height}
(and thus avoids triggering an assert in avfilter because of this).
Do not read padding or out-of-buffer values when computing the output
value for a pixel close to the image buffer edge.
This avoids non visible artifacts which affected the output checksum.
See thread:
Subject: [FFmpeg-devel] [PATCH] lavfi/mp/mcdeint: avoid uninited data read
Date: Thu, 30 May 2013 18:57:14 +0200
