--- Daniel Oberhoff daniel.oberh...@gmail.com
On Aug 20, 2014, at 4:20 PM, Michael Niedermayer <michae...@gmx.at> wrote: > On Wed, Aug 20, 2014 at 03:48:39PM +0200, Daniel Oberhoff wrote: >> >> --- >> Daniel Oberhoff >> daniel.oberh...@gmail.com >> >> >> >> On Aug 20, 2014, at 3:11 PM, Michael Niedermayer <michae...@gmx.at> wrote: >> >>> On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote: >>>> >>>> --- >>>> Daniel Oberhoff >>>> daniel.oberh...@gmail.com >>>> >>>> >>>> >>>> On Aug 20, 2014, at 2:55 PM, Michael Niedermayer <michae...@gmx.at> wrote: >>>> >>>>> On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: >>>>>> >>>>>> --- >>>>>> Daniel Oberhoff >>>>>> daniel.oberh...@gmail.com >>>>>> >>>>>> >>>>>> >>>>>> On Aug 20, 2014, at 2:33 PM, Michael Niedermayer <michae...@gmx.at> >>>>>> wrote: >>>>>> >>>>>>> On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: >>>>>>>> So we prefer int64_t above float32? >>>>>>> >>>>>>> well, its not exactly making me happy either but its just 2 32x32->64 >>>>>>> operations per pixel which shouldnt be that bad when we need to do >>>>>>> 16 multiplications for bicubic per sample >>>>>>> also at the expense of a bit more space they could be precalculated >>>>>>> as they dont change between frames >>>>>>> >>>>>>> >>>>>>>> I assumed we stick with 32bits for calculations. Did you test this >>>>>>>> with very large resolutions? >>>>>>> >>>>>>> just tried: >>>>>>> ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf >>>>>>> lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 >>>>>>> which seems working >>>>>>> >>>>>>> >>>>>>>> I so congratulation :). I am glad I could push you to finish what I >>>>>>>> failed to do :). >>>>>>>> >>>>>>>> As I would still like to have interpolation, I assume I shall refactor >>>>>>>> the interpolation out of perspective and rotation instead, right? >>>>>> >>>>>> Ok, but by default I would only refactor so far as to support all use >>>>>> cases currently in perspective/rotate/lens_correction, and none more. >>>>> >>>>> sure >>>>> >>>>> >>>>>> Do you still think there should be a version/versions of the algorithm >>>>>> for packed formats? >>>>> >>>>> i think if we want to add gamma correct interpolation then yes >>>>> otherwise its probably not worth the work >>>> >>>> to be honest: I have no idea about that, do you have pointers for that? >>>> I.e. what it is, how it works, when it is needed, how it correlates with >>>> the image representation (i.e. yuv vs rgb, compressed vs full, etc)? >>> >>> its very simple >>> normal every day 8bit per sample rgb and yuv are not "linear", in the >>> sense that twice the number of photons does not equal twice the >>> integer value for , lets say red or y >>> >>> but interpolation, be that bilinear or bicubic assumes that it is so >>> so it would be needed to first get linear rgb (which needs more than >>> 8bits per sample to look good) then interpolate in that and then >>> to convert back to everyday gamma corrected 8bit per sample rgb >>> >>> in principle these correction steps could be done by seperate filters >>> and RGB48 could be used in vf_lenscorrection then vf_lenscorrection >>> would not need to know about any of that >> >> Right, so by supporting rgb48 that would be effectively supported. Sounds ok >> to me for the time being as workaround for high quality operation. > > yes, theoretically > in practice we might need something to make it convenient to be used > requiring the user the manually insert some kind of gamma correction > filter before and afterwards is a bit inconvenient Hey, are you going to push this? Could then start a new resampling patch tomorrow. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
