[X] My Assistant

[erwan]

I used Panorama Tools and Autostitch softwares to make Navcam or Pancam mosaics. Though powerful, these softwares assumed pictures to stitch are all shooted from an unique "Optical center". That is not the case for MER Navcam or Pancam images, shooted from the rotating Pancam Mast Assembly. Such an issue is very troublesome with Navcam images, given the wide field of view, and parallax defects between images, especially for close objects. For example, two Navcam images picturing some elements of the Rovers cannot very often be correctly stitched...
A good solution to stitch Navcam images is geometrical, i mean to project the different images reproducing Pancam Mast Assembly rotation. For images available on PDS node websites, we may found adapted PMA parameters near the end of the PDS label (Rover defined parameters, Azimuth and Elevation in degrees).
Then, we may render images projected this way with help of POV-ray sofware - POV-ray home - , and it's not difficult.
We have to create one flat square for each image to stitch. Then translate the square on a virtual sphere, according to Elevation and Azimuth parameters founded on the image label. Then texture the square with an image map: the image. Doing so for the different images to stitch, add a camera on the center of the sphere, render! It works! And we may finely tune every parameters needed to stitch nicely important features as horizon line, to orient the resulting mosaic, etc...

The sketch below illustrate the text:




And the Navcam mosaic linked below was made this way:

[Jeff7]

Yeah, I'm kind of thinking I'll reserve POV-Ray for panoramas of rooms or landscapes, and leave the Mars panoramas either to MMB's wonderous workings, or to the others here who already know how to make them.

My trouble now - rotate again. Rotating along the x and z axes seems to do the same thing.
Example:

rotate <ELEV_IMAGE003, -AZIM_IMAGE003, 20>

seems to do very nearly the same thing as

rotate <ELEV_IMAGE003+20, -AZIM_IMAGE003, 0>


Both instructions merely move the image toward the top of the rendering area. I would expect the first command line there to rotate it 20 degrees to the right - just as the rotate command in a photo editor would do. My understanding:
X axis runs left to right.
Y axis runs up and down.
Z axis runs toward and away from the user, facing the monitor.

Thus rotating along the z axis should simply make the image appear to rotate.
Right?

The tutorial I linked to earlier uses a cone as a demo object. A symmetrical object. So rotating along one axis would net no visible changes for the sake of a demonstration.

[dilo]

Jeff, your axis identifications are absolutely correct.
Now, take in mind that, in the Erwan code, observer (camera) still in the origin, where axes cross. Then, you translate the textured box toward -z direction before to rotate it (herebelow complete sequence for a single image):

CODE

box {
<-1, -1, -1>, <1, 1, 1>
scale <1024/2, 1024/2, 0.00001>/FOV
translate -1423.01*z
material {
image003
}
rotate <ELEV_IMAGE003, -AZIM_IMAGE003, 0.0>
}

The "translate" command is essential to see the image (otherwise observer would lie inside the box!) but after it, any rotation around the other two axis would displace the image (box) in space, not only rotate it!
In other words, when (after translation) you give this command:
rotate <ELEV_IMAGE003, -AZIM_IMAGE003, 20>
your box will be first rotated around X and Y axis which are now outside it and, as you can imagine, this rotation will displace the box from it's original position. In fact, as you observed, the ELEV_IMAGE003 angle determine a shift toward the top and AZIM_IMAGE003 will shift in horizontal direction...
This is absolutely normal: those two angles are elevation and azimut of images centers, referred to observer. At this point, Erwan didn't use again the "translate" command to shift images simply because we need to have images always perpendicular to the line of sight, in order to not distort them with perspective effects.

You are reporting that rotation of angles <ELEV_IMAGE003, -AZIM_IMAGE003, 20> brings same results of rotation <ELEV_IMAGE003+20, -AZIM_IMAGE003, 0>.
This is absolutely incidental and, if you change the initial values of ELEV_IMAGE003 and AZIM_IMAGE003, you will see a different result (coincidence disappear!).
So, again, remember that consecutive rotations aren't commutative and that rotation after translation introduce a spatial shift!
You must use the angles just as their names suggests, so elevation will control height above/below horizon (vertical shift), azimut will shift around horizontally. Last angle (tilt) is the rotation around the line of sight, to eventually correct the horizon inclination inside the image; in fact, it is the real image rotation you are looking for! However, Erwan made it equal to 0 because, in general, images belonging to the same panorama are already aligned to each other (they have the same elevation angle in the rover coordinate system).
So, is more easy to apply a unique final correction to the general stitch orientation, instead to match a single image at each time... In fact, the two parameters "AZIMUT_CAMERA" and "ROLL_CAMERA" will make this final correction! So I reccomend you to play with them and not to touch third (z) angle in the image orientations.

I hope I was clear enough without boring you! Ask for other doubt..
Bye.