Hi group!
I want to adress a topic with high nuisance value. It's about
orientation information in image files. When I shoot raw with my EOS
450D, the resulting CR2 images have orientation information. When I
rotate the camera by 0, 90, 180 and 270 degrees clockwise, here's what
the camera records (with autorotate on, exiftool output):
0°
Orientation : Horizontal (normal)
Camera Orientation : Horizontal (normal)
90°
Orientation : Rotate 90 CW
Camera Orientation : Rotate 90 CW
180°
Orientation : Horizontal (normal)
Camera Orientation : Horizontal (normal)
270°
Orientation : Rotate 270 CW
Camera Orientation : Rotate 270 CW
so far so good - one might argue that not recording the fact that I
held the camera upside down might have some good reason (does it?).
These images were taken with the camera set to auto-rotate; when the
auto-rotate is off, The CR2s appear unrotated in digikam, the EXIF
Orientation tag is horizontal for all, and the Camera Orientation tag
is the same as with the auto-rotate on.
Now when I process the raw files (tried tiff and jpeg), the EXIF
Orientation tag goes to Horizontal for all images with the raw
processors I've tried in my little test (digiKam's built-in, dcraw and
raw therapee), while the Camera Orientation tag is maintained. digikam
rotates the portrait images appropriately, no matter what the
autorotate setting in the camera is (I feel this is wrong), while
dcraw and raw therapee only rotate the images I took with the
autorotate setting on, which I feel is right.
When I read the processed images into hugin, the images show in
whatever orientation they are in the file, and all their roll values
are zero.
I feel this shouldn't be so - hugin should recognize that the portrait
images were shot in portrait and fix the data so that the raw sensor
data are taken as the image and the roll value is set initially to 0,
90 or -90 degrees, respectively - of course it can't know the upside-
down shots were taken upside down, because the camera keeps no record
of it - if it notices at all. To figure this out, it would have to use
this logic:
- if the Camera Orientation tag is horizontal
process the image as-is, and take roll as 0
- else (so, if the Camera Orientation tag is not horizontal)
- if the image is landscape nevertheless
take the image as-is, but set roll accordingly
- else
rotate the image back to landscape and set roll
Why would I want such a thing? Because of the lens shift parameters.
The optical system's characteristics are perfectly independent of the
camera orientation. Nevertheless, hugin's way of dealing with images
taken with different camera orientations forces me to use up to four
different lens numbers for my images. The lens shift parameters, d and
e, have to be different for all four orientations, since they aren't
measured relative to the sensor, but from the image center relative to
the image in the orientation the file provides - and the point where
the true optical axis hits the sensor comes out in different
coordinates for each orientation.
You can easily verify what I say by taking the same shot in four
different orientations, assigning four different lenses, fixing d and
e in one shot and optimize d and e in the other ones (together with y,
p and r, of course).
To the unwary, having to assign differnt lens numbers in this
situation comes as a good opportunity to make a hard-to-figure-out
error (I've been there... :(
If I'm sloppy and mix 90° and 270° portrait images without using
opposite d and e values for them I end up with wrong output, or the
optimization won't work out properly. So, really, I'd have to either
always use the same orientation for panoramas (I've resorted to that
for a while), use only raw processors which respect the no-rotate
setting of my camera (and force me to change that when I switch from
taking panoramas to general photography, where the no-rotate setting
is a nuisance) or look into the metadata of every file and assign
different lenses in hugin if the orientation is different.
I wonder if the Camera Orientation EXIF tag couldn't be exploited with
the logic I've proposed above. I don't know what other cameras record,
but I'd be curious to hear what others have observed. Maybe I'm
missing something? I suppose using this information (and assuming few
people will make panorama shots with the camera upside down) could
make the hugin process simpler and less error-prone. What do you say?
Kay
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
