GNOME Bugzilla – Bug 148400
Auto rotate image using Exif information
Last modified: 2007-04-14 14:18:05 UTC
Gqview has a nice feature which is unfortunately hidden under the "Advanced" tab in it's Options. It's called "Auto rotate image using Exif information". When you turn it on, your photos will be automatically rotated using information stored in the Exif information. This means that if the camera was held vertically when you took the photo, you won't have to manually rotate the image when you view it. It would be nice if Eog supported this. It probably doesn't need a preference either; it should be safe to have it always on.
KDE's embedded image viewer has such a feature (always on) and Konqueror file manager also auto-rotates file thumbnails using that.
*** Bug 159326 has been marked as a duplicate of this bug. ***
The file format says how the image should be displayed. Makes sense to try and fully implement the file format specification (so I'm marking this as New) The slightly tricky part is deciding how to handle the knock on effects.
Valid feature request. We should implement this :)
Done. The attached patch adds the following: 1) eog_image_autorotate() - A function to detect orientation from the exif orientation flag and rotate the image accordingly, currently taking action only with "right-top" and "left-bottom" orientations (the camera tilted 90° either way) as those are the two I could detect with photos of my camera. My camera and one of my friends marks upside down the same as the "normal" orientation so I left it out, assuming this is a general way of digital cameras (which I think are the number one use-case for this). 2) A gconf key to toggle this behaviour - /apps/eog/view/autorotate, boolean 3) A call to the function in eog_window_open(), given that the key is set - seemed like the place this should be at, though I'm not 100% clear on the structure of eog 4) UI to toggle it in the preferences window - I grouped it with the interpolate checkbox and renamed the (information duplicating) title from "Image Interpolation" to "Image enhancements". The wording is not perfect, but I think it describes what is done, it "enhances" it to the correct orientation...ok, I confess, I just didn't come up with anything better. - I added a GUI because this is something that people could find annoying, after all it tells a little white lie about the orientation on disk. The GUI is easy to cut out of the patch though. For big images, the delay of opening the window will be larger, but it's already slow enough to warrant a loading indicator, so that is not considered in this patch. And I don't know what Alan means with "knock on effects" so the patch probably don't address those :)
Created attachment 50020 [details] [review] Patch to rotate images automatically according to exif information
is there still time to commit this fix ? We still have a few weeks before code freeze...
Hi Kalle, Vincent, etc: This is a great feature that I want to have in EOG, but unfortunately we just passed the feature and UI freeze (feature freeze happened Jul 13, UI freeze happened July 25...) so unfortunately it will have to wait until the next release to happen. I will certainly commit this patch as soon as the thaw for 2.13 happens. Thanks.
I didn't really expect it to be in time for 2.12, which probably is just a good thing as I 1) want to see it tested with pictures other than mine 2) want to get feedback on the UI change and whether this is something that even needs UI > I will certainly commit this patch as soon as the thaw for 2.13 happens. That's great, thanks! :)
Was there a problem with this patch or was it just forgotten? Hasn't been applied and was just wondering if there was a reason for it...
Hi Kalle, I'll apply it for 2.13.3.
Lucas, will this miss 2.14? I saw a .90 being released, does this mean there's no new features coming in before 2.14?
*** Bug 331347 has been marked as a duplicate of this bug. ***
Kalle, maybe you could try to send a patch without UI change ?
Created attachment 59825 [details] [review] Patch for autorotation without UI changes Sure, it's only matter of stripping the glade change and the eog-preferences.c code for it. The gconf value can be used to control it, but be warned that this feature should be OFF by default in my opinion if no UI is provided for it....
Do you know any real-world case where the EXIF orientation information would be wrong ? I wish it would be ON by default (there is another similar bug for nautilus that will hopefully get fixed too): http://bugzilla.gnome.org/show_bug.cgi?id=331348
(In reply to comment #16) > Do you know any real-world case where the EXIF orientation information would > be wrong ? Depends what you call wrong :) I imagine any non-exif-aware software that rotates it without updating the data would break this (dunno how well exif is considered in the graphical sw around so hard to say if that would be a real problem). It's not really eogs problem if the exif data is wrong though. But more troublesome than having wrong orientation is the fact that it's presenting to user something that is not real without him having a way to disable it. The orientation on disk differs from the one that eog would show. This has implications when previewing images for sending images with email for example. Automatically saving the rotated image has even more implications, as it is not always lossless operation.
*** Bug 355104 has been marked as a duplicate of this bug. ***
> I imagine any non-exif-aware software that > rotates it without updating the data would break this So isn't that OK as long as we show some text saying "This image was automatically rotated before using the information in the file." with a button saying [Show Original] that will show the unrotated version. > It's not really eogs problem if the exif data is wrong though. I also agree with this.
I don't think there is any need to display a warning. You could consider the EXIF spec as an update to the JPEG spec (or JFIF if you care about these details). EXIF images include an Orientation tag because it is easier for many cameras to flip a single bit than to transpose all pixels in the images. But for all intents and purposes, the image is supposed to be automatically rotated when it is loaded - no questions asked, no warnings. In fact, the automatic rotation according to the EXIF Orientation tag should even be a feature of libjpeg: the application (eog, gimp or others) should not have to care about how the pixels are stored internally. The application should only care about how the image is supposed to be rendered, and this includes the automatic rotation if the EXIF tag says so. Some file formats allow scanlines to be stored in bottom-up or top-down order. Others allow pixels to be stored in R,G,B or B,G,R order. Yet they are all rendered in the same way. The fact that EXIF has been standardized more recently (only 8 years ago) should not be an excuse to annoy or confuse the user with warnings that are only relevant for applications that do not support EXIF correctly.
Raphael, maybe that would work in an ideal world. But in the real world, we have to deal with systems that don't always do the right thing. We should be liberal in what we accept.
Of course we should be liberal in what we accept. That's not the point here. I'm just pointing out that the EXIF spec says that the image should be rotated when rendered, so there is no point to warn the user about the fact that the application is basically following the spec.
gThumb has similar issues, see bug 343867. Also Nautilus thumbnailing is unaware of the exif orientation tag, see bug 335053. I would be nice if all these applications could be updated (and ideally share the same code)!
Created attachment 73961 [details] [review] Stab three at automatic orientation Here is a version that has a bit more sensible way of doing the same thing. This one has both the configuration dialog setting and a button to indicate and toggle automatic orientation status in the toolbar. Though perhaps a button in the statusbar (like web browsers tend to have) would be a bit more suttle, given the very good point made in comment 26. The problems in this patch begin when another transformation is applied, after that the button won't work correctly. The current transformation angle needs to be tracked, I guess simply having a private field and updating it in eog_image_transform() should be enough. Then get_angle_to_exif_rotation() could calculate it relative to that of that and everything would be peachy.
(In reply to comment #24) > This one has both the configuration dialog setting and a button to indicate and > toggle automatic orientation status in the toolbar. Though perhaps a button in > the statusbar (like web browsers tend to have) would be a bit more suttle, > given the very good point made in comment 26. Uh, unless proven otherwise by the next commenter, I did mean comment 20 :)
(In reply to comment #24) > Stab three at automatic orientation I tested you patch and found two problems: 1. 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. 2. The exif orientation tag can have 8 possible values. Your patch only recognizes three of them. Fixing number 2 is not very difficult (I have an almost working patch), but I have no idea for number 1.
Created attachment 75771 [details] [review] Autorotation with support for all 8 possible exif orientation values * libeog/eog-transform.[ch]: Added all 8 possible exif orientation values to EogTransformType and added/updated functions to support the new values. I also added a function to map exif orientation values to the correct transform type. * libeog/eog-image.[ch]: Updated/renamed the eog_image_autorotate and eog_image_get_exif_orientation functions. * shell/eog-window.c: Updated the verb_RotateExif_cb function.
Created attachment 75773 [details] [review] Autorotation with support for all 8 possible exif orientation values Corrected a small typo.
The wiki http://live.gnome.org/EyeOfGnome/EogNg says that auto rotate should be standard in eog but as a plugin. In my opinion it should be by default in Eog and not as a plugin because: 1. It's a very handy feature that more and more users expect to work out of the box, because more and more cameras support this feature as well 2. Plugins are nice for computer savvy people, but an average user will not (be able to) install the plugins 2. It won't need any user interface. It can be done just automatically. In case an image has incorrect EXIF data (because of a non-compliant EXIF program) the user just rotates the image and when he saves it eog makes sure that the EXIF data is correct.
Moving to 2.17. Increasing priority.
Patch (attachment #75773 [details]) commited in HEAD, thanks! Related toolbar and menu entries removed: end-users doesn't have a clue of what EXIF is. For now, let's stay ony with the simple preference option. Please, report any possible problem related to this feature on separate bug reports. 2006-12-18 Lucas Rocha <lucasr@gnome.org> Support for image auto-rotation based on EXIF orientation (Fixes bug #148400). Patch from Kalle Vahlman <zuh@iki.fi> and Jef Driesen <jefdriesen@hotmail.com> * eog.glade: new check box for image auto orientation. * libeog/eog-config-keys.h, eog.schemas.in: new /apps/eog/view/autorotate gconf key. * libeog/eog-image.[ch]: new eog_image_autorotate () method. * libeog/eog-transform.[ch]: auto-rotation support. * shell/eog-window.c: queue autorotation on image list initialization.
Created attachment 78976 [details] [review] Small improvement for reading the exif orientation tag I reported bug 390266 on the issue I described in comment 26. In the meantime, I have a small improvement for the eog_image_get_exif_orientation function. There is no need to 'navigate' (e.g. the e->parent->parent) from the ExifEntry to the ExifData structure to obtain the ExifByteOrder. This removes the need to know the internals of the libexif library. I added the patch to this bug, because I thought was a little overkill to create a new bug.
*** Bug 429606 has been marked as a duplicate of this bug. ***