GNOME Bugzilla – Bug 465506
Use GTK+ for the autorotation metadata
Last modified: 2021-06-19 08:46:58 UTC
As of 2.11.5, the GDK TIFF/JPEG loaders include an "orientation" option string that corresponds to the embedded TIFF/Exif orientation tag, if this is present (See bug #439567), so in theory, libexif is no longer needed to provide the autorotation feature. Moreover, since 2.19.1, libgnomeui thumbnail loader rotates the thumbnails according to this metadata, and as far as I can tell, it does so *all the time* (see bug #440978). So, we have the following situation in EOG: If a user disables autorotation, EOG will not rotate the image (as expected), but libgnomeui will rotate the thumbnail anyway, which will cause thumbnail and image to differ. I'm not really sure how should we handle this, but this needs to be addressed before 2.20. There are two things here: 1) It's probably a good idea to rely on GdkPixbuf "orientation" option to do the rotation and not in libexif. 2) The (do-not-autorotate) feature probably needs to be reworked in order to be compatible with libgnomeui rotating the thumbnails anyway. Thoughs?
Adding Mike to the cc, he is wise in this matter.
I'll add Jef Driesen to the cc as well, since he added the orientation tag support to eog and did much of the exif work in gthumb too. I think you should ALWAYS respect the exif orientation tag. That's what the libgnomeui thumbnailer and gthumb do now. It simplifies the UI, simplifies the code, is consistent with nautilus and gthumb, and complies with the exif standard. I can't think of a reason to not respect it. For obscure use cases where that is desirable, other tools can be used to mangle the exif data. (Side note: old versions of gThumb screwed up the orientation tags, so we added a "Tools > Reset Exif Orientation" tool to it). (In bug 440978 I suggested that you could un-rotate thumbnails in the do-not-autorotate mode, as an not-recommended alternative, but after some reflection that seems like a horrible idea. Forget I mentioned it. It is fraught with peril. Especially since there will be some inevitable confusion as old thumbnails which were generated before orientation support was added linger in the cache.) Most image tools now support exif tags, so "compatibility" isn't really an issue any more. - Mike
The thumbnail cache will only work well if *ALL* applications are creating thumbnails with the same orientation type (i.e. either autorotated according to the exif orientation tag, or not rotated at all). A mixture of the two will result in problems. With this in mind, I think the only viable option (if we want one of course) is making the autorotation feature a global per-user setting, that is respected by all applications on the desktop (eog, gthumb, nautilus,...). Even if an application chooses not to provide any user interface for this setting, it will have to rotate images/thumbnails according to this setting. A global option might work well, because I think users will not alter this setting often (why would they?). But if they do, the cache will contain broken thumbnails. But at least all applications will show the same orientation, so that is still better than the mixture we have now. Old thumbnails in the cache are a problem anyway. I think clearing the entire cache once (after an upgrade for instance) is the best solution once all applications have a common orientation implementation. It will cause some slowdown initially, but no real data is lost because thumbnails are recreated automatically.
(In reply to comment #3) > With this in mind, I think the only viable option (if we want one of course) is > making the autorotation feature a global per-user setting, that is respected by > all applications on the desktop (eog, gthumb, nautilus,...). Ugh. That would be the correct approach if we wanted to keep the ignore-tag option, but we'd need a really compelling usage-case to do all that work. I haven't heard any reasons to ignore the exif orientation tag. Let's opt for simplicity... it's more gnomeish :-) > Old thumbnails in the cache are a problem anyway. I think clearing the entire > cache once (after an upgrade for instance) is the best solution once all > applications have a common orientation implementation. It will cause some > slowdown initially, but no real data is lost because thumbnails are recreated > automatically. I've asked Fedora to purge the cache with anaconda when upgrading to F8 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=252172), but it might be too late for them to implement that. - Mike
Just for the record, I haven't seen bug reports about the concerns we had one year ago, nor anyone complaining about a mess with the orientation of images, so I suppose it is sane to go for this now.
This is implemented now by the way: commit 8ac825bea9ce49e500efd8ed94bd3177b03f9731 Author: Felix Riemann <> Date: Wed Jun 8 20:58:29 2011 +0200 Use GdkPixbuf's "orientation" feature as fallback for autorotation Useful for formats where we don't support extracting the needed data ourselves (e.g TIFF) and if eog is compiled without libexif. https://bugzilla.gnome.org/show_bug.cgi?id=548474 https://bugzilla.gnome.org/show_bug.cgi?id=615114 So, what about the autorotate stuff? Do we want to enable it all the time (aka removing the UI option to switch it)?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.