Legacy ImageMagick Discussions Archive

I will probably also need the slope of the formula for EWA resampling, and that may be a bit trickier.

fmw42 wrote:

I would not be surprised it may be that it is actually engineered to be 90 degrees, but with 57mm being a near approximation (for advertising). We would need to know for certain!

Actually the specs on the reference page say it is nearly 90 degree field of view and give a specific focal length of 57. So one has to believe what they say and not infer too much. The f stop is well defined and so is the focal length which is related to it. So I would tend to believe that rather than assuming that the fov is truly 90 degrees.

The only really firm characteristic of a film-based pinhole camera is the focal length. The angle of view may vary, as especially with roll film many cameras allow this to be changed when you load the film, and scans may not cover the entire frame.

So focal length is the safest number. But it's generally measured in millimeters, and we need it in pixels. Scan resolution is measured in pixels per inch, so it can be converted to pixels... But the scan resolution metadata may have been stripped from the file before it gets to ImageMagick.

So the second best number is angle of view. It's determined at film load time at worst, so the photographer should know. And if the photographer wants to be very precise it can be measured, rather than just trusting the camera manufacturer (many of these cameras are home-made anyway). Focal length is harder to measure accurately.

Also, if the input is angle of view, you can simply ensure that it's <180 before proceeding, and throw an error if it is >=180.

Thanks to everyone for taking this up. This is a great community!

So focal length is the safest number. But it's generally measured in millimeters, and we need it in pixels.

My formula converted it to pixels in the process of evaluating the exact fov, but required knowledge of the width of the image in mm (or cm).

Also see my numbers above on how fast the image size grows with fov. By 160 degrees its area is about 16 times as big as the input.

Fred

fmw42 wrote:Also see my numbers above on how fast the image size grows with fov. By 160 degrees its area is about 16 times as big as the input.

Is that a problem?

Mark Sirota wrote:

fmw42 wrote:Also see my numbers above on how fast the image size grows with fov. By 160 degrees its area is about 16 times as big as the input.

Is that a problem?

Depends upon your computer memory and size of the input image. Also it will grow much faster as you approach 180 at which it will be infinite in size.

fmw42 wrote:references http://mathworld.wolfram.com/CylindricalProjection.html at the bottom where it says
"Cylindrical projection at Mathworld[*] shows an example and gives details on the mathematics"
click the asterisk to see the diagram of the projection

Except that they are mapping sphere angles to a cylinder. we are mapping a cylinder to a flat plain!
As such their use of 'tan' for the y axis is not needed, and instead we get a scaling (that varies with x)

Unfortunately we get a new tan from the x axis mapping instead.

anthony wrote:

fmw42 wrote:references http://mathworld.wolfram.com/CylindricalProjection.html at the bottom where it says
"Cylindrical projection at Mathworld[*] shows an example and gives details on the mathematics"
click the asterisk to see the diagram of the projection

Except that they are mapping sphere angles to a cylinder. we are mapping a cylinder to a flat plain!
As such their use of 'tan' for the y axis is not needed, and instead we get a scaling (that varies with x)

Unfortunately we get a new tan from the x axis mapping instead.

As I said, this is not the same transformation we are doing here as described in the reference. I do not think you can generalize it the way you describe. Perhaps Wolfgang can clarify what it is he really thinks is important to have in IM.

Mark Sirota wrote:

fmw42 wrote:Also see my numbers above on how fast the image size grows with fov. By 160 degrees its area is about 16 times as big as the input.

Is that a problem?

No. it only becomes a problem if you try for 180, or an offset center in the distortion.

That is you want the center of the projection to be 45 degrees to the right, instead of in the middle.

anthony wrote:

Mark Sirota wrote:

fmw42 wrote:Also see my numbers above on how fast the image size grows with fov. By 160 degrees its area is about 16 times as big as the input.

Is that a problem?

No. it only becomes a problem if you try for 180, or an offset center in the distortion.

That is you want the center of the projection to be 45 degrees to the right, instead of in the middle.

I believe that one can live with the center of distortion corresponding to the center of fov (curve of cylinder), i.e. no offsets.

I am not sure how close to 180 you want to allow as it probably grows very fast near 180. Image size and memory or speed if using -limit are the practical limits.

fmw42 wrote:I believe that one can live with the center of distortion corresponding to the center of fov (curve of cylinder), i.e. no offsets.

I am not sure how close to 180 you want to allow as it probably grows very fast near 180. Image size and memory or speed if using -limit are the practical limits.

I'd like the input the center of distortion, as it means given a 360 (or slightly more) arc image, I can then convert that into a set of 4 'cube view' images of 90 degree arcs. each face with have a different center of distortion.

Anthony wrote:I'd like the input the center of distortion, as it means given a 360 (or slightly more) arc image, I can then convert that into a set of 4 'cube view' images of 90 degree arcs. each face with have a different center of distortion.

In my opinion, this P90 transformation does not work for a full circle, it fails at theta = 90 from the center. So if you break this into quadrants of the circle, and do each separately, you won't get a full circle or quadrant for each side and the sides will be huge. The referenced article by Wolfgang was a totally different transformation.

The "cube view" is usually used to represent a full sphere, if I am not mistaken. see
http://www.sai.msu.su/~megera/wiki/SphereCube
http://mathproofs.blogspot.com/2005/07/ ... phere.html
http://stackoverflow.com/questions/4676 ... thm-pseudo
http://paulbourke.net/miscellaneous/cuberender/

Here is cube to cylinder:
http://paulbourke.net/miscellaneous/cube2cyl/
and at the bottom is the usual environment map from cube to sphere

I apologize if I am misunderstanding what you are attempting to do.

Fred

No that is exactly what I want to be able to do. It is after all the same distortion. Just expanding beyond a P90 camera distortion.

Small change to the distortion FX equivalent...
The use of ceil() in ww and hh calculation will ensure the resulting image is properly centered in the quantized pixel array.

It also means the center of the destination is not simply any floating point number but will fall either in the center of a pixel (0.5 offset) or the edge of a pixel (integer).

This preserves image symmetry pixel-wise, and allows it to be properly reversible.

Names of distortion is
Decylinderize (project cylinder to flat plane) -- what the above shows.
Cylinderize (project flat plane to cylinder)
Work is underway (long weekend here in commonwealth countries fro Queens Birthday) but may not be available for some time.

I would suggest you go with the original names, cyl2rect and rect2cyl so as not to confuse that with my script cylinderize and any future implementation of wrapping an image about a cylinder (much the same as my script spherize and similar PS and GIMP function names that distort an image onto a sphere).

Fred

Sounds fair. Your cylinderize script is really a orthogional view of a cylinder wrapped image.
I think you spherize is similar but with a sphere.

However I think I would prefer 'plain' (3d surface) to 'rect' (2d shape or coordinate system)
rect is however appropriate for 'polar' transformations (another 2d coodinate system).