which way is up?
kfj
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
T. Modes
> 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
That's already implemented.
> - else
> rotate the image back to landscape and set roll
That's not implemented. There are some checks implemented to check if
the orientation tag is plausible. Hugin should *not* modify the input
images.
Hugin is using the "official" Orientation tag (tag 0x0112) in the
"normal" EXIF data. This works for me.
But from your mail it seems that your raw converters destroy this
information.
The mentioned tag "CameraOrientation" is a tag from the maker note
section of some Canon cameras (and has depending on the camera model
different tag IDs). This is not used.
Thomas
kfj
> > - else
> > rotate the image back to landscape and set roll
>
> That's not implemented. There are some checks implemented to check if
> the orientation tag is plausible. Hugin should *not* modify the input
> images.
I don't mean hugin should modify the images - only rotate what it has
in memory. As you can see from my outporings, no matter what setting
or raw processor I tried, the Orientation tag is always 'horizontal'.
> Hugin is using the "official" Orientation tag (tag 0x0112) in the
> "normal" EXIF data. This works for me.
> But from your mail it seems that your raw converters destroy this
> information.
Looks like the only place the information is kept is in the unofficial
Canon tag.
> The mentioned tag "CameraOrientation" is a tag from the maker note
> section of some Canon cameras (and has depending on the camera model
> different tag IDs). This is not used.
Thanks for pointing that out. I didn't go that deep in my
investigation. So I must consider myself lucky that at least my camera
produces a tag which the other tools don't destroy :-)
I suppose I'll have to finally make the effort and write a
comprehensive script which deals with my specific scenario - not only
the troubles with the orientation, but also the missing lens
information (I use a manual fisheye lens) and the geotagging (no built-
in GPS) - and I might have cpfind make keyfiles there and then...
Kay
Bruno Postle
>
>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:
I think Hugin needs to keep a distinction that is currently the
case:
EXIF data is purely 'advisory', i.e. we can use EXIF data to set
initial roll, EV, FoV etc... but these parameters are not fixed.
(We can have additional logic that says 'ignore EXIF orientation for
all image files where width is less than height' etc...)
EXIF isn't used at the stitching stage, stitching happens at a lower
pixel-data level, e.g. a 'landscape format' photo relates to the way
the pixels are stored, even if the camera was held in portrait
orientation.
--
Bruno
Naked Robot
I know for a fact that canon cameras have a proper orientation exif tag, as well as the stupid "canon only" orientation tags.
I say "stupid" because sometimes they conflict with the proper orientation tags.
Orientation tag tells you which way the image should be rotated. CameraOrientation (the stupid canon one) tells you which way the camera was being held, but should not instruct anything about how the image itself should be rotated. It really messes things up WRT stitching panoramas
On Thursday, December 15, 2011 9:59:07 PM UTC+1, kfj wrote:
Naked Robot
http://dl.dropbox.com/u/14314213/Screen%20shot%202011-12-15%20at%2012.08.58%20AM.jpg
it has exif orientation tag "8".
http://sylvana.net/jpegcrop/exif_orientation.html
dcraw and all the others certainly do preserve this (and most other) exif tags.
Jeff
kfj
> Kay, Something is wrong.
>
> I know for a fact that canon cameras have a proper orientation exif tag, as
> well as the stupid "canon only" orientation tags.
they do. and they're both set to the same value when you switch
autorotate on in the camera, otherwise only the CameraOrientationtag
is set.
> I say "stupid" because sometimes they conflict with the proper orientation
> tags.
I find the twofold approach understandable. If the Orientation tag is
set, the data from the file are displayed rotated. If the
CameraOrientation tag is set, the camera was rotated. but nothing is
done about it unless the Orientation tag is also set. I think the
confusion begins when these tags are propagated to the results of the
raw conversion. The raw converter might actually rotate the pixel
layout in memory before writing the result. If it doesn't take good
care of keeping the tags consistent, things may screw up.
> Orientation tag tells you which way the image should be rotated.
> CameraOrientation (the stupid canon one) tells you which way the camera was
> being held, but should not instruct anything about how the image itself
> should be rotated. It really messes things up WRT stitching panoramas
As far as I can tell (I just tried), the raw processor I routinely use
(digiKam's built-in one) actually ignores the 'Orientation' tag (even
though digiKam itself rotates the thumbnail display accordingly) and
instead looks at the CameraOrientation tag only. This would make sense
insofar as The CameraOrientation tag says something about the raw data
in the file, so the raw processor should process it.
While I was just about finding a reasonable solution to my problem,
something else f****ed up - currently my hugin fast preview is broken
and hugin always crashes in some obscure place:
Program received signal SIGSEGV, Segmentation fault.
PreviewIdentifyTool::UpdateWithNewImageSet (this=0x0,
new_image_set=...)
at /home/kfj/src/hugin/hugin_clean.hg/src/hugin1/hugin/
PreviewIdentifyTool.cpp:567
567 std::vector<unsigned int>
difference(new_image_set.size());
(gdb) kill
(grrr...) suppose it's not my day today. No idea what I did, it all
worked fine just yesterday evening...
I'll have to figure this one out first, now (sigh)
Kay
kfj
On 16 Dez., 00:11, Bruno Postle <br...@postle.net> wrote:
>
> EXIF isn't used at the stitching stage, stitching happens at a lower
> pixel-data level, e.g. a 'landscape format' photo relates to the way
> the pixels are stored, even if the camera was held in portrait
> orientation.
I suppose what happens and what gives me grief is tha fact that
(some?) raw converters in (some?) situations take the information in
(some?) EXIF tags as a reason to actually rotate the pixel matrix and
store the rotated data, while (some?) others keep the pixel matrix
intact and merely store (some?) EXIF tags to reflect what orientation
should be displayed, and maybe some other EXIF tags keeping a record
of the camera orientation the image was taken with.
This feels like a mess. A mess one can work around by tricking one or
the other bit of software into doing the wanted thing by manipulating
the EXIF tags in the raw files or the files the raw converter
produces, but it's quite unsatisfactory. Isn't there a better way?
Kay
T. Modes
>
> (We can have additional logic that says 'ignore EXIF orientation for
> all image files where width is less than height' etc...)
>
This is already implemented (changeset ef856d01fa01)
Thomas
kfj
On 16 Dez., 15:30, kfj <_...@yahoo.com> wrote:
>
> I suppose what happens and what gives me grief is tha fact that
> (some?) raw converters in (some?) situations take the information in
> (some?) EXIF tags as a reason to actually rotate the pixel matrix and
> store the rotated data, while (some?) others keep the pixel matrix
> intact and merely store (some?) EXIF tags to reflect what orientation
> should be displayed, and maybe some other EXIF tags keeping a record
> of the camera orientation the image was taken with.
I've analyzed the problem some more and figured out that the problem
is the autorotate setting in the camera, and digiKam.
Independent of the autorotate setting, he raw images will always
contain the 'Camera Orientation' tag, which, as Thomas pointed out, is
Canon-specific, but it makes good sense - it tells you which way the
camera was held. But this tag should not affect the raw conversion -
the raw conversion should only honour the 'Orientation' tag. I checked
with three other raw processors (raw therapee, dcraw and Canon's DPP)
and they all behave as they should and leave images alone when the
'Orientation' tag isn't set, which happens when 'autorotate' in the
camera is turned off.
So here's my conclusion:
- when taking images for panoramas, turn off autorotate
- when autorotate was accidentally on, set the 'Orientation' Tag to
'Horizontal (normal)' with exiftool:
exiftool -Orientation='Horizontal (normal)' myimage.CR2
- when processing the raw images, don't use digiKam unless they fix
the bug:
https://bugs.kde.org/show_bug.cgi?id=289181
Because of the unset 'Orientation' tag, portrait images will show
tilted by 90 degrees, but hugin will be able to process all images, be
they rotated left, right, upside-down or not-at-all with the same lens
setting.
Kay
Erik Krause
> - when processing the raw images, don't use digiKam unless they fix
> the bug
There where some dcraw versions that used the CamerOrientation instead
of Orientation. Since I suspect digiKam is based on dcraw code this
might be the reason. It should be solved as soon as they update to the
most recent dcraw. RawTherapee had the same problem BTW:
http://rawtherapee.com/forum/viewtopic.php?f=1&t=2579
--
Erik Krause
http://www.erik-krause.de
kfj
my dcraw is v8.99
rt is 4.0.2.31
both are working fine. my bug report wasn't very helpful, I was
recommended to use a later version than the default for my Kubuntu
11.4 system, and in the followup it got even worse... Anyway, I don't
have to use digiKam's raw processor (no very great loss), I only used
it because I was to lazy to launch yet another application
I suppose it's raw therapee time.
What I'll do is this:
- I'll take images with autorotate off or set 'Orientation' to
horizontal before processing
- I'll use rt for the raw conversion
- now, since the CameraOrientation tag has been preserved, I can set
Orientation back to the same value, so all subsequent steps know the
proper orientation.
this, finally, prepares the images so that hugin sets the initial
rotation according to the Orientation tag, but the image data
themselves are not rotated and I can use the same lens.ini for
everything. Sadly I've found no way to tell any of my raw processors
to do what really would be best:
- not rotate the images at all when converting
- but set the Orientation tag correctly after processing
instead the images always come out 'horizontal' right after
processing, so my little spiel seems to be the only way to do it.
Kay
Naked Robot
I asked Dave Coffin to fix it but he just told me where I could remove the code and recompile. Fair enough I guess :) But it should never be there in the first place!
kfj
> Hugin is using the "official" Orientation tag (tag 0x0112) in the
> "normal" EXIF data. This works for me.
> But from your mail it seems that your raw converters destroy this
> information.
ended up doing is to delete the CameraOrientation tag before raw
processing (with digiKam 1.9.0) or use a raw processor which doesn't
look at the CameraOrientation tag (dcraw, raw therapee, Canon DPP). I
do the raw processing with the Orientation tag (which is a different
tag!) set to horizontal, because otherwise all raw processors I know
will rotate protrait data so they come out horizontal. After raw
processing I set the Orientation tag back to what it would have been,
had the camera been in autoratate mode. Now, finally, I have input fit
for hugin:
- the image data are now stored as per sensor geometry, which is
always landscape, and the top row of the image data coinciding with
the bottom edge of the sensor (because the image is upside down on the
sensor, after all). Why is this important? Because now I can use just
one single lens.ini file for all images with a particular lens, no
matter which way I have rotated the camera, instead of having to use
up to four different ones, one for each possible orientation.
- the images do have rotation information in the Orientation tag,
which is the tag hugin can exploit. This has the effect that when I
generate my panorama with gen_pto, portrait images show up with roll
of 90 or 270 degrees, respectively. This is also important, because
otherwise I can't use one of the portrait images as anchor properly,
and most of my panoramas are mainly in portrait. When loading such
images into a new project in hugin, my hugin (Pre-Release
2011.5.0.71ffba4767f5) did not check the Orientation, but once the
images were in the project I could go to the camera and lens tab,
select all images and click on 'read EXIF data' - and lo and behold,
now my orientation settings were there all right. Maybe the EXIF data
of newly loaded images aren't read completely? Overhead shots will not
show with an initial roll of 180, because my camera does not notice
it's upside down but records 'horizontal' in this situation. I could
manually set 'Orientation' to 180 degrees, but I don't usually shoot
overhead, so I just ignore this possibility.
While looking at these images which are good to feed to hugin, I had a
good laugh at what various image viewers and image processing programs
make of them. A few did what hugin does and displayed them rotated
correctly, as per EXIF Orientation tag. Others ignored this tag and
displayed the images in their 'native' orientation - the one which I
took care to preserve in order to be able to use just one single
lens.ini file on them. I can live with that, I don't look at the raw
material that much and my file manager rotates properly. The funniest
result was in digiKam, again: the image rotated 90CW showed up upside
down and mirror-imaged! I'm sure they'll tell me I should try and
upgrade to a more recent version if I posted a bug report...
Things get even more confused when 'rotating' images in image
processing software. Here, again, there are two possible ways to
achieve a rotation: The software can just change the 'Orientation'
tag, or it can change the memory layout of the image. Some image
processing software gives you a choice what to do. The observable
effect will, obviously, depend on which image viewer you use on the
rotated images.
I conclude that I have found a way of dealing with the problem, but it
was a stony path (one of the reasons I have avoided the matter so
long). There's plenty of possibilites to take a wrong turn here, and
the unwary may easily end up with a false result. For hugin input
data, my in-a-nutshell advice would be:
- avoid rotation of the image data - easiest done by removing all
orientation-related tags from the images before raw processing
- before generating the pto, set the EXIF 'Orientation' tag to an
appropriate value
- generate the pro with pto_gen
- or, after loading the images into hugin, read their EXIF data
explicitly
Kay
kfj
Kay