We've got reports that eog doesn't show some CR2s with the correct orientation:
And a short test showed that these reports are in fact correct.
eog transparently uses libopenraw's gdk-pixbuf loader plugin for this if it is installed.
At first we thought that this is because we don't use the "orientation" option GdkPixbuf provides but the openraw loader apparently doesn't use it.
As the pixbufload and ppmload demos included with libopenraw show the same behaviour I'm now forwarding this to you. Could it be that the loader ignores some orientation data in the files (if there is such)?
No sample file?
some sample files
1391 is in landscape, and displays fine
1392 and 1393 are in portrait, and are flipped
some more listed at http://trac.yorba.org/ticket/3508
It works as advertised - the pixbuf loader does not rotation the image. I don't see where gdkpixbuf allow specifying the orientation. And EOG get the orientation from libexif, not from gdkpixbuf.
When there is an API in gdkpixbuf to pass that kind of information, feel free to file a new bug.
Well, "API" is maybe a bit too big as a word to describe what's actually available.
Basically what the JPEG and TIFF loaders do is to set an "orientation" value for the pixbuf using gdk_pixbuf_set_option (see http://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/io-jpeg.c?id=3645ce712e1c41a7a800585a366402776b2fe1bf#n536).
gdk_pixbuf_apply_embedded_orientation() is then using this or the application could query the value (which eog doesn't, but could be added as a fallback if no Exif data is available e.g. when loading TIFFs where eog doesn't/can't extract the necessary data).
If you think this is too much of a hack to implement, I could live with that as well as I have plans on splitting up eog's image loading (SVG <--> Pixbuf) code in the longterm anyway. So if libopenraw's API allows reading the orientation, I guess one could add another special case for RAW files as well then.
But this does not help EOG since at no point can I find in eog git master tree where it actually get that info from gdk-pixbuf.
Well, admittedly eog doesn't use it yet. I don't remember the exact details but we decided to wait a bit with the implementation back when this functionality was added to GdkPixbuf. And then we basically forgot about it or found no time to implement it (the biggest problem for Claudio and me right now). :(
But during investigation of this bug I got the impression that it should be possible to implement it as a fallback for cases where we don't parse Exif data yet (TIFF, RAW) or when building eog without libexif. If you want to use it as some kind of testcase I could look into pushing the code I used for debugging into master when I find the time to clean it up and do some testing (probably at the weekend).
This is fixed in master.