GNOME Bugzilla – Bug 390266
Only the first image is autorotated
Last modified: 2007-05-17 14:33:56 UTC
Please describe the problem: When viewing multiple images, only the first one is autorotated. It seems that when eog_image_autorotate is called (from eog_window_open in eog-window.c), the exif data is only loaded for the first image. This problem is related to bug 148400, where the autorotation feature was implemented. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Fixed in trunk, thanks! 2007-03-05 Lucas Rocha <lucasr@gnome.org> * libeog/eog-image-private.h, libeog/eog-image.c: schedule automatic orientation for all images in image list for future rotation (Fixes bug #390266).
I tested the latest version and noticed that only the main image is autorotated The thumbnails (in the image collection pane) are not autorotated. This is really confusing for the user. Only when the thumbnail cache (located in ~/.thumbnails) already contains rotated images (e.g created by an external application like gThumb), the thumbnails are shown correctly. And placing (unrotated) thumbnails in the cache makes gThumb (and probably other exif orientation aware viewers) display unrotated thumbnails. I see two possible solutions here: 1. Store normal (unrotated) thumbnails in the cache and rotate them for display. + Backwards compatible with non exif-aware viewers (e.g. nautilus thumbnails), because thumbnails have the same orientation as the image. - Slower display, because an extra transformation is required. (Well I'm not sure if the transformation slowdown is noticeable, because thumbnail images are very small. But you also need to read the exif orientation tag from the full image and that is maybe more problematic than the actual transform.) 2. Store autorotated thumbnails in the cache. + Fast display, because no extra transformation is required. - Non exif-aware viewers will still create normal (unrotated) thumbnails, resulting in the problems I described above. In an ideal world (where every image viewer is aware of the exif orientation tag), solution #2 would be the best. But unfortunately that is not the case and solution #1 is the best option for maximum compatibility. (gThumb and f-spot implement solution #2.) PS: I wanted to write a short comment only, but it turned out to be a more complex issue than I thought at first. Maybe this should go in a new bug?
Closely related: bug 428725 - Mike