Bug 233462 - gthumb doesn't reset EXIF orientation flag when auto-rotating
gthumb doesn't reset EXIF orientation flag when auto-rotating
Product: Fedora
Classification: Fedora
Component: gthumb (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Behdad Esfahbod
Depends On:
  Show dependency treegraph
Reported: 2007-03-22 11:51 EDT by Matt Brodeur
Modified: 2008-01-15 23:48 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-15 23:48:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Matt Brodeur 2007-03-22 11:51:40 EDT
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):

How reproducible:

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-15 23:16:26 EST
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-15 23:23:03 EST
Created attachment 291802 [details]
An image that is not correctly rotated upon "import" using gthumb
Comment 3 Stephen Warren 2008-01-15 23:23:41 EST
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-15 23:40:08 EST
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-15 23:48:10 EST
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.