[FFmpeg-user] v360 / perspective

Michael Koch astroelectronic at t-online.de
Mon Dec 7 23:27:23 EET 2020


Am 05.12.2020 um 21:00 schrieb Michael Koch:
> Am 05.12.2020 um 13:03 schrieb Paul B Mahol:
>> On Sat, Dec 5, 2020 at 12:30 PM Michael Koch 
>> <astroelectronic at t-online.de>
>> wrote:
>>
>>> Am 05.12.2020 um 11:38 schrieb Paul B Mahol:
>>>> On Sat, Dec 5, 2020 at 11:02 AM Michael Koch <
>>> astroelectronic at t-online.de>
>>>> wrote:
>>>>
>>>>> Am 04.12.2020 um 18:14 schrieb Paul B Mahol:
>>>>>> On Wed, Dec 2, 2020 at 11:11 PM Michael Koch <
>>>>> astroelectronic at t-online.de>
>>>>>> wrote:
>>>>>>
>>>>>>> Am 01.12.2020 um 19:56 schrieb Michael Koch:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> there seem to be some problems in the v360 filter with 
>>>>>>>> "perspective"
>>>>>>>> output.
>>>>>>>> Tested with the latest Windows built, 2 days old. You can 
>>>>>>>> reproduce
>>>>>>>> this with any equirectangular input image.
>>>>>>>>
>>>>>>>> ffmpeg -i equirectangular_test.png -lavfi v360=e:perspective -y
>>>>> out1.png
>>>>>>>> The output of the above command has two problems:
>>>>>>>> -- The center of the input image is not mapped to the center of 
>>>>>>>> the
>>>>>>>> output image. For most other projections the image center is
>>> preserved.
>>>>>>>> -- The output is mirror reversed (which means you cannot read 
>>>>>>>> text).
>>>>>>>>
>>>>>>>> Both problems can be corrected with this workaround:
>>>>>>>>
>>>>>>>> ffmpeg -i equirectangular_test.png -lavfi
>>>>>>>> v360=e:perspective:pitch=90:v_flip=1 -y out2.png
>>>>>>>>
>>>>>>>> Now I want to add a yaw rotation after the pitch rotation:
>>>>>>>>
>>>>>>>> ffmpeg -i equirectangular_test.png -lavfi
>>>>>>>> v360=e:perspective:rorder=pyr:pitch=90:yaw=20:v_flip=1 -y out3.png
>>>>>>>>
>>>>>>>> But in the output you can see that a roll rotation was done.
>>>>>>> Today I did for the very first time figure out how to compile 
>>>>>>> ffmpeg.
>>>>>>> The above problem can be solved by changing two lines in vf_v360.c
>>>>>>> Sorry, I haven't yet figured out how to use git.One thing after the
>>>>>>> other...
>>>>>>>
>>>>>>> Old version:
>>>>>>> line 3136:   vec[1] = sin_theta;
>>>>>>> line 3137: vec[2] = cos_theta * cos_phi;
>>>>>>>
>>>>>>> New version:
>>>>>>> line 3136: vec[1] = cos_theta * cos_phi;
>>>>>>> line 3137: vec[2] = sin_theta;
>>>>>>>
>>>>>>> I'm not sure if lines 3139 to 3141 must also be changed.
>>>>>>>
>>>>>>>
>>>>>> Good job!
>>>>>> Please write a patch with correct authorship and send it to the 
>>>>>> devel
>>>>> list.
>>>>>> Fixing this for you was much more work than writing & sending patch
>>> will
>>>>> be.
>>>>>
>>>>> Can you please explain what's the exact meaning of "v_fov" with
>>>>> perspective output?
>>>>>
>>>> What's written in documentation. It just scales differently.
>>> "Set perspective parameter" or "It just scales differently" are too
>>> vague explanations. Especially since the v_fov parameter here seems to
>>> have a completely different meaning than in other projections. One 
>>> thing
>>> is sure: It's not an angle in degrees.
>>>
>> Look again at the formula of projection, it explains everything.
>
>
> The input image is mapped on a sphere and this sphere is viewed with a 
> camera from outside. The distance between camera and sphere is an 
> unknown function of v_fov. It's sure that v_fov can't be the 
> normalized distance, because for the smallest possible v_fov value 
> (1e-5) there is roughly a 60° segment visible in the output image. It 
> must be a more complicated function.
>
> Too many unknowns:
> -- The _exact_ meaning of 'v_fov' is unknown.
> -- It's unknown what type of lens is used in the camera. Fisheye or 
> rectilinear or something else?
>

If the exact meaning of the option 'v_fov' is unknown, then we should 
give it a clear definition.
For example the normalized distance from the camera to the surface of 
the sphere. The internal variable 'h' would be the normalized distance 
from the camera to the center of the unit sphere.
I could rewrite the algorithm for this definition. The resulting mapping 
would be different from the existing mapping. Almost the same for large 
distance, but clearly different for small distance.

In the existing code I don't understand what's done in line 3119.
Line 3121 is the coordinate of the intersection of a line and a circle, 
as described in this wikipedia article:
https://en.wikipedia.org/wiki/Intersection_(Euclidean_geometry)#A_line_and_a_circle
I don't think line 3121 is correct. I may be wrong if 'v_fov' has a 
different meaning. But I have no idea what else it could be.

Michael



More information about the ffmpeg-user mailing list