---- Reported by shotwell-maint@gnome.bugs 2010-09-21 00:22:00 -0700 ----

Original Redmine bug id: 2581
Original URL: http://redmine.yorba.org/issues/2581
Searchable id: yorba-bug-2581
Original author: Yann -
Original description:

Rotate a picture with Shotwell Picture Viewer 0.7.2 (on Ubuntu 10.04), save
the changes and close Shotwell.

Then re-open the picture with one of the following applications and check what
appears :

- the rotation is NOT taken into account by : Evince, Shutter, Pinta, KolourPaint.

- the rotation is taken into account by : Shotwell, EyeOfGnome, gThumb, gPicView, GwenView, Fspot, fotoxx

- Gimp displays the following message : “according to the EXIF data, this picture is rotated. Keep orientation or rotate?â€

(may be related to Ticket #1938)

Related issues:
duplicated by shotwell - Feature #4239: write photo rotation to EXIF data (Open)



---- Additional Comments From shotwell-maint@gnome.bugs 2012-01-06 04:52:00 -0800 ----

### History

####

#1

Updated by Yann - about 3 years ago

Downstream report : https://bugs.launchpad.net/shotwell/+bug/644168

####

#2

Updated by Yann - about 3 years ago

Looks like there are several behaviors :

1ST TEST (with a picture downloaded from internet) :

- the rotation is NOT taken into account by : Evince, Shutter, Pinta, KolourPaint.

- the rotation is taken into account by : Shotwell, EyeOfGnome, gThumb, gPicView, GwenView, Fspot, fotoxx

- Gimp displays the following message : “according to the EXIF data, this picture is rotated. Keep orientation or rotate?â€

NEXT TESTS (with fresh screenshots taken in my session) :

- the rotation is NOT taken into account by all the applications except Shotwell

- Gimp does not display the message any more.

####

#3

Updated by Adam Dingle about 3 years ago

  * **Priority** set to _High_

Yann,

thanks for the bug report. I think this is unrelated to #1938, actually.

What's going on here is that when Shotwell exports a rotated photo, it does
not rotate the photo pixels – it merely sets an EXIF orientation flag
indicating that the photo is rotated. All image applications should respect
that flag, but as you've noticed some don't (e.g. Evince, Shutter, Pinta).
This is arguably a bug in those applications, not in Shotwell.

The behavior you described in your NEXT TESTS above with your own screenshots
was surprising to me, but I am able to reproduce it easily. When GNOME takes a
screenshot, it does not add any EXIF data at all. If you then rotate this
screenshot in Shotwell and save, it contains only the Exif.Image.Orientation
tag and no others:

adam@adam-desktop:~/shotwell-0.7$ exiv2 -pa
'/home/adam/Desktop/Screenshot.png'

Exif.Image.Orientation Short 1 bottom, right

Xmp.tiff.ImageWidth XmpText 1 3

adam@adam-desktop:~/shotwell-0.7$

As you discovered, other photo applications including Eye of GNOME and GIMP
will not notice the EXIF orientation in this case. We were previously unaware
of this behavior.

We could solve this in one of two ways:

Write out more EXIF data when saving the EXIF orientation, so that
applications notice the orientation.

Rotate the pixels whever saving a rotated photo; this will be compatible with
all applications, even those that don't notice EXIF orientation at all (e.g.
Evince).

Upping to high; I think we should address this somehow for 0.8.

####

#4

Updated by Jim Nelson about 3 years ago

Another downstream report this might be related to:
https://bugs.launchpad.net/ubuntu/source/eog/bug/644133

By using Orientation to rotate the image (which is hardly a new or exotic
feature), we avoid re-encoding the JPEG, which degrades image quality. I'm
surprised these other apps don't respect it. However, the GDK Pixbuf library
ignores it as well; an application must explicitly parse the EXIF and apply
the orientation manually after GDK has decoded the image. I suspect this is
why so many apps have this problem.

It also means these applications don't render photos correctly when the camera
itself has applied a non-identity Orientation. We can fix it in Shotwell, but
I would say these apps are busted when dealing with “modern†digital
photos.

####

#5

Updated by Yann - about 3 years ago

Thank you for your answers.

I filled bug reports for apps which don't respect the EXIF flag, and for
Gnome-screenshot : https://bugs.launchpad.net/shutter/+bug/644168

Please don't hesitate to comment/correct me if I misunderstood.

####

#6

Updated by Jim Nelson about 3 years ago

I've made a fuller comment about these issues on Launchpad
(https://bugs.launchpad.net/ubuntu/source/shotwell/bug/644168). To summarize,
one issue I do see with Shotwell is that we're using EXIF Orientation with PNG
files, which is not the greatest strategy. I've ticketed that change at
[](http://trac.yorba.org/search?q=ticket%3A2585)#2585.

I'm not closing this ticket quite yet, because there's a number of issues
being raised here. At some point I think we'll have a better idea of what
Shotwell needs to do and what other apps need to do, and then we can
reorganize the tickets.

####

#7

Updated by Grant Gardner about 3 years ago

Just a reminder that if you do ever rotate the actual pixels that most jpegs
coming out of cameras can be rotated in a lossless way, which is supported by
jpegtran.

One other thing to watch out for iswhere the exif orientation of an embedded
thumbnail is out of sync with the main image.

####

#8

Updated by Adam Dingle almost 3 years ago

  * **Subject** changed from _Rotation in Shotwell is incompatible with some other applications_ to _optionally rotate JPEG pixels_

As a user on the downstream ticket pointed out, a Shotwell user may want to
use photos with an application which doesn't support the EXIF orientation flag
– perhaps on a non-free platform where the application can't be easily
updated. Or they may want to share photos by email with a friend who might use
such an application.

I think Shotwell should rotate photos using the EXIF orientation by default,
but it would be nice if Shotwell could optionally rotate actual JPEG pixels as
well. We could offer the rotate as an option at export time, and possibly when
importing as well. The rotation should be lossless when possible.

####

#9

Updated by Raienr Krug almost 2 years ago

  * **Description** updated (diff)

Just one point to add: the rotation of the jpegs should be done lossless -
there is e.g. jpegtran (http://jpegclub.org/jpegtran/) which can do that.



--- Bug imported by chaz@yorba.org 2013-11-25 21:47 UTC  ---

This bug was previously known as _bug_ 2581 at http://redmine.yorba.org/show_bug.cgi?id=2581

Unknown Component 
   Using default product and component set in Parameters 
Unknown version " in product shotwell. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution