GNOME Bugzilla – Bug 318828
Exif Orientation Tag Incorrectly Updated.
Last modified: 2006-10-03 14:22:30 UTC
When an image is rotated losslessly, the Exif Orientation tag is updated, which is not the correct behaviour. Normally, one rotates an image to make it match that tag. For example, if I take a vertical photograph and the tag is set to "top left", then when I rotate it 90-degrees, I am making that tag correct. Instead, gthumb rotates the image and changes the tag to "left bottom". Essentially, gthumb is specifying the tag to undo the transformation it just made. Fixing this will also allow for "auto-rotation for display only" to be implented, bug 120839. f-spot proves that it is impossible with the current orientation tag situation.
Created attachment 53442 [details] [review] Patch to fix. This patch simply removes the call to the function that applies a rotation to the tag. The function is left, since there are times when it could be used alone, for example, if the feature to rotate only the tag were implemented.
I agree that this patch is correct. An application can either rotate the stored image, or change the exif tag, but not both -- that defeats the whole purpose of the EXIF orientation tag. Paolo, could you please apply this patch? (Preferably to both the stable and unstable branch of gthumb since the current behavior is seriously wrong)
patch applied to HEAD and gnome-2-6 branches, thanks.
I'm sorry to reopen this bug but it is based on a big misunderstanding... when Pat in his original report say: >if I take a vertical photograph and the tag is set to "top left" we should understand that his camera do not contain an orientation captor. Because topleft is the default value when: - the image is well rotated - the camera do not have an orientation sensor applying this patch breaks more gthumb installation than it solves, since nowadays more and more users have camera with that orientation sensor. for those (new) cameras, rotating the image breaks the exif specs (exif orientation should reflect pixels orientation). the fun things in this is that it solve issues for old cameras ;) if you want to revert it back, the code is now in rotation-utils.c
I don't think there's any need to revert this change. Either gthumb should always set the orientation to Top Left after changing the data (which can be understood as "now the data is in the natural order") or it should change *only* the orientation metadata. See http://bugzilla.gnome.org/show_bug.cgi?id=120839 (mentionned here already) http://bugzilla.gnome.org/show_bug.cgi?id=172427 and http://bugzilla.gnome.org/show_bug.cgi?id=343867 for more info. I believe there is no need to reopen this report.
Isn't the proper solution for gthumb to use the exif rotation flag to calculate the proper rotation the photo should have. When you rotate the photo, only modify the exif rotate flag, and re-calculate the new orientation based upon the exif rotation flag. So, I agree with comment #4, and propose the following: 1) revert this patch 2) Implement proper use of the EXIF rotate flag 3) When user rotates a photo, then only update the exif rotation flag.Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but the maintainers need more information to fix the bug. Could you please answer the questions in the other report?
Comments #4 and #6: you're both smoking crack. The *entire* point of this operation in gThumb is to losslessly rotate the image so that I can open the result in eog, put it up on my website and display it properly in Firefox, or whatever. The problem was *caused* by people trying to update the Exif tag, which *breaks* operation like Comment #6 proposes, because it becomes a double-rotation. Comment #4: If you have a sensor, why would you want to rotate that tag? Is the sensor wrong? If it is, then it's as good as not having a sensor... In fact, I *don't care* if there is Exif in the image I'm rotating here. I simply want the image to actually rotate.
Thank you very much for your friendly comment. It really made me want to file more bugs/comments to GThumb. The root cause for this trouble report is that the picture was taken with a camera that did not update the EXIF rotate field with the proper rotation information. Therefore whenever you rotated the photo in GThumb, the photo was displayed wrongly in other applications that actually correctly used the EXIF tag. As you stated, sometimes you do want to rotate the actual photo it self, for whatever reasons, and then you either remove the EXIF fields, or ensure that the EXIF fields are still valid (which means the rotation field). If you read the spec for EXIF. It clearly states that the EXIF rotate tag tells you explicitly how to find the proper rotation of the photo. GThumb/Nautilus is still not checking this EXIF rotation tag in Dapper. So, if we should follow the EXIF standard we have two options. 1) Only change the EXIF field, and do not touch the picture it self. This should be the prefered way, since ALL applications should look at the exif rotate field and calculate the proper rotation of it. 2) Force set the EXIF rotate tag to top left every time the user rotates the photo. This method will ensure all applications (including those that ignores the rotation field) will display the photo correctly. Both these alternatives will ensure gthumb follows the EXIF standard, and any application can present the photo with the correct rotation based upon the EXIF rotate tag. The option to ignore updating the EXIF rotation field is the worst possible choice. All the users who has been using GThumb to check their photos and have rotated photos, now have photos with bad rotation fields. F-Spot and other applications who checks the Rotation field will not be able to display these photos in the correct manner. (F-Spot is now installed by default in Edgy) As a parences. F-Spot only modifes the Rotate field, when you do a rotation. But when you export the photo, you can choose to rotate the actual exported photo (and the EXIF flag will be modifed to indicate the proper rotation)
Bengt, I feel you're not considering the use cases. If I have a camera that sets the Orientation tag properly, why on earth would I want to rotate that tag? I wouldn't. I would only use this "lossless JPEG rotation dialog" for exactly that. Rotating the JPEG losslessly. I use gThumb for that, it's the only GUI application out there that does that. So: 1) Orientation incorrect: upon rotation of JPEG data, I am most likely to normalize to top-left by hand. I don't want the Orientation tag updated, and that's what this bug is about. 2) Orientation correct: I don't want to rotate the Orientation tag, it's set properly. In both cases, *I don't want to update the orientation tag.* If there is a feature request to have something to "fix" the orientation tag, that should be a seperate bug and feature. It should probably show a thumbnail of the image and ask to click on what is actually the top-left corner. That would be a decent interface. Still, that is orthogonal to what this bug fixed.
Pat, If the tag states Right Side Top (portrait mode I think) and the Photo is actually a horisontal photo. In GThumb today, you will see the tree sleeping instead of standing, and after you click on the rotate button, the tree is nicely standing. But now, the rotate field still states Right Side Top. BUT the Photo should not be rotated anymore, since GThumb rotated the actual photo. Which means that the EXIF field can not be used anymore, no matter if it was set correctly from the beginning. Also, if this is the norm, then we can never look at the EXIF rotate tag to calculate how the photo should be displayed. We can not know if we can use the exif rotate field or not. So, if you try to open this photo in any application that actually looks at the rotate field, you end up with a sleeping tree again. To repeat, the Exif Rotate tag has to change whenever the photo is rotated (but photo do not have to be rotated when you modify the exif rotate tag) If they are out of sync to start with (old, or malfunction camera), then it will be fixed by a) only rotating the exif tag, b) forcing the rotate tag to top left and rotate photo.
Pat, the exif metadata doesn't tell the orientation of the camera when you took the picture but rather how to interpret the data. That's why it's perfectly normal and desired to update the exif.
Listen guys, I'm not disputing the validity of modifying the Orientation tag. f-spot does this and does it well. This bug is about rotating both the image *and* the tag. My patch solves it, gThumb works properly now. The tool in question is designed for rotating JPEG data losslessly, with or without Exif information. As per comment #9, if an exif rotation tool is required, it should be a seperate tool. It should be the "main" rotation mode, like in f-spot. But this tool must remain as a seperate option. Sometimes people really want to actually rotate and image, believe it or not. And, once again, I point out that if the camera sets the tag properly, there is little chance that the user will want to rotate the image.
Sorry, I was under the impression that you were disputing it. And with tools like gthumb, there is actually one very obvious reason why the user might want to rotate the picture even though the exif is right and that is that gthumb doesn't use the metadata to properly display the picture in the first place. As for updating both image and tag, the fact is, if you want the picture to display the same in other tools as it does in gthumb, then the orientation tag has to be set to top left. Again, that's because gthumb doesn't use it to properly display the picture. As I've pointed out elsewhere, having gthumb use the metadata when displaying the picture would solve the problems. And I've just seen in http://bugzilla.gnome.org/show_bug.cgi?id=120839 that you seem to agree with that. So I guess we actually really agree on the whole thing and the discussion here is just a misunderstanding.
hmm... seems like we have a good missunderstanding here. Anyway, the root cause for this discussion, is the last sentence in comment #12. ""if the camera sets the tag properly, there is little chance that the user will want to rotate the image"" This is wrong: Why is it wrong? Since gthumb do not use the exif tag at all today, the the user will definitely rotate the picture (independent on if the rotate field is correct or not), and since this patch/bug ensures that the image is rotated, but not the exif tag, the combination is hencefort corrupt. GThumb is corrupt as it is now, and have corrupted a lot of photos for a lot of users. That is every time anyone have rotated his/hers photo, they have ensured that their exif rotate flag can not be used. no more comments from me on this. Thank you for your time.
I was under the impression that someone said that gThumb does show the images rotated according to the exif tag. Since it does not, then yes, the misalignment of tag rotation and display is an issue. But that is a seperate request. This bug was addressing a bug that caused programs that actually use the tag to display the image as double-rotated.
Hello, I'm a simple Gthumb user, i use it to rotate photos after importing them. I'm using the automatic lossless rotation tool for a while (i like it). In my current version 2.7.6 (dapper), Exif ration tags are no more updated to top-left at first rotation. And if i do twice automatic rotation, photos continue to rotate ... This is not normal, this bug is a regression from my point af view. As Bengt said, photos rotated with the lastest version of Gthumb had a corrupted exif rotation tag. So this bug is critical. I built a 2.7.8 and no changes, so i have built an old version 2.6.5 for dapper to used Gthumb normaly. Is there any chances to have a fixe on newer versions ? I do not think that this bug is addressed to programs that use the tag to display the image : it's a pretty genuine Gthumb bug.
Hm, thanks for posting Javier. Perhaps the correct fix to cover this is that if the JPEG data is actually rotated, the exif tag should be reset to top-left? Then, at some point in the future, there could also be a tool just for tag re-writing/rotation.
Yep Pat, if we do any lossless rotation on an image, the roation tag must be reseted to top-left. But if the tag is also to top-left, there is no reason to updated it again to any other value , i mean with the "Adjust photo orientation" check box on. And, Yes an other checkbox to confirm the exif update would be nice ;). But when i read "Adjust photo orientation". It means for me that the exif data would be updated if necessary. So if you add a checkbox, we must found a clear name for this new one and old: * Use JPEG data to find right orientation * Adjust jpeg data after rotate or something like that ?
I made a patch for this problem in bug 343867!
Jef: I agree with the patch in bug #343867. I won't reopen and mark as duplicate, though it really is. All of the work that has gone into that bug seems to supercede anything here. Simply put, resetting the Exif orientation to Top-Left solves the problem reported here initially, as well as the follow-up problems reported by others.