On Tue, Aug 12, 2014 at 12:52:45AM +0200, Daniel Oberhoff wrote: > > Am 11.08.2014 um 17:39 schrieb Clément Bœsch <u...@pkh.me>: > > > On Mon, Aug 11, 2014 at 05:33:10PM +0200, Daniel Oberhoff wrote: > >> > >> Am 11.08.2014 um 00:20 schrieb Michael Niedermayer <michae...@gmx.at>: > >> > >>> On Sun, Aug 10, 2014 at 08:36:37PM +0200, Daniel Oberhoff wrote: > >>>> > >>>> > >>>> Von meinem iPhone gesendet > >>>> > >>>>> Am 10.08.2014 um 17:50 schrieb Michael Niedermayer <michae...@gmx.at>: > >>>>> > >>>>>> On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote: > >>>>>> Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit : > >>>>>>> It is not mandatory(but it would be nice) to add other methods to have > >>>>>>> this filter included into libavfilter. > >>>>>> > >>>>>> Is it really a good idea? We would end up with various interpolation / > >>>>>> anti-aliasing algorithms implemented in each filter that needs it, > >>>>>> none of > >>>>>> them with the same set of architecture optimizations and each with its > >>>>>> own > >>>>>> set of bugs and misfeatures. > >>>>> > >>>>>> Until someone comes up with a really satisfactory solution, I believe > >>>>>> the > >>>>>> simple solution of suggesting users to upscale before the filter and > >>>>>> downscale after, using the optimized lswr scalers, is better. > >>>>> > >>>>> thats not practical > >>>>> a 1024x768 image would need to be upscaled to 262144x196608 to get > >>>>> 8bit precission from a nearest neighbor resampler as basis > >>>>> > >>>>> also see vf_perspective.c which supports bilinear and bicubic > >>>>> interpolation, these surely could be shared and exist already. > >>>>> > >>>>> of course we could push it with just nearest neighbor and work on that > >>>>> later, but i dont think only nearest neighbor and leaving it at that > >>>>> is a reasonable choice, its too poor quality wise > >>>> > >>>> I would like to push now, and try to generate a refactoring patch > >>>> possibly within the week. > >>> > >>> sure, feel free to push and send a pull request, or if you prefer > >>> i can allso apply the patch if you post the latest verision > >> > >> I am not sure about pull requests (would have to read up on how to do that > >> properly) so rigjht now I would prefer it by patch: > >> > >> > >> > >> Is that ok? > >> > > > > Yes, please just re-submit the patch here. > > Darn, forgot that attachements are scrubbed from the list (I had the patch > attached). Will paste at the end. > > > > > Sorry about the suggestion of adding FATE tests, I forgot the fact that > > the filter was actually using floats. > > No probs :) > > From aa27195163da74c6e8f6a3b258f971f589d19aca Mon Sep 17 00:00:00 2001 > From: Daniel Oberhoff <dan...@danieloberhoff.de> > Date: Mon, 28 Jul 2014 23:58:12 +0200 > Subject: [PATCH] avfilter: ported lenscorrection filter from frei0r
patch applied if you would change it to use fixed point instead of floating point calculatios then a regression test would be possible Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
