Copernicus: How to do fisheye distortion?
1316 9 4- raincole
- Member
- 539 posts
- Joined: Aug. 2019
- Offline
I'm trying to make something like this:
Better if I can make it procedurally so I can distort any image with this fake fisheye effect.
This is my best attempt:
It's somewhat similar, but you can see the curvature is not "convex" like the fisheye example.
Is there a better way?
Better if I can make it procedurally so I can distort any image with this fake fisheye effect.
This is my best attempt:
It's somewhat similar, but you can see the curvature is not "convex" like the fisheye example.
Is there a better way?
Edited by raincole - Aug. 8, 2024 01:15:06
- Mike_A
- Member
- 271 posts
- Joined: Aug. 2018
- Online
- raincole
- Member
- 539 posts
- Joined: Aug. 2019
- Offline
- Mike_A
- Member
- 271 posts
- Joined: Aug. 2018
- Online
One thing to note: the wrangle I've added is written in VEX. That is processed on the CPU. Writing it in OpenCL would process it on the GPU - faster, but currently I don't have a clue about writing code in OpenCL...
Maybe some kind OpenCL expert can translate the following VEX into the OpenCL equivalent for us : )
float ang = float(fit(@C,0,1,0,PI/2));
@C *= sin(ang);
Maybe some kind OpenCL expert can translate the following VEX into the OpenCL equivalent for us : )
float ang = float(fit(@C,0,1,0,PI/2));
@C *= sin(ang);
Edited by Mike_A - Aug. 9, 2024 09:33:23
- raincole
- Member
- 539 posts
- Joined: Aug. 2019
- Offline
- jlait
- Staff
- 6413 posts
- Joined: July 2005
- Offline
The problem is we did too good a job making VEX easy to write :>
We've done a lot to make OpenCL less painful, so hopefully you can start to transition for Copernicus nodes.
Here's your code transformed to OpenCL, starting from the default OpenCL node...
Note the use of M_PI rather than PI. VEX also supports M_PI, and I'd recommend you get in the habit of M_PI as it is a lot more portable outside of VEX.
There is a lot more explicit boilerplate in OpenCL, thus the #bind commands to define your interface to the code.
One change you can make in both VEX and OpenCL is to use sinpi(). sinpi() is in 20.5 VEX and allows you to avoid needing to work with Pi. This isn't just an improvement in typing, but also is useful mathematically as PI/2 isn't an exact number, while sin(PI/2) is an exact number.
We are definitely missing all the nice helper functions that VEX has... You often have to go down to mix() or similar. fit01 is luckily present from interpolate.h, but a lot of your other gotos will be missing :<
This is my go-to for references for raw OpenCL functions.
https://www.khronos.org/files/opencl-1-2-quick-reference-card.pdf [www.khronos.org]
We've done a lot to make OpenCL less painful, so hopefully you can start to transition for Copernicus nodes.
Here's your code transformed to OpenCL, starting from the default OpenCL node...
#bind layer src? val=0 float #bind layer !&dst float @KERNEL { float ang = fit01(@src,0,M_PI/2); float result = @src * sin(ang); @dst.set(result); }
Note the use of M_PI rather than PI. VEX also supports M_PI, and I'd recommend you get in the habit of M_PI as it is a lot more portable outside of VEX.
There is a lot more explicit boilerplate in OpenCL, thus the #bind commands to define your interface to the code.
One change you can make in both VEX and OpenCL is to use sinpi(). sinpi() is in 20.5 VEX and allows you to avoid needing to work with Pi. This isn't just an improvement in typing, but also is useful mathematically as PI/2 isn't an exact number, while sin(PI/2) is an exact number.
#bind layer src? val=0 float #bind layer !&dst float @KERNEL { float ang = fit01(@src,0,0.5); float result = @src * sinpi(ang); @dst.set(result); }
We are definitely missing all the nice helper functions that VEX has... You often have to go down to mix() or similar. fit01 is luckily present from interpolate.h, but a lot of your other gotos will be missing :<
This is my go-to for references for raw OpenCL functions.
https://www.khronos.org/files/opencl-1-2-quick-reference-card.pdf [www.khronos.org]
- ballinger500
- Member
- 6 posts
- Joined: April 2013
- Offline
- Mike_A
- Member
- 271 posts
- Joined: Aug. 2018
- Online
- raincole
- Member
- 539 posts
- Joined: Aug. 2019
- Offline
jlait
The problem is we did too good a job making VEX easy to write :>
True. Thank for your help and example code. But while I'm not against learning a bit of OpenCL for trivia case like this, I think letting the user write their custom functions in an unmanaged language (that can crash the whole Houdini or cause memory leak) isn't a very long term solution. Ideally there should be something in between, a safe language that might be limited in power but can utilize GPU in Copernius context.
I know it's not a simple feature and it might not come earlier than H23 or something. It's just my thought.
- GrahamDClark
- Member
- 112 posts
- Joined: July 2005
- Offline
jlaitThanks Jeff, that's awesome.
This is my go-to for references for raw OpenCL functions.
https://www.khronos.org/files/opencl-1-2-quick-reference-card.pdf [www.khronos.org]
here's an openCV one if it helps anyone, hip link here too:https://www.youtube.com/watch?v=IicwSX2od4Y. [www.youtube.com] just make sure to match the aspect, so 1 for your example here. EDIT sorry posted vex version first, OCL version added now
Edited by GrahamDClark - Aug. 25, 2024 19:27:37
-
- Quick Links