Correcting for a curved film plane?

[fmw42]

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

The rect is short for rectangular and is really in this case a perspective projection. Since you avoided rect2polar or cartesian2polar or car2pol, I assumed you would have no objection to rect in this case. In fact is really should be cyl2perspective or cyl2persp, but that is perhaps too long or not so clear. By "plain", do you really mean "plane" (as in planar). That would be OK -- cyl2plane and plane2cyl.


Actually the cylinderize script is not an orthographic or a perspective projection but a "wrapping" concept where the width is converted directly to the angle around the cylinder. It is kind of the reverse way the P90 image is formed (a cylinder that is uncurved). But when we undo it we convert the uncurved image to a cylinder and then to a perspective view.

The spherize script is probably an orthographic projection. But I would need to review my script in more detail to be sure.

Fred

[anthony]

I would not consider using 'perspective', as meaning radial projection, as too many people already think of perspective as being solely a radial Plane to Plane 3D Projection. EG what our eyes see with regards to Planes in the real world.

However I have completed initial implementation, with 'bestfit' in place (no derivatives or center of distortion options) and have uploaded it to SVN.

Distortion names are Cylin2Plane and Plane2Cylin,
and both only takes one argument FOV angular arc.

Here are my tests, with 'bestfit' enabled. However I used an angle of 90 rather than 90.467 and saved using JPEG (generally regarded as a no-no. I used two different virtual pixels, so you can get some idea of what is happening.

Original Image

Code: Select all

 convert P90achop.jpg -virtual-pixel Gray  +distort Cylin2Plane 90 P90achop_distort.jpg

Code: Select all

convert P90achop_distort.jpg  -virtual-pixel black +distort Plane2Cylin 90 P90achop_restored.jpg

PS; distort viewports are enabled, as is verbose FX equivalence test output (which I use to double check the results).

----

Tomorrow I'll get the derivatives in place. Then we can think about any modifications (location of center of distort) or view limits such as extracting a smaller arc from a 360 cylinder, and/or scaling to a specific pixel size.

That last will allow the creation of cube projections, or extract a view from a different directions.
NOTE for cubic views minor scaling factors may need to be calculated so a 90 degree view will coincide with actual pixel boundaries of a cubic face!

The current 1:1 means edges many not match image edges with an image edge in the new image, which is why the previous ceil() addition was needed to prevent clipping and align center points to actual pixel locations (center or edge of a pixel) so distortion is properly reversible.

[anthony]

Hmmm something about this example actually strikes me as funny.

Not every thing in the film is vertical. The only thing that could account for this would be that the image was taken with the camera pointing slightly downward, causing vertical objects (such as trees and fence posts) to diverge as they climb higher.

The only way I can think of correcting that would be to map the cylinder onto a sphere, adjust the angle then map it say directly to a flat plane.

Just a thought.

Obviously a lot more distortions need to be added to IM, and I will need to eventually look at methods of applying a sequence of distortions simultaneously, so as to reduce pixel level distortions to a single lookup. Still its an idea that could be regarded as a major project in self to implement (just as a grid, spline, or triangulation distortion is).

[Mark Sirota]

Yes, it looks to me like that shot had pointing slightly down. That's why I was excited about that other shot I found, which had lots of straight lines -- but while the owner has said it's okay to use it, he hasn't made it available to download and has not responded to my latest request. In any case, since we have permission, I think it's okay to take it from a screen shot, which I've taken and uploaded to my own site -- here's the link:

http://www.sirota.org/mark/photography/poboxes.png

[fmw42]

Anthony,

Why is your second example cropped horizontally and not vertically to remove the gray and black excess? Is there anyway to crop like in my example to keep the full width, but crop the top and bottom to the size at the middle? Can a mode argument be provided to allow such, if needed? Does that not sound useful? See my examples earlier on page 2.

Alternately, could you provide something like -mattecolor to allow the gray to become black (same color as -virtual-pixel) so that -trim could be used subsequently.

Fred

[anthony]

Anthony,

Why is your second example cropped horizontally and not vertically to remove the gray and black excess? Is there anyway to crop like in my example to keep the full width, but crop the top and bottom to the size at the middle? Can a mode argument be provided to allow such, if needed? Does that not sound useful? See my examples earlier on page 2.

Because bestfit by its defintion trys to preserve as much of the input image as posible, which means it will include more virtual pixels. IM has no way of knowing what it can remove!

The input was the result of the first example (second image) and as such the grey parts are part of the image to be preserved. Try it with the second image cropped to the same height as the original input image, and you get the right hight but then you loose the corners of the image.

Alternately, could you provide something like -mattecolor to allow the gray to become black (same color as -virtual-pixel) so that -trim could be used subsequently.

Matte color is used when the math becomes invalid. No parts of this example has invalid areas. And in Plane2Cylin you do not get invalid pixels ever! Cylin2Plane also can not generate invalid pixels, But what it can generate is a infinity wide result image (input FOV 180 degrees). That is taken care of by an argument check (limit 160)

Later when I finally work out the arguments needed to handle 360 cylinder images, (see my previous notes about lining up FOV image edge with image pixel boundaries) then I will need a different FOV output argument that will be limited to less than 160 (probably default 90), instead of the first (input image FOV angle) argument.

Some very nice 360 cylinder examples (vertical FOV 90 degree) on mar scenery is present on Paul Bourke's cubic projection web site.
http://paulbourke.net/miscellaneous/cube2cyl/

Note that stitching panarama images probably work better as cylindrical images! But working out the FOV for a typical normal Digital Photo is something that needs to be worked out. Any ideas?

Then again unless the camera was horizontal, the cylindrical view will not match either! Arrgghhhh...

[anthony]

In any case, since we have permission, I think it's okay to take it from a screen shot, which I've taken and uploaded to my own site -- here's the link:

http://www.sirota.org/mark/photography/poboxes.png

You may like to 'shave' that image by one pixel to get a pixel size of 1024x512


Hmmm running the distortion on it and I did not get stright lines! They bent the other way!

In fact the top line of the postboxes only became straight at a FOV angle of 75 degrees, but the other lines were not straight! They were only straight at an angle of FOV angle 94 degrees

It looks to me like either the film was not properly cylindrical (jumped track or distorted) or the image has been processed in some way.

In any case it does not seem to be quite right.

[fmw42]

Anthony,

Why is your second example cropped horizontally and not vertically to remove the gray and black excess? Is there anyway to crop like in my example to keep the full width, but crop the top and bottom to the size at the middle? Can a mode argument be provided to allow such, if needed? Does that not sound useful? See my examples earlier on page 2.

Because bestfit by its defintion trys to preserve as much of the input image as posible, which means it will include more virtual pixels. IM has no way of knowing what it can remove!

The input was the result of the first example (second image) and as such the grey parts are part of the image to be preserved. Try it with the second image cropped to the same height as the original input image, and you get the right hight but then you loose the corners of the image.

Alternately, could you provide something like -mattecolor to allow the gray to become black (same color as -virtual-pixel) so that -trim could be used subsequently.

Matte color is used when the math becomes invalid. No parts of this example has invalid areas. And in Plane2Cylin you do not get invalid pixels ever! Cylin2Plane also can not generate invalid pixels, But what it can generate is a infinity wide result image (input FOV 180 degrees). That is taken care of by an argument check (limit 160)

Later when I finally work out the arguments needed to handle 360 cylinder images, (see my previous notes about lining up FOV image edge with image pixel boundaries) then I will need a different FOV output argument that will be limited to less than 160 (probably default 90), instead of the first (input image FOV angle) argument.

Some very nice 360 cylinder examples (vertical FOV 90 degree) on mar scenery is present on Paul Bourke's cubic projection web site.
http://paulbourke.net/miscellaneous/cube2cyl/

Note that stitching panarama images probably work better as cylindrical images! But working out the FOV for a typical normal Digital Photo is something that needs to be worked out. Any ideas?

Then again unless the camera was horizontal, the cylindrical view will not match either! Arrgghhhh...

I am puzzled why your second example has both gray and black. I thought that one might be a mattecolor issue. Why is this happening?

In my examples, I never got two background colors. My example looked like your first one, but with black for -virtual-pixel. When you do that you get both gray and black? Very strange to me.

You did not answer my question about a way to emulate my second example, that cropped the image only vertically to remove any signs of the virtual pixel fill. Is that possible in your coding with another argument if needed? Seems to me to be a useful option. To do it manually, one would have to measure the width of the output and use the height of input and do a center crop. Any way, I guess that is not too hard. Just requires an extra step of getting and measuring the output before cropping.

Fred

[fmw42]

In any case, since we have permission, I think it's okay to take it from a screen shot, which I've taken and uploaded to my own site -- here's the link:

http://www.sirota.org/mark/photography/poboxes.png

You may like to 'shave' that image by one pixel to get a pixel size of 1024x512


Hmmm running the distortion on it and I did not get stright lines! They bent the other way!

In fact the top line of the postboxes only became straight at a FOV angle of 75 degrees, but the other lines were not straight! They were only straight at an angle of FOV angle 94 degrees

It looks to me like either the film was not properly cylindrical (jumped track or distorted) or the image has been processed in some way.

In any case it does not seem to be quite right.

Does one really know the fov of that image? Perhaps it was actually 94 degrees?

[anthony]

Looks as if we lost our original questioner.

Both distortions are in place for the next release of IM v6.7.0-8 (UPDATE: This has now been released)
However both only take one argument, the angular FOV (field of view) for the width of the input image.
I am waiting on feed back from another user (by his request) before proceeding further.

The distortions are NOT listed in -list distorts (yet) But are Cylinder2Plane and Plane2Cylinder

Here is a particular advanced example generating an Distorted animation, using "Plane2Cylinder" with a input FOV of 115 degrees chossen so the output FOV ends up to be just short of 180 degrees (an horizon to horizon cylindrical panorama)

Code: Select all

  #
  # Create hole image, duplicate (x6) and append horizontally, duplicate (x2)
  # insert rose image in between and vertically append (black fill)
  # make three frames to form final distortion image size.
  # generate a 20 frame rolling animation using width of one frame only
  # distort all animation frames into a cylinder panorama view
  # add a top/ bottom border, set timeing delay, and save.
  #
  convert -size 12x12 xc: -draw 'circle 6,6 6,2' -negate \
          -duplicate 5 +append +duplicate \
          rose: +swap -background black -append \
          -duplicate 3 +append \
          -virtual-pixel HorizontalTile -background SkyBlue \
          -duplicate 19  -distort SRT '%[fx:72*t/n],0 1 0 0,0' \
          -distort Plane2cylinder 115 \
          -bordercolor Skyblue -border 0x3 -set delay 10 \
          film_strip_anim.gif

More argument options will allows even more effects. Went finished an IM examples section will be created.

[Mark Sirota]

Sorry, I'm still here. I don't know the FOV of that mail boxes image; I assumed it was the full frame from a P.90. But the photographer is not replying to my queries, and I don't yet own one of these things. I have plans to build one...

[Mark Sirota]

Anthony, thank you thank you thank you for implementing this in 6.7.0-8. I'm really impressed by this community!

Next up -- algorithmic vignetting correction for scans from pinhole cameras. I've started a new thread.

[anthony]

As Fred pointed out to me you can also specify the FOV as a equation using radius and frame width...
convert P90_image.png +convert '%[fx:90/57 * 180/pi]' P90_image_flat.png

90/57 is the arc angle of a cylinder of 57mm radius and a circumference width or 90mm frame. The 180/pi converts an angle in radians to degrees.

However there will be other optional arguments added to the above distortion, later. Just waiting on some input from another photographer, who is currently away, to make comments about what these optional arguments should be. As such I expect this discussion will continue, either here, or in another thread.



ASIDE: The argument handling of percent escapes in -distort may change in IM v7, as percent escapes become available in all arguments (and more). This is just a fore-warning to script writers and programmers.

[whugemann]

Hello everybody,

I am back from my cycling holidays in France and have just studied all of what you have written on this thread in the meantime.

I have just read the Hugin projection page more thoroughly and I have to admit that I was wrong in my first comment: Panorama software is trying to map a sphere onto a planar surface, i.e. do what carthographs usually do. The correction we need for the pinhole camera is different, i.e. the projection of a cylinder onto a plane (or vice versa).

As with other options in ImageMagick, I think that the distortion operations could need some grouping, either by naming them more consequently or by introducing another "name layer". If Anthony would for instance introduce spherical map projections sometime in the future, it would be great to group them either by name or by some extra operator -- or even a new option like "-project". For example

convert sphere.jpg -project mercator map.jpg
convert sphere.jpg -project rectilinear map.jpg

Alternatively (but not as good):

convert sphere.jpg -distort project-mercator map.jpg

I don't consider it a good idea to call just any coordinate manipulation a "distortion". I think that mathematicans would call any mapping which uses rays coming out of a single point a projection (including the pespective projection).

[fmw42]

Hello everybody,

I am back from my cycling holidays in France and have just studied all of what you have written on this thread in the meantime.

I have just read the Hugin projection page more thoroughly and I have to admit that I was wrong in my first comment: Panorama software is trying to map a sphere onto a planar surface, i.e. do what carthographs usually do. The correction we need for the pinhole camera is different, i.e. the projection of a cylinder onto a plane (or vice versa).

As with other options in ImageMagick, I think that the distortion operations could need some grouping, either by naming them more consequently or by introducing another "name layer". If Anthony would for instance introduce spherical map projections sometime in the future, it would be great to group them either by name or by some extra operator -- or even a new option like "-project". For example

convert sphere.jpg -project mercator map.jpg
convert sphere.jpg -project rectilinear map.jpg

Alternatively (but not as good):

convert sphere.jpg -distort project-mercator map.jpg

I don't consider it a good idea to call just any coordinate manipulation a "distortion". I think that mathematicans would call any mapping which uses rays coming out of a single point a projection (including the pespective projection).

Wolfgang,

What image would you start with to go to say a mercator projection or any other cartographic map projection? Would you not need an image that is in lat, lon format rather than x,y (properly representing angular coordinates on a sphere of a given radius)

So it seems to me that these cartographic projections are between lat, lon format and the given map projection or the reverse. Or a 3-way from mercator to lat, lon and then to some other map projection.

At least that is what we used to do when I worked at TRW.

Once you start on this, there are so many map projections to consider, it then becomes a major effort to implement many of them, especially as Anthony needs the derivatives of the transformation in order to allow the EWA antialiasing.

I would think that other "distortions" such as the simpler wrapping an image on a cylinder or sphere (my cylinderize and spherize scripts) and more important the fisheye transformations would be more important as fisheye cameras are common and people would want to correct those to more common perspective projections.

Fred