Bug 37920

Summary:	some CR2s are not oriented correctly
Product:	libopenraw	Reporter:	Felix Riemann <friemann>
Component:	General	Assignee:	Hubert Figuiere <hub>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	samtygier
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:	[release:0.1.0]
i915 platform:		i915 features:

Description Felix Riemann 2011-06-04 05:58:27 UTC

We've got reports that eog  doesn't show some CR2s with the correct orientation:
https://bugzilla.gnome.org/show_bug.cgi?id=615114

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)?

Comment 1 Hubert Figuiere 2011-06-04 19:57:13 UTC

No sample file?

Comment 2 sam tygier 2011-06-05 02:07:50 UTC

some sample files
http://www.hep.manchester.ac.uk/u/sam/pub/shotwell/
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

Comment 3 Hubert Figuiere 2011-06-05 11:29:00 UTC

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.

Comment 4 Felix Riemann 2011-06-06 08:28:19 UTC

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.

Comment 5 Hubert Figuiere 2011-06-06 12:52:27 UTC

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.

Comment 6 Felix Riemann 2011-06-06 13:27:52 UTC

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).

Comment 7 Hubert Figuiere 2011-06-06 23:09:59 UTC

This is fixed in master. 

Thanks.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.