The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Christoph Lipka - 2011-09-12
Last edited by Jim Holsenback - 2011-10-14
FS#219 - Panoramic camera broken & obsolete
According to the docs, the panoramic camera...
[...] uses a type of cylindrical projection to be able to use viewing angles larger than 180 degrees with a tolerable lateral-stretching distortion. The angle keyword is used to determine the viewing angle.
However, current implementation differs (and probably always has): The angle keyword has no effect, and the effective viewing angle is fixed to 180 degrees. Also note that this behaviour is identical to the spherical camera with angle 180,180, making the panoramic camera obsolete.
I propose to deprecate the “panoramic” keyword; should the keyword be encountered in a camera block, the code for the spherical camera should be used instead, except that the angle setting should be forced to 180,180; this should be accompanied by a parse warning.
I don't have a 3.6 setup, and don't really plan on doing anything about that, however feel the decision should be based on whether it ever worked ... fix it if it did ... bone yard if it didn't.
It probably can be tested with 3.5, as the camera handling was changed for 3.6. It is possible that this behavior was introduced back then, or it is possible that it was broken in 3.5 already.
Testing with binary linux 3.5 from ftp server, the scene/camera/panoramic.pov : all 3 versions (3.5, 3.6 and 3.7RC3++) provides the same view. (colour saturation is another matter: 3.5 is more saturated, 3.6 is clearer, and 3.7 is in compatibility mode with 3.6)
Changing angle for 3.5 does nothing. (either angle 120, 180 or 80 produce the same view)
Replacing panoramic with spherical/cylinder [1 to 4] never provides the same view. It looks like spherical with angle 180,180 looks the same, but there are significant differences in the geometry:
here after a few (tagged S for spherical, tagged P for panoramic):
* curve of top of top block on right : S=going downward from left to right, horizontal at left. P=going upward from left to right, horizontal at right
* brown/orange box on left is different: S is smaller and further than P.
Using panoramic.pov included in 3.5, I got panoramic.png;
and making a replacement for panoramic with spherical angle 180,180, I got panoramics.png (notice the s extension).
With imagemagick compare (compare panoramic.png panoramics.png delta.png), the difference are more easy to spot.
Attached file is that delta.png
So far, panoramic in 3.7RC3++ is conform to the view of 3.5.
So if I understand this correctly, then the spherical camera has changed from 3.5 to 3.6?
Not from my experiment. panoramic was not spherical in 3.5; and it is not in 3.7RC3 neither.
And it was neither in 3.6
Panoramic from 3.5 to 3.7RC3+ (including 3.6) just stayed the same.
Spherical from 3.5 to 3.7RC3+ (including 3.6) just stayed the same, too.
But panoramic is not spherical. And was not.
Attached the 6 rendered images (prefix p for panoramic, s for spherical, suffix is version of povray)
other details: +H1025 +W1025 +A0.1
Delta on version-lines is minimal.
Delta on camera type is kind of constant. (which seems good)
I checked it again, only to find that you're right: Obviously the panoramic camera isn't as obsolete as I thought.
The docs claim that "panoramic" should be a "cylindrical equirectangular projection" - whatever projection that's supposed to be; my best bet would be what Wikipedia calls "equirectangular projection (also called the equidirectional projection, equidistant cylindrical projection, geographic projection, plate carrée or carte parallelogrammatique projection or CPP)". If that is the case, then a latitude/longitude grid overlaid on an image should have all lines parallel. I tested this by placing a "latitude/longitude cage" around the camera - see the attached files. Obviously it's not an "equirectangular projection" as the docs would lead me to believe (while the "spherical" projection absolutely is), but what kind of beast is it? And which is wrong - the docs or the code?
I have been diving in the code of camera the last few days (*). The comments about panoramic (in source/backend/render/tracepixel.cpp) cite Graphic Gems III.
Current research gives http://tog.acm.org/resources/GraphicsGems/
The relevant code use tan(y) like the code of povray.
The explanation would be in pages p. 288-294, if anyone has the book... nearly 20 years old.
(*): I need to make a kind of tutorial/explanation (at least for myself) about all the various camera and their settings. The difference are sometime subtile.
(for instance, neither panoramic nor spherical would return false, which some other camera do, to provide a black part... despite the comment in panoramic.pov!)
I have this. I can scan if you like.
If/when you guys sort out where this is leading, and it turns out that the docs need changing, I'll still have to defer to another team member to change the content, but I'll do my VERY best to make sure that the wiki-docgen process picks up those changes, and the new doc sets get posted.
The code described in "Graphic Gems III" implements exactly the same projection as POV-Ray's "spherical" camera (albeit using a slightly different algorithm).
After more digging into the code and testing, I found that the "panoramic" camera, too, is an implementation of that projection - but a very limited one, being subject to the following restrictions:
- The viewing angles are limited to 180,180 (the "Graphic Gems III" code also allows for parameterization there, just as the "spherical" camera).
- The "direction", "right" and "up" vectors must have same length (which by default they don't; by contrast, the "spherical" camera ignores the absolute length of these vectors).
Any suggestion on how to proceed with this?
BTW, some of the other exotic camera types also seem to suffer regression / poor definition problems regarding the various camera parameters.
suggestions... : For 3.7, keep the cameras as they are (that's called compatibility with previous versions). That includes the fact that default vectors are not unity-length.
Should panoramic be changed or be obsoleted, in a next version ? I wonder.
spherical is too perfect. It might be interesting, from the artistic point of view, to keep the way panoramic is performed (especially with non-unit, non-perpendicular vector).
About the wrong comment in panoramic.pov (getting a circle or ellipse), it's just a wrong comment. Should it be updated ? Probably.
About the other exotic camera types and the handling of the various camera parameters... well, it need to be documented, and I hope to provide that (at least a draft)... but that should not stop the release process.
excepted for spherical & mesh, all camera types accept an angle single value, in a special processing of options; Some just ignore it anyway (excepted that perspective & orthographic for instance would adjust the Direction vector based on the angle, in the post-processing of the camera's parsing, and then drop it from the equation). The most strange camera so far seems omnimax, whose processing change with aspectRatio (<1, 1<1.283458, >1.283458). (and ultra_wide_angle uses an inverted aspectRatio, (from other cameras' pov))
At least, the documentation about panoramic should stress: the "same-length" vectors are recommended for spherical behaviour. Yet, you're free to not enforce it. Whatever, Angle is ignored with panoramic.
Are there is more changes to the camera documentation needed? If not I'll merge changes/images that were posted to that sections talk page
Entire camera section has been updated (narrative and images) but I haven't processed the changes through wiki-docgen yet. I'm going to wait in case there are anymore changes. In the mean time feel free to review the changes, and I'll watch for any further comments.
new doc sets have been posted in the usual place