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

[Michael Niedermayer]

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 

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/246243c3/attachment.asc>