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

[Daniel Oberhoff]

---
 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)?