Bug 233462 - gthumb doesn't reset EXIF orientation flag when auto-rotating
Summary: gthumb doesn't reset EXIF orientation flag when auto-rotating
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gthumb
Version: 8
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Behdad Esfahbod
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-22 15:51 UTC by Matt Brodeur
Modified: 2008-01-16 04:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-16 04:48:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
An image that is not correctly rotated upon "import" using gthumb (5.00 MB, image/jpeg)
2008-01-16 04:23 UTC, Stephen Warren
no flags Details

Description Matt Brodeur 2007-03-22 15:51:40 UTC
Description of problem:
If I use gthumb pull pictures from a camera with an orientation sensor (Canon
SD800IS), the importer will automatically rotate the images to appear correctly
on the screen.  It doesn't then clear or reset the Orientation flag in the EXIF
header.  This causes any application that supports auto-rotation to further
rotate the photo into an incorrect orientation.

Version-Release number of selected component (if applicable):
gthumb-2.7.8-3.fc6

How reproducible:
100%

Steps to Reproduce:
1. Feed gthumb-import some pictures with an EXIF Orientation other than "top-left"
2. View the imported photos in something that supports auto-rotation based on
EXIF data (such as gthumb's own "Adjust orientation" feature)
  
Actual results:
The image gets rotated a second time.

Expected results:
Once the image is right side up it should stay that way.

Additional info:
I noticed this issue when using gthumb to import photos, but "Adjust photo
orientation" on existing files behaves the same way.  In fact, if you run the
adjuster over and over it keeps spinning the picture around.

Not having the flag match the actual orientation is a problem for applications
which expect it to be correct.  gqview, gallery, and jhead are some that I use,
and I'm sure there are others.

Comment 1 Stephen Warren 2008-01-16 04:16:26 UTC
This bug is still present in F8 (at least partially), in gthumb-2.10.7-1.fc8.

In F8, when plugging in a USB flash reader, the system prompts you to either
ignore, or import photos. If import is selected, gthumb is automatically started
to perform the action.

In the gthumb import dialog, there is an option "Rotate Images Physically". This
is the option that is not working for me. (i.e. the image data is NEITHER
physically rotated *NOR* is the EXIF flag is reset to "top - left")

Note, however, that in the main user interface, the menu option "Tools" ->
"Rotate Images" has an option "Apply physical transform". This option DOES work
correctly (i.e. the image data is physically rotated *and* the EXIF flag is
reset to "top - left")

Finally, there are keyboard rotation shortcuts [ and ]. These also work
correctly (i.e. the image data is physically rotated *and* the EXIF flag is
reset to "top - left")


Comment 2 Stephen Warren 2008-01-16 04:23:03 UTC
Created attachment 291802 [details]
An image that is not correctly rotated upon "import" using gthumb

Comment 3 Stephen Warren 2008-01-16 04:23:41 UTC
Further information: You can view the image in Firefox for testing; Firefox does
not recognize the EXIF rotation flag apparently.

Also, gthumb shows the EXIF information at the bottom of the window if "View" ->
"Show/Hide" -> "Properties" is selected; the entry in question is "Image
Structure" -> "Orientation".

Finally, I am attaching a sample image that was not correctly rotated upon import.


Comment 4 Stephen Warren 2008-01-16 04:40:08 UTC
Excellent. This has apparently been fixed upstream in 2.10.8.

Please see http://bugzilla.gnome.org/show_bug.cgi?id=492111

Let's import this fix into F8 ASAP!


Comment 5 Stephen Warren 2008-01-16 04:48:10 UTC
OK. You guys are a week or so ahead of me. I found the gthumb-2.10.8-1.fc8
update, and it fixes this bug. Thanks!



Note You need to log in before you can comment on or make changes to this bug.