On 7/19/20, Steinar H. Gunderson <steinar+ffm...@gunderson.no> wrote: > On Sun, Jul 19, 2020 at 07:32:18PM +0200, Paul B Mahol wrote: >> I see nothing wrong with that image. > > Let me provide some zooms. First, center artifacts (the “flower” should not > be there): > > http://storage.sesse.net/ffmpeg-radialblur3-zoom1.png > > Then, staircase/uneven horizontal line near the edge (the line should not > wobble up and down): > > http://storage.sesse.net/ffmpeg-radialblur3-zoom2.png
Huh, since when we look at such small differences? > >> You still provided 0 valuable information for your perfect solution >> algorithm. > > I haven't claimed any perfect solutions, but I have suggested two different > algorithms with details that I both believe would be more performant and > sport higher output quality (actually three, but the last one was not with > a lot of details). Could you suggest which information you would regard as > valuable? > > Here's the source code for GIMP's zoom blur implementation, which works > without any similar artifacts, and has no trigonometry per-pixel: > > > https://gitlab.gnome.org/GNOME/gegl/-/blob/master/operations/common-gpl3+/motion-blur-zoom.c#L160 > > If you can explain what you mean the difference between radial and zoom blur > is, it would probably be possible to adapt the idea. That algorithm is very slow for big lengths, it takes ages to process single small image. > > It also has a somewhat more efficient implementation of bilinear filtering > than in your patch (three multiplies instead of eight, and also fewer > add/sub), although it's likely that a fixed-point implementation would save > yet more time if you're interested in trying that. Such micro-optimizations could be added any time later. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
