Sharing knowledge around Autopano
You are not logged in.
hello!
i did a test with my new equippment (nikon d300/18-200/nn3) and got a very interesting but unexpected result...
the workflow was:
7 bracketed shots for each, 10 in a row, 3 rows
the .nef were loaded directly to photomatix, then the resulting .tif into APP... turning 90° didnt change it...
photomatix doesnt seem to write correct exif data, i have to correct them in APP...
but then it should work (?)
new camera, new problems... ![]()
Offline
What's the problem?
Anything more than orientation?
Try centering pano over the tripod then entering manually an adjustment of 90 for Pitch in Move images mode. That usually works. Then try auto horizon after that if still not straight or vertical lines tool.
Last edited by mediavets (2008-07-18 22:29:14)
Offline
Another way to do this is to set the enter point on an object at tabout the same height as the camera, then level the pano. You may then have to rotate it 90 degrees.
Right now, the nadir is so close to the centerpoint that rotating it 90 degrees just rotates it around a point near the tripod.
Last edited by hankkarl (2008-07-20 20:02:22)
Offline
Offline
thanks to you all!
it worked this way:
1. setting the center point to the nadir (tripod)
2. setting the center point to the top of all...
3. optimising the horizon
i just wondered, why this happened... i had this issue never before...
next week i will try it with a strange combination: d300/peleng... (just waiting for the adapter ring...)
Offline
Machart wrote:
I just wondered, why this happened... I had this issue never before...
In any camera there is a special device used to record the camera orientation during exposure. It works fine when the camera is not oriented toward the zenith or the nadir (or about.) When camera pitch value is near to 90°, up or down, the recorded orientation is often (but not always) wrong and APP is confused, lost and disorientate...
Nikon D300 have a special feature known as "Virtual horizon" and this implies it can use a second hardware device to detect roll variations and display them: the perfect camera for panorama would record not only yaw (difficult, GPS needed) but pitch and roll. Nikon made a little move in the right direction: roll is fine but pitch would help, too !
Last edited by GURL (2008-07-21 11:58:29)
Offline
GURL wrote:
Machart wrote:
I just wondered, why this happened... I had this issue never before...
In any camera there is a special device used to record the camera orientation during exposure. It works fine when the camera is not oriented toward the zenith or the nadir (or about.) When camera pitch value is next to 90°, positive or negative, the recorded orientation is often (but not always) wrong and APP is confused, lost and disorientate...
Nikon D300 have a special feature known as "Virtual horizon" and this implies it can use a second hardware device to detect roll variations and display them: the perfect camera for panorama would record not only yaw (difficult, GPS needed) but pitch and roll. Nikon made a little move in the right direction: roll is fine but pitch would help, too !
A GPS receiver only records location, so it wouldn't help with yaw. You would need a compass.
Offline
John_Sauter wrote:
A GPS receiver only records location, so it wouldn't help with yaw. You would need a compass.
"Car GPS" know of the car orientation: wether they are using a compass or not, I don't know (well, the direction of the car moves could be enough...)
Anyway, having pitch and roll recorded in EXIF data would be nice (automatic adjustement of subject vertical lines on rectilinear images needs both.)
Offline
A GPS needs to be moving to tell direction. Even walking is fast enough.
Car GPSes may have a magnetic compas built-in, or may have gyroscopes (the solid state kind probably) or accellerometers to tell when and how far they move.
Offline
this topic went an interesting way... ![]()
i try to resume my state of understanding:
- the d300 writes the orientation (portrait/landscape) into exif. (yes, if i open the .nef in adobe raw plugin, they are turned the right way... my oly e1 doesnt have this feature)
- turning the camera up or down on nn3 confuses the sensor
- feeding photomatix with .nef or .dng keeps this info although they are saved as .tif and turned the right way(?)
no, that cant be.
meanwhile i fed the .exr files (which, as i think, dont keep exif data) produced by photomatix into APP, edited the lens data manually, but the result is - really artistic... it doesnt work...
my idea:
it depends on the lens:
its a (compromising) 18-200mm nikon. the fisheye-like distortion with 18mm (27mm) doesnt fit with the fact, that its no fisheye...
it made a test and edited the lens info to fisheye (it only works after restarting APP, because the cache is a bit too resistant
) but its no good idea... no good results
the funny thing with this topic:
it was just a first - and only technical - ugly shot to calibrate the nodal point with nn3... but the excursion to gps is interesting... ![]()
Offline
machart wrote:
its a (compromising) 18-200mm nikon. the fisheye-like distortion with 18mm (27mm) doesn't fit with the fact, that its no fisheye...
The stitched image resulting from a rather large number of 28mm equivalent lens source images is identical to the stitched image resulting from a smaller number of fisheye source images. To stitch them properly APP must know whether a standard lens or a fisheye was used.
Though I often use a fisheye (8mm Olympus for 4/3 cameras) I recently made some attempts at using the 14mm setting (28mm equivalent) of my standard zoom and a NN3 panohead. The resulting image is much larger (for example 16000 x 8000 pix rather than 8000 x 4000 when using a fisheye) so that more details are visible. The corresponding disadvantage is that more shots are needed (I found 30 images being easy stitch using APP, this corresponds to a 45% global overlap.)
Using a motorized panohead like the modified Merlin/Orion should make this way of producing 360 x 180 panos adequate for quiet subjects...
Offline