Rotation in Shotwell is incompatible with some other applications

Thanks for the bug report and sending it upstream.

According to http://trac.yorba.org/ticket/2581 , this looks to be 2 separate problems:

1) Some apps don't respect the EXIF orientation flag. I opened upstream bugs for this :
Evince : https://bugzilla.gnome.org/show_bug.cgi?id=630307
Shutter : https://bugs.launchpad.net/shutter/+bug/644847
Pinta : https://bugs.launchpad.net/pinta/+bug/644846
KolourPaint : https://bugs.kde.org/show_bug.cgi?id=252003
There are maybe more apps with this problem...

2) 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$
Then, other photo applications including Eye of GNOME and GIMP will not notice the EXIF orientation in this case.

I am not sure what is the best way to solve this. Should I fill a bug for gnome-screenshot ?

I filled a bug for gnome-utils (gnome screenshot) : https://bugzilla.gnome.org/show_bug.cgi?id=630308

> 2) When GNOME takes a screenshot, it does not add any EXIF data at all.
...
> Should I fill a bug for gnome-screenshot ?

EXIF is not required for image files. If it's not present the orientation is assumed to be Top Left, which means no rotation. So, no, I don't think gnome-screenshot is at fault here.

However, now that I look a little closer I do see one potential issue ... we're using the EXIF Orientation field to rotate PNG files. This is important with lossy formats, like JPEG, but not as much a win with lossless formats, like PNG. More significantly, EXIF is closely associated with JPEG and digital photography, but not nearly as widespread in the computer graphics (i.e. PNG) world. The problem with GIMP and EoG may simply be that they're not reading the EXIF data from the PNG. (In fact, libexif doesn't even support reading EXIF from PNG, one reason we switched to Exiv2).

We should be more cognizant of this in Shotwell. When we export a non-JPEG file, we shouldn't rely on the Orientation field to rotate it. I've ticketed this: http://trac.yorba.org/ticket/2585

If those other apps are not respecting the Orientation field in a JPEG file, I do consider that to be a problem. Most modern cameras generate the field rather than rotate the image prior to encoding.

Fixed in https://github.com/jpobst/Pinta/commit/de8c70e2e87dbe7cdfb17765b5b7edf37acca88b.

The libpixbuf backend (providing the ability to open jpeg files) has been removed upstream: "The pixbuf backend is just a toy, Evince is not an image viewer, use eog instead."

Photos are often meant to be shared -- e.g. sent by email to a friend.

We may not know what software will be used to view the photos we share; and unfortunately there's still a lot of software out there that does not make use of the exif orientation tag. (It seems to me that Firefox and Thunderbird do not respect the exif orientation tag in jpeg files, and nor does Windows 7.) So sometimes the best thing to do is to actually rotate the image data. This applies even to odd-sized jpeg files, where rotation cannot be completely lossless. It at least needs to be an option.

Unfortunately, we can't add "Windows 7" to the "Affects" list ...

Since digital cameras usually produce jpegs of a size for which lossless rotation is possible, this really should be an option on import, as it is in many other applications.

mannheim,

that's a good point. I've updated the upstream ticket (http://trac.yorba.org/ticket/2581) to be called "optionally rotate JPEG pixels", and I agree it would be good to offer this as an option. We could offer to rotate at export time and/or when importing.

It'd be good to have that option not enabled by default, so to encourage
other apps to start respecting exif.

Fixed in Pinta: https://bugs.launchpad.net/pinta/+bug/644846

why is that a gnome-utils issue?

Status changed to 'Confirmed' because the bug affects multiple users.