[FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code

[Michael Niedermayer]

On Wed, Aug 20, 2014 at 03:48:39PM +0200, Daniel Oberhoff wrote:
> 
> ---
>  Daniel Oberhoff 
>  daniel.oberhoff at gmail.com
> 
> 
> 
> On Aug 20, 2014, at 3:11 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote:
> >> 
> >> ---
> >> Daniel Oberhoff 
> >> daniel.oberhoff at gmail.com
> >> 
> >> 
> >> 
> >> On Aug 20, 2014, at 2:55 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> 
> >>> On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote:
> >>>> 
> >>>> ---
> >>>> Daniel Oberhoff 
> >>>> daniel.oberhoff at gmail.com
> >>>> 
> >>>> 
> >>>> 
> >>>> On Aug 20, 2014, at 2:33 PM, Michael Niedermayer <michaelni at 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

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20140820/f1fab385/attachment.asc>