Ubuntu

Rotation in Shotwell is incompatible with some other applications

Reported by YannUbuntu on 2010-09-21
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evince
Won't Fix
Medium
Pinta
Low
Unassigned
Shotwell
New
Unknown
Shutter
Low
Mario Kemper (Romario)
gnome-utils
Unknown
Medium
eog (Ubuntu)
Low
Unassigned
evince (Ubuntu)
Low
Unassigned
gnome-utils (Ubuntu)
Low
Unassigned
shotwell (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: shotwell

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 :

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.

Remark : bug #644133 may be a duplicate of this one.

YannUbuntu (yannubuntu) on 2010-09-21
description: updated
Omer Akram (om26er) wrote :

Thanks for the bug report and sending it upstream.

Changed in shotwell (Ubuntu):
importance: Undecided → Low
status: New → Triaged
YannUbuntu (yannubuntu) on 2010-09-21
description: updated
Changed in shotwell:
status: Unknown → New
YannUbuntu (yannubuntu) wrote :

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 ?

YannUbuntu (yannubuntu) wrote :

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

Changed in gnome-utils:
importance: Unknown → Medium
status: Unknown → New
Jim Nelson (yorba-jim) wrote :

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

Changed in shutter:
milestone: none → 0.87
assignee: nobody → Mario Kemper (Romario) (mario-kemper)
importance: Undecided → Low
status: New → In Progress
Changed in shutter:
status: In Progress → Fix Committed
Jonathan Pobst (jpobst) wrote :
Changed in pinta:
importance: Undecided → Low
milestone: none → 0.6
status: New → Fix Committed

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

Changed in evince (Ubuntu):
status: New → Invalid
Changed in evince:
importance: Undecided → Unknown
status: New → Unknown
mannheim (kronheim) wrote :

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.

Adam Dingle (adam-yorba) wrote :

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.

Changed in shutter:
status: Fix Committed → Fix Released
grofaty (grofaty) wrote :
Changed in pinta:
status: Fix Committed → Fix Released
Sebastien Bacher (seb128) wrote :

why is that a gnome-utils issue?

Changed in gnome-utils (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Changed in evince (Ubuntu):
importance: Undecided → Low
Changed in eog (Ubuntu):
importance: Undecided → Low
Changed in gnome-utils (Ubuntu):
status: Incomplete → Invalid
Changed in gnome-utils:
status: New → Unknown
Changed in evince:
importance: Unknown → Medium
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.